Een van de belangrijkste bestanden van een WordPress installatie is het configuratiebestand. Het bevindt zich in de hoofdmap en bevat constante definities en PHP-instructies die WordPress laten werken zoals jij dat wilt.
Het wp-config.php bestand slaat gegevens op zoals informatie over de databaseconnectie, tabelprefixes, paden naar specifieke mappen en een heleboel instellingen gerelateerd aan specifieke functies waar we in dit artikel dieper op in zullen gaan.

Het basis wp-config.php bestand

Wanneer je WordPress voor het eerst installeert, wordt je gevraagd om de benodigde informatie in te voeren, zoals database details en tabel prefix. Soms zal je host WordPress voor je installeren, en hoef je de installatie niet handmatig uit te voeren. Maar wanneer je de 5-minuten installatie handmatig uitvoert, wordt je gevraagd om een aantal van de meest relevante gegevens in wp-config in te voeren.

Wanneer je de setup uitvoert, word je gevraagd om gegevens in te voeren die zijn opgeslagen in het bestand wp-config.php
Wanneer je de setup uitvoert, word je gevraagd om gegevens in te voeren die zijn opgeslagen in het bestand wp-config.php

Hier is een basis wp-config.php bestand:

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'database_name_here');

/** MySQL database username */
define('DB_USER', 'username_here');

/** MySQL database password */
define('DB_PASSWORD', 'password_here');

/** MySQL hostname */
define('DB_HOST', 'localhost');

/** Database Charset to use in creating database tables. */
define('DB_CHARSET', 'utf8');

/** The Database Collate type. Don't change this if in doubt. */
define('DB_COLLATE', '');

define('AUTH_KEY',		'put your unique phrase here');
define('SECURE_AUTH_KEY',	'put your unique phrase here');
define('LOGGED_IN_KEY',		'put your unique phrase here');
define('NONCE_KEY',		'put your unique phrase here');
define('AUTH_SALT',		'put your unique phrase here');
define('SECURE_AUTH_SALT',	'put your unique phrase here');
define('LOGGED_IN_SALT',	'put your unique phrase here');
define('NONCE_SALT',		'put your unique phrase here');

$table_prefix  = 'wp_';

/* That's all, stop editing! Happy blogging. */

Gewoonlijk wordt dit bestand automatisch gegenereerd wanneer je de set-up uitvoert, maar soms heeft WordPress geen rechten om in de installatiemap te schrijven. In deze situatie dien je een leeg wp-config.php bestand aan te maken, de inhoud van wp-config-sample.php te kopiëren en te plakken, en de juiste waarden in te stellen voor alle gedefinieerde constanten. Wanneer je klaar bent, upload je het bestand naar de hoofdmap en start je WordPress.

Opmerking: definities van constanten en PHP instructies hebben een specifieke volgorde, die we nooit mogen veranderen. En we mogen nooit inhoud toevoegen onder de volgende commentaarregel:

/* That's all, stop editing! Happy blogging. */

Eerst komen de definities van de databaseconstanten die je van je host zou moeten hebben ontvangen:

  • DB_NAME
  • DB_USER
  • DB_PASSWORD
  • DB_HOST
  • DB_CHARSET
  • DB_COLLATE

Na de databasegegevens, zie je acht beveiligingssleutels die de site veiliger maken tegen hackers. Wanneer je de installatie uitvoert, zal WordPress automatisch beveiligingssleutels en salt keys genereren, maar je kunt ze op elk moment wijzigen door een willekeurige string toe te voegen. Voor een betere beveiliging kun je overwegen om de online generator te gebruiken.

De variabele $table_prefix slaat de prefix van alle WordPress tabellen op. Helaas kent iedereen de standaardwaarde en gebruik hiervan zou de WordPress database kunnen blootstellen aan kwetsbaarheden, die eenvoudig kan worden verholpen door een aangepaste waarde in te stellen voor $table_prefix wanneer de setup wordt uitgevoerd.
Om de tabelprefix te veranderen in een werkende website, moet je verschillende queries uitvoeren voor de database, en dan handmatig het wp-config.php bestand aanpassen. Als je geen toegang hebt tot de database of je hebt niet de nodige kennis om aangepaste queries te bouwen, dan kan je een plugin installeren zoals Change Table Prefix die de databasetabellen en veldnamen zal hernoemen, en het config-bestand zal updaten zonder risico.

Opmerking: het is een goede gewoonte om een backup te maken van de WordPress bestanden en database, zelfs als je de tabel prefix wijzigt met een plugin.

Tot nu toe is de analyse beperkt gebleven tot de basis configuratie. Maar we hebben veel constanten tot onze beschikking die we kunnen definiëren om functies in te schakelen, de installatie aan te passen en te beveiligen.

Over de basisconfiguratie: het bewerken van het bestandssysteem

Het bestandssysteem van WordPress is goed bekend bij gebruikers en hackers. Om deze reden kun je overwegen om de ingebouwde bestandsstructuur te wijzigen door specifieke mappen te verplaatsen naar willekeurige locaties en de corresponderende URL’s en paden in wp-config bestand in te stellen.
Eerst kunnen we de inhoudsmap verplaatsen door twee constanten te definiëren. De eerste stelt het volledige directory pad in:

define( 'WP_CONTENT_DIR', dirname(__FILE__) . '/site/wp-content' );

De tweede stelt de URL van de nieuwe directory in:

define( 'WP_CONTENT_URL', 'http://example.com/site/wp-content' );

We kunnen alleen de plugin map verplaatsen door de volgende constanten te definiëren:

define( 'WP_PLUGIN_DIR', dirname(__FILE__) . '/wp-content/mydir/plugins' );
define( 'WP_PLUGIN_URL', 'http://example.com/wp-content/mydir/plugins' );

Op dezelfde manier kunnen we de uploads map verplaatsen, door het nieuwe directory pad in te stellen:

define( 'UPLOADS', 'wp-content/mydir/uploads' );

Opmerking: Alle paden zijn relatief ten opzichte van ABSPATH, en ze mogen geen leading slash bevatten.

Wanneer je klaar bent, orden de mappen en herlaad WordPress.

De afbeelding toont de ingebouwde bestandsstructuur vergeleken met een aangepaste structuur
De afbeelding toont de ingebouwde bestandsstructuur vergeleken met een aangepaste structuur

Het is niet mogelijk om de /wp-content/themes map te verplaatsen vanuit het wp-config bestand, maar we kunnen wel een nieuwe thema map registreren in een plugin of een thema’s functies bestand.

Features voor ontwikkelaars: debugmodus en queries opslaan

Als je een ontwikkelaar bent, kun je WordPress dwingen om fouten en waarschuwingen te tonen die je zullen helpen bij het debuggen van thema’s en plugin’s. Om debugmodus in te schakelen hoef je alleen maar WP_DEBUG waarde op true te zetten, zoals hieronder getoond:

define( 'WP_DEBUG', true );

WP_DEBUG is standaard ingesteld op false. Als je debug modus wilt uitschakelen, kun je simpelweg de definitie verwijderen, of de waarde van de constante op false zetten.
Wanneer je werkt aan een actieve site, moet je debugmodus uitschakelen. Fouten en waarschuwingen mogen nooit getoond worden aan bezoekers van de site, omdat dit waardevolle informatie kan opleveren voor hackers. Maar wat als je toch moet debuggen?
In dergelijke situaties kun je WordPress dwingen om het geheugen van fouten en waarschuwingen bij te houden in debug.log bestand, geplaatst in /wp-content map. Om deze functie in te schakelen, kopieer en plak je de volgende code in je wp-config.php bestand:

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

Om deze functie te laten werken moeten we eerst de debugmodus inschakelen. Dan, door WP_DEBUG_LOG op true te zetten, dwingen we WordPress om berichten op te slaan in debug.log bestand, terwijl we door WP_DEBUG_DISPLAY op false te zetten, ze verbergen van het scherm. Tenslotte zetten we de waarde van de PHP variabele display_errors op 0, zodat foutmeldingen niet op het scherm worden afgedrukt. wp-config wordt nooit uit de cache geladen. Om deze reden is het een goede plaats om php.ini instellingen te overschrijven.

Opmerking: Dit is een geweldige functie waarvan je gebruik kan maken om berichten te registreren die WordPress niet op het scherm zou afdrukken. Bijvoorbeeld, wanneer de publish_post actie wordt getriggerd laadt WordPress een script dat gegevens opslaat en vervolgens de gebruiker doorverwijst naar de pagina om het bericht te bewerken. In deze situatie kun je berichten registreren, maar niet op het scherm afdrukken.

Een andere debug-constante bepaalt de versies van scripts en stijlen die geladen moeten worden. Zet SCRIPT_DEBUG op true als je ongecomprimeerde versies wilt laden:

define( 'SCRIPT_DEBUG', true );

Als je thema of plugin gegevens toont die uit de database zijn opgehaald, wil je misschien de query details opslaan om ze later te kunnen bekijken. De SAVEQUERIES constante dwingt WordPress om query informatie op te slaan in $wpdb->queries array. Deze details zouden afgedrukt worden door de volgende code toe te voegen aan het footer template:

if ( current_user_can( 'administrator' ) ) {
        global $wpdb;
        echo '<pre>';
        print_r( $wpdb->queries );
        echo '</pre>';
}

Voor een diepere analyse van deze functie, zie Zo bouw je efficiënte queries op WordPress.

Contentgerelateerde instellingen

Wanneer je website groter wordt, wil je misschien het aantal berichtrevisies verminderen. Standaard slaat WordPress revisies automatisch elke 60 seconden op. We kunnen deze waarde veranderen door een aangepast interval in te stellen in wp-config – als volgt:

define( 'AUTOSAVE_INTERVAL', 160 );

Natuurlijk kun je het auto-save interval ook verminderen.
Telkens wanneer we onze bewerkingen opslaan, voegt WordPress een rij toe aan het posttabel, zodat we vorige revisies van posts en pagina’s kunnen terugzetten. Dit is een nuttige functionaliteit die een probleem kan worden wanneer onze site groter wordt. Gelukkig kunnen we het maximum aantal te bewaren postrevisies verlagen, of de functionaliteit helemaal uitschakelen.
Als je postrevisies wilt uitschakelen, definieer dan de volgende constante:

define( 'WP_POST_REVISIONS', false );

Als je het maximum aantal revisies wilt beperken, voeg dan de volgende regel toe:

define( 'WP_POST_REVISIONS', 10 );

Standaard bewaart WordPress weggegooide berichten, pagina’s, bijlagen en commentaren 30 dagen, daarna worden ze definitief verwijderd. We kunnen deze waarde veranderen met de volgende constante:

define( 'EMPTY_TRASH_DAYS', 10 );

We kunnen zelfs de prullenbak uitschakelen door de waarde op 0 te zetten, maar bedenk wel dat WordPress je dan niet meer zal toestaan dat je de content terugzet.

Toegestane geheugengrootte

Af en toe kun je een bericht als het volgende ontvangen:

Fatal error: Allowed memory size of xxx bytes exhausted …

De maximale geheugengrootte is afhankelijk van de serverconfiguratie. In het geval dat je geen toegang hebt tot php.ini bestand, kun je de geheugenlimiet alleen voor WordPress verhogen door de constante WP_MEMORY_LIMIT in wp-config bestand in te stellen.
Standaard probeert WordPress 40Mb aan PHP toe te wijzen voor enkele sites en 64 MB voor Multisite installaties. Natuurlijk, als PHP toegewezen geheugen groter is dan 40Mb (of 64Mb), zal WordPress de maximale waarde aannemen.
Dit gezegd hebbende, kun je een aangepaste waarde instellen met de volgende regel:

define( 'WP_MEMORY_LIMIT', '128M' );

Indien nodig kun je ook een maximale geheugenlimiet instellen, met de volgende verklaring:

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

Aanbevolen om te lezen: Zo verhoog je het PHP geheugenlimiet in WordPress.

Automatic Automatische updates

Vanaf versie 3.7 ondersteunt WordPress automatische updates voor beveiligingsreleases. Dit is een belangrijke functie die sitebeheerders in staat stelt hun website steeds veilig te houden.
Je kunt alle automatische updates uitschakelen door de volgende constante te definiëren:

define( 'AUTOMATIC_UPDATER_DISABLED', true );

Misschien is het geen goed idee om beveiligingsupdates uit te schakelen, maar het is jouw keuze.
Standaard werken automatische updates niet met grote releases, maar je kunt alle core updates inschakelen door WP_AUTO_UPDATE_CORE als volgt te definiëren:

# Disables all core updates:
define( 'WP_AUTO_UPDATE_CORE', false );

# Enables all core updates, including minor and major:
define( 'WP_AUTO_UPDATE_CORE', true );

De standaardwaarde is minor:

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Een extra constante schakelt auto-updates uit (en elke update of verandering aan een bestand). Als je DISALLOW_FILE_MODS op true zet, zullen alle bestandsbewerkingen worden uitgeschakeld, zelfs thema en plugin installaties en updates. Om deze reden wordt het gebruik hiervan niet aanbevolen.

Beveiligingsinstellingen

We kunnen het wp-config bestand gebruiken om de veiligheid van de site te verhogen. Naast de wijzigingen aan de bestandsstructuur die we hierboven hebben bekeken, kunnen we enkele functies vergrendelen die onnodige kwetsbaarheden zouden kunnen openen. Allereerst kunnen we de bestandseditor in het admin paneel uitschakelen. De volgende constante zal het Appearance Editor scherm verbergen:

define( 'DISALLOW_FILE_EDIT', true );

Opmerking: denk eraan dat sommige plugins niet goed werken als deze constante op true is gedefinieerd.

disallow_file_edit
disallow_file_edit

Een beveiligingsfunctie is Admin via SSL. Als je een SSL certificaat hebt aangeschaft, en het is correct geconfigureerd, kun je WordPress dwingen om gegevens over SSL te verzenden bij elke login- en adminsessie. Gebruik de volgende constante:

define( 'FORCE_SSL_ADMIN', true );

Raadpleeg de Codex als je meer informatie nodig hebt over Admin via SSL.

De andere twee constanten maken het mogelijk om externe verzoeken te blokkeren en een lijst van toegelaten hosts te maken.

define( 'WP_HTTP_BLOCK_EXTERNAL', true );
define( 'WP_ACCESSIBLE_HOSTS', 'example.com,*.anotherexample.com' );

In dit voorbeeld hebben we eerst alle toegang van externe hosts uitgeschakeld, daarna hebben we een lijst gemaakt van toegestane hosts, gescheiden door komma’s (wildcards zijn toegestaan).

Andere geavanceerde instellingen

WP_CACHE op true gezet bevat het wp-content/advanced-cache.php script. Deze constante heeft alleen effect als je een persistente caching plugin installeert.

CUSTOM_USER_TABLE en CUSTOM_USER_META_TABLE worden gebruikt om aangepaste gebruiker tabellen in te stellen anders dan de standaard wp_users en wp_usermeta tabellen. Deze constanten maken een handige functie mogelijk die websitegebruikers toegang geeft tot meerdere websites met slechts één account. Om deze functie te laten werken, moeten alle installaties dezelfde database delen.

Vanaf versie 2.9, ondersteunt WordPress Automatisch Database Optimalisatie. Dankzij deze functie, waarbij WP_ALLOW_REPAIR op true wordt gezet, zal WordPress een beschadigde database automatisch repareren.

WordPress maakt een nieuwe set afbeeldingen telkens wanneer je een afbeelding bewerkt. Als je de originele afbeelding herstelt, zullen alle gegenereerde sets op de server blijven staan. Je kunt dit gedrag overschrijven door IMAGE_EDIT_OVERWRITE op true te zetten, zodat, wanneer je de originele afbeelding terugzet, alle bewerkingen van de server worden verwijderd.

Vergrendel wp-config.php

Nu weten we waarom wp-config.php een van de meest belangrijke WordPress bestanden is. Dus, waarom verbergen we het niet voor hackers? Allereerst kunnen we wp-config een niveau boven de WordPress rootmap verplaatsen (slechts één niveau). Deze techniek is echter een beetje controversieel, dus ik zou voorstellen om andere oplossingen te gebruiken om het bestand te beschermen. Als je website op Apache Web Server draait, kun je de volgende directives toevoegen aan .htaccess bestand:

<files wp-config.php>
order allow,deny
deny from all
</files>

Als de website op Nginx draait, kun je de volgende directive toevoegen aan het configuratiebestand:

location ~* wp-config.php { deny all; }

Opmerking: deze instructies dienen pas te worden toegevoegd nadat de set-up is voltooid.

Als je website meerdere migraties heeft ondergaan of je hebt hem van iemand anders gekocht, is het aan te raden dat je een nieuwe set WordPress beveiligingssleutels aanmaakt. Deze sleutels zijn een set van willekeurige variabelen die de encryptie van informatie opgeslagen in de cookies van de gebruiker verbeteren. Sinds WordPress 2.7 zijn er 4 verschillende sleutels: AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, en NONCE_KEY.

Standaard worden ze willekeurig voor je gegenereerd. Maar WordPress heeft een gratis tool die je kunt gebruiken om nieuwe willekeurige sleutels te genereren. Je kan dan eenvoudig je huidige sleutels bijwerken die zijn opgeslagen in je wp-config.php bestand.

WordPress beveiligingssleutels
WordPress beveiligingssleutels

Lees meer over WordPress beveiligingssleutels.

En tenslotte, moet je dubbel controleren en ervoor zorgen dat je toegangsrechten op je wp-config.php bestand zijn verhard. Normaal gesproken worden bestanden in de rootdirectory van een WordPress site ingesteld op 644, wat betekent dat bestanden leesbaar en schrijfbaar zijn door de eigenaar van het bestand en leesbaar door gebruikers in de groep eigenaar van dat bestand en leesbaar door alle anderen. Volgens de WordPress documentatie zouden de rechten op het wp-config.php bestand op 440 of 400 gezet moeten worden om te voorkomen dat andere gebruikers op de server het kunnen lezen. Je kan dit eenvoudig wijzigen met je FTP client.

wp-config.php toegangsrechten
wp-config.php toegangsrechten

Summary

In deze post heb ik een lijst gemaakt van WordPress constanten die we kunnen definiëren in wp-config bestand. Sommige van deze constanten worden vaak gebruikt, en hun functies zijn gemakkelijk te begrijpen. Andere constanten maken geavanceerde functies mogelijk die een diepgaande kennis van WordPress en site administratie vereisen.

Ik heb de meest voorkomende functies opgesomd, en laat enkele geavanceerde functies buiten beschouwing die we in toekomstige posts kunnen bespreken. Als je functies en constanten wil verkennen die hier niet vermeld zijn, voel je gerust om een gesprek te starten in de comments hieronder en we zullen diep in het onderwerp duiken.

Carlo Daniele Kinsta

Carlo is een gepassioneerd liefhebber van webdesign en front-end development. Hij werkt al meer dan 10 jaar met WordPress, ook in samenwerking met Italiaanse en Europese universiteiten en onderwijsinstellingen. Hij heeft tientallen artikelen en gidsen over WordPress geschreven, gepubliceerd op zowel Italiaanse als internationale websites en in gedrukte tijdschriften. Je kunt Carlo vinden op X en LinkedIn.