wp-config.php: de essentiële instellingen die elke WordPress-eigenaar moet kennen

Scope en versies. Deze naslag behandelt de wp-config.php-constanten die je het meest tegenkomt, aanpast of verklaard moet krijgen, voor WordPress 5.5 en nieuwer, met expliciete notities waar een constante pas vanaf een latere versie bestaat (WordPress 5.5 introduceerde WP_ENVIRONMENT_TYPE, WordPress 6.3 introduceerde WP_DEVELOPMENT_MODE). Bewust gekozen, niet uitputtend. De officiële wp-config.php-reference uit het Advanced Administration Handbook somt elke constante op die WordPress herkent, en het APIs-handbook behandelt ze nog een keer vanuit een developer-hoek. Dit artikel kiest de subset die in de dagelijkse praktijk telt en legt uit wat de defaults echt betekenen.

Eerst een kleine kadering. Elke constante hieronder is een PHP define() die moet draaien voordat wp-settings.php start, en daarom zet WordPress de markering /* That's all, stop editing! Happy publishing. */ in het meegeleverde bestand. Constanten die je onder die regel plakt, worden in sommige bootstrap-situaties genegeerd. De regel is dus simpel: zet nieuwe defines boven die markering, niet eronder.

Wat wp-config.php regelt

wp-config.php staat in de WordPress-root (of, in een gehardende setup, één map hoger, daar kijkt WordPress automatisch). Het is een PHP-bestand dat heel vroeg in de WordPress-bootstrap door wp-load.php wordt geladen, en het zet de omgeving op waar wp-settings.php daarna de rest van core mee initialiseert. Het regelt grofweg drie dingen:

• Bootstrap-parameters: database-credentials, table prefix, site-URLs, filesystem-methode, cache-includes. Deze worden ingelezen voordat WordPress-core draait.
• Runtime-toggles: debug-flags, memory-limieten, environment type, cron-gedrag. Deze worden gelezen terwijl WordPress draait en sturen het gedrag van elk request.
• Security-constanten: keys en salts die wp_salt() gebruikt om authentication-cookies en nonces te salten.

Omdat het een gewoon PHP-bestand is, worden wijzigingen actief bij het volgende request. Geen service te restarten, geen cache te flushen, geen daemon te reloaden. Dit is een hardnekkig misverstand (onderaan dit artikel staat de uitleg), en het brengt site-eigenaren in verwarring die denken dat wp-config.php zich gedraagt als een PHP-ini-bestand.

Database-verbinding

De vier database-constanten zijn wat de WordPress-installer als eerste neerzet. Ze zijn verplicht en het zijn de enige plek waar WordPress credentials voor MySQL of MariaDB opslaat:

Een vuistregel: als WordPress Error establishing a database connection toont, check dan als eerste of DB_HOST klopt met wat je host werkelijk aanbiedt. Veel shared hosts gebruiken een andere hostname dan localhost, en veel managed hosts wijzigen dit tijdens een servermigratie zonder het te melden.

WordPress-URLs

WP_SITEURL en WP_HOME zijn optionele overrides voor de twee URL-waarden die WordPress anders in de wp_options-tabel bewaart als siteurl en home. Ze in wp-config.php zetten heeft drie praktische effecten:

1. De URLs staan niet meer in de database, dus een search-replace na een migratie hoeft er niet meer langs.
2. De URLs zijn op slot, dus een beheerder kan ze niet per ongeluk wijzigen in Instellingen > Algemeen en zichzelf uitloggen.
3. Het lost redirect loops op die kunnen ontstaan als de database een andere URL bevat dan de browser feitelijk gebruikt, bijvoorbeeld na een haastige HTTP-naar-HTTPS-overstap.

define( 'WP_HOME', 'https://jouwsite.nl' );
define( 'WP_SITEURL', 'https://jouwsite.nl' );

WP_HOME is de URL die bezoekers zien (de voorkant van de site). WP_SITEURL is waar de WordPress-core staat. In de meeste installaties zijn ze gelijk. Ze verschillen alleen als je WordPress-core in een eigen submap plaatst terwijl de voorkant op de root blijft.

Gebruik geen trailing slash. WordPress verwacht de URL zonder.

Memory-limieten

WordPress heeft twee memory-limit-constanten, en beide zijn ondergeschikt aan PHP's memory_limit, niet aan iets in WordPress zelf. WordPress kan nooit meer geheugen allocaten dan PHP toestaat; deze constanten verhogen alleen het plafond binnen wat PHP toelaat.

Deze defaults staan in het APIs-handbook genoemd. De normale oorzaak van Allowed memory size exhausted is een specifieke plugin die boven de 40M-front-end-default uitkomt. Dat getal stamt uit de tijd voor 2010 en slaat op moderne servers nergens meer op. Beide constanten verhogen kan gewoon, mits de onderliggende PHP memory_limit het toelaat; het feitelijke plafond is de laagste van de twee.

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Staan deze waarden al hoog en crasht de site toch met een memory-fout? Dan zit de bottleneck in PHP zelf. Kijk in php.ini of het PHP-paneel van je host.

Debug-instellingen

Debug is waar de meeste schade wordt aangericht, omdat de default bij WP_DEBUG = true ook meteen fouten toont op de voorkant van de site. De officiële debug-guide is daar expliciet over: "It is not recommended to use WP_DEBUG or the other debug tools on live sites; they are meant for local testing and staging installs."

De veilige debug-pattern voor productie is loggen zonder tonen:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', '0' );

De display_errors-override hoort erbij, omdat sommige PHP-errortypes door de outputfilters van WordPress heen glippen als PHP's eigen display-toggle nog aanstaat. Zonder die regel lek je alsnog foutmeldingen naar bezoekers.

Nog een beveiligingspunt: wp-content/debug.log is schrijfbaar voor de PHP-user en, bij default, gewoon te bereiken via /wp-content/debug.log door de webserver, dus iedereen die het pad weet of gokt, kan je errors lezen. Als je WP_DEBUG_LOG in productie aanzet, ook al is het even, wijs het bestand dan aan buiten de webroot, of voeg een .htaccess- of nginx-regel toe die de toegang blokkeert. Het Advanced Administration Handbook vlagt dit expliciet als beveiligingsrisico.

Krijg je zodra debug-logging aanstaat een stroom aan set_time_limit()-meldingen? Dan zit je in het gebied van Maximum execution time exceeded, dat vaak pas opvalt als debug-logging aanstaat en een trage plugin begint te klagen.

Security keys en salts

WordPress genereert deze als acht constanten: vier keys (AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY) en vier salts (AUTH_SALT, SECURE_AUTH_SALT, LOGGED_IN_SALT, NONCE_SALT). Hun enige taak is input leveren voor wp_salt(), dat de salts produceert waarmee WordPress authentication-cookies en nonces hasht.

Ze versleutelen niets. Ze raken de database niet. Ze worden niet op wachtwoorden in rust toegepast. Dit is het misverstand-stuk om even rustig te lezen: security keys zijn salts voor hashes die session-cookies en CSRF-nonces gebruiken, meer niet.

Genereer ze via https://api.wordpress.org/secret-key/1.1/salt/, dat elk request een verse set teruggeeft. Plak de acht regels in wp-config.php en vervang de bestaande waarden.

Wat gebeurt er als je ze roteert? Alle bestaande cookies worden ongeldig, dus elke ingelogde gebruiker (jij dus ook) wordt onmiddellijk uitgelogd. Elk formulier dat nu net met een nonce bezig is, wordt ook ongeldig. Daarom roteer je keys bewust, meestal als onderdeel van incident response, en niet op een schema. Snicco's "How WordPress Uses Salts and Why You Should Not Rotate Them" onderbouwt uitgebreid waarom schema-rotatie geen beveiligingswinst oplevert, wel operationele kosten.

Filesystem-instellingen

Zodra WordPress zelf bestanden moet schrijven (core-updates, plugin-installs, theme-updates), gebruikt het de WP_Filesystem-API, die een "method" kiest op basis van wat schrijfbaar is. Twee constanten sturen dat gedrag:

De reden om FS_METHOD expliciet te zetten is het "please enter your FTP credentials"-scherm. Als FS_METHOD auto-detecteert en de PHP-user niet eigenaar is van de WordPress-bestanden (een klassieke shared-hosting-misconfiguratie), valt WordPress terug op FTP-credentials vragen bij elke update. De combinatie define( 'FS_METHOD', 'direct' ); samen met het eigenaarschap van wp-content bijzetten naar de PHP-user is wat die prompt permanent wegneemt. Als direct niet werkt omdat het eigenaarschap echt niet aan te passen is, waarschuwt die prompt voor een reëel permissie-probleem en is hem verbergen erger dan hem zien.

Environment flags

Dit zijn de runtime-flags die senior admins zetten om een site vast te zetten of gedrag te scopen voor een specifieke omgeving.

De constante die de meeste mensen in de war brengt, is DISALLOW_FILE_EDIT. De default is altijd false geweest (editor staat aan). Op true zetten is een expliciete keuze. WordPress 4.9 heeft hem niet geïntroduceerd en heeft de default niet gewijzigd; wat 4.9 wel toevoegde, is een loopback-gebaseerde fatal-error-sandbox rondom de editor, een heel andere feature. De constante zelf bestaat ongeveer sinds WordPress 2.9.

wp-config.php veilig bewerken

Vier regels die meer sites redden dan welke configuratiewaarde dan ook.

1. Maak eerst een backup. Een kapotte wp-config.php legt de hele site plat met een wit scherm, want elk request laadt dit bestand. Kopieer het naar wp-config.php.bak voordat je iets aanraakt, of gebruik de "dupliceer"-optie van je filemanager. Terugzetten is één commando; om twee uur 's nachts een syntax error debuggen zonder backup is dat niet.
2. Zet nieuwe defines boven de "stop editing"-comment. Het meegeleverde bestand eindigt met /* That's all, stop editing! Happy publishing. */ en daarna de include van wp-settings.php. Alles erboven draait voordat WordPress wordt geladen. Alles eronder draait pas als core al opgestart is, waardoor sommige constanten daar gewoon niet meer werken.
3. Plak geen snippets met smart quotes. Copy-pasten uit blogs zet rechte quotes (" en ') nogal eens om in typografische quotes (" en '), die PHP als syntax error weigert. Als de site breekt na een paste, is dit meestal de oorzaak. Typ de aanhalingstekens liever zelf over.
4. Scherpe file-permissies. Omdat wp-config.php het databasewachtwoord in platte tekst bevat, zijn de permissies belangrijk. De hardening-guide adviseert 440 of 400, in eigendom van de user die PHP draait. Op shared hosts kom je soms niet onder 644; dat is een beperking van je hostingomgeving, niet iets wat je in wp-config.php zelf kunt fixen.

Wijzigingen worden meteen actief bij het volgende request. Je hoeft PHP-FPM niet te restarten. Het hardnekkige misverstand "wp-config.php wijzigingen vragen om een PHP-FPM restart" komt uit een ander probleem: OPcache dat verouderde kopieën van PHP-bestanden blijft serveren omdat de server opcache.validate_timestamps=0 heeft staan. Dat is een server-misconfiguratie, geen normaal WordPress-gedrag, en de fix is OPcache fixen, niet PHP restarten voor elke wp-config-wijziging.

Verwante artikelen

Als wp-config.php goed staat, zijn de drie errors waarvoor hij het vaakst de schuld krijgt de moeite waard om in volgorde te lezen, want elke error wijst terug naar een specifieke constante hierboven. Voor de database-variant: begin bij Error establishing a database connection. Voor de memory-variant: Allowed memory size exhausted in WordPress. Voor de PHP-timeout-variant: Maximum execution time exceeded.