I was wondering if there is a way to make a plugin “undisableable” - so only a site administrator can enable/disable it, and everyone else cant? I can see some plugins have the checkbox greyed out in the plugin interface, and cant be disabled. Is this done in the settings of the plugin, and if yes, how?
This will involve coding changes – but very short ones. I’d suggest having a look at the getCanDisable and isSitePlugin functions in lib/pkp/classes/plugins/Plugin.inc.php. The first affects whether the plugin’s “enable/disable” checkbox is available and it’s probably the most relevant; you might consider having it return a value depending on whether the user is a site administrator.
Regards,
Alec Smecher
Public Knowledge Project Team
Thanks, this looks like something I could use. Is this a function I should add in the plugin.php.inc for the specific plugin I do not want people to be able to disable? I’m still not completely familiar with the way the entire Open Journal System works I have a fully functional plugin, that I’ve made, that I simply do not want anyone to disable, not on the overall site, or any of the journals below.
The functions you mentioned worked perfectly for that they say they do. However, I encountered one small problem. If I’ve uploaded the plugin on the main site, and set the getEnabled() to true like below,
function getEnabled() {
return true;
}
the plugin is set on the main site (probably because it already initiated since it has been uploaded before), but any new journals does not have the plugin enabled, even though the checkbox is ticked off. Do you have any idea how to fix this? I assume it has something do to with it not being properly initiated (like when you upload a plugin straight into the folder and have to run the lib/pkp/tools/installPluginVersion.php) I would like to make sure this plugin is enabled and active on any new journal being created in the system.
Tiny update - when i set isSitePlugin() to true, the plugin is checked off on the journals admin plugin interface, but does not show up on the actual journal website. This also prevents me from checking it off again. I can’t really figure out why at the moment,
I guess the .inc.php main file is the one you’re interested in looking at? Or is it the whole plugin? I put the .inc.php main file up at gist here Main file for CookiePolicy plugin · GitHub - There really is not much else apart from the locale file, the .js and .css file I add to the template and the index file that includes the same as all other plugins.
As an added note for you, @asmecher, I’m trying to restrict the plugin only to be disabled by a site administrator. I thought i could do this with the following piece of code:
However, this gets me a undefined variable warning in the php, suggesting $userRoles is not defined. Is there another way to check if the user is a site administrator? I had trouble fiding anything about user roles in the official documentation.
Thanks, that worked like a charm regarding limiting who can enable and disable the module. I still havent gotten the plugin to load on both main site and all the journals, with the
function isSitePlugin() {
return true;
}
This sets the checkbox in the plug-in management tab, but does not load the plugin. I posted the .inc.php main file in a gist in a post above, if you at some point have time to look at it.
If your plugin seems to be fine in the administration/setup area but isn’t behaving as you’d expect in the rest of the site, check to make sure it’s registered properly with OJS. You’ll need to install it into the versions table, either by uploading it into the plugin installer, or (since you’re writing it from scratch) running
Sorry for the delayed response, I’ve been a little hung up on another project. What does it mean when you say:
“Ensure that your version.xml’s element corresponds to the path in plugins/generic that the code lives in.”
At the moment, in my , I’ve only written the plugins name, does that need to be a path? And if so, from what point? Should it just say “plugins/generic/modulename”? If so, that might be the problem?
Where is your plugin installed, and what’s in the <application> element in your plugin’s version.xml? Do you see an entry for your plugin in the versions table in the database, and if so, how does it read?
Regards,
Alec Smecher
Public Knowledge Project Team
Don’t mind the formatting, the editor on the forum accepts the tags as real tags and remove them without the spaces.
the plugin is installed at /plugins/generic/RDLCookiePolicy, and seems to be loading and working as expected when I remove the IsSitePlugin() command. I haven’t been able to look into the database. I’m not even sure I got access to do that, but I could try to look at that, if you could tell me how.
All I’m really looking for now, is a way to ensure that if a new journal is created, the plugin is activated upon creation, just as the Dublin Core 1.1 meta-data plugin is, or the language toggle block.