Plugins in Joomla

Plugins zijn de onzichtbare werkers van Joomla. Het zijn stukjes code die reageren op gebeurtenissen en op de achtergrond worden uitgevoerd om gedrag te veranderen in plaats van een pagina op te bouwen. Een plugin heeft geen URL, geen modulepositie en vaak zelfs helemaal geen zichtbare uitvoer.

Toch zijn plugins de manier waarop vrijwel alles in Joomla kan worden uitgebreid zonder ook maar één regel core-code aan te passen.

Hoe Joomla reageert op gebeurtenissen en zichzelf uitbreidt zonder de core aan te raken.

In dit artikel lees je hoe Joomla-plugins echt werken. We beginnen bij de basis voor website-eigenaren en beheerders en gaan daarna verder met de technische details voor ontwikkelaars. Je leert wat een plugin is, hoe Joomla deze activeert, hoe een moderne plugin is opgebouwd en hoe je de meest voorkomende fouten voorkomt.

De belangrijkste gedachte om mee te nemen is deze: een plugin is een luisteraar. Hij wacht tot er iets gebeurt en reageert vervolgens. Begrijp je hoe één plugin zich abonneert op één event, dan begrijp je hoe vrijwel alle uitbreidbaarheid van Joomla werkt.

2. Hoe plugins worden geactiveerd

2.1 Het publish/subscribe-model

Plugins werken via Joomla's event dispatcher. Er zijn twee partijen betrokken, die elkaar nooit rechtstreeks kennen:

  PUBLISHER                            SUBSCRIBER
  (core of een component)              (jouw plugin)

  dispatch('onContentPrepare')  ---->  onContentPrepare()
        |                                    |
        |  "er is iets gebeurd"              |  "ik handel dit af"
        └----------- los gekoppeld ----------┘

• De publisher activeert een event op naam en gaat vervolgens verder.
• Elke ingeschakelde plugin die zich op dat event heeft geabonneerd, wordt daarna uitgevoerd.
• Geen van beide partijen weet welke andere partij erbij betrokken is. Dit heet losse koppeling (loose coupling).

Dit is misschien wel het belangrijkste ontwerpprincipe binnen Joomla. Zodra dit kwartje valt, wordt het hele extensiesysteem veel logischer.

2.2 Een event heeft een naam, gegevens en soms een resultaat

Wanneer een component een event activeert, geeft het gegevens mee. Een plugin kan deze gegevens lezen, aanpassen of zelfs de actie stoppen:

// Een component activeert een event en geeft gegevens mee:
$event = new BeforeSaveEvent('onContentBeforeSave', [
    'context' => 'com_content.article',
    'subject' => $article,        // gegevens die plugins mogen lezen of wijzigen
    'isNew'   => $isNew,
]);
$this->getDispatcher()->dispatch($event->getName(), $event);

// Een plugin kan de actie stoppen:
if ($somethingWrong) {
    $event->addError('Opslaan is niet toegestaan.');
    $event->stopPropagation();     // volgende plugins worden niet meer uitgevoerd
}

Een event bevat meestal de volgende onderdelen:

2.3 De naam van een event verraadt het moment waarop het wordt uitgevoerd

Eventnamen zijn bewust leesbaar gemaakt. Het werkwoord in de naam vertelt je wanneer het event wordt geactiveerd:

onContentBeforeSave   ← vlak vóór de actie (je kunt deze nog annuleren)
onContentAfterSave    ← direct na de actie (de actie is al uitgevoerd)
onUserLogin           ← op het moment van inloggen
onAfterRoute          ← een controlepunt in de requestcyclus

4. Binnenin een plugin (de moderne structuur)

4.1 De mapstructuur van Joomla 4, 5 en 6

Sinds Joomla 4 zijn plugins opgebouwd met namespaces, PSR-4-autoloading en dependency injection, net als componenten:

plugins/content/example/
├── example.xml                 ← manifest (groep, element, bestanden, parameters)
├── services/
│   └── provider.php            ← DI-registratie (het entry point)
├── src/
│   └── Extension/
│       └── Example.php         ← de pluginklasse (de listener)
├── language/                   ← vertaalbestanden (.ini)
└── tmpl/ (optioneel)           ← layouts als de plugin HTML genereert

Net als bij componenten is services/provider.php tegenwoordig het entry point. Er wordt niet langer gewerkt met "magische" bestandsnamen die automatisch worden geladen.

4.2 services/provider.php, de plugin registreren

De provider registreert de plugin in de DI-container en geeft alle benodigde services door, zoals de databaseverbinding of de applicatie:

return new class () implements ServiceProviderInterface {
    public function register(Container $container): void
    {
        $container->set(
            PluginInterface::class,
            function (Container $container) {
                $dispatcher = $container->get(DispatcherInterface::class);
                $plugin = new Example(
                    $dispatcher,
                    (array) PluginHelper::getPlugin('content', 'example')
                );
                $plugin->setApplication(Factory::getApplication());
                return $plugin;
            }
        );
    }
};

De container injecteert alle afhankelijkheden automatisch, waardoor de plugin eenvoudiger te testen is en niet afhankelijk wordt van globale variabelen.

4.3 De pluginklasse, twee stijlen

Klassieke stijl (nog steeds ondersteund): één publieke methode per event, met dezelfde naam als het event.

class Example extends CMSPlugin
{
    public function onContentPrepare($context, &$article, &$params, $page = 0)
    {
        $article->text = str_replace('{hello}', 'Hallo JUG!', $article->text);
    }
}

Moderne stijl (de voorkeursmethode in Joomla 5 en 6): implementeer SubscriberInterface en geef expliciet aan welke events worden afgehandeld.

class Example extends CMSPlugin implements SubscriberInterface
{
    public static function getSubscribedEvents(): array
    {
        return ['onContentPrepare' => 'transformText'];
    }

    public function transformText(ContentPrepareEvent $event): void
    {
        $article = $event->getItem();
        $article->text = str_replace('{hello}', 'Hallo JUG!', $article->text);
    }
}

De methode getSubscribedEvents() maakt direct duidelijk welke events de plugin afhandelt. Joomla hoeft daardoor niet meer te raden op basis van methodenamen.

4.4 Eventgegevens lezen en aanpassen

In de moderne API werk je niet langer met &$reference-argumenten. In plaats daarvan gebruik je getypeerde eventobjecten met getters en setters:

public function transformText(ContentPrepareEvent $event): void
{
    $context = $event->getContext();   // 'com_content.article'
    $item    = $event->getItem();      // het artikelobject
    $params  = $event->getParams();    // Registry met parameters

    if ($context !== 'com_content.article') {
        return;                        // niet voor mij bedoeld
    }

    $item->text .= '<p>Toegevoegd door mijn plugin.</p>';
}

Joomla 6 verschuift steeds meer richting immutabele events. Lees gegevens via getters, wijzig ze via de methoden die het event aanbiedt en gebruik stopPropagation() om verdere verwerking te stoppen. Pas argumenten niet rechtstreeks aan.

6. Gespecialiseerde plugingroepen

6.1 Authentication en User, de inlogketen

Inloggen bestaat niet uit één stap, maar uit een kleine keten van events. Verschillende plugingroepen verzorgen verschillende onderdelen van dit proces:

Inlogformulier verzonden
   v
onUserAuthenticate     ← authenticatieplugins proberen de gebruiker te verifiëren
   |   (Joomla-database? LDAP? OAuth? eerste succesvolle verificatie wint)
   v
onUserAuthorisation    ← mag deze geverifieerde gebruiker daadwerkelijk naar binnen?
   v
onUserLogin / onUserAfterLogin   ← user-plugins reageren (sessie instellen, loggen)

Zo kunnen single sign-on, sociale login en tweefactorauthenticatie worden toegevoegd zonder dat com_users hoeft te worden aangepast.

6.2 Editors, Fields en Web Services

// Een webservices-plugin koppelt API-routes aan de API-controllers van een component:
public function onBeforeApiRoute(&$router)
{
    $router->createCRUDRoutes('v1/content/articles', 'articles', ['component' => 'com_content']);
}

Het inschakelen van Web Services - Content betekent letterlijk dat je een plugin inschakelt. Daarmee wordt het endpoint /api/index.php/v1/content/articles beschikbaar gemaakt.

6.3 Task-plugins, Joomla's cron-systeem

Het component Scheduled Tasks (com_scheduler) wordt volledig aangedreven door plugins uit de groep task:

Een trigger (webcron / CLI / lazy)
   v
onExecuteScheduledTask
   v
De bijbehorende task-plugin voert zijn taak uit
   (oude logs verwijderen, sessies opschonen,
    een feed ophalen, een samenvatting versturen ...)

• Elke task-plugin definieert zijn beschikbare taken via getSubscribedEvents().
• Dit is de moderne, via de interface beheerde vervanger van handmatig geschreven cronjobs.

Een task-plugin is in feite "gewoon een plugin" die wordt gestart door de scheduler in plaats van door een paginaverzoek.

8. Meer dan de basis

8.1 Plugins versus de alternatieven, kies het juiste gereedschap

Plugins zijn krachtig, maar niet altijd de juiste oplossing. Gebruik onderstaande tabel om te bepalen wat je nodig hebt:

Als je antwoord is: "wanneer X gebeurt, moet Y gebeuren", dan is een plugin vrijwel altijd de juiste keuze.

8.2 Prestatie-overwegingen

Omdat system-plugins bij elk verzoek worden uitgevoerd, vormen ze een belangrijk aandachtspunt voor prestatie-optimalisatie:

Eén slecht geschreven system-plugin kan de volledige website vertragen, omdat deze op elke pagina voor iedere bezoeker wordt uitgevoerd.

8.3 Plugins en gedeelde services

Plugins zorgen ervoor dat Joomla's gedeelde services uitbreidbaar blijven zonder onderlinge afhankelijkheden:

• Aangepaste velden worden geleverd als fields-plugins. Elk veldtype is een afzonderlijke plugin.
• Slim Zoeken indexeert inhoud via finder-plugins, één per inhoudsbron.
• Categorieën activeren eveneens content-events zoals onContentPrepare en onContentBeforeSave, met de context com_content.categories. Daardoor kan dezelfde plugin zowel artikelen als categorieën uitbreiden.

if ($event->getContext() === 'com_content.categories') {
    // Dezezelfde plugin wordt ook uitgevoerd voor categoriebeschrijvingen.
}

De gedeelde categorieënservice is geen gesloten systeem. Ze activeert dezelfde events als artikelen, waardoor plugins categorieën automatisch kunnen uitbreiden.

10. Best practices

Als je maar een paar dingen uit dit artikel onthoudt, laat het dan deze zijn:

• Een plugin is een eventlistener. Hij verandert gedrag, niet de pagina zelf.
• Abonneer je op één specifiek event en controleer altijd eerst de context voordat je iets doet.
• Stop zo vroeg mogelijk om system-plugins snel te houden.
• Gebruik getSubscribedEvents() en getypeerde eventobjecten in moderne plugins.
• Let op de uitvoervolgorde wanneer meerdere plugins dezelfde gegevens aanpassen.
• Kies het juiste gereedschap: component voor inhoud, module voor blokken, plugin voor gedrag.

12. Samenvatting

Plugins vormen in Joomla de stille laag die alles met elkaar verbindt. Ze bouwen geen pagina's op en verschijnen niet op een vaste positie op het scherm. In plaats daarvan luisteren ze naar gebeurtenissen en reageren ze daarop, waardoor vrijwel elk onderdeel van Joomla kan worden uitgebreid zonder de core aan te passen.

Zodra je het publish/subscribe-model begrijpt, volgt de rest vanzelf:

• System-plugins haken in op de levenscyclus van een verzoek en worden op elke pagina uitgevoerd.
• Content-plugins verwerken en transformeren inhoud.
• Gespecialiseerde groepen verzorgen authenticatie, gebruikersbeheer, editors, velden, webservices, geplande taken en tweefactorauthenticatie.
• Moderne plugins zijn PSR-4-klassen met namespaces, geregistreerd via services/provider.php en opgebouwd rond SubscriberInterface en getypeerde events.

Wanneer je een nieuwe functionaliteit ontwikkelt, onverwacht gedrag onderzoekt of probeert te achterhalen waarom een website traag is, zijn plugins vaak de eerste plek om te kijken. Ze zijn klein, maar bepalen in hoge mate hoe het hele systeem zich gedraagt.

Heb je hulp nodig bij het bouwen van een eigen plugin, het opsporen van een problematische plugin of het optimaliseren van eventgestuurde code voor prestaties en veiligheid, dan begint het begrip van deze architectuur altijd bij dezelfde basis: events, listeners en een goede scheiding van verantwoordelijkheden.