Activate/Deactivate Plugins Per Page?

Archive
1

I’ve gotten a simple little plug-in working called Getter. In getter.yaml I can put enabled: true or enabled: false and the get expected behavior.

But using either true or false in the page front matter like getter: false will not turn the plug-in off for that page if it’s on in `getter.yaml’ nor the other way around.

So I’m doing it wrong. How do I make my plug-in respect the page header configuration options?

2

Bob, you just need to provide the logic to merge the plugin defaults that are available via the plugin .yaml and the page headers. You can see plenty of examples of this in the various plugins we have but here is a specific example:

You will need to do something similar in order to get page header specific options that can override defaults.

3

I tried this:

public function onPluginsInitialized()
{
	if ($this->isAdmin()) {
		$this->active = false;
		return;
	}

	$defaults = (array) $this->config->get('plugins.getter');

	$page = $this->grav['page'];
	if (isset($page->header()->getter)) {
		$this->config->set('plugins.getter', array_merge($defaults, $page->header()->getter));
	}
	if ($this->config->get('plugins.getter.enabled')) {
		$this->enable([
			'onTwigSiteVariables' => ['onTwigSiteVariables', 0]
			]);
	} 
}

but couldn’t get that to go.

4

Well that looks correct. After this event you should have your default configuration merged with your page header configuration so for example on your page you can override the defaults with something like:

getter:
   enabled: false

This would override the default configuration, but you still need to have logic that uses it. Your code above is only enabling the onTwigSiteVariables event if this enabled flag is true.

Note, you can enable the plugin in the yaml and then disable it per-page. However, you cannot, have enabled false, and enable per page this way because if the plugin is disabled in yaml, it is not loaded at all, so it never even gets to this onPluginsInitialized method to merge config options.

5

Regarding your last point, this can also not be the desired behaviour.
Lets take for example the highlight plugin.
Now on every page which does not have any code highlighted, I have to put in the header:
highlight:
enabled: false

Otherwise I serve on every page the highlight js and css…
Who should be responsible for this mess, grav or should the plugin offer some option?

6

@zack-s To be honest it has to be implemented in the plugin. Usually out-of-the-box the enabled option is designed to disable or enable the plugin completely. In a later version it got enhanced to disable a plugin per page (but this has to be implemented in the plugin of course).

The other way (globally disabled and enabled on some pages) needs a second option.

In my plugins I’m using a process option in order to do that. But again the plugin has to implement the functionality. If you think Highlight plugin needs such a behaviour the best is to open an issue here https://github.com/getgrav/grav-plugin-highlight/issues or even better provide a pull request https://github.com/getgrav/grav-plugin-highlight/pulls .

If you have a better idea solving this from within Grav, please let us know! :smiley: At the time the plugins are loaded, there is no access to any page and if we try to do it better, there is probably a performance penalty we (surely) don’t want to have…

7

The plugin can offer the option to read the page header and depending on a setting, enable its functionality or not. This can be done on the onPageInitialized event, but it’s a plugin decision to implement this or not, depending on its goal