Hello,
I'd like to write a plugin for Moodle that adds some custom JS/HTML to every single moodle page on my site. Having looked through the list of plugin types, it looks like the "Local Plugin" type is what I need, but it says that "Local plugins are used in cases when no standard plugin fits" so I just want to check this is the correct course to be taking.
Looking forward to honing my development skills and hopefully helping and contributing in turn in the future!
As far as I know, the only "right" way to do the kind of thing you're talking about is using a Theme, overriding one of the core renders that's used on every page like footer(). It's possible to do with other plugin types, but hacky. In this case, a local plugin is as good a choice as any.
Would this not mean that no one could use my plugin if they wanted a visual theme for their VLE? Or can multiple themes be applied to the entire site at once (I know a second theme can be applied to a single course)
Basically, you're right. It is possible for themes to inherit from each other, so it could be possible for someone to build a theme based on yours, but if they want to use a different 3rd-party theme it's trickier.
It will help to hear more about the intended features. I saw some local plugins trying to inject HTML/JS into every page by having such code in the global scope of lib.php and hacks like that. It often has side effects - e.g. CLI scripts and AJAX response break etc.
In one particular case, it turned out that what those guys actually needed, was a block. Blocks can exist on almost all pages in Moodle even if they are not actually displayed as blocks. They have opportunity to inject into the page nicely and cleanly. They can be aware of the page context and customise things according to that.
Typical use case is a contact form, 24/7 live support chat window and things like that.
Blocks can exist on almost all pages in Moodle even if they are not actually displayed as blocks.
I have developed a couple of blocks, but I have very little knowledge of how they're actually used on Moodle sites. Can you elaborate what you mean by "not actually displayed as blocks"?
I meant that the block's get_content() method can return empty content so the block is not displayed at all. Even if it exists on the page. And it still has a chance to inject and execute the javascript via $this->page->requires which in turn can modify HTML etc. Such a block can be configured to appear across the whole site. As a result, you can embed your JS into almost every page in Moodle.
I've written a Chrome extension that adds a local floating admin UI to Moodle when viewed on my computer. It does everything from offer link shortcuts I use a lot as an administrator, to listing recently visited course pages, to automating repetitive tasks and scraping data from the page.
It's entirely JS based but I and my university are interested in developing this is a proper plugin we can share with other Moodle users. I've found is really increases the productivity of myself and the other Learning Technologists in my team.
One of the goals of my little UI was to not touch the page layout at all (hence a floating UI) so that when testing the site during upgrades or theme changes, we know it's not going to skew the effect as seen by someone not using the extension. Unlike a block, it is also fixed to the corner of the screen so no scrolling to access it!
I have a lot of experience with PHP, JS etc but am only 6 months into my job here working with Moodle so I appreciate the help understanding how to correctly integrate to it.
Blocks and other plugins can have their own style.css file and if you prefix all of the styles with one id or class that wraps your entire content, then it would only be overridden by a theme if the theme designer specifically targets it.
The problem comes if you are trying to get your block/plugin to override theme css after the theme has been added, simply because that's not how the css inheritance works (core -> plugins -> themes).
It sounds like you might need a local plugin - and you may want to look at adminer. That has a kind of floating UI for database management and has its own self contained css, so may be a useful starting point.
Richard
See my other post where I describe how to use the block get_content() and simply use the block as a widget to execute your JS.
Interesting!
Richard, how do you expect coding this as a block instead of a local plugin would affect the behaviour and usability?
(I've written a block before, so the temptation to go with what I know is high! Local plugins look like they have a lot more files associated with them that I would have to learn how to create)
Blocks need to be put on the page, or someone to add them as a 'sticky' block across the site.
Adding the functionality to a local plugin should remove that requirement as it would always be available in the same way as something like adminer. That said, it may be that you want this to float over the current page (adminer does open its own in the background) in which case maybe a block is better.
To be perfectly honest, where you have written blocks before, I have written quite a few themes, so I would have been tempted to build this functionality into a theme - but again, if your institution needs to use multiple themes, that may not be appropriate either
As far as I can tell, the need to add the block to the page(s) is the only way it would affect behaviour/usability that I can think of and that could be an advantage in terms of controlling where it appears (or doesn't). But the suggestion really came from having just been using adminer this morning and knowing that that has a kind of 'floating UI' and is installed as a local plugin
R
