Making a plugun "un-disableable" for anyone but a site administrator

Hi there, community!

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?

Kinds regards,
Jesper.

As I know, in OJS 3 by default plugin’s tab isn’t available for journal editors and other staff.

Hi @jesperlauridsen,

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

1 Like

Hmm. And for what roles plugin’s tab is available by default?

Hi @Vitaliy,

The Site Administrator alone has access to the site-wide Plugins area. (This is only visible when more than one journal exists.)

The Site Administrator, Journal Manager, Journal Editor, and Production Editor (by default) have access to the journal-specific Plugins area.

Regards,
Alec Smecher
Public Knowledge Project Team

1 Like

Hi @asmecher,

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 :wink: 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.

Kind regards,
Jesper.

Hi @jesperlauridsen,

Yes, you’d add the function to your plugin’s class, overriding the default implementation in a parent class.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher,

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.

Hi @jesperlauridsen,

Did you also use the isSitePlugin function?

Regards,
Alec Smecher
Public Knowledge Project Team

1 Like

Hi @asmecher,

I did, but removed it again, since it seems it makes the plugin only work on the mothersite, and not any of the journals it is hosting. Is that wrong?

Kind regards,
Jesper.

Hi @asmecher,

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,

Kind regards,
Jesper.

Hi @jesperlauridsen,

Are you willing/able to post the plugin in Github? It’s much easier to debug what might be happening with some practical code to look at.

Regards,
Alec Smecher
Public Knowledge Project Team

1 Like

Hi @asmecher,

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.

Kind regards,
Jesper.

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:

function getCanEnable() {
if(array_intersect(array(ROLE_ID_SITE_ADMIN), (array)$userRoles)) {
return true;
}
else {
return false;
}
}

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.

Kind regards,
Jesper.

Hi @jesperlauridsen,

Yes, $userRoles is not defined in the context your code is executing in. You can use this shorthand to check whether a user is a site administrator:

if (Validation::isSiteAdmin()) {
    ...
}

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher,

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.

Kind regards,
Jesper.

Hi @jesperlauridsen,

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

php lib/pkp/tools/installPluginVersion.php path/to/my/plugin's/version.xml

Ensure that your version.xml's <application> element corresponds to the path in plugins/generic that the code lives in.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher,

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?

Kind regards,
Jesper.

Hi @jesperlauridsen,

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

Hi @asmecher,

Again, sorry for the (very) delayed response - I’ve been on holiday.

my version.xml looks as follows:
< version>
< application>RDLCookiePolicy< /application>
< type>plugins.generic< /type>
< release>1.0.0.0< /release>
< date>2017-02-03< /date>
< lazy-load>1< /lazy-load>
< class>RDLCookiePolicyPlugin< /class>
< /version>

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.

Kind regards,
Jesper.