We have three instances of OJS. Let’s call them dev, test and stage.
All three instances run on virtual hosts on the same CentOS machine, under php 7.3.28
All three instances are 3.3.0.6 (stage is a fresh install, while dev and test were updated from 3.2.1 and 3.3.0.5)
Our theme plugin is a child of the default theme, and was created and tested on dev, then the plugin directory was copied to test and stage, making sure to preserve the directory name and context (ownership, permissions, SELinux parameters, etc)
The plugin works as expected on instance test.
However, on instance stage, and only on that one, the plugin appears in the plugins tab, can be activated (with popup confirmation), but fails to appear in the dropdown menu of the Appearance tab.
Refreshing the page and clearing the templace cache have no effect.
Apache and PHP logs throw no errors whatsoever.
The plugin does not use any absolute paths (which would prevent it to work on the test instance anyway).
Reinstalling OJS from scratch and repeating all of the above steps had no effect.
At this point, I suspect a low level, non-OJS related problem – but I really can’t put my finger on it.
Was the plugin actually installed on all of the machines? Copying the directory over will not necessarily actually install the plugin - it won’t create the records in the plugin_settings and versions tables.
I ran that tool as suggested, with no effect. Then I had a look at version.xml and realized the application tag had to match the directory name, so I changed it and ran the script a second time. Again, no effect.
That’s one of the puzzling things: I didn’t run that script on test either, and yet it worked.
One other question, then. What about directory permissions? Can the webserver user for stage read the directory?
Also, is the theme plugin enabled (checked off) on the Plugins tab, down in the installed themes? If it’s not checked off there, it won’t appear in the dropdown in the Appearance area.
I tried several approaches (recursive chown and chmod, and cp -pr --preserve=context) and double checked (manually and with diff) the permissions and ownerships of directories and files, and used the very same commands on both test and stage. If something was wrong at that level, the plugin wouldn’t even appear in the plugins tab.
And yes, I triple, quadruple checked that the plugin was indeed enabled in the plugins tab. I also created a few journals and had a look at their specific appearance/plugin parameters, and the behaviour was the same.
I guess the next step is to erase entirely the directory structure and database of stage, and replace them with dev contents to make sure whether the problem is OJS or server related.
Have you looked in the database? Maybe verify that the settings for the plugin in the versions and plugin_settings tables are the same across your installations.
Are the permissions correct on the cache directory (and sub directories)? I suppose that it’s possible that the plugin registry has some stale content in the directory on the stage server. Maybe clean it out via the link in the Administration page?
Ok… this is going to sound silly (and probably it is) but, after enable the plugin, did you try to clear your browser cache?
I found similar issue when I enable the them but I didn’t refresh the page.
Second stupid suggestion (yes, today I’m on fire)… if this is a child theme, is the parent theme enabled?
Anyway, if you want to be sure ojs is taking the plugin, do what Jason is telling you and check it in the DB.
@marc I cleaned the cache several times, I would say compulsively, and made sure the permissions were ok on the cache directory structure – Apache would have logged 403’s anyway. And yes, the parent theme is enabled in all instances.
@jnugent Could it be a problem with the plugins class names?
Oh, what a mess…
That being said, the plugins have the same class names on both test and stage db, and yet it works on test.
Oooh, wait, though - what’s that other one on TEST? theme-uqam (ThemeUQUAMPlugin). It doesn’t appear on the other ones. Or is it on DEV but just not included in your list? Can you confirm the actual class name in the plugin’s main class file?
@jnugent theme-uqam is an older version of the plugin, and was removed from /plugin/themes when we decided to recode the whole thing, a few weeks ago. It never was installed on any of the two other instances.
I grepped the word class in the root of the three plugins, with identical results:
plugins/themes/uqam-child/UqamChildThemePlugin.inc.php: * @class UqamChildThemePlugin
plugins/themes/uqam-child/UqamChildThemePlugin.inc.php:import('lib.pkp.classes.plugins.ThemePlugin');
plugins/themes/uqam-child/UqamChildThemePlugin.inc.php:class UqamChildThemePlugin extends ThemePlugin
plugins/themes/uqam-child/version.xml: <!-- The class name of the plugin. See index.php -->
plugins/themes/uqam-child/version.xml: <class>DefaultChildThemePlugin</class>
Breaking news: while having a new look at the test instance, I discovered that while the plugin appears to work in the main site parameters panel, it does not in the individual journals parameter panel.
Looks like there’s something rotten in the database. Is there a method to flush it all up, and reinstall the child plugin from scratch?
There’s not so much an easy way to flesh it all out, but:
The <class> element in your versions.xml file should exactly match the class name in your PHP file. You appear to have a mismatch (DefaultChildThemePlugin in the XML versus UqamChildThemePlugin in the PHP file)
You can just delete the records in the versions and plugin_settings table for, well, all of your UQuam themes and then reinstall using the command line tool.
