Our Joomla template releases often implement additional features that may require that specific text strings are replaced with HTML code, much like the coding trick discussed in the first Joomla tips article on enhanced module syntax. It’s widely accepted that this kind of action should be handled by Joomla! plugins, however in my opinion if the application is relatively simple it doesn’t make sense to create a dedicated plugin. Instead, we can use alternative, lighter solutions available in Joomla that I like to think of as “plugins without plugins”.
When should the “plugins without plugins” approach be used?
This method isn’t a be all and end all option that supercedes plugins; instead, think of it as a way of lightening the load on your template’s users when the added features are small and simple enough to make creating a separate plugin seem like overkill! A good way of discerning if you should use this approach with one of your features is to examine the following points; if one or more of these fit the description of your proposed plugin, then the “plugins without plugins” method we’ll cover later in this article might be for you:
- The function we want to implement is tied closely to the specific template’s functionality.
- Implementation of the feature does not require additional configuration options, or the there are few such option (1-3 parameters max).
- The user experience will be improved if the options associated with the function are included within the template options.
- We need to modify the live template code to, for example, remove from the resultant page code elements that can’t be deleted via other methods i.e. overwriting page elements in the template.
- Our feature does not rely on the results of other installed plugins to perform its function (if it does then it can cause an issue due to the order of code execution).
The core “plugins without plugins” method
Implementing the idea of plugins without plugins is very simple; we take advantage of the featureset offered by the JEventDispatcher class, through which we can add support for events generated by Joomla’s code to the template code. The most common event in this case is onAfterRender, which is called when the result of the page’s code is completely generated and ready to be sent to the user browser.
This event is the best moment to have access to your generated code pages, since they include all the main elements including a full <head> section of your site.
An example of this method’s implementation
To show you this concept in action, here’s a simple code sample that works as a plugin at the template level, replacing all strings of ABC with XYZ:
$dispatcher = JEventDispatcher::getInstance();
$dispatcher->register('onAfterRender', 'CustomParser');
function CustomParser(){
$body = JResponse::getBody();
$body = str_replace('ABC', 'XYZ', $body);
JResponse::setBody($body);
}
How does this code work? Here’s a brief breakdown:
- First, we create an object containing an instance of the JEventDispatcher class.
- We then add an instance of our own CustomParser function to the onAfterRender event.
- With the function registered with the onAfterRender event, we then create the function itself; beginning by pulling the content of the buffer (which includes the HTML code of the website that’s going to be displayed).
- Using the str_replace function, we modify the buffer content stored in the $body variable, replacing instances of ABC with XYZ.
- With the changes to $body completed, we then save the modified content back into the buffer, ready to be sent to the browser.
Of course, this example is very easy, but the possibilities this method opens up are virtually unlimited thanks to the availability of more complex functions such as preg_replace.
Important things to remember
As you may already have noticed, there are some advantages that we gain when using plugins over this method, such as:
- Plugins allow us to use the code multiple times across multiple template.
- Plugins allow us to update code fragments independently from the rest of the template code.
- Plugins have access to a much wider spectrum of events that are called by the Joomla! code, such as the event called before displaying the template.
- In-built template code may lead to issues with the Joomla cache.
Each of the above points, as well as those at the start of this article, should be weighed up when considering whether to go with a plugin-less approach.
The first two issues mentioned above may be partly solved via efficient code structuring; then replacing it will require only the specific template files. However, we cannot completely avoid the issue of a separate code update.
The lack of events available to built-in code is of course something that can’t be avoided; we’re limited to events that are executed after the event our sample code is registered to. When it comes to the cache issue, the solution is…plugin! That is, a plugin that adds our own event, for example, onBeforeCache, that will be called directly through the plugin supporting cache; the point here is to perform our functions on the resultant code after getting it from the cache but before sending it to the browser.
Summary
As you can see, this solution has a mixture of pros and cons. Personally, I like them a lot, but I think the application of this method is very specific and should only be used in certain cases when all its limitations have been taken into account.
As a live example of how this code can be used; at GavickPro we use this approach to support our SocialAPI in templates, and to remove unnecessary portions of code or delete minor incompatibilities with some components.
We hope this method helps you with your coding, and if you’ve got any interesting applications for the plugins without plugins concept, let us know in the comments below!