Add a CSS to block plugin in 3.2.0-1

Software Support
1

Hi there,

I’m trying to make a custom block plugin for OJS 3.2.0-1, but I’ve encountered a problem with adding a stylesheet to this plugin.

Usually I would do something like this:

  function displayCallback($hookName, $params) {
    $template = $params[1];
    $templateMgr = $params[0];
    $request = PKPApplication::get()->getRequest();
    $templateMgr->addStylesheet('languageFlags', $request->getBaseUrl() . DIRECTORY_SEPARATOR . $this->getPluginPath() . DIRECTORY_SEPARATOR . 'css' . DIRECTORY_SEPARATOR . 'languageFlags.css');

return false;
}

But it only works with generic plugins, not with block plugins. So I guess, something has changed there? Could you recommend a plugin where I can see how it is done, now?

Kind regards
Daniela

2

Hello again,

I’m still working on this problem and I think it might be a problem with this line:

HookRegistry::register(‘TemplateManager::display’, array($this, ‘displayCallback’));

I have the impression the function isn’t called properly in the block plugins. Nothing what happens in there works in my installation (in generic plugins it works, unless it behaves like a block plugin). Does anyone noticed something similar?

Kind regards
Daniela

1 Like
3

Hi @UBWolf,

I suspect you’re running into differences in how plugins are loaded depending on their categories. The generic plugin category is loaded the earliest in handling a request; others are loaded later, or not at all depending on what the user is doing and what kind of plugin it is.

In the case of block plugins, these are loaded in lib/pkp/classes/template/PKPTemplateManager.inc.php in the displaySidebar function:

$plugins = PluginRegistry::loadCategory('blocks', true);

The displaySidebar function is attached to the Templates::Common::Sidebar hook, which is called from the lib/pkp/templates/frontend/components/footer.tpl template (or equivalent, if using a theme that overrides it). So the block plugins will only be able to react to hooks that are called after that template is prepared for sending to the user – which will be pretty late in the request lifecycle.

Regards,
Alec Smecher
Public Knowledge Project Team

4

Hi @asmecher,

this sound very comprehensible. Has the loading order been changed after 3.1.2? With the old OJS version it worked, so I think something must have been changed.

Kind regards
Daniela

5

Hi @UBWolf,

I’m not aware of anything that’s changed related to this since OJS 3.1.2. I’d suggest double-checking the versions table to make sure your plugin’s entry is accurate – if it isn’t, that can sometimes cause problems with hook registration.

Regards,
Alec Smecher
Public Knowledge Project Team

6

Hi all,

We are in the process of migrating from version 3.1.2 to 3.2.0 and I see the same problem in all the block plugins developed by us.

I confirm @UBWolf issue: this has changed after updating. The call to the register function of any block plugin occurs after calling to hooks such as “TemplateManager::display” or “LoadHandler” have been triggered.

This makes impossible to add additional CSS or other behaviors, such as defining endpoints to display additional information pages or even defining configuration options for a plugin in the plugin manager.

With generic plugins everything works as expected, but I think it is impossible to define a block plugin in the generic category.

I think this makes programming block plugins too simple and impossible to customize beyond trivial behavior.

Regards,
Juan Maiquez

7

Hi all,

Could one of you put together a concise example that shows the different behaviour? I’d have to explore locally based on that.

Regards,
Alec Smecher
Public Knowledge Project Team

8

Hello @asmecher,

I have created a simple example plugin from scratch to test the problem:

As you can see, it has a register function that registers two hooks as an example: ‘TemplateManager::display’ and ‘LoadHandler’, although I suspect there will be many more affected. I have only implemented one of them, but I think this will be enough to test its operation even if it had no implementation.

Using xdebug I have put a breakpoint in the register function and two others in the following points of my OJS installation:

lib/pkp/classes/template/PKPTemplateManager.inc.php:889
lib/pkp/classes/core/PKPPageRouter.inc.php:187

I’ve tested it both on the front of a single journal and on the front of my multi-journal site.

The result is that, due to the characteristics of the block type plugin, these hooks have no effect when registering after the launch of the hooks.

I can assure you that this worked in our old OJS 3.1.2 installation. To test it in an installation with version 3.1.2 you would only have to uncomment/comment lines 23 and 24 of the plugin code.

I hope this helps. Thank you!

Regards,
Juan Maiquez

EDIT: I am testing this on OJS version 3.2.0-2.

9

Hi all,

I think I have a workaround based on the customBlockManager plugin code.

As I said previously:

With generic plugins everything works as expected, but I think it is impossible to define a block plugin in the generic category.

But if a block type plugin is created and registered indirectly, through a plugin of the generic category, everything works correctly.

I have published a functional example code here:

I hope this can help someone.

Regards,
Juan Maiquez

10

Hi all,

I’ve opened an issue: Hooks aren't being called from block plugins · Issue #5892 · pkp/pkp-lib · GitHub