Tous les secrets du wp-config.php 1 - BoiteAWeb
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
Réédition de aout 2018 – Julio Potier – https://boiteaweb.fr
Tous les secrets du wp-config.php
-1-
Réédition de aout 2018 – Julio Potier – https://boiteaweb.fr
Tous les secrets du wp-config.php
Introduction
L'auteur
Je suis Julio Potier, Consultant en Sécurité Web, Ingénieur et Formateur WordPress,
créateur de l'extension de Sécurité WordPress SecuPress.
J'ai choisi WordPress en 2009 pour sa flexibilité et facilité de création d'extensions. J'en
développe tous les jours, pour moi ou pour des clients. J'aime partager mon savoir, j'aime aller
plus loin, je me pose toujours pleins de questions et n'hésite pas à tout remettre en cause. J'ai
sûrement bu de l'eau venant de "La Fontaine du Doute", enfin, je pense que c'était elle, ça je
n'en suis pas sûr…
Où me trouver :
○ Dans mon bureau devant mon PC,
○ Sur mon blog technique sur lequel je crée des articles relatifs au développement
sous WordPress : http://www.boiteaweb.fr
○ Sur le Slack de WordPress-fr : https://wordpressfr.slack.com/
○ Sur le site de SecuPress : http://www.secupress.pro
○ Sur Twitter : @boiteaweb et @SecuPress
○ En invité sur quelques blogs WordPress comme GeekPress, WPChannel,
ScreenFeed, WPFormation …
Pourquoi ce livre ?
Avril 2013, mois de la sortie de WordPress 3.6, j'ai voulu répertorier et tester toutes les
constantes possibles contenues dans WordPress et aller au delà du codex qui nous informe sur
les constantes les plus utilisées. J'ai trouvé plus de 160 constantes utiles et je les ai toutes
testées. J'ai décidé d'écrire ces pages afin que tout le monde puisse tirer le meilleur potentiel
de son site WordPress, ce fichier de configuration wp-config.php ne doit plus avoir de secret
pour vous après la lecture de ce livre.
-2-
Réédition de aout 2018 – Julio Potier – https://boiteaweb.fr
EDIT Aout 2018 : Un peu de plus 5 ans après la vente de cet ebook, je décide de le
mettre à jour et de le rendre gratuit. J'ai trié les constantes pour supprimer celles qui étaient
dépréciées depuis trop longtemps (mais j'ai laissé les plus récentes comme WPLANG, quoi, vous
ne saviez pas ?). Aussi je n'ai pas ajouté celles qui n'ont aucun intérêt à être connu ni qui ne
pourrait servir pour du développement.
Pour qui ce livre ?
Ce livre est donc destiné à tout utilisateur de WordPress sachant modifier son fichier de
configuration, c'est-à-dire le fichier wp-config.php à la racine de son site. Vous n'avez pas
forcément besoin d'être un développeur pour lire et comprendre ce livre, vous pouvez
aisément copier/coller et adapter à votre besoin.
En même temps, il est aussi destiné aux développeurs de plugins et de thèmes, aux
créateurs d'astuces et de hacks en tout genre. Il contient des morceaux de codes et parfois cela
parle un peu plus technique, mais surtout pour la compréhension du pourquoi et du comment.
Que contient ce livre ?
En grande partie, des constantes, un peu plus de 160. Des constantes WordPress mais
aussi en bonus des constantes PHP car, que serait WordPress sans le PHP : rien !
sur mon blog qui vous aidera encore.
J'ai créé un Guide complet sur les constantes PHP33
Je parle aussi du fichier wp-config.php lui même. Comment fonctionne-t-il, que fait-il là, que
peut-on en faire etc.
Si vous trouvez une erreur ou un oubli, ajoutez un commentaire dans la source. Merci
!
Comment lire ce livre ?
Les constantes forment la plus grande partie de ce livre. Elles sont toutes formatées de
la même façon, celle-ci :
NOM DE LA CONSTANTE
Type : string - Valeur par défaut : "chaîne"
Description : Courte description.
Explications longues contenant d es mots inclus dans le code. Et aussi des
morceaux plus complet comme :
-3-
Réédition de aout 2018 – Julio Potier – https://boiteaweb.fr
Les types de constantes (oui, une constante n'est pas typée je sais) que vous pourrez
rencontrer sont :
○ string : Chaîne de caractères quelconque.
○ bool : Valeur booléenne, soit vrai (TRUE) soit faux (FALSE).
○ integer : Nombre entier.
○ octal : Nombre octal.
○ null : le fait de déclarer cette constante l'active, peu importe sa valeur.
Viennent ensuite dans le texte quelques mots qui ont un formatage particulier :
○ Les noms-de-fichiers.php sont stylés en italique et toujours avec leur extension,
○ Les noms_de_fonctions() sont stylés en italique avec leur deux parenthèses,
○ Les noms des hooks filtres et actions sont notés "filtre" et "action" en plus d'être
précisés,
○ Les nombres en exposant comme le zéro sur le dernier mot de cette phrase par
exemple qui vous invite à visiter le Lexique0.
Le fichier wp-config.php
Car c'est tout de même de lui dont on parle ici, ce fichier de configuration, nous
l'appellerons comme ça dans le reste du livre : "fichier de configuration".
Avant de le modifier je vous conseille de faire une sauvegarde en local de votre version
actuelle, si vous sauvegardez online, gardez l'extension .php, évitez les .old et .bak qui sont des
fichiers texte et deviennent lisible aux yeux de tous.
Ensuite quand vous ajouterez une constante, ajouter aussi un commentaire ainsi que la
date d'ajout. Cela vous permettra de vous souvenir du but de cette constante, pourquoi vous
l'aviez entrée avec telle ou telle valeur et depuis quand. Si jamais vous vous rendez compte que
quelque-chose semble boguer depuis X semaines, vous pourrez alors aller vérifier si cela coïncide
avec un ajout d'une constante.
Si vous devez supprimer une constante, je vous conseille plutôt de la commenter en
ajoutant "//" devant la ligne puis la date de cette désactivation pour la même raison d'une
possible découverte d'un bogue plus tard, vous saurez quelle constante a été désactivée et
quand.
Attention, certaines constantes ne doivent plus être modifiées sur un site en production
au risque d'avoir des erreurs 404 ou pire. Aussi n'activez pas de mode deboguage en production.
-4-
Réédition de aout 2018 – Julio Potier – https://boiteaweb.fr
1. Déplacer le fichier de configuration
a. Façon hiérarchique
Saviez-vous que le fichier wp-config.php pouvait être remonté d'un cran dans son
arborescence ? Et bien maintenant vous savez. Il y a deux conditions à respecter pour que cela
fonctionne correctement :
● Votre configuration PHP doit permettre à WordPress de naviguer un cran plus haut que
le dossier d'installation, ceci se fait dans le paramètre o pen_basedir de php.ini. Ce
paramètre peut être redéfini grâce à un ini_set() et vaut par défaut quelque chose
comme /host/public_html/www/. Il faut plutôt utiliser /host/public_html/.
● Le dossier se trouvant un cran plus haut ne doit pas, lui, être une autre installation de
WordPress, sinon ce second WordPress devrait avoir 2 fichiers de configuration, bref
impossible.
Personnellement sur un aspect sécurité c'est excellent puisque le fichier n'est pas
accessible depuis votre site ! Voici un exemple un peu plus concret pour comprendre :
Si votre installation se trouve ici dans [www] alors, si la configuration PHP le permet,
vous pouvez déplacer votre fichier de configuration dans [public_html] car la racine de votre
site, accessible depuis l'extérieur, est /www/ et non pas /public_html/. Par contre :
Si votre seconde installation se trouve dans [example.com], vous ne pouvez plus
déplacer son fichier, car le cran supérieur dans l'arborescence serait alors [www]. Cette
première installation n'irait plus chercher un cran plus haut puisqu'elle trouverait un fichier de
configuration à son niveau, mais ce n'est pas le sien !
Vous devez donc soit avoir une seule installation par [www], soit avoir une installation
dans des doubles dossiers comme ceci :
-5-
Réédition de aout 2018 – Julio Potier – https://boiteaweb.fr
Dans le premier [www] ne se trouve aucune installation, que des dossiers contenant
d'autres installations. Ce [www] ne doit pointer vers aucun nom de domaine. Ensuite vos
installations ont chacune un dossier portant leur nom de domaine. Puis voici l'astuce, créer de
nouveau un [www] à l'intérieur, c'est dans ce dossier que vous installez votre WordPress et que
vous faites pointer votre nom de domaine. Vous pouvez donc remonter le wp-config.php dans
le dossier [example.com]. Je ne vous ai pas déjà perdu ?
b. Façon inclusion
Si le déplacement ci-dessus n'est pas possible, vous pouvez toujours jouer avec des
inclusions de fichier. Le fichier wp-config.php ne sera pas physiquement déplacé mais son
contenu, oui.
Coupez tout le contenu de ce fichier pour le coller dans un autre, nommé par exemple
wp-config-dev.php. Et dans le fichier wp-config.php ajoutez ceci :
Ce code PHP sur gist ⍈
Réédition de aout 2018 – Julio Potier – https://boiteaweb.fr
a. La façon Apache/Nginx
On peut aussi utiliser le fichier .htaccess présent à la racine des sites dont le serveur
utilise Apache23. Pour ceux sous Nginx22 il faut le faire directement dans le fichier de
configuration.
Le but est d'empêcher un accès direct sur le fichier de configuration. Il restera accessible
en inclusion via PHP mais jamais via une URL pointant vers votre site.
Sous Apache avec l'Access Control1 ajoutez ce code dans votre fichier .htaccess après la
balise # END WORDPRESS:
Ce code ApacheConf sur gist ⍈
#END WORDPRESS
order allow, deny
deny from all
Sous Nginx avec HttpAccessModule2 ajoutez ce code dans le fichier de configuration :
Ce code Nginx sur gist ⍈
location ~* wp-config.php$ {
deny all;
}
b. La façon chmod
Un chmod3 , cela signifie "change mode". Oui encore de la technique, mais promis,
après on passe au copier/coller.
Le but cette fois est d'empêcher la lecture du fichier en modifiant son mode. Par défaut
les fichiers sont en chmod 0644 ce qui donne ceci :
-7-Réédition de aout 2018 – Julio Potier – https://boiteaweb.fr
On peut voir que le propriétaire, le groupe et tous les autres ont le droit de lecture sur
ce fichier, il est préférable de ne laisser que le propriétaire en lecture, même pas en écriture :
Voici le résultat après la commande en ligne4 chmod suivante :
chmod -c 400 /host/www/wp-config.php qui peut aussi être faite via une interface agréable
comme sur mes captures via votre logiciel de FTP29 favori pour n'en citer aucun. Si vous avez
des soucis avec 0 400, essayez 0 440, ajouter le "groupe" reste sécuritaire et règle très souvent le
problème de conflit "propriétaire" versus "groupe".
3. Des astuces en plus
a. Au diable ABSPATH
Allez, au diable ABSPATH, cette constante présente dans votre fichier de configuration,
vers la fin du fichier vous devriez avoir ceci :
if ( !defined('ABSPATH') )
define('ABSPATH', dirname(__FILE__) . '/');
Et bien sachez que vous pouvez supprimer ces 2 lignes, si si vraiment. En fait elles datent
du temps où le fichier wp-config.php pouvait servir de bootstrap5 mais cela a été déprécié. Par
contre, on a laissé cette ligne pour des raisons de rétro-compatibilité. Entre nous, si vous
utilisez un code qui utilise wp-config.php comme bootstrap, changez de crémerie.
ABSPATH est déjà défini dans le fichier wp-load.php qui est lui forcément chargé...
b. Au diable les clés de sécurité
Non je ne suis pas fou, je les supprime de ce fichier, je suis assez paranoïaque par
déformation professionnelle, et je ne préfère pas laisser traîner ces clés qui rendraient mon site
vulnérable à une faille CSRF6. Je les déplace ailleurs. Je l'ai expliqué plus haut, vous pouvez jouer
avec des inclusions de fichiers etc, mais je vais encore plus loin.
-8-Réédition de aout 2018 – Julio Potier – https://boiteaweb.fr
Avant, je les supprimais car je savais que WordPress, ne les trouvant pas, irait lui mêmes
les ajouter en base de données. Ça me paraissait déjà pas mal de cacher mes clés, introuvables
dans mon fichier de config. Mais cela m'a posé 2 problèmes. Le premier est que la page
/wp-admin/options.php reprends un maximum d'option du site et ces clés sont modifiables et
donc trouvables ici, ça je ne veux pas. Et l'autre problème vient d'une hypothétique faille
d'injection SQL qui pourrait alors lire mes clés ... Oui, je suis parano merci.
Mon but, maintenant et toujours, est de faire en sorte qu'aucune personne ne puisse ni
deviner le chemin, ni le nom du fichier qui va contenir mes clés de sécurité. Et je vais vous
montrer que je suis encore plus parano, mes clés changent toutes seules tous les mois. Nulle
part je ne vais avoir besoin d'écrire le nom de mon fichier, car je vais utiliser un mu-plugin.
SecuPress (aussi dans sa version gratuite) est capable de créer ce mu-plugin qui
remplacera vos clés de sécurité lisibles dans le fichier de configuration par des clés illisibles
humainement, seul du code PHP peu le faire, ce qui limite encore plus le risque de hack.
Pour finir, n'oubliez pas de commenter ou supprimer vos clés de sécurité actuelles déjà
présentes dans le fichier wp-config.php.
A quoi cela sert :
1. Cela sert à cacher ses clés de sécurité au mieux car personne ne sait que vous
connaissez ce script, et s'ils le devinent, le nom de fichier ayant été laissé libre à
votre imagination, je doute qu'il soit devinable,
2. Cela change le hash par défaut de la constante C OOKIEHASH,
3. Les clés changent automatiquement tous les mois,
4. Aucun accès à la base de données, aucune perte de performances,
5. Vous pouvez à tout moment supprimer ce fichier et remettre des clés dans
wp-config.php,
6. 5 raisons sont suffisantes, non ?
4. Le fichier wp-config-sample.php
Aux côtés de wp-config.php vous aurez remarqué un fichier wp-config-sample.php.
Comme son nom l'indique c'est un échantillon, goûtez-y, mais ne l'utilisez pas comme ça. Il sert
en fait de modèle de fichier de configuration contenant les constantes obligatoires, habituelles
et plus courantes.
Lorsque WordPress s'installe en 5 minutes pour la première fois, il tente d'écrire le fichier
wp-config.php, si il n'a pas eu les droits, il vous demande alors de le faire vous même. Vous
-9-Réédition de aout 2018 – Julio Potier – https://boiteaweb.fr
pouvez donc vous baser sur cet échantillon. Le minimum à remplir sont les informations de
base de données et toutes les clés de sécurité8. Renommez-le en wp-config.php si vous vous en
êtes servi ou supprimez-le, il est inutile pour le restant de sa vie.
Une globale
Dans ce livre je vais vous parler du fichier wp-config.php et donc des constantes, plus de
160. Il existe un gros paquets de variables globales dans WordPress, ceci pourrait être un autre
livre. Néanmoins, le fichier de configuration en contient une, je ne peux pas passer à côté !
1. $table_prefix
$TABLE_PREFIX
Type : string - Valeur par défaut : "wp_"
Description : Contient le préfixe des tables de cette installation.
Le préfixe permet de différencier plusieurs installation de WordPress sur la même base
de données SQL. La valeur par défaut est à éviter pour des raisons de sécurité, en effet, les
pirates savent que cette valeur est "wp_" et peuvent l'utiliser lors de tests de failles. Ce préfixe
étant proposé lors de l'installation, modifiez le dès le début. Si vous avez déjà votre site installé
et que vous désirez changer tout de même, SecuPress peut là aussi le faire pour vousl.
Par contre, il ne faut pas utiliser cette globale pour lire le préfixe mais plutôt lire la
classe $ wpdb comme ceci : $ wpdb->prefix.
- 10 -Réédition de aout 2018 – Julio Potier – https://boiteaweb.fr
Les constantes WordPress
Il est important de commencer par ces constantes car elles vont vous être utiles dans la
déclaration d'autres constantes ou dans l'ajout d'astuces simples et rapides.
Au fur à mesure du temps, vous les connaîtrez sur le bout des doigts et leur existence
vous paraîtra naturelle.
Prêtez attention à la présence ou non d'une "/" de fin, elle n'y est pas souvent.
1. Les constantes des chemins WordPress
a. Les chemins de base
ABSPATH
Type : string - Valeur par défaut : dirname( __FILE__ ) . '/'
Description : Contient le chemin absolu de votre installation WordPress.
Cette constante n'est pas vraiment à définir puisqu'en réalité elle est déjà définie
comme suit dans le fichier wp-load.php :
define( 'ABSPATH', dirname( __FILE__ ) . '/' ); // chemin absolu de mon
installation
Dans vos développements, il est obligatoire d'utiliser ABSPATH au lieu de
$_SERVER['DOCUMENT_ROOT'] car les deux valeurs peuvent être différentes si votre installation se
trouve dans un dossier.
N'oubliez pas que A SBPATH est un chemin sur le serveur et non pas une URL sur Internet.
Voici un exemple de code à utiliser en 1ère ligne dans tous vos fichiers PHP de vos plugins
et thèmes s'ils n'ont pas à être interprétés directement par le navigateur mais plutôt inclus par
et dans WordPress :
Ce code PHP sur gist ⍈Réédition de aout 2018 – Julio Potier – https://boiteaweb.fr
WPINC
Type : string - Valeur par défaut : "wp-includes"
Description : Contient le nom du dossier des inclusions du core de WP
WP_CONTENT_DIR
Type : string - Valeur par défaut : "ABSPATH . 'wp-content'"
Description : Contient le chemin absolu vers le dossier des contenus WordPress.
Ce dossier contient habituellement et par défaut les langues, les thèmes, les plugins, les
uploads, le cache. Les plugins ajoutent parfois d'autres dossiers comme les sauvegardes ou des
dossiers personnels contenant leur configuration ou leur propre contenu de médias.
Si vous souhaitez modifier ce chemin pour mettre "wp-contenu", déclarez WP_CONTENT_DIR
comme suit :
define( 'WP_CONTENT_DIR', ABSPATH . 'wp-contenu' ); // mon contenu
Attention, la modification de ce chemin peut empêcher certains plugins de fonctionner
car si leur auteur n'utilise pas ces constantes mais entre dans le code le chemin par défaut, c'est
évidemment une "Erreur 404, page non trouvée" qui ressortira.
WP_CONTENT_URL
Type : string - Valeur par défaut : "get_option( 'siteurl' ) . '/wp-content'"
Description : Contient l'URL vers le dossier des contenus WordPress.
Cette constante va de pair avec WP_CONTENT_DIR et elles doivent être cohérentes entre
elles. Si vous aviez modifié ce chemin pour mettre "wp-contenu", déclarez WP_CONTENT_URL
comme suit :
define( 'WP_CONTENT_URL', get_option( 'siteurl' ) . 'wp-contenu' ); // mon contenu
Attention, comme pour WP_CONTENT_DIR la modification de cette URL peut empêcher
certains plugins de fonctionner car si leur auteur n'utilise pas ces constantes mais entre dans le
code l'URL par défaut, c'est évidemment une "Erreur 404, page non trouvée" qui ressortira.
WP_HOME
Type : string - Valeur par défaut : aucune
Description : Contient l'URL de l'accueil de votre site.
Une option existe dans WordPress, c'est "home". Mais si cette constante est définie, elle
- 12 -Réédition de aout 2018 – Julio Potier – https://boiteaweb.fr
prends le pas que cette option et la remplace.
Il est conseillé d'utiliser la constante et non pas l'option. Déjà, imaginez que vous ou un
de vos clients soit en train de modifier ces valeurs "pour voir ce que ça fait" . Le risque qu'il se
retrouve avec un site front-end et back-end inutilisable est énorme.
Niveau sécurité, si le compte admin se fait corrompre de quelques manières que ce soit
ou qu'une faille quelconque réussisse à modifier cette option, alors l'attaquant peut mettre son
site de phishing9 à la place du votre, puis comme son site reçoit de la requête de la part du
votre, il prends la main et redirige la page sur SON url, votre site s'est fait remplacer par un
clone dans un pays de l'est, aïe. Le fait d'utiliser les constantes empêche cette option d'être
modifiée.
Exemple d'utilisation :
define( 'WP_HOME', 'https://www.example.com' ); // mon accueil
WP_SITEURL
Type : string - Valeur par défaut : aucune
Description : Contient l'URL de votre site incluant le sous-dossier s'il existe.
Une option existe dans WordPress, c'est "siteurl". Mais si cette constante est définie,
elle prends le pas que cette option et la remplace. Il est conseillé là aussi d'utiliser la constante
et non pas l'option pour les mêmes raisons que W P_HOME.
La différence entre les 2 options est parfois obscure et la question revient souvent, voici
enfin la réponse : Vous pouvez avoir une installation dans un sous-dossier "/wordpress/" tout
en gardant un accueil sur la racine du site. Dans ce cas, les 2 options seront différentes car
P_SITEURL sera l'url du sous-dossier,
WP_HOME sera l'url "racine", l'accueil des visiteurs, là où W
celui contenant les fichiers de l'installation.
Voici 2 exemples pour comprendre :
// pour un site sous /host/www/wordpress/
define( 'WP_SITEURL', 'https://www.example.com/wordpress' );
// pour un site sous /host/www/
define( 'WP_SITEURL', 'https://www.example.com' );
RELOCATE
Type : bool - Valeur par défaut : aucune
Description : Permet d'indiquer à WordPress de remettre à jour l'option "siteurl" correctement.
Cette constante vous sert à redéfinir automatiquement l'URL du site dans les options.
Dans le cas où vous auriez mal orthographié l'URL de votre site ou que vous ayez réintégré une
base de données d'un autre site, l'option "siteurl" serait alors erronée et il vous serait
- 13 -Réédition de aout 2018 – Julio Potier – https://boiteaweb.fr
impossible de vous connecter. Pour remédier à ça, ajouter cette constante temporairement :
Ce code PHP sur gist ⍈
define( 'RELOCATE', TRUE ); // visitez la page login puis à supprimer !
Ensuite, retournez sur la page de connexion https://example.com/wp-login.php. C'est
déjà fait ! Vous pouvez (devez !) maintenant retirer la constante et de nouveau vous connecter
dans votre administration. Si vous aviez aussi l'option "home" erronée, vous avez maintenant la
possibilité de la modifier de façon habituelle. Et voilà, le site est de nouveau sur pieds !
WP_TEMP_DIR
Type : string - Valeur par défaut : dépends de get_temp_dir() qui peux renvoyer 4 valeurs
différentes - sans compter cette constante - selon la configuration de votre serveur.
Description : Contient le chemin absolu vers le dossier des fichiers temporaires.
Il est fortement déconseillé de mettre un chemin accessible depuis votre site, évitez
donc "wp-content/temp/" ou des choses du genre accessible facilement.
La valeur par défaut dépends donc de get_temp_dir() qui lira en tout premier cette constante.
Ce dossier est utilisé par les fonctions d'upload qui vont temporairement écrire des fichiers
dans ce dossier, voilà pourquoi il est important de ne pas laisser les fichiers d'attente en accès.
define( 'WP_TEMP_DIR', '
/host/tmp/' ); // hors /www/
ENVIRONMENT
Type : string - Valeur par défaut : aucune
Description : Contient l'environnement de développement actuel.
Cette constante n'est pas une vraie constante WordPress ni un chemin, je triche mais
j'en ai besoin pour la prochaine constante. J'ai déjà parlé de ENVIRONMENT plus haut. Elle est utile
lorsque vous avez à développer dans différents environnements, entre "dev", "pre-prod",
"recette", "prod" par exemple. Son but est d'inclure un fichier de configuration différent selon
cet environnement. Voici comment procéder :
Ce code PHP sur gist ⍈
define( 'ENVIRONMENT', '
dev'); // Je suis en "dév"eloppement
// ...
require_once( 'wp-config-' . 'ENVIRONMENT' . '.php' ); // wp-config-dev.php
Vous pouvez donc déplacer par exemple les informations de base de données si vous
avez une base de données de test, de dev. Déplacer aussi les informations FTP si vous avez un
- 14 -Réédition de aout 2018 – Julio Potier – https://boiteaweb.fr
compte particulier lors des dev, même chose pour des chemins si les uploads lors des
développements ne sont pas à mélanger avec ceux de production.
Vous avez donc maintenant un fichier wp-config.php contenant ce code, cette
constante, puis les constantes communes à tous les environnements, puis vous avez un fichier
de configuration spécifique à chaque environnement : wp-config-dev.php,
wp-config-pre-prod.php, wp-config-recette.php, wp-config-prod.php, …
Ceci afin de bien séparer les informations, éviter de les mélanger et s'emmêler les
pinceaux. C'est aussi une bonne pratique qui consiste à toujours bien ranger vos fichiers.
STATICPATH
Type : string - Valeur par défaut : aucune
Description : Contient l'URL vers les fichiers statics de votre site.
Je triche encore, c'est une constante maison qui me vient de Jonathan Buttigieg10. Les
fichiers statiques sont par exemple les styles.css, script.js ou autres images.jpg relatives au
thème, et non pas les images des médias uploadés. Le but ici est de pouvoir basculer facilement
entre les fichiers présents dans les dossiers du thème et son équivalent en CDN11 lorsque le site
sera en production.
La constante est utilisable dans le fichier wp-config.php si vous utilisez aussi la constante
ENVIRONMENT. Voici un exemple d'utilisation dans un test ternaire12 :
Ce code PHP sur gist ⍈
define( 'STATICPATH', ENVIRONMENT != 'prod' ? get_template_directory_uri() .
'/includes' : 'https://cdn.example.com' ); // pas en 'prod = '/includes' sinon le
CDN.
Attention, il faut déclarer cette constante SOUS la ligne d'inclusion du fichier
wp-settings.php car sinon la fonction get_template_directory_uri() n'est pas encore déclarée.
b. Les chemins de langues
WP_LANG_DIR
Type : string - Valeur par défaut : "WP_CONTENT_DIR . '/languages'"
Description : Contient le chemin relatif à ABSPATH du dossier contenant les traductions.
Il est donc important de connaître cette constante dans le cas où vous avez changé le
chemin vers "wp-content", il faut donc aussi faire suivre ce dossier.
Si vous souhaitez concentrer vos fichiers de langues à la racine dans un dossier "trad"
voici le code :
define( 'WP_LANG_DIR', '
trad' ); // dossier /trad/ à la racine
- 15 -Réédition de aout 2018 – Julio Potier – https://boiteaweb.fr
c. Les chemins des extensions/plugins
WP_PLUGIN_DIR
Type : string - Valeur par défaut : "WP_CONTENT_DIR . '/plugins'"
Description : Contient le chemin absolu vers le dossier des plugins.
Puisque la valeur de cette constante contient WP_CONTENT_DIR, elle en est donc
évidemment dépendante. Vous pouvez renommer ou totalement déplacer le dossier des
plugins comme ici :
// dans le contenu
define( 'WP_PLUGIN_DIR', WP_CONTENT_DIR . '/add-ons' );
// à la racine
define( 'WP_PLUGIN_DIR', ABSPATH . '/add-ons' );
WP_PLUGIN_URL
Type : string - Valeur par défaut : "WP_CONTENT_URL . '/plugins'"
Description : Contient l'URL vers le dossier des plugins.
Puisque la valeur de cette constante contient WP_CONTENT_URL, elle en est donc
évidemment dépendante. Vous pouvez là aussi renommer ou totalement déplacer le dossier
des plugins comme ici :
// dans le contenu
define( 'WP_PLUGIN_URL', WP_CONTENT_URL . '/add-ons' );
// à la racine
define( 'WP_PLUGIN_URL', ABSPATH . '/add-ons' );
Je me répète : les 2 constantes doivent bien sûr être cohérentes entre elles.
WPMU_PLUGIN_DIR
Type : string - Valeur par défaut : "WP_CONTENT_DIR . '/mu-plugins'"
Description : Contient le chemin absolu vers le dossier des Must Use Plugins7.
Sa valeur est elle encore dépendante de WP_CONTENT_DIR. Vous pouvez renommer ou
totalement déplacer le dossier des mu-plugins comme ici :
- 16 -Réédition de aout 2018 – Julio Potier – https://boiteaweb.fr
// dans le contenu et à la racine
define( 'WPMU_PLUGIN_DIR', WP_CONTENT_DIR . '/must-use' );
define( 'WPMU_PLUGIN_DIR', ABSPATH . '/must-use' );
WPMU_PLUGIN_URL
Type : string - Valeur par défaut : "WP_CONTENT_URL . '/mu-plugins'"
Description : Contient l'URL vers le dossier des must-use plugins.
Sa valeur est elle encore dépendante de WP_CONTENT_URL. Vous pouvez renommer ou
totalement déplacer le dossier des mu-plugins comme ici :
// dans le contenu
define( 'WPMU_PLUGIN_URL', WP_CONTENT_URL . '/must-use' );
// à la racine
define( 'WPMU_PLUGIN_URL', ABSPATH . '/must-use' );
Je me répète, les 2 constantes doivent bien sûr être cohérentes entre elles.
d. Les chemins des thèmes
TEMPLATEPATH
Type : string - Valeur par défaut : get_template_directory()
Description : Contient le chemin absolu vers le thème parent actif sur votre site.
Vous pouvez utilisez cette constante pour lire le chemin vers le thème parent, mais pour
la déclarer c'est un peu différent car WordPress le fera par la suite. Cette constante est un peu
plus spéciale en fait car vous devez la déclarer dans le fichier functions.php de votre thème.
Voici comment procéder :
Ce code PHP sur gist ⍈
if( ! defined( 'TEMPLATEPATH' ) ) {
define( 'TEMPLATEPATH', get_template_directory() );
}
Le résultat est, pour le thème "TwentyThirteen" :
/host/www/wp-content/themes/twentythirteen
Habituellement on ne vérifie pas si la constante existe, mais ici elle est déclarée par
WordPress après le chargement de la configuration et des plugins mais juste avant le thème.
Cette valeur pourrait être dépréciée au profit de get_template_directory(), il est donc conseillé
de la définir afin de garder la rétrocompatibilité de vos anciens codes.
- 17 -Réédition de aout 2018 – Julio Potier – https://boiteaweb.fr
STYLESHEETPATH
Type : string - Valeur par défaut : get_stylesheet_directory()
Description : Contient le chemin absolu vers le thème enfant actif sur votre site.
Même chose que pour TEMPLATEPATH, vous pouvez utilisez cette constante pour lire le
chemin vers le thème enfant, mais pour la déclarer c'est un peu différent car WordPress le fera
par la suite. Cette constante est un peu plus spéciale en fait car vous devez la déclarer dans le
fichier functions.php de votre thème. Voici comment procéder :
Ce code PHP sur gist ⍈
if ( ! defined( 'STYLESHEETPATH' ) ) {
define( 'STYLESHEETPATH' , get_stylesheet_directory() );
}
Le résultat est, pour le thème "TwentyThirteen-child" :
/host/www/wp-content/themes/twentythirteen-child
Habituellement on ne vérifie pas si la constante existe, mais ici elle est déclarée par
WordPress après le chargement de la configuration et des plugins mais juste avant le thème.
Cette valeur pourrait être dépréciée au profit de get_stylesheet_directory(), il est donc conseillé
de la définir afin de garder la rétrocompatibilité de vos anciens codes.
d. Les autres chemins
GETID3_TEMP_DIR
Type : string - Valeur par défaut : $temp_dir (ini_get('upload_tmp_dir'); sinon tempnam())
Description : Contient le chemin absolu vers les fichiers temporaires lors de la création par WP
de metadonnées des médias MP3.
2. Les constantes WordPress utiles
a. Les constantes de temps humainement lisibles
Ces constantes ne sont pas redéfinissables, elles vous sont utiles et à utiliser dans vos
développements WordPress afin de faciliter la lecture humaine et donc faciliter la maintenabilité
de votre code.
MINUTE_IN_SECONDS
Type : integer - Valeur : 60
- 18 -Réédition de aout 2018 – Julio Potier – https://boiteaweb.fr
HOUR_IN_SECONDS
Type : integer - Valeur : 60 * MINUTE_IN_SECONDS
DAY_IN_SECONDS
Type : integer - Valeur : 24 * HOUR_IN_SECONDS
WEEK_IN_SECONDS
Type : integer - Valeur : 7 * DAY_IN_SECONDS
MONTH_IN_SECONDS
Type : integer - Valeur : 30 * DAY_IN_SECONDS
YEAR_IN_SECONDS
Type : integer - Valeur : 365 * DAY_IN_SECONDS
b. Les constantes de poids humainement lisibles
KB_IN_BYTES
Type : integer - Valeur : 1024
MB_IN_BYTES
Type : integer - Valeur : 1024 * KB_IN_BYTES
GB_IN_BYTES
Type : integer - Valeur : 1024 * MB_IN_BYTES
TB_IN_BYTES
Type : integer - Valeur : 1024 * GB_IN_BYTES
c. Les constantes diverses
WP_MAX_MEMORY_LIMIT
Type : string - Valeur par défaut : "64M"
Description : Contient la valeur de la mémoire allouée à WordPress dans l'administration et
quelques fonctions.
- 19 -Réédition de aout 2018 – Julio Potier – https://boiteaweb.fr
WordPress touche ici à la configuration PHP de votre serveur afin de modifier la taille de
la mémoire allouée. Mais il le fait bien car la valeur par défaut étant 64Mo, si vous aviez déjà
paramétré plus, alors il ne change rien, dans le cas contraire, il augmente donc cette valeur.
Les fonctions dans lesquelles cette taille mémoire est utilisée sont : Zip/Unzip et
l'éditeur d'images. Si vous pensez que vous avez besoin de plus de mémoire à cause du nombre
ou de la complexité de vos plugins n'hésitez pas à l'augmenter comme ceci :
define( 'WP_MAX_MEMORY_LIMIT', '
128M' ); // Alloue 128Mo de mémoire au lieu de 64
Hors administration, c'est du côté de WP_MEMORY_LIMIT qu'il faut regarder.
WP_MEMORY_LIMIT
Type : string - Valeur par défaut : "40M"
Description : Contient la valeur de la mémoire allouée à WordPress hors administration.
WordPress touche encore à la configuration PHP de votre serveur afin de modifier la
taille de la mémoire allouée. Mais il le fait bien car la valeur par défaut étant 40Mo, si vous
aviez déjà paramétré plus, alors il ne change rien, dans le cas contraire, il augmente donc cette
valeur.
Dans l'administration c'est W P_MAX_MEMORY_LIMIT qui entre en jeu. Si vous pensez que
vous avez besoin de plus de mémoire à cause du nombre ou de la complexité de vos plugins,
d'un site e-commerce bien rempli etc n'hésitez pas à augmenter comme ceci :
define( 'WP_MEMORY_LIMIT', '
64M' ); // Alloue 64Mo de mémoire au lieu de 40
WPLANG ⚠ Dépréciée depuis WordPress 4.0, le 04 septembre 2014.
Type : string - Valeur par défaut : "en_US"
Description : Contenait le nom du fichier de traduction linguistique13 sans extension.
Si WP_LANG_DIR n'est pas déclarée, WordPress regardait en premier dans
"wp-content/languages" puis ensuite dans "wp-includes/languages" si le fichier WPLANG . '.mo'
est présent.
Par défaut la valeur est "en_US" et non pas "en_EN" qui n'existe pas ! Il faut aussi savoir
que charger une traduction d'un site, thème, plugin etc prends plus de temps. Un site en anglais
natif a donc de meilleures performances qu'un site traduit et on ne peut rien y faire.
Dans vos développements ne lisez pas cette constante pour connaître la langue du site,
il faut passer par la fonction get_locale() qui peut être différente car les plugins de langues
peuvent utiliser les hooks pour modifier la valeur à la volée.
- 20 -Réédition de aout 2018 – Julio Potier – https://boiteaweb.fr
SHORTINIT
Type : bool - Valeur par défaut : "FALSE"
Description : Défini si WordPress doit se charger en entier ou pas.
Logiquement utilisé lors de l'utilisation d'un bootstrap5, cela permet de charger
WordPress avec le minimum de choses dont la base de données. Il est donc possible d'utiliser
WordPress sans WordPress, comme un framework, un squelette.
Ne définissez jamais cette constante dans le fichier de configuration car il en résulte une
page blanche en guise de site web. Je vous invite à visiter la référence 5 pour plus de détails.
Dernière chose, même avec S HORTINIT sur T RUE, vous devez avoir une connexion à la base de
données correcte.
RESET_CAPS
Type : bool - Valeur par défaut : NULL
Description : À définir si vous avez besoin de reset les rôles en base de données lors de l'update
de WordPress.
3. Les constantes d'administration
Voici quelques constantes qui n'ont un effet que dans l'administration de WordPress.
a. Les constantes de sécurité
FORCE_SSL_ADMIN
Type : bool - Valeur par défaut : "FALSE"
Description : Permet de forcer le mode SSL31 dans l'administration.
Les appels aux pages d'administrations se feront sur le protocole SSL (HTTPS) au lieu de
HTTP. SSL (ou TLS) est un protocole de sécurisation des échanges sur Internet, il fait passer la
connexion dans un canal sécurisé. Il est souvent associé à HTTP pour former le protocole
HTTPS, utilisé pour sécuriser l'accès à un site web. Cela déclenche aussi la création des cookies
en mode sécurisé. Malheureusement il ne suffit pas de déclarer cette constante sur T RUE pour
profiter d'une connexion sécurisée, vous devez au préalable faire bien plus de choses14. Par
défaut le protocole utilisé est celui distribué par le serveur, la plupart du temps HTTP.
Si votre serveur/hébergeur le permet et que le paramétrage est fait, voici la constante :
Ce code PHP sur gist ⍈
- 21 -Réédition de aout 2018 – Julio Potier – https://boiteaweb.fr
define( 'FORCE_SSL_ADMIN', T
RUE ); // SSL admin activé
FORCE_SSL_LOGIN
Type : bool - Valeur par défaut : "FALSE"
Description : Permet de forcer le mode SSL31 dans la page de connexion.
Dans le même esprit que pour FORCE_SSL_ADMIN, vous pouvez demander à ce que la
page de connexion, qui est aussi la page d'enregistrement, soit gérée sous le protocole HTTPS.
Cela déclenche aussi la création des cookies en mode sécurisé. Par défaut le protocole utilisé
est celui distribué par le serveur, la plupart du temps HTTP.
Ce code PHP sur gist ⍈
define( 'FORCE_SSL_LOGIN', T
RUE ); // SSL login activé
DISALLOW_FILE_EDIT
Type : bool - Valeur par défaut : "FALSE"
Description : Défini si les fichiers des plugins et thèmes peuvent être modifiés directement
depuis l'interface d'administration.
Je ne peux que vous recommander de passer cette constante à TRUE partout où vous
passez. Si vous avez besoin de modifier des fichiers, alors faites le depuis le FTP29 et non pas
depuis une interface d'administration de blog/site. Laisser une porte ouverte à l'édition de
fichiers PHP sur un site est bien trop dangereux. Voici comment passer à TRUE :
Ce code PHP sur gist ⍈
define( 'DISALLOW_FILE_EDIT', TRUE ); // interdit l'édition des fichiers
plugins/themes
DISALLOW_FILE_MODS
Type : bool - Valeur par défaut : "FALSE"
Description : Défini si les fichiers des plugins et thèmes peuvent être modifiés par WordPress
lors d'une mise à jour.
DISALLOW_FILE_MODS fait la même chose que DISALLOW_FILE_EDIT pour les fichiers des
plugins et des thèmes. Mais en plus, elle rends impossible toute modification de ces fichiers et
de ceux du code de WordPress lors des mises à jour automatiques. Contrairement à
DISALLOW_FILE_EDIT il n'est pas obligatoire de passer cette constante à T RUE, sinon voici
comment faire :
Ce code PHP sur gist ⍈
define( 'DISALLOW_FILE_MODS', TRUE ); //interdit la modif. fichiers
plugins/themes/core
- 22 -Réédition de aout 2018 – Julio Potier – https://boiteaweb.fr
DISALLOW_UNFILTERED_HTML
Type : bool - Valeur par défaut : "FALSE"
Description : Défini si le code HTML doit toujours être filtré pour tous les utilisateurs, même
administrateurs.
Cette constante permet d'interdire pour tout le monde l'ajout de code HTML louche ou
malicieux dans une publication par exemple. Par défaut, le fait d'être administrateur nous
donne ce droit, il nous est donc possible d'ajouter des balises dans les publications. Si
vous ne souhaitez pas que cela arrive, même aux administrateurs, déclarez cette constante sur
TRUE.
Ce code PHP sur gist ⍈
define( 'DISALLOW_UNFILTERED_HTML', TRUE ); // toujours filtrer le code HTML
b. Les constantes de développements
WP_ADMIN
Type : bool - Valeur par défaut : "FALSE"
Description : Indique à WordPress que la page actuelle fait partie de l'administration monosite.
Cette constante n'est pas à définir dans le fichier de configuration. Elle est déclarée par
WordPress lorsque vous visitez une page de l'administration monosite. Elle l'est aussi lors d'une
requête AJAX, qu'elle vienne véritablement d'une page admin ou du côté visiteur. En effet
certains plugins ont besoin de faire appel au fichier wp-admin/admin-ajax.php pour mettre à
jour une valeur ou envoyer un formulaire de contact par exemple, cette constante vaudra donc
TRUE.
Même chose pour le fichier de bootstrap5 wp-admin/admin-post.php qui permet d'être
la cible de formulaire côté admin ou non, cette constante vaut la aussi T RUE.
Ne vérifiez pas cette constante directement pour savoir si nous sommes dans une page
d'administration, utilisez plutôt la fonction is_admin().
Encore la même chose pour l'upload asynchrone de fichier via Flash ou d'autres
méthodes maison. Enfin vous pouvez vous aussi la déclarer dans vos développements si vous
créer des bootstrap maison ou des appels ajax personnalisés avec vos propres fichiers.
WP_NETWORK_ADMIN
Type : bool - Valeur par défaut : "FALSE"
Description : Indique à WordPress que la page actuelle fait partie de l'administration du réseau
MultiSite.
- 23 -Réédition de aout 2018 – Julio Potier – https://boiteaweb.fr
Cette constante n'est pas à définir dans le fichier de configuration. Elle est déclarée par
WordPress lorsque vous visitez une page de l'administration du MultiSite. Elle n'est pas définie
lors des requêtes AJAX contrairement à W P_ADMIN.
Ne vérifiez pas cette constante directement pour savoir si nous sommes dans une page
d'administration, utilisez plutôt la fonction is_network_admin(). Cette constante vaut F ALSE si
vous êtes dans un site du réseau, voyez plutôt W P_BLOG_ADMIN.
Enfin vous pouvez vous aussi la déclarer dans vos développements si vous créer des
bootstrap maison ou des appels ajax personnalisés avec vos propres fichiers.
WP_USER_ADMIN
Type : bool - Valeur par défaut : "FALSE"
Description : Indique à WordPress que le menu super admin du MultiSite est chargé.
Cette constante n'est pas à définir dans le fichier de configuration. Elle est déclarée par
WordPress lorsque vous visitez la page de profil du Super-Admin à l'adresse suivante
https://example.com/wp-admin/user/ cette page spéciale ne l'est pas vraiment, elle est même
plutôt vide et j'avoue ne pas avoir trouvé d'utilité ni de documentation supplémentaire.
Ne vérifiez pas cette constante directement pour savoir si nous sommes dans une page
d'administration, utilisez plutôt la fonction is_user_admin().
Enfin vous pouvez vous aussi la déclarer dans vos développements si vous créer des
bootstrap maison ou des appels ajax personnalisés avec vos propres fichiers.
WP_BLOG_ADMIN
Type : bool - Valeur par défaut : "FALSE"
Description : Indique à WordPress que la page visitée est une page du MultiSite, dans un des
sites du réseau.
Cette constante n'est pas à définir dans le fichier de configuration. Elle est déclarée par
WordPress lorsque la page chargée est celle d'un des blogs du réseau MultiSite.
Ne vérifiez pas cette constante directement pour savoir si nous sommes dans une page
d'administration, utilisez plutôt la fonction is_blog_admin().
AUTOMATIC_UPDATER_DISABLED
Type : bool - Valeur par défaut : NULL
Description : Non définie par défaut, elle sert à empêcher la mise à jour automatique du core de
WordPress de fonctionner.
- 24 -Réédition de aout 2018 – Julio Potier – https://boiteaweb.fr
Ne pas l'utiliser, ou alors à FALSE. Voir le filtre "automatic_updater_disabled".
WP_AUTO_UPDATE_CORE
Type : bool|string - Valeur par défaut : NULL
Description : Non définie par défaut, elle peut prendre 3 valeurs : TRUE, FALSE, "minor". Elle
sert à autoriser, refuser ou limiter les mises à automatique du core de WordPress selon la
version.
FALSE= aucune (voir AUTOMATIC_UPDATER_DISABLED), TRUE = majeure + mineure, "minor"
= seulement mineures.
c. Les constantes des médias
IMAGE_EDIT_OVERWRITE
Type : bool - Valeur par défaut : "FALSE"
Description : Permet de ne garder que l'image d'origine lors d'une modification d'image.
Par défaut, quand vous modifiez une image dans WordPress via les médias, WordPress
crée d'autres fichiers en plus de ceux d'origine. Si vous faites 4 manipulations avec 4
sauvegardes et que vous avez 4 tailles d'images vous aurez 64 fichiers. WordPress garde toutes
vos modifications même si vous avez changé d'avis et qu'au final vous gardez l'image d'origine.
Si vous souhaitez que WordPress ne garde pas ces images non utilisées, déclarez cette
constante à T RUE.
Ce code PHP sur gist ⍈
define( 'IMAGE_EDIT_OVERWRITE', TRUE ); // écrase les images des médias lors des
modifs
MEDIA_TRASH
Type : bool - Valeur par défaut : "FALSE"
Description : Permet d'activer la corbeille pour les médias.
Par défaut la corbeille n'est activée que pour les publications. Si vous souhaitez l'activer
pour vos médias, vous pouvez déclarer cette constante sur TRUE. La constante
EMPTY_TRASH_DAYS entre en jeu. Si vous y aviez entré 0 ou F ALSE, alors cette constante est
inutile.
Ce code PHP sur gist ⍈
define( 'MEDIA_TRASH', T
RUE ); // corbeille activée pour les médias
- 25 -Réédition de aout 2018 – Julio Potier – https://boiteaweb.fr
- 26 -Réédition de aout 2018 – Julio Potier – https://boiteaweb.fr
d. Les constantes des utilisateurs
IS_PROFILE_PAGE
Type : bool - Valeur par défaut : "FALSE"
Description : Permet de savoir si la page d'édition d'un utilisateur est la notre.
Cette constante n'est pas à définir, WordPress s'en charge lorsque vous modifiez votre
profil ou que vous essayez de modifier un utilisateur qui n'est autre que vous. Si vous éditer un
autre utilisateur, cette constante faudra F ALSE. Il est très intéressant ici de l'utiliser dans vos
développements afin de savoir si la personne qui édite un utilisateur est en fait en train de
mettre à jour son propre profil.
e. Les constantes des publications
WP_MAIL_INTERVAL
Type : integer - Valeur par défaut : "300" (300 secondes soit 5 minutes)
Description : Contient le nombre de secondes à attendre entre une prochaine vérification de
mails.
Dépendante du filtre enable_post_by_email_configuration ou de la constante dépréciée
POST_BY_EMAIL, cette valeur indique à WordPress le délai de vérification du serveur POP3
paramétré en tant que compte de création de publications à distance.
REST_API_VERSION
Type : integer - Valeur par défaut : La dernière version de REST API14
Description : Indique le numéro de la version de l'API REST en cours.
Cette constante n'est pas à définir, WordPress s'en charge lorsqu'il reçoit une requête
de ce type. Vous pouvez par contre la lire et l'utiliser dans vos développements si vous
souhaitez restreindre ou au contraire, ne faire des actions que si c'est une requête REST.
REST_REQUEST
Type : bool - Valeur par défaut : false
Description : Indique à WordPress qu'une requête de type REST API14 est en cours.
Cette constante n'est pas à définir non plus.
- 27 -Réédition de aout 2018 – Julio Potier – https://boiteaweb.fr
XMLRPC_REQUEST
Type : bool - Valeur par défaut : "FALSE"
Description : Indique à WordPress qu'une requête de type XMLRPC est en cours.
Cette constante n'est pas à définir, WordPress s'en charge lorsqu'il reçoit une requête
de ce type. Vous pouvez par contre la lire et l'utiliser dans vos développements si vous
souhaitez restreindre ou au contraire, ne faire des actions que si c'est une requête XMLRPC.
La fonctionnalité XML-RPC est activée par défaut depuis WordPress 3.5. Dans les
versions précédentes de WordPress, XML-RPC est actif si l'utilisateur le décide. Pour l'activer,
allez dans "Réglages > Ecriture > Edition distante" et cochez la case.
DOING_AUTOSAVE
Type : bool - Valeur par défaut : "FALSE"
Description : Constante témoin indiquant qu'une sauvegarde automatique est en cours.
Cette constante n'est encore une fois pas à définir, elle est définie par WordPress
lorsqu'une sauvegarde automatique d'une publication est lancée. Si vous définissez vous même
cette constante sur T RUE, l'effet sera qu'aucune révisions des publication ne sera faite.
DOING_AJAX
Type : bool - Valeur par défaut : "FALSE"
Description : Constante témoin indiquant qu'une requête AJAX est en cours.
Cette constante n'est pas à définir, elle est définie par WordPress lorsqu'une requête est
lancée afin de modifier son comportement à beaucoup d'endroits. Si vous définissez vous
même cette constante sur T RUE, l'effet sera qu'aucun cron ne se lancera, l'admin bar sera
cachée, certaines pages seront lues comme dans une frame, bref, des bogues en vue, évitez
juste de la définir vous même, hors d'un fichier AJAX maison.
f. Les constantes des extensions
WP_UNINSTALL_PLUGIN
Type : bool - Valeur par défaut : "FALSE"
Description : Indique à WordPress et aux plugins qu'un plugin est en cours de désinstallation.
- 28 -Vous pouvez aussi lire
