Le guide pour vous apprendre à modifier le fichier WordPress wp-config.php

30 avril 2021

L’un des fichiers les plus importants d’une installation WordPress est sans conteste le fichier wp-config.php. Il est situé à la racine du répertoire de WordPress et contient les configurations de base de votre site web, comme les informations de connexion à la base de données.

Quand vous téléchargez WordPress le fichier wp-config.php n’existe pas. Le programme d’installation automatique se charge de le créer pour vous à partir des informations que vous saisissez.

Vous pouvez créer manuellement un fichier wp-config.php en éditant le fichier wp-config-sample.php qui est situé à la racine du répertoire d’installation puis en le sauvegardant sous le nom de wp-config.php.

Note : le contenu du fichier wp-config-sample.php est ordonné de manière spécifique. Cet ordre est important. Si un fichier wp-config.php existe déjà, le fait de changer l’ordre de son contenu peut provoquer des erreurs sur votre site.

Pour modifier le fichier wp-config.php de votre installation, vous aurez besoin des informations suivantes :

Nom de la base données utilisée par WordPress ;
Nom d’utilisateur utilisé pour accéder à la base de données ;
Mot de passe de l’utilisateur utilisé pour accéder à la base de données ;
Nom du serveur de la base de données. Un numéro de port, un socket Unix ou un pipe peuvent également être nécessaires.

Si votre hébergeur a installé WordPress pour vous, vous pourrez récupérer ces informations auprès de ce dernier. Si vous gérez vous même votre serveur web ou compte d’hébergement, vous aurez ces informations lorsque vous créez une base de données et un utilisateur.

Base de données

Important : utilisez un éditeur de texte pour modifier les fichiers de WordPress. N’utilisez pas un logiciel de traitement de texte comme Word. Personnellement, j’emploie Notepad++.

Localisez le fichier wp-config-sample.php à la racine de votre installation et ouvrez-le avec un éditeur de texte.

Connexion

Voici les réglages par défaut du fichier wp-config-sample.php. Pour connecter votre base de données, vous devrez adapter les valeurs des exemples suivants à votre configuration.
Les textes entre /** */ sont des commentaires et ne sont pas lus par WordPress.

// ** Réglages MySQL - Votre hébergeur doit vous fournir ces informations. ** //
/** Nom de la base de données de WordPress. */
define( 'DB_NAME', 'votre_nom_de_bdd' );

/** Utilisateur de la base de données MySQL. */
define('DB_USER', 'votre_utilisateur_de_bdd');

/** Mot de passe de la base de données MySQL. */
define('DB_PASSWORD', 'votre_mdp_de_bdd');

/** Adresse de l’hébergement MySQL. */
define('DB_HOST', 'localhost');

Nom de la base données

Remplacez votre_nom_de_bdd par le nom de votre base de données, par exemple ma_base_de_donnees.

define( 'DB_NAME', 'ma_base_de_donnees' ); // Exemple de nom de base de données MySQL

Nom d’utilisateur

Remplacez votre_utilisateur_de_bdd, par le nom d’utilisateur utilisé pour accéder à la base de données, par exemple mon_utilisateur_de_bdd.

define( 'DB_USER', 'mon_utilisateur_de_bdd' ); // Nom d’utilisateur de base de données

Mot de passe

Remplacez votre_mdp_de_bdd par le mot de passe de l’utilisateur, par exemple mon_mdp_de_bdd.

define( 'DB_PASSWORD', 'mon_mdp_de_bdd' ); // Mot de passe de base de données

Nom du serveur

Remplacez localhost par le nom du serveur de la base de données, par exemple mon_hote_de_bdd. Un numéro de port ou un socket Unix peuvent également nécessaires.

define( 'DB_HOST', 'mon_hote_de_bdd' ); // Hôte de base de données

Note : il est probable que vous n’ayez pas besoin de modifier cette valeur. Si vous n’êtes pas sûr, essayez de laisser la valeur par défaut (localhost) et si l’installation échoue, contactez votre hébergeur.

Port MySQL alternatif

Si votre serveur de base de données utilise un port alternatif vous devrez changer la valeur de DB_HOST par la valeur donnée par votre hébergeur.

Pour localhost :

define( 'DB_HOST', '127.0.0.1:3307' );

dans certains cas la valeur sera :

define( 'DB_HOST', 'localhost:3307' );

Pour un serveur spécifique :

define( 'DB_HOST', 'mysql.example.com:3307' );

Remplacez 3307 par le numéro de port de votre serveur.

Sockets ou Pipes MySQL

Si votre serveur utilise des sockets Unix ou des pipes, ajustez la valeur de DB_HOST en fonction, par exemple :

define( 'DB_HOST', '127.0.0.1:/var/run/mysqld/mysqld.sock' );
// or define( 'DB_HOST', 'localhost:/var/run/mysqld/mysqld.sock' );
// or define( 'DB_HOST', 'example.tld:/var/run/mysqld/mysqld.sock' );

Remplacez /var/run/mysqld/mysqld.sock par le socket ou le pipe fourni par votre hébergeur.

Les valeurs possibles de DB_HOST

Les hébergeurs utilisent des configurations différentes pour leurs bases de données MySQL. Si votre hébergeur est listé dans le tableau ci-dessous dans la colonne de gauche, référez-vous à la colonne de droite correspondante pour connaître la valeur de DB_HOST.
Si votre hébergeur ne se trouve pas dans le tableau contactez-le ou consultez sa documentation en ligne.

Hébergeur	Valeur de DB_HOST
1and1	db12345678
A2 Hosting	localhost
AN Hosting	localhost
Aruba.it	localhost ou l’adresse IP fournie dans le mail d’activation.
A Small Orange	localhost
AT&T	xxxxxxxx.carrierzone.com l’adresse complète du serveur située dans PHPMyAdmin.
BlueHost	localhost
DreamHost	mysql.example.com
GoDaddy – Shared and 4GH Hosting	Dans le menu databases/bases de données, allez dans MySQL. À la droite du nom de la base de données, cliquez sur actions dans details/actions et détails. Le nom du serveur est en bas de la fenêtre.
GoDaddy – cPanel Hosting	localhost
GoDaddy – Plesk Hosting	Utilisez l’adresse IP affichée dans la section databases/bases de données de Plesk. N’incluez pas :3306.
HostGator	localhost
ICDSoft	localhost:/tmp/mysql5.sock
Infomaniak Network	mysql.yourdomain
InMotion Hosting	localhost
iPage	username.ipagemysql.com
IPower	username.ipowermysql.com
Laughing Squid	localhost
MediaTemple Grid	internal-db.s00000.gridserver.com – (Remplacez « 00000 » par le numéro du site)
MediaTemple DV	localhost
MegaHost	localhost
NearlyFreeSpeech.Net	username.db
NetworkSolutions	mysqlv5
one.com	example.com.mysql
OVH	nomdelabase.mysql.db
pair Networks	dbnnnx.pair.com
QTH.com	localhost
SysFix.eu Power Hosting	datapower.sysfix.eu
Site5	localhost
Yahoo	mysql
Hosts with cPanel	localhost
Hosts with Plesk	localhost
Hosts with DirectAdmin	localhost
Tophost.it	sql.your-domain-name.it

Jeu de caractères

DB_CHARSET permet de désigner le jeu de caractères de la base de données (par exemple tis620 pour TIS620 Thaï) à utiliser lors de la définitions des tables de la base de données MySQL

La valeur par défaut utf8 (Unicode UTF-8 – en anglais) est la plupart du temps la meilleure option car il supporte toutes les langues. En général on laisse DB_CHARSET sur utf8 et on utilise DB_COLLATE pour spécifier une langue.

La valeur par défaut de DB_CHARSET dans WordPress est :

define( 'DB_CHARSET', 'utf8' );

En général il n’y a pas de raison de changer la valeur par défaut de DB_CHARSET. Si votre site a besoin d’un jeu de caractères différent, lisez Character Sets and Collations MySQL Supports (en anglais) pour connaître les valeurs valides.
Attention aux changements effectués sur la base de données par ce réglage.

Si DB_CHARSET et DB_COLLATE n’existent pas dans votre fichier wp-config.php, ne les ajoutez pas avant d’avoir lu et compris comment convertir le jeu de caractères de la base de données. Le fait d’ajouter ces réglages au fichier wp-config.php d’un site existant peut causer d’importants problèmes.

Interclassement

DB_COLLATE permet de désigner l’interclassement de la base de données (par exemple l’ordre de titre du jeu de caractères). Dans la plupart des cas, cette valeur doit être laissée vide (null) pour que l’interclassement soit automatiquement assigné par MySQL en fonction du jeu de caractères spécifié par DB_CHARSET.

Un exemple de cas où vous devrez peut-être définir DB_COLLATE sur l’une des valeurs UTF-8 définies dans les jeux de caractères UTF-8 (en anglais) pour la plupart des langues d’Europe occidentale serait lorsqu’une langue différente dans laquelle les caractères que vous avez saisis sont différents de ce qui est affiché.

La valeur par défaut de DB_COLLATE dans WordPress est :

define( 'DB_COLLATE', '' );

Interclassement général Unicode UTF-8 :

define( 'DB_COLLATE', 'utf8_general_ci' );

Interclassement UT-8 Turque :

define( 'DB_COLLATE', 'utf8_turkish_ci' );

En général il n’y a pas de raison de changer la valeur par défaut de DB_COLLATE. Laisser cette valeur vide (null) permettra à MySQL de la définir automatiquement quand la base de données est créée.
Attention aux changements effectués sur la base de données par ce réglage.

Si DB_CHARSET et DB_COLLATE n’existent pas dans votre fichier wp-config.php, ne les ajoutez pas avant d’avoir lu et compris comment convertir le jeu de caractères de la base de données. Le changement des ces valeurs peut nécessiter une mise à jour de WordPress.

Clés de sécurité

Vous n’avez pas besoin de mémoriser ces clés, faites juste en sorte qu’elles soient longues, aléatoires et complexes. Le plus simple et sécurisé est d’utiliser le générateur en ligne. Vous pouvez changer ces clés à n’importe quel moment pour invalider les cookies existants. Cela ne veut pas dire que tous les utilisateurs devront se reconnecter.

Par exemple (n’utilisez pas ces clés !) :

define( 'AUTH_KEY',         't`DK%X:>xy|e-Z(BXb/f(Ur`8#~UzUQG-^_Cs_GHs5U-&Wb?pgn^p8(2@}IcnCa|' );
define( 'SECURE_AUTH_KEY',  'D&ovlU#|CvJ##uNq}bel+^MFtT&.b9{UvR]g%ixsXhGlRJ7q!h}XWdEC[BOKXssj' );
define( 'LOGGED_IN_KEY',    'MGKi8Br(&{H*~&0s;{k0<S(O:+f#WM+q|npJ-+P;RDKT:~jrmgj#/-,[hOBk!ry^' );
define( 'NONCE_KEY',        'FIsAsXJKL5ZlQo)iD-pt??eUbdc{_Cn<4!d~yqz))&B D?AwK%)+)F2aNwI|siOe' );
define( 'AUTH_SALT',        '7T-!^i!0,w)L#JK@pc2{8XE[DenYI^BVf{L:jvF,hf}zBf883td6D;Vcy8,S)-&G' );
define( 'SECURE_AUTH_SALT', 'I6`V|mDZq21-J|ihb u^q0F }F_NUcy`l,=obGtq*p#Ybe4a31R,r=|n#=]@]c #' );
define( 'LOGGED_IN_SALT',   'w<$4c$Hmd%/*]`Oom>(hdXW|0M=X={we6;Mpvtg+V.o<$|#_}qG(GaVDEsn,~*4i' );
define( 'NONCE_SALT',       'a|#h{c5|P &xWs4IZ20c2&%4!c(/uG}W:mAvy<I44`jAbup]t=]V<`}.py(wTP%%' );

Ces clés de sécurités rendent votre site plus difficilement attaquables en ajoutant des éléments aléatoires aux mots de passes.

Une clé secrète est un est mot de passe contenant des éléments qui rendent plus difficiles les attaques qui consistent à deviner les mots de passe.
Un mot de passe comme « password » ou « test » est simple et facile à deviner. Au contraire, un mot de passe long et aléatoire comme « 88a7da62429ba6ad3cb3c76a09641fc » prendra des années à être deviné lors d’une attaque. Une clé de « salage » est utilisée pour améliorer encore la sécurité du résultat généré.

Les quatre clés sont nécessaires pour une sécurité renforcée. Si elles n’existent pas dans le fichier wp-config.php WordPress les générera automatiquement.

Pour plus d’informations sur le contexte technique et la répartition des clés secrètes et des mots de passe sécurisés, ces articles (en anglais) peuvent être consultés :

Options avancées

Les sections suivantes peuvent contenir des informations sur des sujets avancés et certaines modifications peuvent entraîner des problèmes imprévus. Assurez-vous d’effectuer des sauvegardes régulièrement et de savoir comment les restaurer avant toute modification.

table_prefix

La variable $table_prefix représente la valeur ajoutée avant le nom de vos tables dans la base de données. Vous pouvez changer cette valeur pour utiliser autre chose que la valeur par défaut (wp_), par exemple si vous installez plusieurs sites dans la même base de données, comme c’est le cas pour le multisite.

$table_prefix = 'r235_'; // Uniquement des lettres, chiffres et underscores

WP_SITEURL

WP_SITEURL permet de définir l’adresse où sont situés les fichiers de WordPress. Elle doit contenir https:// en début et pas de slash / à la fin.
La valeur de WP_SITEURL surpasse l’option siteurl de la table wp_options.
Ajouter cette constante peut réduire le nombre d’appels à la base de données au chargement de votre site.

Remarque : définir WP_SITEURL ne change pas les valeurs de la base de données. Utilisez la constante RELOCATE si vous souhaitez modifier la valeur de siteurl de la base de données depuis le fichier wp-config.php.

Si WordPress est installé dans un répertoire « wordpress » sur le nom de domaine example.com, voici la valeur à définir :

define( 'WP_SITEURL', 'http://example.com/wordpress' );

Définir dynamiquement WP_SITEURL en fonction de $_SERVER['HTTP_HOST'] :

define( 'WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST'] . '/path/to/wordpress' );

Remarque : HTTP_HOST est créé dynamiquement par PHP sur la base de la valeur de l’en-tête HTTP HOST dans la requête, ce qui permet éventuellement les vulnérabilités d’inclusion de fichiers (en anglais), ou Systèmes de détection et de prévention d’intrusions dans les systèmes distribués.

SERVER_NAME peut également être créé dynamiquement. Cependant, lorsqu’Apache est configuré avec UseCanonicalName sur « on », SERVER_NAME est défini par la configuration du serveur, au lieu d’être créé dynamiquement. Dans ce cas, il est plus sûr d’utiliser SERVER_NAME que HTTP_HOST.

Définir dynamiquement WP_SITEURL à partir de $_SERVER['SERVER_NAME'] :

define( 'WP_SITEURL', 'http://' . $_SERVER['SERVER_NAME'] . '/path/to/wordpress' );

Adresse du site

Comme WP_SITEURL, WP_HOME surpasse l’option home de la table wp_options (en anglais) mais ne change pas sa valeur en base de données. Cette valeur correspond à l’adresse à laquelle votre site WordPress est accessible. Elle doit contenir https:// en début et pas de slash / à la fin.
La valeur de WP_SITEURL surpasse l’option siteurl de la table wp_options (en anglais).
Ajouter cette constante peut réduire le nombre d’appels à la base de données au chargement de votre site.

define( 'WP_HOME', 'http://example.com' );

Si vous donnez à WordPress son propre répertoire alors suivez l’exemple ci-dessous. Rappelez-vous qu’il faut placer un fichier index.php à la racine de votre répertoire web si vous utilisez ce type de configuration.

define( 'WP_HOME', 'http://example.com/wordpress' );

Définir dynamiquement WP_HOME à partir de $_SERVER['HTTP_HOST'] :

define( 'WP_HOME', 'http://' . $_SERVER['HTTP_HOST'] . '/path/to/wordpress' );

Déplacer le répertoire wp-content

Vous pouvez déplacer le répertoire wp-content – qui contient vos thèmes, extensions et fichiers téléversés – à l’extérieur du répertoire de WordPress.

WP_CONTENT_DIR doit contenir le chemin local complet du répertoire, sans slash à la fin, par exemple :

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

WP_CONTENT_URL doit contenir l’adresse complète du répertoire, sans slash à la fin, par exemple :

define( 'WP_CONTENT_URL', 'http://example/blog/wp-content' );

Déplacer le répertoire des extensions

WP_PLUGIN_DIR doit avoir pour valeur le chemin local complet du répertoire, sans slash à la fin :

define( 'WP_PLUGIN_DIR', dirname(__FILE__) . '/blog/wp-content/plugins' );

WP_PLUGIN_URL doit avoir pour valeur l’adresse complète du répertoire, toujours sans slash à la fin :

define( 'WP_PLUGIN_URL', 'http://example/blog/wp-content/plugins' );

Si vous rencontrez des incompatibilités avec des extensions, définissez PLUGINDIR avec le chemin local complet du répertoire, sans slash à la fin :

define( 'PLUGINDIR', dirname(__FILE__) . '/blog/wp-content/plugins' );

Déplacer le répertoire des thèmes

Vous ne pouvez pas déplacer le répertoire des thèmes car son chemin est défini en dur par rapport au répertoire wp-content :

$theme_root = WP_CONTENT_DIR . '/themes';

Vous pouvez par contre définir des répertoires alternatifs pour vos thèmes en utilisant la fonction register_theme_directory.

Pour mieux comprendre comment le répertoire des thèmes est déterminé, wp-includes/theme.php.

Déplacer le répertoire des fichiers téléversés

Exemple de définition pour UPLOADS :

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

Le chemin ne peut pas être absolu, il est toujours relatif à ABSPATH (le chemin absolu du répertoire de WordPress), et ne doit pas contenir de slash à la fin.

Intervalle d’enregistrement automatique

Quand vous éditez une publication, WordPress utilise Ajax pour enregistrer automatiquement des révisions. Vous pouvez augmenter la valeur de AUTOSAVE_INTERVAL pour définir des intervalles plus longs, ou au contraire le diminuer pour être sûr de ne jamais perdre de modifications. La valeur par défaut est de 60 secondes.

define( 'AUTOSAVE_INTERVAL', 160 ); // Seconds

Révisions

WordPress, par défaut, sauvegardera une révision de chaque modification apportée à une publication, vous permettant de revenir en arrière à tout moment. La création de ces révisions peut être désactivée, ou leur nombre maximum peut être défini.

Désactiver les révisions

Si vous ne définissez pas la valeur de WP_POST_REVISIONS, elle sera pas défaut à true (activée). Si vous souhaitez désactiver l’enregistrement des révisions, utilisez ce réglage :

define( 'WP_POST_REVISIONS', false );

Remarque : si votre réglage n’est pas pris en compte essayez de le déplacer sous le premier commentaire du fichier wp-config.php.

Définir un nombre maximum de révisions

Pour définir et limiter le nombre de révisions maximum par publication, définissez la valeur de WP_POST_REVISIONS sur le nombre voulu :

define( 'WP_POST_REVISIONS', 3 );

Remarque : si votre réglage n’est pas pris en compte essayez de le déplacer sous le premier commentaire du fichier wp-config.php.

Définir le domaine des cookies

Le domaine défini pour les cookies de WordPress peut être spécifié pour les configurations de domaines inhabituelles. Par exemple, si des sous‑domaines sont utilisés pour afficher du contenu statique, vous pouvez définir le domaine des cookies uniquement sur vos domaines non statiques afin d’éviter que les cookies soient envoyés à chaque requête sur votre site statique.

define( 'COOKIE_DOMAIN', 'www.example.com' );

Activer le multisite

WP_ALLOW_MULTISITE permet d’autoriser la création d’un réseau multisite. Si elle n’est pas définie, elle est par défaut désactivée.

Pour l’activer, utilisez ce réglage :

define( 'WP_ALLOW_MULTISITE', true );

Rediriger les sites inexistants

NOBLOGREDIRECT est utilisé pour rediriger à une certaine adresse lorsqu’un visiteur accède à un sous-domaine ou un sous-répertoire qui n’existe pas :

define( 'NOBLOGREDIRECT', 'http://example.com' );

Désactiver le mode récupération

WordPress 5.2 a introduit le mode récupération (Recovery Mode – en anglais) qui affiche un message d’erreur au lieu d’un écran blanc lorsqu’une erreur fatale apparaît :

Le site rencontre des difficultés techniques. Veuillez consulter la boîte de réception du courrier électronique de l’administrateur pour obtenir des instructions.

Si lors de vos développements vous souhaitez afficher à nouveau les erreurs avec WP_DEBUG_DISPLAY, vous devez d’abord désactiver le mode récupération en passant WP_DISABLE_FATAL_ERROR_HANDLER à true :

define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true );   // 5.2 define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', true );

WP_DEBUG

La constante WP_DEBUG contrôle la remontée de certaines erreurs et avertissements et permet d’utiliser les constantes WP_DEBUG_DISPLAY et WP_DEBUG_LOG. Elle est désactivée par défaut (false).

define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true );   // 5.2 
define( 'WP_DEBUG', true );

Les erreurs de base de données sont remontées seulement si WP_DEBUG est définie à true (en anglais). Elles sont gérées par la classe wpdb et ne sont pas affectées par les réglages des erreurs de PHP.

Activer WP_DEBUG élève également le niveau de notification d’erreur à E_ALL et active l’affichage des avertissements lorsque des fonctions ou fichiers obsolètes sont utilisés. Par défaut WordPress défini le niveau de notification d’erreur sur E_ALL ^ E_NOTICE ^ E_USER_NOTICE.

WP_ENVIRONMENT_TYPE

La constante WP_ENVIRONMENT_TYPE contrôle le type d’environnement d’un site : local, development, staging, ou production. Les valeurs des types d’environnement sont traitées dans l’ordre ci-dessus, chaque méthode remplaçant séquentiellement les valeurs précédentes.

Pour les deux méthodes, si la valeur d’un type d’environnement fourni ne figure pas dans la liste des types d’environnement autorisés, la valeur production sera renvoyée par défaut.

Le moyen le plus simple de définir la valeur est de définir la constante :

define( 'WP_ENVIRONMENT_TYPE', 'staging' );

Remarque : lorsque wp_get_environment_type() retourne la valeur developement, WP_DEBUG est mis à true s’il n’est pas défini dans le fichier wp-config.php du site.

SCRIPT_DEBUG

La constante SCRIPT_DEBUG, quand elle est activée, force WordPress à utiliser les versions de développements des scripts et styles dans wp-includes/js, wp-includes/css et wp-admin/js. Les fichiers de wp-admin/css sont utilisés à la place des versions minifiées (.min.css et .min.js).
Si vous souhaitez modifier des fichiers JavaScript ou CSS de WordPress, vous devrez ajouter ce code à votre fichier wp-config.php :

define( 'SCRIPT_DEBUG', true );

Désactiver la concaténation JavaScript

Pour accélérer le chargement des écrans d’administration tous les fichiers JavaScript sont concaténés en une seule URL.
La constante CONCATENATE_SCRIPTS est par défaut activée, pour la désactiver, utilisez ce code :

define( 'CONCATENATE_SCRIPTS', false );

Configurer la journalisation des erreurs

La configuration de la journalisation des erreurs peut être un peu délicate. Tout d’abord, les paramètres par défaut du journal d’erreurs et de l’affichage de PHP sont définis dans le fichier php.ini, auquel vous pouvez ou non avoir accès. Si c’est le cas, ils doivent être réglés sur les paramètres souhaités pour les pages PHP servies au public. Il est fortement recommandé de ne pas afficher de messages d’erreur au public et de les enregistrer dans un journal d’erreurs. Enfin, les journaux d’erreurs ne doivent pas être situés dans la partie accessible au public de votre serveur. Voici un exemple de paramètres des erreurs recommandés pour le fichier php.ini :

error_reporting = 4339
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /home/example.com/logs/php_error.log
log_errors_max_len = 1024
ignore_repeated_errors = On
ignore_repeated_source = Off
html_errors = Off

À propos du rapport d’erreurs 4339 : il s’agit d’une valeur personnalisée qui ne consigne que les problèmes qui affectent le fonctionnement de votre site, et ignore des éléments telles que les notices qui ne sont peut-être pas des erreurs. Reportez-vous à la liste des constantes d’erreur PHP pour la signification de chaque position binaire pour 1000011110011, qui est le nombre binaire égal à 4339.

Le 1 à l’extrême gauche signifie « signaler toutes les erreurs de type E_RECOVERABLE_ERROR ».
Le 0 suivant signifie « ne pas déclarer E_STRICT », (qui est lancé lorsque le code n’est pas optimal mais fonctionnel) et ainsi de suite.
N’hésitez pas à déterminer votre propre numéro de rapport d’erreur personnalisé à utiliser à la place de 4339.

Il est évident que vous voudrez des réglages différents pour votre environnement de développement. Si votre site de développement se trouve sur le même serveur ou si vous n’avez pas accès au fichier php.ini, vous devrez remplacer les paramètres par défaut au moment de l’exécution, dans le fichier wp-config.php.
Il s’agit d’une question de préférence personnelle, que vous préfériez que les erreurs soient enregistrées dans un fichier journal, ou que vous préfériez être averti immédiatement de toute erreur, ou peut-être les deux. Voici un exemple, à insérer dans votre fichier wp-config.php, qui signale immédiatement toutes les erreurs :

@ini_set( 'log_errors', 'Off' );
@ini_set( 'display_errors', 'On' );
define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true );   // 5.2 and later
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', true );

Comme le fichier wp-config.php est chargé pour chaque page vue non mise en cache, c’est un excellent endroit pour définir les réglages du php.ini qui contrôlent votre installation de PHP. C’est utile si vous n’avez pas accès à un fichier php.ini, ou si vous souhaitez simplement modifier certains paramètres à la volée. La seule exception est pour le réglage error_reporting.
Lorsque WP_DEBUG est activé, error_reporting sera défini sur E_ALL par WordPress, indépendamment de ce que vous essayez de définir dans wp-config.php. Si vous avez vraiment besoin de définir error_reporting sur une autre valeur, vous devez le faire après le chargement du fichier wp-settings.php, par exemple dans un fichier d’une extension.

Si vous activez la journalisation des erreurs, n’oubliez pas de supprimer le fichier par la suite, car il se trouve souvent dans un endroit accessible au public, où n’importe qui pourrait avoir accès à votre journal.

Voici un exemple qui active le réglage PHP error_logging et journalise les erreurs dans un fichier spécifique. Si WP_DEBUG est défini à true, les erreurs seront également journalisées dans ce fichier. Il suffit de placer ce fichier au-dessus des fonctions require_once ou include :

@ini_set( 'log_errors', 'On' );
@ini_set( 'display_errors', 'Off' );
@ini_set( 'error_log', '/home/example.com/logs/php_error.log' );
/* That's all, stop editing! Happy blogging. */

Un autre exemple de configuration de la journalisation des erreurs, suggéré par Mike Little dans la liste wp-hackers (en anglais) :

/**
 * This will log all errors notices and warnings to a file called debug.log in
 * wp-content (if Apache does not have write permission, you may need to create
 * the file first and set the appropriate permissions (i.e. use 666) )
 */
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Une version améliorée, de Mike Little, sur le groupe Manchester WordPress User (en anglais) :

/**
 * This will log all errors notices and warnings to a file called debug.log in
 * wp-content only when WP_DEBUG is true. if Apache does not have write permission,
 * you may need to create the file first and set the appropriate permissions (i.e. use 666).
 */
define( 'WP_DEBUG', true ); // Or false
if ( WP_DEBUG ) {
    define( 'WP_DEBUG_LOG', true );
    define( 'WP_DEBUG_DISPLAY', false );
    @ini_set( 'display_errors', 0 );
}

Ce qui peut être déroutant, c’est que WordPress a trois constantes qui semblent pouvoir faire la même chose.
Tout d’abord, souvenez-vous que si WP_DEBUG est désactivée, celle-ci et les deux autres constantes DEBUG de WordPress ne font rien, les directives PHP, quelles qu’elles soient, prévaudront. À l’exception du réglage error_reporting, WordPress le définira à 4983 si WP_DEBUG est défini comme false.
Deuxièmement, même si WP_DEBUG est activée, les autres constantes ne font quelque chose que si elles sont elles aussi activées. Si elles sont définies à false, les directives PHP restent inchangées. Par exemple, si votre fichier php.ini contient la directive 'display_errors' = 'On', mais que vous avez la déclaration define('WP_DEBUG_DISPLAY', false ); dans votre fichier wp-config.php, les erreurs seront toujours affichées à l’écran car ce sont les réglages de PHP qui sont prioritaires.
C’est pourquoi il est très important de définir les directives PHP en fonction de vos besoins au cas où l’une des constantes WordPress correspondantes serait définie sur false. Pour être sûr, définissez explicitement les deux types. Des descriptions plus détaillées des constantes WordPress sont disponibles dans l’article Débogage dans WordPress.

Pour votre installation publique de WordPress en production, vous pourriez envisager de placer ce qui suit dans votre fichier wp-config.php, même si cela peut être partiellement redondant :

@ini_set( 'log_errors', 'On' );
@ini_set( 'display_errors', 'Off' );
define( 'WP_DISABLE_FATAL_ERROR_HANDLER', false );   // 5.2 and later
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );

Le fichier journal de débogage par défaut est situé dans le répertoire (/wp-content/debug.log). Le fait de placer les journaux d’erreurs dans des endroits accessibles au public constitue un risque pour la sécurité. Idéalement, vos fichiers journaux devraient être placés au-dessus du répertoire racine public de votre site. Si vous ne pouvez pas le faire, réglez au moins les permissions du fichier journal sur 600 et ajoutez cette entrée au fichier .htaccess dans le répertoire racine de votre installation WordPress :

<Files debug.log>
    Order allow,deny
    Deny from all
</Files>

Cela empêche toute personne d’accéder au fichier en HTTP, dans un navigateur par exemple. Vous pouvez toujours consulter le fichier journal en le récupérant sur votre serveur en utilisant un client FTP.

Augmenter la mémoire allouée à PHP

La constante WP_MEMORY_LIMIT vous permet de spécifier la quantité maximale de mémoire qui peut être consommée par PHP. Ce paramètre peut être nécessaire dans le cas où vous recevez un message comme « Allowed memory size of xxxxxx bytes exhausted ».

Ce paramètre augmente la mémoire PHP uniquement pour WordPress, et non pour d’autres applications. Par défaut, WordPress tentera d’augmenter la mémoire allouée à PHP à 40MB (le code se trouve au début du fichier /wp-includes/default-constants.php) pour un seul site et 64MB pour plusieurs sites, donc le paramètre dans wp-config.php doit avoir une valeur plus élevée que 40MB ou 64MB, selon votre configuration.

WordPress vérifiera automatiquement si PHP a reçu moins de mémoire que la valeur saisie avant d’utiliser cette fonction. Par exemple, si PHP s’est vu allouer 64 Mo, il n’est pas nécessaire de définir cette valeur à 64M car WordPress utilisera automatiquement les 64 Mo si nécessaire.

Remarque : certains hébergeurs ne permettent pas d’augmenter automatiquement la limite de mémoire allouée à PHP. Dans ce cas, contactez votre hébergeur pour augmenter la limite de mémoire PHP. De plus, de nombreux hôtes fixent la limite PHP à 8 Mo.

Augmenter la mémoire allouée à PHP à 64Mo :

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

Augmenter la mémoire allouée à PHP à 96Mo :

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

Les tâches effectuées dans le tableau de bord nécessitent plus de mémoire que le fonctionnement habituel. Lorsqu’on se trouve dans le tableau de bord, la mémoire peut être augmentée ou diminuée à partir de la valeur WP_MEMORY_LIMIT en définissant WP_MAX_MEMORY_LIMIT :

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

Remarque : cette constante doit être définie avant l’inclusion de wp-settings.php.

Cache

Lorsque la constante WP_CACHE est activée, le fichier wp-content/advanced-cache.php est chargé par le fichier wp-settings.php.
Par défaut, le fichier advanced-cache.php n’existe pas, il est souvent créé par les extensions de cache.

define( 'WP_CACHE', true );

Tables personnalisées des utilisateurs et leurs métadonnées

Les constantes CUSTOM_USER_TABLE et CUSTOM_USER_META_TABLE peuvent être utilisées pour personnaliser les tables de la base de données dans lesquelles les utilisateurs et leurs métadonnées sont stockés.
Par défaut, ce sont les tables wp_users et wp_usermeta qui sont utilisées.

define( 'CUSTOM_USER_TABLE', $table_prefix.'my_users' );
define( 'CUSTOM_USER_META_TABLE', $table_prefix.'my_usermeta' );

Ces deux constantes peuvent être utilisées pour partager une base d’utilisateurs entre plusieurs installations de WordPress, si les différents sites partagent la même base de données.

Remarque : même si CUSTOM_USER_META_TABLE est définie manuellement, une table wp_usermeta sera créée pour chaque base de données avec les permissions correspondantes pour chaque instance. Par défaut, l’installateur de WordPress y ajoutera les permissions du premier utilisateur créé, portant l’identifiant 1. Vous devrez également gérer les permissions des utilisateurs via une extension ou une fonction personnalisée. Si vous ne le faites pas vous rencontrerez des problèmes de permissions et de connexion au tableau de bord.

Si vous utilisez ces constantes pour partager des utilisateurs entre plusieurs sites, il est plus facile d’utiliser CUSTOM_USER_TABLE au moment de l’installation du premier site. En utilisant cette constante dans le fichier wp-config.php, vous définissez où seront stockés les utilisateurs pour tous les sites.
Une fois le premier site installé, vous pouvez copier le fichier wp-config.php dans le site suivant en changeant le préfixe des tables de la base données ($table_prefix), mais en conservant la même valeur de CUSTOM_USER_TABLE.
Lors de l’installation des sites suivants, n’utilisez pas l’adresse e-mail d’un utilisateur existant dans la première installation.
Quand vous aurez terminé l’installation du second site, connectez-vous à son tableau de bord avec le compte administrateur créé automatiquement. Ensuite, dans la liste des utilisateurs, attribuez le rôle d’administrateur à votre utilisateur du premier site puis déconnectez-vous.
Enfin, connectez-vous à nouveau au tableau de bord en utilisant votre premier compte (celui que vous venez de passer en administrateur), et supprimez ceux qui ne seront pas utilisés.

Langues et répertoire des langues

Depuis la version 4.0 de WordPress vous permet de changer la langue de votre installation dans les écrans d’administration. Pour modifier ce réglage, allez dans le menu Réglages puis Général, et sélectionnez votre langue dans Langue du site.

WordPress version 3.9.6 et inférieures

La constante WPLANG définit le nom du fichier de traduction à utiliser, par exemple pour utiliser le fichier fr_FR.mo :

define( 'WPLANG', 'fr_FR' );

La constante WP_LANG_DIR définit le chemin absolu du répertoire dans lequel les fichiers de traductions sont situés. Si elle n’est pas définie WordPress chargera d’abord les fichiers de traductions situés dans le répertoire wp-content/languages, puis dans le répertoire wp-includes/languages pour le fichier définit par WPLANG.

define( 'WP_LANG_DIR', dirname(__FILE__) . 'wordpress/languages' );

Pour trouver le code correspondant à votre langue, consultez le tableau des locales (en anglais), dans la colonne « WP Locale ».

Enregistrer les requêtes pour analyse

L’activation de la constante SAVEQUERIES permet d’enregistrer les requêtes faites à la base de données dans un tableau qui, une fois affiché, aide à analyser ces requêtes. Pour chaque requête, vous saurez quelle fonction l’a lancée et son temps d’exécution.
Remarque : l’activation de cette constante impacte la performance de votre site, assurez-vous de la désactiver quand vous avez terminé votre débogage.

Tout d’abord, activez la constante dans le fichier wp-config.php :

define( 'SAVEQUERIES', true );

Ensuite, insérez ce code dans le fichier footer.php de votre thème pour visualiser le résultat enregistré :

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

Modifier les autorisations par défaut des fichiers

Les constantes FS_CHMOD_DIR et FS_CHMOD_FILE permettent de modifier les autorisations par défaut des fichiers. Elles ont été développées en réponse au problème de l’échec de la fonction de la mise à jour du cœur sur les serveurs fonctionnant avec suexec (en anglais).
Si un serveur utilise des autorisations de fichiers restrictives (par exemple 400) pour tous les fichiers utilisateur et refuse d’accéder aux fichiers dont les autorisations de groupe ou générales sont définies, ces définitions pourraient résoudre le problème.

define( 'FS_CHMOD_DIR', ( 0755 & ~ umask() ) );
define( 'FS_CHMOD_FILE', ( 0644 & ~ umask() ) );

Exemple pour fournir setgid :

define( 'FS_CHMOD_DIR', ( 02755 & ~umask() ) );

Remarque : 0755 et 02755 sont des valeurs octales. Elles doivent être préfixées d’un 0 et ne doivent pas être entourées de guillemets simples (‘).
À lire aussi : Modifier les permissions de fichiers.

Constantes de mises à jour

Certaines des constantes ci-dessous peuvent vous aider à résoudre des problèmes liés aux mises à jour.

Les causes les plus courantes nécessitant de les définir sont les suivantes :

Votre serveur fonctionne avec une configuration d’installation particulière impliquant des liens symboliques. Dans ce cas, vous devrez peut-être définir les constantes liées au chemin (FTP_BASE, FTP_CONTENT_DIR et FTP_PLUGIN_DIR) ; souvent la définition de FTP_BASE sera suffisante ;
Certaines installations PHP configurées avec une extension PHP FTP incompatible avec certains serveurs FTP, dans ces rares cas, il peut être nécessaire de définir FTP_METHOD sur ‘ftpsockets‘ ;

Voici la liste des constantes utiles dans le cadre des mises à jour de WordPress :

FS_METHOD force la méthode du système de fichier (filesystem). La valeur peut être uniquement direct, ssh2, ftpext, ou ftpsockets. En règle générale, vous ne devez modifier cette option que si vous rencontrez des problèmes de mise à jour. Si vous le changez et que cela ne résous pas le problème, retirez la ou revenez à la valeur précédente. Dans la plupart des cas, la valeur ftpsockets fonctionnera si la méthode choisie automatiquement ne fonctionne pas.
Voici les descriptions des différentes méthodes :

direct (premier choix) : force à utiliser des requêtes I/O (entrée/sortie) directes depuis PHP, ce qui entraîne des problèmes de sécurité sur des hôtes mal configurés. C’est l’option par défaut le cas échéant ;
ssh2 (second choix) : force à utiliser l’extension SSH de PHP si elle est installée ;
ftpext (troisième choix) : force à utiliser l’extension FTP de PHP pour l’accès FTP ;
ftpsockets (quatrième choix) : utilise la classe de Sockets PHP pour l’accès FTP ;
FTP_BASE indique le chemin complet vers le répertoire « base » ou « racine » (ABSPATH) de l’installation ;
FTP_CONTENT_DIR indique le chemin complet vers le répertoire wp-content de l’installation ;
FTP_PLUGIN_DIR indique le chemin complet vers le répertoire des extensions (wp-content/plugins) de l’installation ;
FTP_PUBKEY indique le chemin complet vers la clé publique SSH ;
FTP_PRIKEY indique le chemin complet vers votre clé privée SSH ;
FTP_USER indique à la fois le compte utilisateur FTP et le nom d’utilisateur SSH. La plupart du temps ils sont identiques, mais utilisez celui qui convient pour le type de mise à jour que vous souhaitez faire ;
FTP_PASS est le mot de passe pour le compte utilisateur défini dans FTP_USER ;
FTP_HOST est la combinaison de l’adresse du serveur et du port (hostname:port) pour votre serveur SSH ou FTP. Le port FTP par défaut est 21 et le port par défaut SSH est le 22. Ces derniers n’ont pas besoin d’être mentionnés ;
FTP_SSL à définir à true pour une connexion SSL si supporté par le protocole de transport (pas disponible sur tous les serveurs). Ceci est utilisé pour la méthode de connexion « Secure FTP » et non pour le SSH SFTP ;

define( 'FS_METHOD', 'ftpext' );
define( 'FTP_BASE', '/path/to/wordpress/' );
define( 'FTP_CONTENT_DIR', '/path/to/wordpress/wp-content/' );
define( 'FTP_PLUGIN_DIR ', '/path/to/wordpress/wp-content/plugins/' );
define( 'FTP_PUBKEY', '/home/username/.ssh/id_rsa.pub' );
define( 'FTP_PRIKEY', '/home/username/.ssh/id_rsa' );
define( 'FTP_USER', 'username' );
define( 'FTP_PASS', 'password' );
define( 'FTP_HOST', 'ftp.example.org' );
define( 'FTP_SSL', false );

Certaines configurations devraient régler FTP_HOST sur localhost afin d’éviter les problèmes 503 lors de la mise à jour des extensions ou de WordPress lui-même.

Activer l’accès à la mise à niveau SSH

Il y a deux façons de mettre à niveau en utilisant SSH2.

La première en utilisant l’extension « SSH SFTP Updater Support » (en anglais). La seconde consiste à utiliser l’outil de mise à niveau SSH2 intégré, qui nécessite l’installation de l’extension pecl SSH2.

Pour installer l’extension pecl SSH2, vous devrez lancer une commande similaire à la suivante ou contacter votre hébergeur web pour l’installer :

pecl install ssh2

Après avoir installé l’extension pecl ssh2, vous devrez modifier votre configuration PHP pour la charger automatiquement.

pecl est fourni par le paquet pear dans la plupart des distributions Linux.
Pour installer pecl sur Redhat/Fedora/CentOS, lancez la commande suivante :

yum -y install php-pear

Pour installer pecl sur Debiant/Ubuntu :

apt-get install php-pear

Il est recommandé d’utiliser une clé privée qui n’est pas protégée par une phrase de passe. De nombreux rapports indiquent que les clés privées protégées par une phrase de passe ne fonctionnent pas correctement. Si vous décidez d’essayer une clé privée protégée par une phrase de passe, vous devrez la saisir sous la forme FTP_PASS, ou la saisir dans le champ « mot de passe » du champ d’identification lors de l’installation des mises à jour.

Cron alternatif

Il peut y avoir plusieurs raisons d’utiliser un cron alternatif à celui de WordPress. Le plus souvent, c’est lorsque les publications planifiées ne sont pas publiées comme prévu. Cette méthode alternative utilise une approche de redirection. Le navigateur de l’utilisateur reçoit une redirection lorsque le cron doit être lancé, de sorte qu’il revient immédiatement sur le site alors que le cron continue à fonctionner dans la connexion qu’il vient de quitter. Cette méthode présente certains risques, car elle dépend d’un service WordPress non natif.
Pour utiliser un cron alternatif, définissez la constante suivante :

define( 'ALTERNATE_WP_CRON', true );

Désactiver le cron et définir un délai de verrouillage

Pour désactiver complètement le cron de WordPress :

define( 'DISABLE_WP_CRON', true );

Pour définir un temps de verrouillage pour une tâche cron, utilisez la constante WP_CRON_LOCK_TIMEOUT. Par exemple, pour s’assurer qu’une tâche cron dispose de 60 secondes pour être exécutée sans être interrompue :

define( 'WP_CRON_LOCK_TIMEOUT', 60 );

Constantes additionnelles

Voici d’autres constantes qui peuvent être définies. Elles ne devraient probablement pas être définies à moins que d’autres méthodes n’aient été essayées au préalable. Les définitions des cookies peuvent être particulièrement utiles si vous avez une configuration de domaine inhabituelle.

define( 'COOKIEPATH', preg_replace( '|https?://[^/]+|i', '', get_option( 'home' ) . '/' ) );
define( 'SITECOOKIEPATH', preg_replace( '|https?://[^/]+|i', '', get_option( 'siteurl' ) . '/' ) );
define( 'ADMIN_COOKIE_PATH', SITECOOKIEPATH . 'wp-admin' );
define( 'PLUGINS_COOKIE_PATH', preg_replace( '|https?://[^/]+|i', '', WP_PLUGIN_URL ) );
define( 'TEMPLATEPATH', get_template_directory() );
define( 'STYLESHEETPATH', get_stylesheet_directory() );

Délai de suppression de la corbeille

Cette constante contrôle le nombre de jours avant que WordPress supprime définitivement les publications (articles, pages, fichiers joints, commentaires) qui sont dans la corbeille. La valeur par défaut est 30 jours :

define( 'EMPTY_TRASH_DAYS', 30 ); // 30 days

Pour désactiver la suppression automatique des publications, définissez la valeur à zéro :

define( 'EMPTY_TRASH_DAYS', 0 ); // Zero days

Remarque : si cette constante est définie à zéro, WordPress ne demandera pas de confirmation lors de la suppression définitive d’une publication dans le tableau de bord.

Réparation automatique de la base de données

Pour activer le support de la réparation automatique de la base de données, définissez la constante WP_ALLOW_REPAIR :

 define( 'WP_ALLOW_REPAIR', true );

Remarque : cette fonction ne doit être activée qu’en cas de besoin et désactivée une fois le problème résolu. Lorsqu’elle est activée, un utilisateur n’a pas besoin d’être connecté pour accéder à la fonctionnalité, puisque son but principal est de réparer une base de données corrompue et que les utilisateurs ne peuvent souvent pas se connecter lorsque la base de données est corrompue.

Le script est accessible à l’adresse suivante : {$your_site}/wp-admin/maint/repair.php.

Ne pas mettre à niveau les tables globales

La constante DO_NOT_UPGRADE_GLOBAL_TABLES permet de désactiver la mise à niveau des tables globales de la base de données. Cela empêche que dbDelta() et les fonctions de mise à niveau fassent des requêtes coûteuses en ressources serveur sur les tables globales.

Les sites qui ont de grandes tables globales (en particulier les utilisateurs et les métadonnées des utilisateurs), ainsi que les sites qui partagent des tables d’utilisateurs avec bbPress et d’autres installations de WordPress, peuvent empêcher la mise à jour de ces tables pendant la mise à niveau en définissant DO_NOT_UPGRADE_GLOBAL_TABLES à true. Étant donné qu’un ALTER, ou un DELETE ou UPDATE sans limite, peut prendre beaucoup de temps, les grands sites veulent généralement éviter qu’ils soient exécutés dans le cadre de la mise à niveau afin de pouvoir la gérer eux-mêmes. De plus, si les installations partagent des tables d’utilisateurs entre plusieurs installations bbPress et WordPress, vous pouvez souhaiter qu’un site soit le maître de la mise à niveau globale.

define( 'DO_NOT_UPGRADE_GLOBAL_TABLES', true );

Voir toutes les constantes définies

PHP a une fonction qui permet de retourner un tableau de toutes les constantes définies, ainsi que leurs valeurs :

print_r( @get_defined_constants() );

Désactiver l’éditeur de thème

La constante DISALLOW_FILE_EDIT permet de désactiver l’éditeur de thème, ce qui empêchera l’édition des fichiers du thème et des extensions via le tableau de bord. Désactiver cette fonctionnalité est une bonne pratique de sécurité pour éviter les mauvaises manipulations de fichiers ou les piratages.

define( 'DISALLOW_FILE_EDIT', true );

Remarque : certaines extensions qui se basent sur cette constante en utilisant current_user_can( 'edit_plugins' ) dans leur code pourraient ne plus fonctionner si vous définissez la constante à true. Les auteurs d’extensions devraient éviter de se baser sur cette permission, ou au moins vérifier que la constante est définie et afficher un message d’erreur approprié le cas échéant.

Désactiver l’installation et mises à niveau des thèmes et extensions

La constante DISALLOW_FILE_MODS permet de désactiver l’installation et les mises à niveau des thèmes et extensions depuis le tableau de bord.
Cela désactive également l’éditeur de thème, aussi si vous définissez cette constante à true, vous n’avez pas besoin de d’utiliser la constante DISALLOW_FILE_EDIT.

define( 'DISALLOW_FILE_MODS', true );

Forcer SSL pour l’administration

La constante FORCE_SSL_ADMIN permet de forcer le SSL pour l’accès au tableau de bord, ce qui veut dire qu’il sera accessible uniquement via https://, ainsi que la page de connexion. Cela permet de sécuriser son accès en s’assurant que les mots de passe et les cookies ne sont jamais transmis en clair.
Lisez « Tableau de bord en SSL » pour plus de détails.

define( 'FORCE_SSL_ADMIN', true );

Remarque : cette constante a été introduite dans WordPress 4.0, pour les versions antérieures utilisez FORCE_SSL_LOGIN à la place.

Bloquer les requêtes URL externes

La constante WP_HTTP_BLOCK_EXTERNAL permet de bloquer les requêtes d’URL externes, en permettant uniquement à localhost (le serveur) et votre site d’y faire des requêtes.
La constante WP_ACCESSIBLE_HOSTS permet de définir des hôtes spécifiques qui seront autorisés à faire des requêtes sur votre site. Elle accepte une liste de domaines séparés par des virgules, les sous-domaines sont autorisés.

define( 'WP_HTTP_BLOCK_EXTERNAL', true );
define( 'WP_ACCESSIBLE_HOSTS', 'api.wordpress.org,*.github.com' );

Désactiver les mises à niveau automatiques

La constante AUTOMATIC_UPDATER_DISABLED permet de désactiver les mises à niveau automatiques des extensions et des thèmes et du cœur de WordPress. Cela peut-être utile si vous souhaitez tester vos développements avant d’appliquer les mises à niveau.

 define( 'AUTOMATIC_UPDATER_DISABLED', true );

Configurer les mises à niveau automatiques de WordPress

La façon la plus simple de configurer les mises à niveau automatiques du cœur de WordPress est d’utiliser la constante WP_AUTO_UPDATE_CORE, il existe trois réglages :

 # Désactiver toutes les mises à niveau :
 define( 'WP_AUTO_UPDATE_CORE', false );

 # Autoriser toutes les mises à niveau, mineures ou majeures :
 define( 'WP_AUTO_UPDATE_CORE', true );

 # Autoriser les mises à niveau mineures (valeur par défaut) :
 define( 'WP_AUTO_UPDATE_CORE', 'minor' );

À lire aussi : Désactiver les mises à niveau automatiques dans WordPress 3.7 (en anglais)

Stockage des éditions des images

Par défaut, WordPress crée un nouvel ensemble d’images à chaque fois que vous modifiez une image, et lorsque vous restaurez l’original, il laisse toutes les modifications sur le serveur. Définir IMAGE_EDIT_OVERWRITE à true modifie ce comportement : un seul ensemble de modifications d’images est créé et lorsque vous restaurez l’original, les modifications sont supprimées du serveur.

define( 'IMAGE_EDIT_OVERWRITE', true );

Vérifiez à deux fois avant de sauvegarder

Assurez-vous de vérifier les espaces de début et / ou de fin autour des valeurs données dans cet article, et ne supprimez pas les guillemets simples !

Avant de sauvegarder vos modifications, assurez-vous de vérifier à deux fois que vous n’avez pas supprimé de guillemets simples autour des valeurs.
Soyez sûr qu’il n’y a rien après la balise de fermeture PHP.
La dernière chose dans le fichier doit être ?> rien d’autre, aucun espaces.

Enregistrez le fichier wp-config.php à la racine de votre installation WordPress. Téléversez le fichier sur votre serveur et vous serez prêt à installer WordPress !

Source : WordPress

Le guide pour vous apprendre à modifier le fichier WordPress wp-config.php

Base de données

Connexion

Jeu de caractères

Interclassement

Clés de sécurité

Options avancées

table_prefix

WP_SITEURL

Adresse du site

Déplacer le répertoire wp-content

Déplacer le répertoire des extensions

Déplacer le répertoire des thèmes

Déplacer le répertoire des fichiers téléversés

Intervalle d’enregistrement automatique

Révisions

Désactiver les révisions

Définir un nombre maximum de révisions

Définir le domaine des cookies

Activer le multisite

Rediriger les sites inexistants

Désactiver le mode récupération

WP_DEBUG

WP_ENVIRONMENT_TYPE

SCRIPT_DEBUG

Désactiver la concaténation JavaScript

Configurer la journalisation des erreurs

Augmenter la mémoire allouée à PHP

Cache

Tables personnalisées des utilisateurs et leurs métadonnées

Langues et répertoire des langues

WordPress version 3.9.6 et inférieures

Enregistrer les requêtes pour analyse

Modifier les autorisations par défaut des fichiers

Constantes de mises à jour

Activer l’accès à la mise à niveau SSH

Cron alternatif

Désactiver le cron et définir un délai de verrouillage

Constantes additionnelles

Délai de suppression de la corbeille

Réparation automatique de la base de données

Ne pas mettre à niveau les tables globales

Voir toutes les constantes définies

Désactiver l’éditeur de thème

Désactiver l’installation et mises à niveau des thèmes et extensions

Forcer SSL pour l’administration

Bloquer les requêtes URL externes

Désactiver les mises à niveau automatiques

Configurer les mises à niveau automatiques de WordPress

Stockage des éditions des images

Vérifiez à deux fois avant de sauvegarder

Partager :

Articles similaires

Laisser un commentaire Annuler la réponse.

Catégories

Etiquettes

Article le plus populaire

Abonnez-vous à ce blog par e-mail.

Articles récents