PHP voor Joomla

1. De basis

1.1 Wat is PHP?

PHP is een programmeertaal gemaakt voor het web. Hij draait op de server, niet in de browser. Wanneer iemand een Joomla-pagina opent, draait de server PHP-code, praat PHP met de database, bouwt de HTML op en stuurt die afgewerkte HTML terug naar de browser. De bezoeker ziet de PHP zelf nooit, alleen het resultaat.

De naam is een grapje dat naar zichzelf verwijst: het staat voor "PHP: Hypertext Preprocessor". Voor een Joomla-site is het belangrijke punt dat PHP de laag is tussen de webserver en de database, en dat Joomla een grote PHP-applicatie is die in die laag leeft.

1.2 Waarom Joomla PHP nodig heeft

Een Joomla-pagina is geen bestand dat op schijf klaarstaat. Joomla bouwt hem bij elke aanvraag opnieuw op: het leest het menu, laadt het artikel, draait de plugins, rendert het template en stelt de pagina samen. Al dat werk is PHP. Zonder PHP zijn de bestanden in je public_html-map gewoon tekst; PHP is wat ze tot leven brengt.

1.3 Waar PHP in de stack zit

PHP is de middelste laag in de klassieke keten die elke Joomla-pagina serveert:

Browser
   ↓
Webserver (Apache / Nginx / LiteSpeed)
   ↓
PHP (draait Joomla's index.php)
   ↓
Database (MySQL of MariaDB)
   ↓
HTML terug naar de browser

De webserver bepaalt hoe de aanvraag binnenkomt; PHP bepaalt wat Joomla ermee doet. Dit artikel richt zich op die PHP-laag.

3. configuration.php: PHP als configuratie

3.1 Een PHP-bestand, geen instellingenscherm

Joomla bewaart zijn instellingen in een enkel PHP-bestand in de hoofdmap van de site, configuration.php. De instellingen die je wijzigt in Systeem → Algemene configuratie worden teruggeschreven naar dit bestand. Het is gewone PHP: een class met een property per instelling.

<?php
class JConfig {
    public $sitename = 'My Joomla Site';
    public $editor = 'tinymce';
    public $error_reporting = 'default';
    public $gzip = false;
    public $tmp_path = '/path/to/site/tmp';
    public $log_path = '/path/to/site/administrator/logs';
    // ...nog veel meer...
}

3.2 Waarom dit belangrijk is

Omdat het PHP is, breekt een enkele typefout in configuration.php (een ontbrekende puntkomma, een verdwaald aanhalingsteken) de hele site met een blanco pagina of een parse error. Bewerk het zorgvuldig, houd altijd een back-up voordat je het met de hand wijzigt, en laat nooit een kopie genaamd configuration.php.bak in de webroot staan, want die kopie kan als platte tekst worden gedownload en hij bevat je databasewachtwoord.

3.3 Het databasewachtwoord staat hier

Dit bestand bevat de databasehost, de gebruiker en het wachtwoord in leesbare PHP. Daarom is het beschermen ervan zo belangrijk: iedereen die configuration.php kan lezen, kan je databasegegevens lezen. Houd de bestandsrechten strak (vaak 444 of 644) en zorg dat de webserver het niet als download kan serveren.

5. PHP-extensies die Joomla nodig heeft

5.1 Wat een extensie is (in PHP-termen)

PHP zelf is klein. De meeste echte kracht komt uit extensies: optionele modules die in PHP zijn gecompileerd en die functies toevoegen zoals afbeeldingsverwerking of databasetoegang. Dit zijn PHP-extensies, geen Joomla-extensies; verwar de twee niet. Joomla heeft er een set van nodig om volledig te werken.

5.2 Vereiste en aanbevolen extensies

5.3 Hoe je ziet wat je hebt

Open Systeem → Systeeminformatie en bekijk de tabbladen PHP-informatie en Directives. De pagina PHP-informatie toont elke geladen extensie. Als het schalen van afbeeldingen mislukt of een extensie niet wil installeren, is een ontbrekende PHP-extensie een veelvoorkomende oorzaak, en dit is waar je het bevestigt.

7. Hoe PHP achter de webserver draait

7.1 De webserver draait PHP niet zelf

De webserver ontvangt de aanvraag, maar geeft het PHP-werk aan een aparte PHP-handler. De handler die je gebruikt beinvloedt snelheid en geheugen meer dan bijna iets anders op de server.

7.2 PHP-FPM in gewone woorden

PHP-FPM (FastCGI Process Manager) houdt een pool van PHP-werkers klaar. Wanneer een Joomla-aanvraag binnenkomt, geeft de webserver die aan een vrije werker, die index.php draait en de pagina teruggeeft. Omdat de werkers los staan van de webserver, kun je verschillende PHP-versies draaien voor verschillende sites op een machine en PHP herstarten zonder de webserver te herstarten.

7.3 Meerdere PHP-versies

Daarom kan een enkele server de ene site op PHP 8.3 draaien en de andere op 8.4. De meeste hosting-controlepanelen laten je de PHP-versie per site of per map kiezen. Wanneer je upgradet naar Joomla 6, is dit de instelling die je wijzigt om de site naar PHP 8.3 of nieuwer te brengen. De webserver zelf wordt uitgebreid behandeld in een apart artikel; hier is het punt dat de handler, niet het servermerk, je PHP draait.

9. Onder de motorkap: hoe Joomla PHP gebruikt

9.1 Objectgeorienteerde PHP en MVC

Modern Joomla is vrijwel volledig objectgeorienteerd. In plaats van lange scripts met code van boven naar beneden, is het werk opgesplitst in classes (blauwdrukken) en objecten (instanties van die blauwdrukken). Een paar ideeen dragen het meeste gewicht:

• Overerving: een class breidt een andere uit om gedrag te hergebruiken en te specialiseren.
• Interfaces: een contract dat zegt welke methoden een class moet bieden, zonder te zeggen hoe.
• Traits: herbruikbare stukken code die over meerdere classes worden gedeeld.
• Encapsulatie: houd de interne werking prive en bied een schone set methoden aan.

Bovenop OOP volgen Joomla-componenten het MVC-patroon (Model-View-Controller): het model verzorgt de data en de regels, de view rendert de uitvoer en de controller koppelt een aanvraag aan het juiste model en de juiste view. Deze opdeling kennen vertelt je waar elke soort code thuishoort als je een component leest of bouwt.

9.2 Namespaces en autoloading

Moderne Joomla-code is georganiseerd in namespaces en wordt op aanvraag geladen via PSR-4-autoloading. Je schrijft geen lange lijsten met include-opdrachten; je verwijst naar een class via zijn volledige naam en PHP laadt het juiste bestand automatisch.

use Joomla\CMS\Factory;
use Joomla\Database\DatabaseInterface;

9.3 De Factory

De Factory-class is het klassieke toegangspunt tot Joomla's belangrijkste objecten. Het is een handige manier om de applicatie, de database, de huidige gebruiker, het document en de mailer te bereiken:

use Joomla\CMS\Factory;

$app  = Factory::getApplication();                // de huidige applicatie
$user = Factory::getApplication()->getIdentity(); // de huidige gebruiker

De Factory is eenvoudig in gebruik, maar het is een statische lookup. Een aantal van zijn methoden is nu verouderd en wordt in Joomla 7 verwijderd: Factory::getDbo(), Factory::getDocument() en Factory::getUser() geven allemaal een deprecation-waarschuwing en vertellen je om het object in plaats daarvan uit de dependency injection-container te laden (het document en de gebruiker zijn ook bereikbaar via Factory::getApplication()). Voor nieuwe componentcode is de moderne stijl om in plaats daarvan te injecteren wat je nodig hebt, zoals hierna getoond.

9.4 De Dependency Injection-container

Joomla 6 is opgebouwd rond een Dependency Injection (DI)-container. In plaats van dat code zelf zijn afhankelijkheden ophaalt, maakt de container objecten aan en geeft die door ("injecteert") wat ze nodig hebben. Een component registreert zijn services in services/provider.php:

// administrator/components/com_example/services/provider.php
use Joomla\DI\Container;
use Joomla\DI\ServiceProviderInterface;

return new class () implements ServiceProviderInterface {
    public function register(Container $container): void
    {
        // registreer hier de services van je component
    }
};

Vervolgens vraagt een class via zijn constructor om wat hij nodig heeft, wat de code schoner en makkelijker te testen maakt:

public function __construct(DatabaseInterface $db)
{
    $this->db = $db;
}

9.5 De database-API

Joomla wil nooit dat je losse SQL door je PHP heen verspreidt. Het biedt een query builder die veilige, overdraagbare SQL voor je schrijft en waarden escapet om SQL-injectie te voorkomen. Haal de database uit de DI-container en bouw de query met createQuery() (het oude getQuery(true) is verouderd):

use Joomla\CMS\Factory;
use Joomla\Database\DatabaseInterface;

$db    = Factory::getContainer()->get(DatabaseInterface::class);
$query = $db->createQuery()
    ->select($db->quoteName(['id', 'title']))
    ->from($db->quoteName('#__content'))
    ->where($db->quoteName('state') . ' = :state')
    ->bind(':state', 1, ParameterType::INTEGER);

$db->setQuery($query);
$articles = $db->loadObjectList();

Het prefix #__ wordt tijdens het draaien vervangen door je echte tabelprefix, en de gebonden parameter houdt de waarde veilig gescheiden van de SQL.

9.6 PSR-standaarden en Composer

Joomla volgt de standaarden van de PHP-gemeenschap: PSR-4 voor autoloading en PSR-12 voor codestijl, en het beheert externe PHP-bibliotheken met Composer. Composer installeert een bibliotheek en zijn afhankelijkheden met een commando, zet PSR-4-autoloading op en zet versies vast zodat een build reproduceerbaar is. Als je extensies bouwt, houdt schrijven volgens deze standaarden je code consistent met de Joomla core en klaar voor de volgende grote Joomla-versie.

Als je eigen extensie een externe bibliotheek nodig heeft, draai dan niet composer install of composer update tegen Joomla's eigen composer.json in de hoofdmap van de site. Die map hoort bij Joomla, en het wijzigen van de inhoud van libraries/vendor/ maakt je site anders dan de officiele release, wat updates breekt en niet wordt ondersteund. Houd in plaats daarvan een aparte composer.json binnen je eigen extensie, draai Composer daar, en lever de resulterende vendor/-map mee verpakt met je component:

com_example/
├─ composer.json        je eigen afhankelijkheden
├─ vendor/              gebouwd door Composer, meegeleverd in je pakket
│   └─ autoload.php
└─ src/                 je componentcode

Laad die meegeleverde autoloader vervolgens een keer vanuit je code (bijvoorbeeld require_once JPATH_ROOT . '/components/com_example/vendor/autoload.php';). Om botsingen te voorkomen wanneer twee extensies dezelfde bibliotheek meeleveren, kun je je meegeleverde namespaces van een prefix voorzien met een tool als PHP-Scoper. Op deze manier reizen je afhankelijkheden mee met je extensie en raken ze nooit Joomla's core bibliotheken.

9.7 Ontwikkelaarsgereedschap

Professionele Joomla-ontwikkelaars werken zelden met PHP alleen. Een kleine set tools vangt bugs lang voordat ze de productie bereiken:

Joomla's eigen core gebruikt deze tools, en een extensie die ermee is gebouwd is veel makkelijker te onderhouden door PHP- en Joomla-upgrades heen.

11. Foutmeldingen en PHP debuggen

11.1 De instelling voor foutrapportage

Joomla verpakt PHP's foutrapportage in een keuzelijst bij Systeem → Algemene configuratie → Server → Foutrapportage. Die komt overeen met PHP's eigen niveaus:

11.2 Toon nooit fouten op een live site

Laat PHP op productie geen fouten op de pagina afdrukken. Een zichtbare fout kan bestandspaden, de databasestructuur of andere details onthullen die een aanvaller kan gebruiken. Zet Foutrapportage op Geen of Eenvoudig op een live site, en houd display_errors uit in PHP. Stuur fouten in plaats daarvan naar een logbestand.

11.3 Het witte scherm des doods

Wanneer een fatale PHP-fout optreedt en fouten verborgen zijn, krijg je een blanco witte pagina zonder bericht. Om de echte oorzaak te vinden, zet je Foutrapportage op Maximaal op een testkopie, of lees je het PHP-foutenlog. Het log noemt meestal het exacte bestand en de regel, wat een giswerk omzet in een snelle oplossing.

11.4 Debug-modus

Joomla heeft zijn eigen Debug-instelling in de Algemene configuratie. Wanneer die aan staat, toont Joomla onderaan elke pagina de uitgevoerde databasequery's, de geladen bestanden en het gebruikte geheugen. Het is een krachtig diagnostisch hulpmiddel, maar het toont interne details, dus zet het op productie weer uit.

11.5 Exceptions en logging

Moderne PHP meldt problemen via exceptions: wanneer er iets misgaat, "gooit" code een exception die omhoog reist totdat iets die "opvangt". Goed geschreven Joomla-code verpakt riskante handelingen in een try/catch-blok zodat een enkele storing niet de hele pagina laat crashen:

try {
    $db->setQuery($query);
    $rows = $db->loadObjectList();
} catch (\RuntimeException $e) {
    Log::add($e->getMessage(), Log::ERROR, 'com_example');
}

In plaats van de fout aan de bezoeker te tonen, legt dit hem vast via Joomla's eigen logging. Stuur op productie fouten naar een logbestand en lees ze daar; de stack trace binnen een exception noemt precies de keten van aanroepen die tot de storing leidde.

11.6 Xdebug voor stapsgewijs debuggen

Wanneer het lezen van het log niet genoeg is, is Xdebug het favoriete gereedschap van de ontwikkelaar. Het is een PHP-extensie die verbinding maakt met je editor (zoals PhpStorm of VS Code) en je de code op elke regel laat pauzeren, elke variabele laat inspecteren en Joomla stap voor stap laat doorlopen. Gebruik het alleen op een ontwikkelmachine; Xdebug is traag en mag nooit op een live site draaien.

13. PHP op de commandoregel en webservices

13.1 PHP voorbij de browser

PHP draait niet alleen wanneer een browser om een pagina vraagt. Het draait ook vanaf de commandoregel, en Joomla levert daar een commandoregelapplicatie voor. Vanuit de hoofdmap van de site kun je onderhoudstaken draaien zonder browser:

php cli/joomla.php core:update:check
php cli/joomla.php scheduler:run
php cli/joomla.php extension:list

Dit is de betrouwbare manier om lange taken zoals updates of geplande taken te draaien, omdat de commandoregel niet gebonden is aan de max_execution_time van de webserver.

13.2 De CLI gebruikt een andere php.ini

Een veelvoorkomende verrassing: de commandoregel gebruikt vaak een andere php.ini dan de website, en soms een andere PHP-versie. Als een CLI-taak zich anders gedraagt dan de site, controleer dan welke PHP-binary en welke instellingen de commandoregel gebruikt met php -v en php --ini.

13.3 PHP drijft de Web Services-API aan

Joomla's Web Services-API is ook PHP, draaiend via zijn eigen front controller op api/index.php. Een extern programma stuurt een HTTP-aanvraag met een token, en PHP draait dezelfde Joomla-code om content te lezen of te wijzigen:

curl -H "X-Joomla-Token: <token>" \
  https://example.test/api/index.php/v1/content/articles

Of de aanvraag nu van een browser, de commandoregel of de API komt, dezelfde PHP-applicatie beantwoordt hem; alleen het toegangspunt verschilt.

15. SEO en metadata

PHP heeft geen eigen SEO-instellingen, en toch beinvloedt het de zoekresultaten via een ding waar zoekmachines om geven: snelheid. Google meet hoe snel je server een pagina begint te versturen (Time To First Byte), en die tijd is grotendeels PHP die zijn werk doet.

• Een snelle PHP-versie verlaagt de serverreactietijd, wat de Core Web Vitals voedt en de ranking helpt.
• OPcache verkort de tijd die PHP besteedt aan compileren bij elke aanvraag, zodat pagina's eerder beginnen aan te komen.
• Genoeg geheugen voorkomt half-gerenderde pagina's en foutpagina's, die crawlers als kapot behandelen.
• Correcte foutafhandeling betekent dat een ontbrekende pagina een echte 404 van Joomla teruggeeft, niet een fatale PHP-fout met een 200-status die crawlers in de war brengt.

Kortom: je optimaliseert PHP niet rechtstreeks voor SEO. Je houdt PHP snel, goed voorzien van middelen en foutvrij, en goede Core Web Vitals volgen vanzelf.

17. Best practices

Als je maar een paar dingen uit dit artikel onthoudt, onthoud dan deze:

• Draai een ondersteunde PHP-versie: minimaal 8.3 voor Joomla 6, en bij voorkeur de nieuwste die je extensies toelaten.
• Draai nooit een PHP-tak waarvan de levensduur is verlopen; die krijgt geen beveiligingsfixes.
• Houd OPcache aan en groot genoeg om alle Joomla-bestanden te bevatten.
• Gebruik PHP-FPM of LSAPI in plaats van het oude mod_php.
• Stel memory_limit in op 256M of meer, en post_max_size boven upload_max_filesize.
• Verberg PHP-fouten op productie; toon ze alleen op een testkopie.
• Bewerk nooit core bestanden; breid uit met plugins, overrides, componenten en events.
• Filter in je eigen code de invoer, escape de uitvoer, gebruik CSRF-tokens en de database-query-builder.
• Bescherm configuration.php en verwijder alle back-upkopieen uit de webroot.
• Test een PHP-upgrade op staging, nadat je Joomla en alle extensies hebt bijgewerkt.
• Controleer de echte instellingen in Systeeminformatie, niet alleen de php.ini op schijf.

19. Samenvatting

PHP is de motor onder elke Joomla-site. Je schrijft er misschien nooit een regel van, maar de keuzes eromheen bepalen hoe je site presteert en hoe veilig hij is:

• Versie: Joomla 6 heeft PHP 8.3 of nieuwer nodig, en een actuele tak is sneller en veiliger dan een oude.
• Configuratie: een handvol php.ini-instellingen (geheugen, uploads, foutweergave) voorkomen de meest voorkomende Joomla-fouten.
• Prestaties: OPcache en een moderne handler zoals PHP-FPM geven het grootste deel van de snelheid, met weinig moeite.
• Ontwikkeling: Joomla gebruikt PHP via namespaces, de Factory, de DI-container en een veilige database-API, en het geeft je schone plekken om je eigen code toe te voegen.
• Beveiliging: een gepatchte PHP-versie, beschermde geheimen en verborgen fouten houden de motor stil en veilig.

De meeste PHP-problemen op een Joomla-site zijn configuratieproblemen, geen codeproblemen: een oude versie die een upgrade blokkeert, een geheugenlimiet die te laag is, fouten die op een live pagina lekken, of een met de hand bewerkte configuration.php. Ze zijn snel op te lossen zodra je weet waar je moet kijken.

Als je Joomla-site traag is, geheugenfouten geeft of weigert bij te werken vanwege de PHP-versie, ligt de oorzaak meestal in de PHP-laag en niet in Joomla zelf. Een zorgvuldige blik op de versie, de OPcache en de belangrijkste php.ini-instellingen lost het vaak snel op, en het is precies het soort fundamentwerk dat een site jarenlang snel en veilig houdt.