My plugin settings modal window does not close

Software Support
1

I work on the new reviewqualitycollector plugin in the OJS 3.1.2 codebase.
It has a plugin settings dialog consisting of an AjaxModal with a form in it that is based on my own Form class, which gets/sets two fields in the database.
I get this behavior:

  • The modal opens correctly.
  • The form shows correctly.
  • There are two buttons on it: OK and Cancel.
  • Cancel works correctly (the modal closes).
  • OK saves the form values correctly, but does not close the modal.

What do I need to tell the framework where in order to make the dialog close itself?

Bonus questions:
When I last worked on my code months ago (then based on OJS master, not a release), my dialog already worked completely (including the closing). I had to correct a lot of things in my code to get it working again even as described above. Many things appear to have become less lenient in OJS.
Is there any place to read up a list of what these might be?
The release notes only talk about ‘features’ and ‘fixes’, not relevant internal changes – and my code is not in the public codebase yet.
Any advice in this respect?

2

Hi @prechelt,

We could definitely get better at documenting changes that are needed to upgrade e.g. third-party plugins. I’ll try to track this better.

One good way to identify these changes is to look at how one of the “official” plugins evolves between releases. We generally try to avoid breaking changes but it’s not always possible. For example, here are the changes to the Static Pages plugin between OJS 3.1.1 and OJS 3.1.2:

In particular, based on your description, make sure that the commits referring to JSON response types are reflected in your plugin. The software has gotten pickier about how server responses identify their content types (e.g. JSON vs. HTML).

Regards,
Alec Smecher
Public Knowledge Project Team

3

Hi @asmecher,
thanks, that was helpful wrt the bonus questions.
What about the main one: making the modal dialog close?

I did my best to align my code with the plugin-related developer docs and am stumped as to what to try or do now to make my modal close itself after OK was clicked.

4

Hi @prechelt,

Did the JSON response type changes have any effect? Make sure that the response to the Save operation specifies that it’s a JSON response in its headers. A failure to do that could well account for the modal not closing.

Regards,
Alec Smecher
Public Knowledge Project Team

5

My code returns a JSONMessage object and the framework then correctly sets the headers.

So that’s not the problem, unfortunately. But thank you for the hint!

Lutz

6

Hi @prechelt,

Does your form have an AjaxFormHandler (or a subclass of that) attached to it? We’re getting into territory where it might be helpful to be able to see the code.

Regards,
Alec Smecher
Public Knowledge Project Team

7

Hi @asmecher,

sure, here you go:

The code to open a settings dialog was written with nearly no understanding of how it works, by mere imitation of other plugins (OpenAIRE and Browse, if I remember correctly).

Question: Could I submit all this to OJS master soonish although it’s far from complete and usable? The pain to get my previously-working code working again on stable-3_1_2 was unbelievable and I could well do without another round of that.

Lutz

8

Hi @prechelt,

To fix the save function, off the top of my head, you’ll need to remove the $form->fetch call from the manage function in the case where the form was successfully saved. It should just be a return new JSONMessage(true);

Could I submit all this to OJS master soonish although it’s far from complete and usable?

We’re trying to reduce the number of plugins shipped with OJS in favour of keeping them in their own repository, even commonly-used “officially-maintained” plugins. See e.g. GitHub - pkp/staticPages: Plugin permitting the creation of static pages like a CMS (OJS 3.0+ and OMP 1.1.1+), GitHub - pkp/customBlockManager: Plugin permitting the creation of custom sidebar blocks, and GitHub - pkp/customHeader: Custom header plugin for OJS/OMP 3.x. This keeps the amount of clutter down in the main repository, and decentralizes the management of the software.

So I’m afraid we’d be unlikely to add more plugins to the OJS repo – but one option, if you’re worried about regressions, would be to make use of the automated plugin testing tools we’ve been working with lately. See e.g. .travisrc and tests/ in the repositories linked above; you can see the results at e.g. https://travis-ci.org/pkp/staticPages.

I’ll try to maintain better upgrade documentation to decrease future surprises around plugin maintenance, and will note that the 3.1.1 to 3.1.2 upgrade introduced more breaking changes than we will normally do, for various reasons.

Regards,
Alec Smecher
Public Knowledge Project Team

9

Hi @asmecher,

you wrote

you’ll need to remove the $form->fetch call

Yes, that did the job. Thank you dearly.