Your PHP-Installatie Lijkt de MySQL-Extensie te Missen in WordPress – Volledige Oplossing

De Fout Die Plotseling Verschijnt

Je upgrade PHP.
Of migreert je website.
Of zet een nieuwe VPS op en installeert WordPress vanaf nul.

Alles lijkt prima — totdat dat niet meer zo is.

Plotseling zie je, in plaats van je homepage, dit:

Your PHP installation appears to be missing the MySQL extension which is required by WordPress.

Het is zo’n melding die eenvoudig klinkt… maar dat zelden is.

In oudere handleidingen is de uitleg bijna altijd hetzelfde:
“Installeer de MySQL-extensie.”

In werkelijkheid, vooral in moderne omgevingen (PHP 8.2, 8.3, 8.4), heeft deze fout meestal weinig te maken met een ontbrekende extensie — en veel meer met hoe PHP is geconfigureerd, geladen of gescheiden tussen verschillende omgevingen.

Soms verschijnt deze fout:

• direct na het upgraden naar PHP 8.3
• na het overstappen van Apache naar Nginx
• tijdens een Docker-rebuild
• na een servermigratie
• wanneer CLI en FPM verschillende PHP-versies gebruiken

En soms — na

Snelle Diagnose in 60 Seconden

Voordat je iets opnieuw installeert of configuratiebestanden wijzigt, is het verstandig even te stoppen. Wanneer je de melding your php installation appears to be missing the mysql extension ziet, is de eerste reactie meestal om direct pakketten te gaan installeren. In de praktijk maakt dat het probleem vaak alleen maar groter.

Het echte doel is eenvoudig: bepalen of wordpress missing mysql extension daadwerkelijk wordt veroorzaakt door een ontbrekende extensie, of dat PHP iets anders laadt dan je verwacht.

In moderne omgevingen, vooral met PHP 8.2 of 8.3, draait het probleem vaak meer om de context dan om een ontbrekende component.

1. Controleer de Actieve PHP-versie

Begin met de basis. Welke PHP-versie draait er eigenlijk?

Als je SSH-toegang hebt:

php -v

Dit toont de CLI-versie. Dat is nuttig, maar niet doorslaggevend. Je webserver kan namelijk een compleet andere PHP-build gebruiken.

Om de web runtime te controleren, maak een tijdelijk bestand aan met de naam info.php in de rootmap van je WordPress-installatie:

Open dit in je browser en controleer:

• de PHP-versie
• het pad van het Loaded Configuration File
• de Server API (Apache, FPM/FastCGI, enz.)

Het komt verrassend vaak voor dat je in de CLI PHP 8.3 ziet, terwijl de browser PHP 8.1 rapporteert. In zo’n situatie heeft php missing mysql extension wordpress mogelijk helemaal niets met MySQL te maken. Het kan simpelweg een andere PHP-instantie zijn die wordt gebruikt.

2. Controleer of MySQLi of PDO_MySQL Is Geladen

Zoek in de output van phpinfo() naar:

• mysqli
• pdo_mysql

Als geen van beide verschijnt, dan heeft PHP daadwerkelijk geen MySQL-ondersteuning en is de melding your php installation appears to be missing the mysql extension technisch gezien correct.

Als ze wel verschijnen, wordt de situatie interessanter. WordPress kan nog steeds een missing mysqli extension wordpress-fout tonen, ook al bestaat de extensie. Dat wijst meestal op een configuratieverschil in plaats van een installatieprobleem.

Via SSH kun je ook het volgende uitvoeren:

php -m | grep -i mysql

Ook dit controleert alleen de CLI-modules. De webserver kan een andere set extensies laden.

3. Controleer het Geladen php.ini-Bestand

Zoek op de phpinfo()-pagina naar de regel:

Loaded Configuration File

Zorg ervoor dat het pad overeenkomt met de PHP-versie die je webserver daadwerkelijk gebruikt.

Zoek vervolgens naar:

extension_dir

Als extension_dir naar een verkeerde map of naar een andere PHP-build verwijst, kunnen extensies zoals mysqli of pdo_mysql wel op de server aanwezig zijn maar niet worden geladen tijdens runtime. In zulke gevallen betekent fix mysql extension error wordpress niet dat je iets nieuws moet installeren. Het betekent dat je PHP moet laten verwijzen naar de juiste extensiemap.

Op dit punt ontstaat meestal één van de volgende conclusies:

• De extensie is helemaal niet geïnstalleerd.
• De extensie is geïnstalleerd maar niet geactiveerd voor de actieve runtime.
• CLI en web-PHP gebruiken verschillende configuraties.

Ga pas verder nadat je hebt vastgesteld welk scenario van toepassing is. Anders loop je het risico dat je het verkeerde probleem probeert op te lossen.

Waarom Deze Fout Misleidend Is in Moderne PHP-omgevingen

Op het eerste gezicht klinkt de melding your php installation appears to be missing the mysql extension heel precies. Het suggereert dat er iets ontbreekt en dat het installeren ervan alles zal oplossen.

In 2026 is die aanname echter vaak onjuist.

De oorspronkelijke mysql-extensie is al jaren verouderd en volledig verwijderd uit moderne PHP-versies. WordPress gebruikt deze niet meer. In plaats daarvan maakt het gebruik van mysqli of pdo_mysql, die beide standaard aanwezig zijn in PHP 8.x-builds.

Dus wanneer WordPress tegenwoordig een wordpress missing mysql extension-fout toont, betekent dit zelden dat je “MySQL-ondersteuning vergeten bent te installeren.” Vaker geeft het aan dat PHP tijdens runtime de juiste module niet heeft geladen.

Dit verschil is belangrijk.

Lees ook: Hoe je Time to First Byte (TTFB) voor je WordPress-site kunt verbeteren

MySQL vs MySQLi: De Naamval

De foutmelding verwijst nog steeds naar de “MySQL-extensie”, waardoor veel ontwikkelaars naar het verkeerde pakket zoeken. Ze proberen mysql te installeren, maar dat bestaat niet meer in PHP 8.2 of 8.3.

Wat WordPress daadwerkelijk nodig heeft is:

• mysqli
• of pdo_mysql

Als geen van beide beschikbaar is voor de actieve PHP-runtime, kun je variaties tegenkomen zoals missing mysqli extension wordpress of php missing mysql extension wordpress.

Maar de formulering in de foutmelding is niet mee geëvolueerd met PHP. Daar begint de verwarring.

PHP 8.x en het Probleem van Runtime-context

Moderne PHP-configuraties zijn zelden eenvoudig.

Je kunt bijvoorbeeld hebben:

• meerdere geïnstalleerde PHP-versies
• afzonderlijke PHP-FPM-pools
• containerized deployments
• op maat gecompileerde PHP-builds
• verschillende php.ini-bestanden voor CLI en web

In zulke omgevingen betekent fix mysql extension error wordpress niet dat je een module moet downloaden. Het gaat erom dat de juiste PHP-runtime de juiste extensie uit de juiste map laadt.

Bijvoorbeeld:

• CLI kan tonen dat mysqli geladen is
• maar de web-runtime mogelijk niet
• of PHP-FPM kan verwijzen naar een verouderde extension_dir
• of een container-rebuild kan pdo_mysql hebben overgeslagen

Al deze scenario’s veroorzaken dezelfde melding.

Daarom is het zelden de juiste eerste stap om blind pakketten te installeren. Het echte probleem draait bijna altijd om afstemming.

WordPress, PHP en de database moeten binnen dezelfde configuratiecontext werken. Wanneer één onderdeel verschuift — vooral tijdens een upgrade naar PHP 8.3 — breekt het systeem stilletjes, en toont WordPress deze algemene foutmelding.

Wanneer het Niet eens om de Extensie Gaat

Er is nog een nuance die makkelijk over het hoofd wordt gezien.

Soms is de extensie correct geladen, maar kan WordPress nog steeds geen verbinding maken met de database. In zulke gevallen kan de melding verschijnen omdat de database-laag al vroeg in het bootstrap-proces faalt.

Dit kan gebeuren wanneer:

• databasegegevens onjuist zijn
• het MySQL-socketpad is gewijzigd
• MariaDB via TCP draait terwijl PHP een Unix-socket verwacht
• de databaseservice niet draait
• SELinux de toegang blokkeert

Vanuit het perspectief van WordPress mislukt de databaseverbinding. De standaardaanname is dan dat MySQL-ondersteuning ontbreekt.

Met andere woorden: de foutmelding beschrijft niet altijd de werkelijke oorzaak. Ze beschrijft het symptoom.

Als je deze context begrijpt, verandert ook je aanpak van het probleem. In plaats van extensies opnieuw te installeren, begin je de uitvoeringsketen te volgen.

En daar begint de echte diagnose.

Lees ook: Hoe je de WordPress-cache wist wanneer je wijzigingen niet zichtbaar zijn

Waar de Verbinding Breekt

Wanneer WordPress de melding your php installation appears to be missing the mysql extension toont, faalt er iets in de uitvoeringsketen. De duidelijkste manier om dit te begrijpen is door die keten zelf te bekijken.

Op hoofdniveau ziet de flow er zo uit:

WordPress Core
 ↓
PHP Runtime (Web SAPI / PHP-FPM / Apache Module)
 ↓
MySQL-extensie (mysqli of pdo_mysql)
 ↓
Database-engine (MySQL 8 / MariaDB)

Als een schakel in deze keten niet goed op elkaar aansluit, kan WordPress de database-laag niet initialiseren. Het resultaat kan een wordpress missing mysql extension-fout zijn, zelfs als de extensie technisch gezien aanwezig is.

Laten we bekijken waar deze keten meestal breekt.

1. De Extensie Is Niet Geïnstalleerd

Dit is het eenvoudigste scenario. PHP is geïnstalleerd zonder mysqli of pdo_mysql.

Dit kan gebeuren wanneer:

• PHP vanuit de bron wordt gebouwd zonder mysqlnd
• er minimale container-images worden gebruikt
• PHP handmatig op een VPS wordt geïnstalleerd zonder het MySQL-pakket

In dat geval zullen php -m en phpinfo() geen mysqli of pdo_mysql tonen. De foutmelding is dan correct.

2. De Extensie Is Geïnstalleerd maar Niet Geactiveerd

Hier bestaat de extensie wel op de server, maar wordt deze niet geladen.

Veelvoorkomende oorzaken:

• extension=mysqli ontbreekt in php.ini
• de extensie is gecompileerd maar niet geactiveerd
• er worden verschillende php.ini-bestanden gebruikt voor CLI en web
• een verkeerde extension_dir is ingesteld

Hier vallen veel gevallen van php missing mysql extension wordpress onder. Ontwikkelaars zien mysqli.so in de map met extensies en gaan ervan uit dat alles in orde is. Ondertussen laadt PHP-FPM deze extensie helemaal niet.

3. CLI en Web-PHP Zijn Verschillend

Dit is een van de meest voorkomende oorzaken in moderne configuraties.

Je voert uit:

php -m | grep -i mysql

Het toont mysqli.

Alles lijkt correct.

Maar de webserver gebruikt een compleet andere PHP-versie. Die versie kan MySQL-ondersteuning mogelijk niet geactiveerd hebben.

In deze situatie is het probleem niet dat MySQL-ondersteuning ontbreekt. Het is een mismatch in de runtime.

Dit komt vooral vaak voor na:

• een upgrade naar PHP 8.3
• het wisselen van hostingpanelen
• het inschakelen van MultiPHP in cPanel
• een migratie van Apache naar Nginx

De CLI- en webomgevingen lopen dan ongemerkt uit elkaar.

4. De Extensie Wordt Geladen maar de Databaselaag Faalt

Dit is het subtiele geval.

mysqli verschijnt in phpinfo().
PHP is correct.
Configuratiepaden lijken in orde.

Toch toont WordPress nog steeds meldingen van het type fix mysql extension error wordpress.

Hier ontstaat de breuk lager in de keten:

• verkeerd socketpad
• onjuiste host in wp-config.php
• de databaseservice draait niet
• MariaDB is geüpdatet en heeft standaardinstellingen gewijzigd
• rechtenproblemen op het socketbestand

Vanuit het perspectief van WordPress mislukt de verbinding tijdens het bootstrapproces. De foutmelding gaat ervan uit dat de extensielaag verantwoordelijk is.

Technisch gezien is dat niet zo.

5. Gecontaineriseerde en Cloudomgevingen

In Docker- of cloudimplementaties kan de breuk tijdens de buildfase ontstaan.

Bijvoorbeeld:

• de basisimage bevat geen pdo_mysql
• docker-php-ext-install mysqli pdo_mysql is overgeslagen
• een rebuild verving de PHP-laag maar niet de configuratie
• omgevingsvariabelen wijzigden de databaseverbinding

In zulke gevallen kan wordpress missing mysql extension verschijnen na wat een ogenschijnlijk niet-gerelateerde infrastructuurupdate leek.

Daarom staat deze fout zelden op zichzelf. Ze is bijna altijd contextgebonden.

Wanneer je de keten begrijpt, behandel je dit niet langer als een eenvoudig installatieprobleem. In plaats daarvan bepaal je welke laag is verschoven.

Met dat perspectief wordt de oplossing methodisch in plaats van reactief.

De Werkelijke Oorzaken Achter de MySQL-extensiefout

Tegen dit punt heb je waarschijnlijk al vastgesteld waar de keten breekt. Nu wordt de vraag praktisch: wat moet er precies worden gecorrigeerd?

Het antwoord hangt volledig af van je omgeving. Een shared hostingomgeving werkt heel anders dan een eigen VPS of een Docker-deployment. De foutmelding kan hetzelfde zijn, maar de onderliggende oorzaak verschilt.

Laten we de meest voorkomende scenario’s bekijken.

Shared Hostingomgevingen

Op shared hosting, vooral met cPanel of vergelijkbare controlepanelen, heeft het probleem vaak te maken met het wisselen van PHP-versies.

Veel hostingproviders laten meerdere PHP-versies naast elkaar bestaan. Je kunt bijvoorbeeld upgraden naar PHP 8.3 in het paneel, terwijl het domein nog steeds gekoppeld is aan een oudere handler.

Als je wordpress missing mysql extension ziet op shared hosting, controleer dan:

• welke PHP-versie aan het domein is toegewezen
• of mysqli en pdo_mysql zijn ingeschakeld in de lijst met PHP-extensies
• of MultiPHP Manager de juiste handler toepast

In cPanel betekent dit meestal:

1. Select PHP Version openen
2. controleren dat PHP 8.2 of 8.3 actief is
3. controleren dat mysqli en mysqlnd zijn aangevinkt

Na het opslaan vernieuw je de website. Als de runtime correct wisselt, verdwijnt de fout onmiddellijk.

Als dat niet gebeurt, kan het domein nog steeds aan een andere PHP-pool gekoppeld zijn.

Hier voorkomt goed doorlopend WordPress onderhoud stille configuratiedrift. Kleine versieverschillen zijn makkelijk te missen totdat ze de productieomgeving verstoren.

VPS- en Dedicated Server-configuraties (Ubuntu / Debian)

In VPS-omgevingen is het probleem meestal duidelijker zichtbaar.

Als PHP zonder MySQL-ondersteuning is geïnstalleerd, kun je dit controleren:

php -m | grep -i mysql

Als er niets verschijnt, installeer dan de vereiste module:

sudo apt update
sudo apt install php-mysql

Start daarna de juiste service opnieuw:

sudo systemctl restart php8.3-fpm

Of, als je Apache gebruikt:

sudo systemctl restart apache2

Maar hier maken mensen vaak een fout.

Ze herstarten de verkeerde PHP-FPM-versie.

Als meerdere versies zijn geïnstalleerd, zorg er dan voor dat je precies de service herstart die je webserver gebruikt. Het herstarten van php8.2-fpm terwijl Nginx naar php8.3-fpm verwijst, verandert niets.

Alleen al deze mismatch kan php missing mysql extension wordpress-fouten veroorzaken, zelfs wanneer de extensie aanwezig is.

Nginx + PHP-FPM mismatch

In moderne configuraties, vooral na PHP-upgrades, verwijzen configuratiebestanden soms nog steeds naar oudere sockets.

Bijvoorbeeld:

fastcgi_pass unix:/run/php/php8.1-fpm.sock;

Als het systeem is geüpgraded naar PHP 8.3 maar Nginx nog steeds naar de 8.1-socket verwijst, laadt WordPress de verkeerde runtime.

In dat scenario:

• CLI toont mysqli
• PHP 8.3 heeft MySQL-ondersteuning
• De webserver blijft 8.1 gebruiken zonder deze ondersteuning

De fout verschijnt en lijkt op een ontbrekende extensie.

In werkelijkheid is het een probleem met een configuratieverwijzing.

Docker- en containergebaseerde deployments

Gecontaineriseerde omgevingen voegen nog een extra laag toe.

Als je bouwt vanuit de officiële PHP-image, zijn MySQL-extensies niet altijd standaard inbegrepen. Je moet ze expliciet toevoegen tijdens de build:

RUN docker-php-ext-install mysqli pdo pdo_mysql

Als deze regel wordt verwijderd, overgeslagen of overschreven tijdens een rebuild, kan de volgende deployment plotseling de fout your php installation appears to be missing the mysql extension veroorzaken.

Dit gebeurt vaak na:

• upgrades van de base image
• het overschakelen van Debian- naar Alpine-images
• wijzigingen in de CI/CD-pipeline

De extensie werd nooit handmatig “verwijderd”. De container werd simpelweg opnieuw opgebouwd zonder deze extensie.

In complexe omgevingen met API-lagen, SaaS-systemen of AI-integratie in moderne webplatforms komen deze bijwerkingen van rebuilds vaak voor. WordPress kan slechts één onderdeel zijn binnen een grotere architectuur.

Meerdere PHP-installaties

Dit verdient extra aandacht.

Veel servers draaien met:

• /usr/bin/php
• /usr/local/bin/php
• meerdere FPM-pools
• afzonderlijke pools per domein

Je kunt bevestigen dat mysqli globaal is geïnstalleerd, maar de actieve pool kan een ander php.ini gebruiken.

Hier wordt ervaring met professionele WordPress webontwikkeling relevant. Vaststellen welke PHP-runtime het verzoek daadwerkelijk verwerkt, vereist het analyseren van poolconfiguratiebestanden, niet alleen het controleren van modules.

Wanneer multi-versie configuraties uit elkaar beginnen te lopen, maakt WordPress zich niet druk over de reden. Het meldt simpelweg een ontbrekende extensie.

In al deze scenario’s is het patroon hetzelfde. Het probleem gaat zelden over het installeren van iets nieuws. Het gaat erom dat de juiste runtime de juiste extensie laadt binnen de juiste configuratiecontext.

Hoe complexer de infrastructuur, hoe subtieler de misconfiguratie.

Lees ook: 5 stappen om 301-redirects aan WordPress toe te voegen via htaccess (volledige praktische gids)

Probleemoplossingstabel: Symptoom → Oorzaak → Oplossing

Hieronder vind je een praktisch overzicht van de meest voorkomende variaties van de fout your php installation appears to be missing the mysql extension.

Deze tabel laat zien wat doorgaans de fout wordpress missing mysql extension veroorzaakt in moderne PHP 8.x-omgevingen.

Let op iets belangrijks.

In meer dan de helft van deze scenario’s is de extensie technisch gezien aanwezig. Het probleem is contextueel — verkeerde runtime, verkeerd configuratiebestand of een verkeerde service-restart.

Daarom lost het blind opnieuw installeren van pakketten vaak niets op.

Als geen van de bovenstaande rijen op jouw situatie van toepassing is, is het de moeite waard om naar het werkelijke gedrag van het systeem te kijken in plaats van alleen naar de theorie.

Laten we bekijken hoe dit er in de praktijk uitziet.

Praktijkvoorbeeld: na een upgrade naar PHP 8.3

Een veelvoorkomende situatie ziet er als volgt uit.

Een server draait PHP 8.1 zonder problemen.
Alles werkt.
De beheerder upgradet naar PHP 8.3.

Direct na de upgrade toont WordPress:

your php installation appears to be missing the mysql extension

De eerste reflex is om te denken dat PHP 8.3 MySQL-ondersteuning heeft laten vallen.

Dat is niet zo.

Wat er in veel van deze gevallen daadwerkelijk gebeurde:

• PHP 8.3 werd correct geïnstalleerd
• mysqli werd gecompileerd en was beschikbaar
• Nginx verwees nog steeds naar de oude 8.1-socket
• PHP-FPM 8.3 werd nooit opnieuw gestart

Vanuit het perspectief van WordPress faalde de databaselaag tijdens het opstarten. Daardoor verscheen de generieke foutmelding.

Bij CoDiCo hebben we dit patroon herhaaldelijk gezien tijdens versieovergangen. De oplossing was zelden het installeren van iets nieuws. Bijna altijd ging het om het uitlijnen van de runtime-lagen na de upgrade.

Zodra de webserver naar de juiste FPM-pool verwees en de service correct opnieuw werd gestart, verdween de fout meteen.

Randgevallen die je niet zou verwachten

Er zijn situaties waarin alles aan de oppervlakte correct lijkt. mysqli is zichtbaar in phpinfo(). De PHP-versie komt overeen met wat de server zou moeten draaien. De databasegegevens in wp-config.php lijken correct. En toch meldt WordPress nog steeds your php installation appears to be missing the mysql extension.

Op dit punt ligt het probleem meestal dieper in de stack.

Een van de meest over het hoofd geziene oorzaken is een socket-mismatch. Op veel Linux-systemen communiceert MySQL of MariaDB via een Unix-socketbestand in plaats van via TCP. Als het socketpad verandert tijdens een upgrade, kan PHP nog steeds mysqli laden, maar geen verbinding tot stand brengen. WordPress toont dan een generieke melding wordpress missing mysql extension, ook al werkt de extensie zelf perfect.

Een ander subtiel probleem verschijnt na MariaDB-upgrades. Standaard authenticatiemethoden of verbindingsinstellingen kunnen ongemerkt veranderen. Als PHP één configuratie verwacht terwijl de databaseserver nu een andere vereist, mislukt de handshake al vroeg. Vanuit de applicatielaag lijkt het alsof MySQL-ondersteuning ontbreekt. In werkelijkheid gaat het om een authenticatie- of transportprobleem.

SELinux kan ook interfereren. Op streng beveiligde systemen kunnen beveiligingsregels, zelfs wanneer mysqli is ingeschakeld en correct geladen, voorkomen dat PHP toegang krijgt tot de database-socket. De extensie is aanwezig, maar de runtime kan deze niet gebruiken. De foutmelding die volgt is misleidend, maar technisch gezien consistent met een mislukte database-initialisatie.

Aangepast gecompileerde PHP-builds introduceren nog een extra variabele. Als PHP is gecompileerd zonder mysqlnd, of is gebouwd tegen een incompatibele clientbibliotheek, kan de module geïnstalleerd lijken maar onvoorspelbaar gedrag vertonen. Deze gevallen zijn zeldzaam, maar wanneer ze optreden, werken standaard troubleshootingstappen niet omdat het probleem structureel is.

Containerorkestratie voegt nog meer complexiteit toe. In gedistribueerde omgevingen kan de databasehost die in wp-config.php is gedefinieerd, binnen het containernetwerk anders worden opgelost. Een verkeerd geconfigureerde servicenaam of omgevingsvariabele kan de connectiviteit verbreken, en WordPress kan opnieuw melden php missing mysql extension wordpress, zelfs wanneer de extensie correct binnen de container wordt geladen.

Het patroon in al deze randgevallen is consistent. De zichtbare fout beschrijft zelden de echte oorzaak. Ze geeft alleen aan dat WordPress zijn databaselaag niet kon initialiseren, waarbij de extensielaag simpelweg de eerste veronderstelling is.

Tegen de tijd dat je dit niveau van troubleshooting bereikt, gaat de oplossing niet langer over het installeren van pakketten. Het wordt een proces van het volgen van de uitvoeringsstroom, het controleren van configuratie-afstemming en het bevestigen dat elke laag precies communiceert zoals bedoeld.

Het goede nieuws is dat, zodra het echte breekpunt is gevonden, de oplossing meestal eenvoudig is. De moeilijkheid ligt niet in het toepassen van de correctie, maar in het vaststellen van de juiste laag.

Vervolgens bundelen we alles in een laatste diagnostische checklist, zodat je elke laag systematisch kunt controleren voordat je verder escaleert.

Lees ook: Een eenvoudige, duidelijke gids voor het bewerken van het functions.php-bestand in WordPress

Laatste diagnostische checklist

Als je dit probleem op een duidelijke en systematische manier wilt oplossen zonder steeds willekeurige fixes te proberen, gebruik dan de onderstaande checklist. Deze is bedoeld voor precies de situatie waarin WordPress blijft melden your php installation appears to be missing the mysql extension, terwijl de echte oorzaak verborgen kan zitten in de runtimecontext.

• Controleer de PHP-versie in de browser via phpinfo(), niet alleen via SSH. Als CLI- en webversies verschillen, debug je niet dezelfde runtime.
• Controleer in phpinfo() of mysqli of pdo_mysql wordt vermeld. Als geen van beide verschijnt, ontbreekt de extensie daadwerkelijk.
• Controleer het pad bij Loaded Configuration File. Zorg ervoor dat de php.ini die je bewerkt daadwerkelijk door de webruntime wordt geladen.
• Zoek extension_dir en controleer of dit overeenkomt met de actieve PHP-build. Een verkeerd pad kan stilletjes voorkomen dat modules worden geladen.
• Als je PHP-FPM gebruikt, controleer welke pool en welke socket door je webserver worden gebruikt. Na upgrades blijven Nginx- of Apache-configuraties vaak naar oudere sockets verwijzen.
• Herstart de juiste service. Het herstarten van “een” PHP-FPM-service is niet voldoende als er meerdere versies bestaan. De actieve service moet opnieuw worden gestart.
• Als de extensie geladen is maar de fout blijft bestaan, controleer de databaseverbinding: servicestatus, hosttype (socket vs TCP) en of het socketpad is gewijzigd.
• Controleer opnieuw wp-config.php voor DB_HOST. In containeromgevingen is de juiste host vaak een servicenaam in plaats van localhost.
• Als je systeem SELinux of andere streng beveiligde policies gebruikt, controleer dan of PHP toegang heeft tot de databasesocket of netwerkpoort.
• Verwijder het bestand info.php zodra je klaar bent. Het publiek toegankelijk laten is een beveiligingsrisico.

Als je alle bovenstaande punten kunt afvinken en de site nog steeds niet werkt, zit je niet langer in het “ontbrekende extensie”-scenario. In dat stadium gaat het om een dieper infrastructuur- of buildconsistentieprobleem, niet om een WordPress-updateprobleem.

FAQ

Waarom zegt WordPress dat de MySQL-extensie ontbreekt als MySQLi geïnstalleerd is?

Omdat de melding verouderde formulering gebruikt. WordPress heeft mysqli of pdo_mysql nodig, maar als PHP ze niet laadt in de actieve runtime, of als de runtimecontext niet overeenkomt, kan WordPress toch wordpress missing mysql extension-fouten tonen.

Ondersteunt PHP 8.3 nog steeds MySQL?

Ja. PHP 8.3 ondersteunt MySQL via mysqli en pdo_mysql. Als je php missing mysql extension wordpress ziet, gaat het meestal om een configuratie- of runtime-afstemmingsprobleem en niet om ontbrekende ondersteuning in PHP zelf.

Hoe schakel ik MySQLi in PHP in?

Op de meeste systemen doe je dit door het juiste pakket te installeren (vaak php-mysql) of de module in je hostingpaneel te activeren. Op Windows kan het nodig zijn om extension=mysqli in php.ini te decommentariëren. Het belangrijkste detail is dat je het inschakelt voor de PHP-runtime die je webserver daadwerkelijk gebruikt.

Waarom toont php -m mysqli, maar werkt WordPress nog steeds niet?

Omdat php -m de CLI-runtime controleert. Je webserver kan een andere PHP-versie gebruiken, een andere php.ini laden of een andere PHP-FPM-pool draaien. Dit is een van de meest voorkomende oorzaken achter situaties met fix mysql extension error wordpress.

Kan deze fout worden veroorzaakt door onjuiste databasegegevens?

Ja. Als WordPress vroeg faalt tijdens de initialisatie van de database, kan de foutmelding misleidend zijn. Verkeerde inloggegevens, een niet draaiende databaseservice of een socket-mismatch kunnen vergelijkbare symptomen veroorzaken, zelfs wanneer mysqli geladen is.

Wordt dit probleem meestal opgelost door WordPress bij te werken?

Soms, maar in moderne configuraties niet vaak. In PHP 8.x-omgevingen hangt deze fout meestal samen met serverconfiguratie en niet met verouderde WordPress corebestanden.

Afsluitende opmerking

In de meeste praktijkgevallen is your php installation appears to be missing the mysql extension geen WordPress-probleem en ook geen kwestie van “PHP opnieuw installeren”. Het is een signaal dat één laag in de PHP-runtimeketen niet goed is afgestemd. Zodra je vaststelt welke runtime het verzoek daadwerkelijk verwerkt en bevestigt dat mysqli of pdo_mysql daar geladen is, is de oplossing meestal direct.

Bij CoDiCo komen de snelste oplossingen bijna altijd voort uit het eerst controleren van runtime-afstemming, niet uit het installeren van extra pakketten.