Guide avancé du développeur pour le fichier wp-config.php

Publié: 2022-09-28

Connaissez-vous vraiment wp-config ? Il y a une puissance surprenante dans ces quelques lignes de PHP ! Cet article est une visite guidée de certains éléments de wp-config que vous ne connaissiez peut-être pas, mais que vous devriez vraiment connaître.

Savez-vous tout ce qu'il y a à savoir sur le fichier wp-config.php ? Avez-vous lu toute la page de documentation de WordPress à ce sujet ? Jusqu'au bout ?

Si vous êtes déjà familiarisé avec les bases de wp-config , la lecture de la documentation officielle de WordPress sera probablement un véritable festin de répétition.

Si vous voulez les vrais délices du développeur, bien regroupés par sujet et livrés avec ce qu'on pourrait appeler « un enthousiasme totalement inutile pour quelques constantes PHP », alors restez dans les parages : je suis sur le point de rendre wp-config.php cool à nouveau.

Milhouse des Simpsons, avec "wp-config" sur le visage et la légende "Ma mère dit que je suis cool".

Table des matières

  1. Qui devrait lire ceci ?
  2. Pourquoi devriez-vous lire ceci ?
  3. Les bases
  4. Affichage des constantes wp-config
  5. Décomposer le processus de chargement de wp-config.php
    1. wp-config peut être déplacé vers le haut
    2. L'écran de configuration se charge s'il n'y a pas de fichier wp-config.php
    3. wp-config.php se charge très tôt
    4. Ne plaisante pas avec wp-config.php !
  6. Vérification/Linting de votre fichier wp-config.php
  7. Sécuriser WordPress avec wp-config.php
    1. Protéger wp-config.php des visiteurs du site Web
    2. Touches rotatives/sels
    3. Déplacer et cacher des choses
    4. Désactivation des éditeurs de fichiers
    5. Désactivation des mises à jour automatiques
    6. Empêcher les requêtes HTTP externes
  8. Déplacer des trucs
    1. Déplacement des tables User et Usermeta
    2. Déplacer les répertoires de contenu, de téléchargements et de plugins
  9. Paramètres liés au contenu
    1. Modifier les URL du site et du tableau de bord
    2. Paramètres de publication
    3. Post-révisions
    4. Modification de l'intervalle d'enregistrement automatique
  10. Emballer

Qui devrait lire ceci ?

Cet article est destiné aux développeurs et aux utilisateurs avancés qui savent déjà comment modifier le fichier wp-config.php et connaissent certains des paramètres de configuration que vous pouvez y mettre.

Je ne vais pas vous dire comment modifier le fichier en utilisant FTP ou cPanel, ou pourquoi vous ne devriez pas utiliser MS Word pour le modifier.

Je ne vais pas vous dire comment configurer votre base de données ou passer en revue les paramètres hérités que vous utilisiez en 2013, mais vous ne devriez vraiment plus en avoir besoin. Et la plupart des hôtes s'occuperont de toute façon des bases pour vous.

Si vous êtes nouveau sur wp-config.php , les guides qui vous donneront les bases ne manquent pas, ou vous pouvez toujours creuser dans la documentation officielle.

Pourquoi devriez-vous lire ceci ?

Ouais, ouais, je t'entends. Si les détails de base de ce que vous pouvez mettre dans cet article sont tous couverts ailleurs, et si votre hébergeur s'occupe quand même de la plupart des bases, pourquoi devriez-vous lire ceci ? Et, en effet, pourquoi est-ce que je passe mon temps à l'écrire ?

Eh bien, si vous êtes satisfait de l'édition de wp-config.php et que vous connaissez les bases de ce qu'il fait, alors vous êtes probablement au moins un développeur WordPress de niveau intermédiaire.

Vous êtes probablement au moins en partie responsable de l'hébergement de grands sites, probablement pour des clients. Vous devez donc savoir comment vous pouvez utiliser ce fichier en cas d'urgence. Et pour avoir une compréhension suffisante de ce fichier, si vous le modifiez, vous ne ferez rien de mal.

De plus, vous voudrez presque certainement verrouiller certaines fonctionnalités de WordPress au-delà de ce que votre hébergeur vous permettra de configurer automatiquement.

Il y a probablement des choses que vous ne savez même pas pouvoir faire avec wp-config.php ! Quelques "Aha !" des instants à vivre.

Cet article est un point de référence utile pour configurer certains éléments internes de WordPress. Alors continuez à lire, marquez et partagez avec vos amis et collègues.

Les bases

J'ai dit que ce n'était pas un article pour débutant, mais nous devrions établir les faits de base pour nous assurer que nous sommes au même point de départ.

Le fichier wp-config.php réside à la racine de votre installation WordPress (il peut résider à d'autres endroits, mais nous y reviendrons), se charge dans le cadre de l'initialisation de WordPress et vous permet de configurer le noyau de WordPress.

Il est essentiel au fonctionnement de WordPress. Il stocke un ensemble de constantes qui vous permettent de spécifier :

  • La connexion à la base de données et le préfixe de table utilisés par WordPress.
  • Informations de sécurité comme les sels et les clés d'authentification.
  • Paramètres pour d'autres fonctionnalités du noyau WordPress telles que WP_CACHE et WP_DEBUG .
  • Paramètres pour les plugins qui peuvent ajouter leurs propres options au fichier.
  • Vos propres options de configuration.

Fondamentalement, wp-config.php est un fichier spécifique à l'environnement. Son contenu peut (et devrait !) être différent pour différents sites. Même les copies locales, intermédiaires et en direct du même site auront des valeurs différentes dans le fichier.

WordPress est livré avec un fichier wp-config-sample.php qui contient le strict minimum de détails dont WordPress a besoin pour fonctionner. Vous pouvez copier ceci dans votre propre wp-config.php dans le cadre de l'installation, mais ces jours-ci, cela se fait généralement pour vous.

Enfin, notez simplement qu'il est possible que lorsque vous ouvrez un fichier wp-config.php à partir d'un site existant, vous puissiez voir certaines anciennes constantes PHP pour les fonctionnalités héritées telles que les autorisations de fichier par défaut et les informations d'identification FTP pour l'exécution des mises à niveau. Nous ne les couvrirons pas ici car il est peu probable que vous ayez besoin de les utiliser.

Affichage des constantes wp-config

Il existe plusieurs façons de vérifier rapidement les valeurs des constantes WordPress sans se connecter en SSH à un serveur distant et sans ouvrir le fichier.

La fonctionnalité Santé du site du cœur de WordPress vous permet d'afficher certaines valeurs de base en accédant à Outils -> Santé du site -> Infos -> Constantes WordPress. Les constantes de base de données peuvent également être vues dans la section "Base de données" de la même page.

Constantes de base de données, affichées ici dans la section Base de données de la page Santé du site WordPress.

Le plugin Query Monitor a un panneau "Environnement" où vous pouvez voir certaines constantes wp-config couramment utilisées.

Le panneau "Environnement" du plug-in Query Monitor, affichant certaines constantes wp-config couramment utilisées.

WP-CLI, l'interface de ligne de commande WordPress, a une commande wp config qui peut être utilisée pour obtenir et définir des constantes dans wp-config.php . Cela nécessiterait normalement que vous vous connectiez d'abord à SSH, mais si vous configurez des alias dans votre configuration WP-CLI, vous pouvez créer un raccourci rapide pour afficher et modifier les constantes dans les fichiers wp-config distants.

Décomposer le processus de chargement de wp-config.php

Il est utile de savoir quand le fichier wp-config.php se charge, car cela détermine certaines des choses que vous pouvez et ne pouvez pas faire avec. C'est un bon exercice pour suivre le processus de chargement :

  • WordPress commence à se charger avec le fichier index.php . Cela nécessite le fichier wp-blog-header.php .

  • À peu près la première chose que fait wp-blog-header.php est de charger wp-load.php .

  • Ensuite, wp-load.php définit la constante ABSPATH (le répertoire de base de WordPress) et initialise error_reporting() avant de charger wp-config.php .

Ce processus de chargement, et le code de wp-load.php en particulier, peuvent nous apprendre quelques choses intéressantes. Voici ce code :

 /* * If wp-config.php exists in the WordPress root, or if it exists in the root and wp-settings.php * doesn't, load wp-config.php. The secondary check for wp-settings.php has the added benefit * of avoiding cases where the current directory is a nested installation, eg / is WordPress(a) * and /blog/ is WordPress(b). * * If neither set of conditions is true, initiate loading the setup process. */ if ( file_exists( ABSPATH . 'wp-config.php' ) ) { /** The config file resides in ABSPATH */ require_once ABSPATH . 'wp-config.php'; } elseif ( @file_exists( dirname( ABSPATH ) . '/wp-config.php' ) && ! @file_exists( dirname( ABSPATH ) . '/wp-settings.php' ) ) { /** The config file resides one level above ABSPATH but is not part of another installation */ require_once dirname( ABSPATH ) . '/wp-config.php'; } else { // A config file doesn't exist. // [Code here to load the setup screen for in-browser configuration] }

Que voyons-nous ici ?

wp-config.php peut être déplacé vers le haut

Tout d'abord, le commentaire nous dit que nous pouvons mettre wp-config.php dans la « racine WordPress ». Ce qu'il omet de mentionner, c'est que la "racine" peut en fait être un répertoire au- dessus de l' ABSPATH où se trouve wp-load.php .

Nous pouvons voir cette vérification supplémentaire dans le elseif où il recherche dirname( ABSPATH ) . '/wp-config.php' dirname( ABSPATH ) . '/wp-config.php' . La condition supplémentaire dans le elseif est expliquée dans le commentaire.

L'écran de configuration se charge s'il n'y a pas de fichier wp-config.php

Deuxièmement, nous pouvons voir que si un fichier de configuration n'existe pas, il chargera l'écran de configuration.

Il est tout à fait possible que vous n'ayez jamais vu cet écran auparavant. Il vous permet de saisir les informations de configuration initiales, telles que les informations d'identification de la base de données, dans une interface utilisateur Web :

L'écran de configuration WordPress rarement vu. WordPress le charge s'il ne trouve pas de fichier de configuration, ce qui vous permet de définir manuellement les options de configuration.

C'est une fonctionnalité de WordPress qui mérite d'être connue. Si jamais vous placez les fichiers principaux de WordPress sur un serveur Web accessible au public, mais que vous ne créez pas de fichier wp-config.php , quelqu'un d'autre (ou, plus probablement, un bot) peut venir et configurer WordPress à sa façon. et éventuellement compromettre votre hébergement.

wp-config.php se charge très tôt

La troisième chose à noter est que wp-config.php est chargé très tôt dans la séquence de démarrage de WordPress. Cela signifie que:

  1. Il y a beaucoup de choses que nous ne pouvons pas faire dans wp-config.php . Par exemple, nous ne pouvons pas ajouter de crochets (actions ou filtres) ici car les fonctions et les structures de données pour le faire ne sont pas encore chargées. Et nous n'avons accès à aucune des fonctions, objets et API internes de WordPress.

  2. Nous avons beaucoup de contrôle sur ce qui se passe ensuite. Parce que le fichier est chargé si tôt, il a beaucoup d'influence sur WordPress. Ceci est à la fois bon et mauvais. Nous pouvons facilement faire mourir complètement WordPress. Mais nous pouvons également accéder à tout ce qui est défini dans wp-config.php à peu près n'importe où ailleurs dans WordPress.

Ne plaisante pas avec wp-config.php !

La dernière chose que nous apprenons de ce processus est que ce grand pouvoir s'accompagne d'une grande responsabilité.

Au bas du fichier wp-config.php se trouvent ces lignes :

 /* Add any custom values between this line and the "stop editing" line. */ /* That's all, stop editing! Happy publishing. */ /** Absolute path to the WordPress directory. */ if ( ! defined( 'ABSPATH' ) ) { define( 'ABSPATH', __DIR__ . '/' ); } /** Sets up WordPress vars and included files. */ require_once ABSPATH . 'wp-settings.php';

Il y a quelques instructions ici, mais la ligne "arrêter l'édition" est importante. Après cette ligne se trouve la suite de la séquence d'initialisation de WordPress. L'ajout d'un nouveau code au mauvais endroit n'aura probablement pour résultat que le nouveau code n'ayant aucun effet. Mais pour être sûr, je recommande de suivre ces instructions. Ils sont là pour une bonne raison.

Vérification/Linting de votre fichier wp-config.php

Si vous travaillez en production, vous ne voulez vraiment pas mettre d'erreurs dans le fichier wp-config.php . Les erreurs ici peuvent casser votre site Web et il se peut que vous n'obteniez pas de message d'erreur utile lorsqu'il le fait.

Vous pouvez exécuter php sur la ligne de commande avec l'option -l ("lint") pour vérifier votre fichier wp-config.php pour les erreurs fatales de syntaxe PHP.

$ php -l wp-config.php

Erreur d'analyse : erreur de syntaxe, jeton inattendu "require_once" dans wp-config.php à la ligne 9

Erreurs d'analyse de wp-config.php

Vous pouvez même écrire un script shell pour…

  1. Copiez wp-config.php dans un fichier temporaire,
  2. Modifier le fichier temporaire,
  3. Lint le fichier temporaire, et
  4. Recopiez-le uniquement s'il ne contient aucune erreur de syntaxe.

Si vous êtes satisfait de la ligne de commande, il est plus sûr d'utiliser les commandes WP-CLI telles que wp config set <name> <value> pour définir des valeurs en toute sécurité plutôt que de le faire à la main.

Vous pouvez également répertorier vos valeurs de configuration avec WP-CLI (il s'agit d'un exemple avec certaines entrées supprimées - vous voyez l'idée !) :

$ liste de configuration wp
+---------------------+------------------------------------- --------------------+----------+
| nom | valeur | taper |
+---------------------+------------------------------------- --------------------+----------+
| root_dir | /Utilisateurs/smithers/sites/snpp | variables |
| répertoire_racine_web | /Utilisateurs/smithers/sites/snpp/public | variables |
| préfixe_table | wp_ | variables |
| WP_HOME | https://snpp.test | constante |
| WP_SITEURL | https://snpp.test/ | constante |
| DB_NAME | snpp | constante |
| DB_USER | racine | constante |
| DB_PASSWORD | Montgomery | constante |
| DB_HOST | 127.0.0.1 | constante |
| DB_CHARSET | utf8mb4 | constante |
| DB_COLLATE | | constante |
| DB_PREFIX | wp_ | constante |
| WP_DEBUG | 1 | constante |
| WP_DEBUG_LOG | 1 | constante |
| WP_DEBUG_DISPLAY | | constante |
| WP_ENVIRONMENT_TYPE | développement | constante |
| DISABLE_WP_CRON | | constante |
| DISALLOW_FILE_EDIT | 1 | constante |
+---------------------+------------------------------------- --------------------+----------+

Ces deux techniques pourraient vraiment vous éviter des tracas et vous empêcher de paniquer à l'idée de mettre accidentellement un point-virgule au mauvais endroit dans un fichier aussi critique.

Sécuriser WordPress avec wp-config.php

La sécurité est un sujet perpétuellement brûlant dans WordPress. Certains paramètres que nous pouvons modifier dans le fichier wp-config placent plus d'outils dans notre boîte à outils de sécurité.

Ces parties du fichier wp-config ne sont certainement pas les seules choses que vous devriez utiliser pour obtenir une bonne sécurité WordPress. Assurez-vous de bien comprendre la sécurité du site Web en plus des informations de la section suivante.

Protéger wp-config.php des visiteurs du site Web

Votre fichier wp-config réside par défaut dans le répertoire racine de votre site Web, et il se trouve qu'il contient des informations critiques telles que les informations de connexion à votre base de données et les sels de mot de passe. Vous ne voulez pas que ces informations soient accessibles au public, vous devez donc vous assurer que votre fichier wp-config est protégé contre les visiteurs du site Web.

Votre hébergeur le fera souvent pour vous. Vous pouvez vérifier en essayant d'accéder au fichier depuis votre navigateur en ajoutant /wp-config.php juste après votre domaine. Cette URL peut être différente si vous avez déplacé le fichier.

Si vous avez placé le fichier wp-config dans le répertoire au-dessus du répertoire racine de votre site Web, vous ne devriez pas pouvoir le voir. Dans la plupart des autres cas, vous obtiendrez de toute façon un message d'erreur PHP lorsque vous essaierez de visiter le fichier, il n'y a donc généralement rien à faire ici. Mais si vous souhaitez le sécuriser correctement, vous pouvez le faire en modifiant la configuration de votre serveur Web (Apache ou nginx) pour en bloquer l'accès.

Enfin, si vous stockez le fichier de votre site Web dans Git, il est important de ne pas stocker le fichier wp-config dans votre référentiel Git. Cela pourrait divulguer des informations critiques sur votre site, mais en plus, vous voudrez probablement une version différente de ce fichier dans chaque environnement de toute façon. Il est donc préférable de l'ajouter à votre .gitignore et de gérer manuellement les fichiers dans chaque environnement.

Touches rotatives/sels

Que sont les clés/sels ?

La section keys and salts est l'une des parties les plus mystérieuses de wp-config . Cet ensemble de constantes étranges aide au cryptage de choses comme les cookies et les nonces. Sans entrer dans les détails, comme le fait WP Engine, ils ajoutent une couche supplémentaire de caractère aléatoire qui rend les choses plus difficiles à décrypter si vous ne connaissez pas les sels et les clés.

Pourquoi "tourner" les clés/sels ?

Tout d'abord, "rotation" n'est qu'un mot fantaisiste pour "changer". Je ne sais pas pourquoi nous utilisons "rotation". Ce n'est pas comme si nous revenions jamais au même jeu de clés !

Vous devriez probablement changer vos clés et vos sels si le site a été piraté, car vous ne pouvez pas garantir que les clés et les sels sont toujours secrets. Mais vous voudrez peut-être les faire pivoter régulièrement de toute façon, comme avec les mots de passe, juste pour être sûr que personne ne sait ce qu'ils sont.

Le problème avec la rotation des clés/sels

Changer les clés et les sels n'est pas sans douleur. Quiconque possède un jeu de cookies le perdra. Ainsi, toute personne connectée sera expulsée et toute personne disposant d'un panier WooCommerce le verra vidé.

Comment faire pivoter les clés/sels

Je veux dire, vous pouvez modifier le fichier wp-config et simplement taper de nouveaux caractères aléatoires sur les anciens. Mais ce serait fastidieux et les humains ne sont pas très doués pour le hasard.

Alors laissez-moi vous parler de quelques façons de définir de nouvelles clés/sels dans votre wp-config .

  1. Ajouter manuellement des clés à partir d'un générateur : vous pouvez utiliser le générateur wordpress.org pour obtenir le code dont vous avez besoin. Copiez-le simplement et collez-le dans le fichier wp-config à la place des anciennes valeurs.
  2. Utilisez un plugin : De nombreux plugins de sécurité comme Sucuri Security, iThemes Security et Malcare ont tous cette fonctionnalité. Et Salt Shaker est un plugin dédié qui automatisera ce processus selon un calendrier pour vous.
  3. Utilisez WP-CLI. Avons-nous déjà dit à quel point WP-CLI est génial ? Nous faisions? D'ACCORD. Eh bien, nous le répétons ! Et vous pouvez utiliser la commande wp config shuffle-salts pour faire ce travail en quelques secondes.

Déplacer et cacher des choses

Les spécialistes de la sécurité vous diront que la "sécurité par l'obscurité" n'est pas du tout la sécurité, mais certaines personnes aiment toujours cacher leurs éléments WordPress pour ériger des barrières supplémentaires contre les pirates.

Le fichier wp-config vous offre un certain nombre d'options pour ce faire, et nous les couvrirons dans des sections ultérieures sur le déplacement d'éléments et la désactivation de l'édition de fichiers.

Désactivation des éditeurs de fichiers

WordPress a une fonctionnalité pratique qui vous permet de modifier des fichiers dans des thèmes et des plugins depuis le tableau de bord d'administration. La modification wp-config.php vous permet de désactiver ces éditeurs de fichiers ! Certaines personnes aiment les désactiver pour avoir l'esprit tranquille.

Maintenant, je sais qu'il existe un argument de sécurité selon lequel si quelqu'un a un accès administrateur à votre site - ce qui est nécessaire pour utiliser ces éditeurs - alors il peut télécharger un plugin et faire ce qu'il veut de toute façon. L'activation de ces éditeurs ne fournit pas aux pirates plus de pouvoir qu'ils n'en ont déjà.

Cependant, bien que la sécurité ne soit pas réellement améliorée en les désactivant, la vraie raison de le faire est d'empêcher les personnes qui sont réellement autorisées en tant qu'administrateurs de les utiliser. Si vous êtes une agence, vous ne voulez probablement pas que vos clients découvrent qu'ils peuvent modifier tous leurs fichiers de thème, n'est-ce pas ?

De nombreux hôtes désactiveront simplement cette fonctionnalité par défaut. Mais si vous voulez les faire disparaître c'est aussi simple que d'ajouter :

 define( 'DISALLOW_FILE_EDIT', true );

Ou si vous voulez vraiment verrouiller votre système de fichiers, il y a DISALLOW_FILE_MODS , que nous aborderons dans la section suivante.

Désactivation des mises à jour automatiques

Que vous les aimiez ou les détestiez, les mises à jour automatiques de WordPress ont eu un impact net positif sur l'écosystème WordPress et sont difficiles à ignorer. Mais tout le monde ne veut pas que son logiciel s'occupe de lui-même !

Ainsi, wp-config vous permet de contrôler le processus de mises à jour automatiques avec un simple ensemble de constantes explicites que vous pouvez définir :

 # Disable all core updates: define( 'WP_AUTO_UPDATE_CORE', false ); # Enable all core updates, including minor and major: define( 'WP_AUTO_UPDATE_CORE', true ); # Enable core updates for minor releases (default): define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Si vous voulez quelque chose de plus extrême, vous pouvez DISALLOW_FILE_MODS :

 define( 'DISALLOW_FILE_MODS', true );

Mais cela empêche WordPress d'écrire quoi que ce soit sur le disque lié au noyau, aux thèmes, aux plugins ou aux traductions, et cela désactive les notifications par e-mail sur les mises à jour mineures. Il a été décrit par un contributeur principal comme "fou stupide à utiliser à moins que vous ne sachiez exactement ce que vous faites".

AUTOMATIC_UPDATER_DISABLED est légèrement moins extrême. Cela vous permet d'installer des plugins et des thèmes, mais ne les mettra pas à jour ni le logiciel principal. Il désactive également les mises à jour de traduction.

 define( 'AUTOMATIC_UPDATER_DISABLED', true );

Il existe un guide détaillé sur tout cela sur wordpress.org, y compris d'autres options comme l'utilisation de filtres pour un contrôle plus précis.

Enfin, je note que si votre site est sous contrôle de version, il est probable que WordPress ait de toute façon désactivé les mises à jour pour vous. Par exemple, la présence d'un répertoire .git à la racine du site (ou de divers autres fichiers à différents endroits) désactivera les mises à jour automatiques sans que vous ayez besoin d'ajouter quoi que ce soit à wp-config .

Configuration de HTTPS

La configuration de HTTPS était souvent difficile. Avec l'avènement de certificats de sécurité gratuits et fiables provenant d'endroits comme LetsEncrypt et Cloudflare, de nombreux hébergeurs le configureront pour vous en quelques clics. Ce paramètre devrait probablement être considéré comme hérité, mais vous en avez peut-être encore besoin pour quelque chose.

La constante FORCE_SSL_ADMIN indique à WordPress de toujours utiliser SSL pour les pages de connexion et le tableau de bord WordPress. Cela garantit que les informations d'identification sécurisées et les cookies ne peuvent pas être envoyés non cryptés.

Mais, comme je l'ai dit, une bonne société d'hébergement va de toute façon simplifier la configuration de HTTPS sur votre site, alors faites-le.

Empêcher les requêtes HTTP externes

Enfin en sécurité, vous pouvez bloquer les requêtes HTTP externes. Cela signifie que WordPress ne peut pas contacter d'autres endroits sur Internet pour faire des choses comme faire des appels d'API ou télécharger des mises à jour.

Autoriser WordPress à contacter des services externes via HTTP est généralement une bonne idée car cela vous permet d'obtenir des mises à jour, d'installer des plugins et des thèmes, et de nombreux plugins tomberont en panne si vous désactivez les requêtes HTTP.

Mais le cœur de WordPress et de nombreux plugins et thèmes renvoient la « télémétrie » ou les « données d'utilisation » aux serveurs centraux. Cela peut être bon - cela aide les développeurs de plugins et de thèmes à savoir qui utilise leur logiciel et comment. Mais si vous avez un site qui contient des données particulièrement sensibles, vous pouvez désactiver cela. Et vous pouvez le faire avec :

 define( 'WP_HTTP_BLOCK_EXTERNAL', true );

Si vous souhaitez avoir une liste autorisée d'hôtes pouvant être contactés, vous pouvez également le faire :

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

Notez que la liste des hôtes accessibles est une liste séparée par des virgules et que les sous-domaines génériques sont autorisés. Et vous pouvez surveiller les hôtes contactés à l'aide du plug-in Log HTTP Requests.

Déplacer des trucs

Toutes les installations de WordPress ne sont pas identiques. Certains hébergeurs ou frameworks aiment déplacer des répertoires pour des raisons de sécurité ou pour garder le code et les actifs spécifiques au site séparés du noyau WordPress. Mon article sur l'utilisation de Git et Composer pour gérer WordPress couvre certains avantages de cette approche.

Alors, quelles options WordPress vous offre-t-il - faute d'un meilleur terme - "déplacer des choses" ?

Modification du préfixe de la base de données

WordPress utilise le préfixe de nom de table de base de données wp_ par défaut. Ce préfixe est ajouté à tous les noms de table de base de données et est également utilisé à d'autres endroits, par exemple l'option <prefix>user_roles dans la table des options et les entrées de méta utilisateur <prefix>capabilities .

Les pirates ou les attaquants peuvent utiliser le préfixe par défaut lors d'une attaque, en essayant de découvrir ou de modifier vos tables de base de données. Certaines personnes recommandent donc de le modifier par défaut.

L'option wp_config $table_prefix vous permet de faire cela et vous devriez probablement la définir sur une chaîne courte mais aléatoire, suffixée par un trait de soulignement :

 $table_prefix = 'b4F8az_';

Cela indiquera à WordPress d'utiliser des noms de table tels que b4F8az_posts au lieu de wp_posts .

Vous ne devriez pas avoir à mettre à jour de code pour répondre à ce changement (à moins que ce code ne soit très mal écrit), mais si vous modifiez cela sur un site existant, vous devrez faire quelques mises à jour de votre base de données - et pas seulement renommer les tables!

Certains plugins de sécurité le feront pour vous et il existe un plugin qui peut aussi le faire. Nous vous recommandons fortement de faire une sauvegarde de votre base de données avant de faire cela, et notez qu'il est préférable de sélectionner un préfixe de table autre que celui par défaut lors de l'installation de WordPress, et non lors de sa modification pendant que votre site est en cours.

Une remarque curieuse à ce sujet est que $table_prefix est une variable, pas une constante. C'est la seule variable définie dans l'exemple de fichier de configuration que WordPress vous donne ! Et si vous êtes encore curieux : oui, les commandes wp config de WP-CLI s'en chargent pour vous sans même que vous ayez à le savoir !

Déplacement des tables User et Usermeta

Je n'ai jamais vu cela se faire, et j'ai seulement appris que cela pouvait être fait lors de la rédaction de cet article, mais vous pouvez également modifier complètement les noms des tables user et usermeta.

Je suppose que cela aide à empêcher une attaque par injection SQL qui tente de "SELECT * FROM wp_usermeta;", mais je suis heureux d'entendre d'autres raisons de le faire.

Dans tous les cas, les constantes CUSTOM_USER_TABLE et CUSTOM_USER_META_TABLE sont ce dont vous avez besoin :

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

Il y a quelques mises en garde qu'il vaut la peine de connaître avant d'utiliser ces constantes. Consultez la documentation officielle avant d'utiliser cette fonctionnalité. Et comme l'utilisation d'un préfixe de table personnalisé, il est certainement préférable de le faire lors de l'installation d'un nouveau site, plutôt que de le modifier ultérieurement.

Déplacer les répertoires de contenu, de téléchargements et de plugins

Il est également possible de déplacer tout le répertoire wp-content , le répertoire uploads et les répertoires themes et plugins . À noter :

  • Dans certains de ces cas, vous devez définir l'URL ainsi que le répertoire.
  • Vous devez faire attention à utiliser des chemins complets ou des chemins relatifs, selon le cas.
  • Aucun de ces paramètres ne doit avoir une barre oblique à la fin.

Consultez la documentation officielle pour plus de détails – je ne vais pas répéter tout cela ici.

Enfin, notez qu'un plugin ou un thème mal codé peut gâcher si vous les modifiez. Cela ne devrait jamais arriver, mais cela vaut la peine d'être connu.

Si vous êtes un développeur de plugins ou de thèmes, il est important de se rappeler que ces chemins peuvent changer. Assurez-vous donc de ne pas coder en dur les chemins vers les répertoires ou les URL. Les fonctions utiles pour vous ici sont :

wp_upload_dir
plugins_url
plugin_dir_url
plugin_dir_path
get_stylesheet_directory
get_stylesheet_directory_uri
get_template_directory - notez que pour un thème enfant, cela renvoie l'emplacement du thème parent
get_template_directory_uri

Il existe une liste plus exhaustive de fonctions comme celles-ci dans le manuel du développeur WordPress.

Enfin, en plus de déplacer des fichiers dans votre installation WordPress, vous pouvez également déplacer votre emplacement wp-admin ou modifier l'emplacement de votre site. Et wp-config.php peut également vous aider.

Paramètres liés au contenu

WordPress est, après tout, un système de gestion de contenu. Vous vous attendez donc à certaines des constantes que vous pouvez utiliser dans wp-config.php pour contrôler les options de contenu. Jetons un coup d'œil et voyons ce que nous pouvons faire.

Modifier les URL du site et du tableau de bord

Ceux-ci m'ont toujours confondu.

Pour définir l'URL de votre site, vous devez utiliser la constante WP_HOME , et non la constante WP_SITEURL .

La constante WP_SITEURL ne change pas l'URL de votre site.

Confus?

La description officielle de ce que fait WP_SITEURL est "l'adresse où résident vos fichiers principaux WordPress". C'est également déroutant car il s'agit d'une URL, pas d'un répertoire.

Ne me blâmez pas pour cela, je ne suis que votre guide touristique pour la journée !

La définition de WP_HOME et WP_SITEURL remplace les entrées home et siteurl dans la table de base de données wp_options . Donc ça, au moins, c'est logique.

 // NOTE: These must not have trailing slashes define( 'WP_HOME', 'https://helfish.media' ); define( 'WP_SITEURL', 'https://hellfish.media/wordpress` );

Vous pouvez utiliser ces constantes après avoir déplacé un site vers une nouvelle URL, pour que le site soit opérationnel pendant que vous corrigez correctement la base de données. Vous pouvez même choisir de les laisser en place par la suite.

Le paramètre WP_SITEURL peut également être utilisé lorsque vous avez déplacé vos fichiers WordPress principaux vers un autre répertoire.

Leur utilisation empêche également l'exécution d'une ou deux requêtes de base de données pour obtenir les valeurs de la table d'options, ce qui peut avoir un gain de performances marginal. Cependant, si vous faites de la mise en cache d'objets, ce gain est probablement négligeable.

Il y a plus de détails dans la documentation officielle, et même un article d'assistance complet sur la modification de l'URL du site. De plus, cet article inclut l'obscure constante RELOCATE pour wp-config.php dont je n'avais jamais entendu parler avant de rechercher cet article.

Enfin, lorsque vous déplacez des sites, notez que ce n'est pas la seule chose que vous devez changer. Une recherche et un remplacement complets de la base de données pour les chaînes d'URL sont recommandés.

Paramètres de publication

Il existe quelques paramètres différents que vous pouvez modifier en ce qui concerne les publications. La plupart d'entre eux concernent soit les révisions de publication, soit la fonction d'enregistrement automatique.

Post-révisions

Le comportement par défaut de WordPress consiste à enregistrer toutes les révisions apportées aux publications et aux pages. L'avantage est qu'il est facile de revenir aux versions précédentes. Les inconvénients sont que toutes ces révisions occupent de l'espace dans la base de données et peuvent avoir un impact sur les performances du site en ralentissant les requêtes de la base de données.

Il est possible de désactiver complètement les révisions de publication en modifiant la valeur WP_POST_REVISIONS dans votre fichier wp-config.php . Il est vrai par défaut. Pour désactiver les révisions, vous pouvez le définir sur false :

 define( 'WP_POST_REVISIONS', false );:

Certains hébergeurs, y compris WP Engine, désactivent les révisions de publication par défaut. Je vous recommande de vérifier auprès de votre fournisseur d'hébergement avant d'apporter des modifications. Cela varie d'un hôte à l'autre, mais si vous utilisez WP Engine, vous ne pouvez pas activer les révisions via wp-config , car elles seront écrasées au niveau du serveur.

Si votre hôte contrôle cela et que vous essayez de le changer, vous ne casserez pas nécessairement quelque chose, mais vous risquez de perdre votre temps.

Si vous craignez que les révisions de publication ne ralentissent les requêtes de base de données, une meilleure option pourrait être de limiter le nombre de révisions stockées par WordPress. Ceci est contrôlé par la constante WP_POST_REVISIONS , que vous pouvez définir sur le nombre maximum de révisions que vous souhaitez conserver :

 define( 'WP_POST_REVISIONS', 5 );

Modification de l'intervalle d'enregistrement automatique

Vous pouvez également réduire la fréquence à laquelle la sauvegarde automatique se déclenche. La valeur par défaut est toutes les 60 secondes, mais vous pouvez la modifier comme bon vous semble. Si vous êtes paranoïaque, vous voudrez peut-être régler cela à 20 ou 30 secondes à la place.

Il est important de garder à l'esprit la durée d'une sauvegarde automatique. Vous ne voulez pas qu'ils se chevauchent en les faisant se produire trop fréquemment, alors ne définissez pas cette valeur sur, par exemple, une seconde. Il est peu probable que les sauvegardes automatiques prennent plus de 60 secondes par défaut, mais vous pouvez augmenter l'intervalle si vous souhaitez enregistrer les requêtes :

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

Emballer

Il y a beaucoup de potentiel dans wp-config qui n'attend que d'être débloqué. J'espère que cette tournée a aidé à mettre en évidence une partie de ce qui est possible. Dans un prochain article, j'examinerai davantage les fonctionnalités avancées inhérentes à wp-config , y compris les installations multisites et le débogage. J'examinerai également les performances, y compris comment ajuster les limites de mémoire, les problèmes CRON et les types d'environnement.

Il y a sans aucun doute d'autres trésors cachés dans la documentation officielle, attendant d'être découverts. Quels conseils avez-vous trouvé pour utiliser wp-config ? Faites-moi savoir dans les commentaires.