1

My component hooks into some core Joomla behaviour, adding an extra path that it needs other related components to be able to use. I do this simply by adding it to the global path include ( defines.php ) on install and removing it on uninstall.

This works well, although I accept that it may be bad policy. I need this path to be available globally and the current approach achieves that.

The problem is that if Joomla updates there is potential for my path to be erased if the update overwrites that file. I have seen this happen and it obviously makes a mess of my other components.

Having the path available is far tidier and more readable than using a component path globally, especially as some of the code that requires it may not be part of a component at all, so I would prefer to keep it this way. What I am looking for is a way to maintain this configuration across updates.

Is there a way to either keep the configured path somewhere that it will always be available but Joomla will not remove it on update or is there some kind of signal or event when a Joomla update has completed so I can hook into that in order to check the path and re-add it if necessary after the update?

2
  • 1
    Could you clarify why a core modification is required if you are simply adding a global defines statement? Surely a system plugin is the right tool for that. Sep 9, 2019 at 23:48
  • It probably is! There are a lot of different things in Joomla and the correct one to use in different situations is not always obvious. If that's the solution designed for this kind of problem I'm happy to accept an answer to that extent.
    – glenatron
    Sep 10, 2019 at 9:13

1 Answer 1

2

System Plugins

Official Documentation: https://docs.joomla.org/Plugin/Events/System

A system plugin is not only useful for a wide variety of site tasks, but is also a good intro to the lifecycle. Take note of the naming coventions plg group name written camel case for the class and snake case for the the internal plugin name.

All active system plugins are registered for every request, which means that if you wish to add functions etc to the global space you can declare them outside of the class declaration.

Example Manifest

File Location: /plugins/system/example/example.xml

<?xml version="1.0" encoding="utf-8"?>
<extension version="3.8" type="plugin" group="system">
  <name>plg_system_example</name>
  <author>Author</author>
  <creationDate>January 2018</creationDate>
  <version>1.0.1</version>
  <description>An example system plugin</description>
  <files>
    <filename plugin="example">example.php</filename>
  </files>
  <config></config>
</extension>

Entry File

File Location: /plugins/system/example/example.php

<?php
defined('_JEXEC') or die;

function myGloballyAvailableThing($x){
// do stuff
}

define('RANDOMCONSTANT','USEFULVALUE');


class plgSystemExample extends JPlugin
{
    public function onAfterInitialise()
    {
        // Do something onAfterInitialise
        // eg. Manipulate the input prior to the router dealing with it
    }

    public function onAfterRoute()
    {
        // Do something onAfterRoute
        // eg. Test to see if this a certain component and if so run some script
    }

    function onBeforeCompileHead()
    {
        // Do something onBeforeCompileHead
        // eg. Manipulate something in the head tag
    }

    public function onAfterRender()
    {
        // Do something onAfterRender
        // eg. pull the html from the document buffer and do a string replace on something
    }
}

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.