Articles

WordPress Configuration Tricks

Beaucoup d’utilisateurs de WordPress connaissent le fichier wp-config.php comme la clé de la base de données de WordPress. C’est là que vous définissez le nom de la base de données, le nom d’utilisateur, le mot de passe et l’emplacement (parmi d’autres choses comme les clés de sécurité, le préfixe de la base de données et la langue localisée).

Voici une capture d’écran de wp-config.php (alias le fichier de configuration de WordPress) pour ceux qui ne sont pas encore familiers:

The WordPress Configuration File, wp-config.phpLe wp-config.php contient les informations nécessaires à WordPress pour se connecter à la base de données

Mais ce que beaucoup d’utilisateurs ne savent pas, c’est que le fichier wp-config.php peut être utilisé pour spécifier une grande variété de paramètres de configuration, vous permettant d’améliorer les fonctionnalités, les performances et la sécurité de votre site alimenté par WordPress. Dans cet article, je partage autant de ces astuces de configuration que j’ai pu en collecter au fil des années. Ce guide couvre tout ce qui se trouve dans le Codex WordPress, ainsi que quelques astuces supplémentaires que vous n’avez probablement pas vues auparavant. Si vous connaissez d’autres astuces de configuration de WordPress, partagez-les dans les commentaires et je les ajouterai à l’article.

Mise à jour ! Consultez l’article suivant pour d’autres astuces de configuration de WordPress « 

Database Credentials *

Cet ensemble de quatre définitions de configuration est nécessaire pour que WordPress se connecte à la base de données :

define('DB_NAME', 'database-name');define('DB_USER', 'database-username');define('DB_PASSWORD', 'database-password');define('DB_HOST', 'localhost');

Le nom de la base de données, le nom d’utilisateur et le mot de passe devraient être facilement disponibles pour vous lors de la création de la base de données, mais la valeur DB_HOST peut être plus difficile à acquérir. Le plus souvent, cette valeur est simplement « localhost« , mais si cela ne fonctionne pas, voici quelques autres valeurs à essayer :

  • 1and1 Hosting – db12345678
  • DreamHost – mysql.example.com
  • GoDaddy – h41mysql52.secureserver.net
  • ICDSoft – localhost:/tmp/mysql5.sock
  • MediaTemple. (GS) – internal-db.s44441.gridserver.com
  • Pair Networks – dbnnnx.pair.com
  • Yahoo – mysql

Vous pouvez même spécifier un port alternatif pour votre serveur de base de données. Voici deux exemples :

define('DB_HOST', 'localhost:1234');
define('DB_HOST', 'mysql.domain.tld:1234');

Une autre astuce sympa consiste à détecter automatiquement la valeur du serveur de base de données :

define('DB_HOST', $_ENV{DATABASE_SERVER});

Si tout cela échoue, ou si vous avez encore des problèmes, consultez votre fournisseur d’hébergement pour obtenir de l’aide.

Jeu de caractères et collation de la base de données *

Depuis la version 2.2 de WordPress, vous pouvez spécifier un jeu de caractères pour vos tables de base de données MySQL. En général, il n’y a aucune raison de changer la valeur par défaut du jeu de caractères UTF-8, qui est généralement parfait car il supporte toutes les langues. Voici le paramètre par défaut (et recommandé) :

define('DB_CHARSET', 'utf8');

La version 2.2 de WordPress vous permet également de spécifier la collation, qui est l’ordre de tri du jeu de caractères de votre base de données. Le paramétrage de la collation est généralement géré automatiquement par MySQL en fonction du jeu de caractères, ce qui est activé en laissant la valeur de collation vide comme cela est fait dans le paramétrage par défaut de cette définition. Voici le réglage par défaut (et recommandé) :

define('DB_COLLATE', '');
Note : n’utilisez ces deux définitions que si elles existent déjà dans votre fichier wp-config.php.

Clefs de sécurité *

Depuis WordPress 2.7, il existe quatre clés de sécurité disponibles qui sont conçues pour assurer un meilleur cryptage des cookies. Ces clés fonctionnent silencieusement en arrière-plan et doivent être aussi aléatoires et compliquées que possible (non, vous n’aurez jamais besoin de vous en souvenir). La façon la plus simple de générer ces clés est de le faire automatiquement sur le service de clés secrètes de WordPress.org. Il suffit de visiter ce lien et de copier/coller les résultats dans votre fichier wp-config.php. Notez que ces clés peuvent être modifiées à tout moment, et le faire invalidera tous les cookies existants de vos utilisateurs, de sorte qu’ils devront se reconnecter à votre site.

define('AUTH_KEY', ':dr+%/5V4sAUG-gg%aS*v;&xGhd%{YV)p:Qi?jXLq,<h\`39');define('SECURE_AUTH_KEY', '@*+S=8\"\'+\"}]<m#+}V)p:Qi?jXLq,<h\`39m_(');define('LOGGED_IN_KEY', 'S~AACm4h1;T^\"qW3_8Zv!Ji=y|)~5i63JI |Al.'/path/to/wordpress');define('WP_SITEURL', 'http://'.$_SERVER.'/path/to/wordpress');

Probablement mieux d’échapper à ces valeurs si vous les utilisez sur un site public.

Chemin de modèle et chemin de feuille de style

Comme pour les constantes prédéfinies pour l’adresse du blog et l’adresse du site (voir la section précédente), vous pouvez également stimuler les performances en éliminant les requêtes de base de données pour le chemin de modèle et le chemin de feuille de style de votre site. Voici les valeurs par défaut de ces deux définitions :

define('TEMPLATEPATH', get_template_directory());define('STYLESHEETPATH', get_stylesheet_directory());

En l’état, ces deux définitions interrogent toujours la base de données, mais nous pouvons éliminer ces requêtes superflues en codant en dur les valeurs en place :

define('TEMPLATEPATH', '/absolute/path/to/wp-content/themes/active-theme');define('STYLESHEETPATH', '/absolute/path/to/wp-content/themes/active-theme');

Désactiver le cache et l’expiration du cache

Ces deux options s’appliquent aux anciennes versions de WordPress qui utilisent toujours le mécanisme de mise en cache par défaut basé sur les objets. La première définition vous permet d’activer ou de désactiver le cache, tandis que la seconde vous permet de spécifier le délai d’expiration du cache.

Activer le cache

define('WP_CACHE', true); // enable the cachedefine('ENABLE_CACHE', true); // enable the cachedefine('CACHE_EXPIRATION_TIME', 3600); // in seconds

Désactiver le cache

define('WP_CACHE', false); // disable the cachedefine('DISABLE_CACHE', true); // disable the cache

Spécifier le domaine des cookies

Il existe plusieurs raisons pour lesquelles vous souhaitez spécifier un domaine de cookies pour votre site. Un exemple courant consiste à empêcher l’envoi de cookies avec des demandes de contenu statique sur des sous-domaines. Dans ce cas, vous utiliseriez cette définition pour dire à WordPress d’envoyer des cookies uniquement à votre domaine non statique. Cela peut constituer un gain de performance significatif. Voici quelques exemples de définition de diverses informations sur le chemin et le domaine des cookies :

define('COOKIE_DOMAIN', '.digwp.com'); // don't omit the leading '.'define('COOKIEPATH', preg_replace('|https?://+|i', '', get_option('home').'/'));define('SITECOOKIEPATH', preg_replace('|https?://+|i', '', get_option('siteurl').'/'));define('PLUGINS_COOKIE_PATH', preg_replace('|https?://+|i', '', WP_PLUGIN_URL));define('ADMIN_COOKIE_PATH', SITECOOKIEPATH.'wp-admin');

Passer outre les autorisations de fichiers

Si les autorisations de fichiers par défaut de votre hébergeur sont trop restrictives, l’ajout de ces définitions à votre fichier de configuration WordPress peut aider à résoudre le problème. Notez que vous n’avez pas besoin des guillemets autour des valeurs de permission. Par exemple :

define('FS_CHMOD_FILE', 0755);define('FS_CHMOD_DIR', 0755);

Voir toutes les constantes définies

Vous avez besoin de voir toutes les constantes prédéfinies ? Bonne nouvelle, cette fonction PHP renverra un tableau de toutes les constantes actuellement définies:

print_r(@get_defined_constants());

Tables d’utilisateurs et d’usermeta personnalisées

Qu’en est-il des tables d’utilisateurs et d’usermeta personnalisées ? Yep, vous pouvez le faire aussi, avec les définitions suivantes:

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

Constantes FTP/SSH

Cet ensemble de définitions de configuration est conçu pour aider les utilisateurs à localiser et utiliser les connexions FTP/SSH. Voici un exemple d’ensemble de constantes prédéfinies pour les mises à jour FTP/SSH:

define('FS_METHOD', 'ftpext'); // forces the filesystem method: "direct", "ssh", "ftpext", or "ftpsockets"define('FTP_BASE', '/path/to/wordpress/'); // absolute path to root installation directorydefine('FTP_CONTENT_DIR', '/path/to/wordpress/wp-content/'); // absolute path to "wp-content" directorydefine('FTP_PLUGIN_DIR ', '/path/to/wordpress/wp-content/plugins/'); // absolute path to "wp-plugins" directorydefine('FTP_PUBKEY', '/home/username/.ssh/id_rsa.pub'); // absolute path to your SSH public keydefine('FTP_PRIVKEY', '/home/username/.ssh/id_rsa'); // absolute path to your SSH private keydefine('FTP_USER', 'username'); // either your FTP or SSH usernamedefine('FTP_PASS', 'password'); // password for FTP_USER usernamedefine('FTP_HOST', 'ftp.domain.tld:21'); // hostname:port combo for your SSH/FTP server

Déplacement de votre répertoire wp-content

Depuis la version 2.6 de WordPress, vous pouvez modifier l’emplacement par défaut du répertoire wp-content. Il y a plusieurs bonnes raisons de le faire, notamment le renforcement de la sécurité du site et la facilitation des mises à jour FTP. Quelques exemples:

// full local path of current directory (no trailing slash)define('WP_CONTENT_DIR', $_SERVER.'/path/wp-content'); // full URI of current directory (no trailing slash)define('WP_CONTENT_URL', 'http://domain.tld/path/wp-content');

Vous pouvez également spécifier un chemin personnalisé pour votre répertoire plugins. Cela peut aider à résoudre les problèmes de compatibilité avec certains plugins :

// full local path of current directory (no trailing slash)define('WP_PLUGIN_DIR', $_SERVER.'/path/wp-content/plugins'); // full URI of current directory (no trailing slash)define('WP_PLUGIN_URL', 'http://domain.tld/path/wp-content/plugins');

Gérer les révisions d’articles

Les versions récentes de WordPress fournissent un système de révision d’articles qui permet aux utilisateurs d’enregistrer différentes versions de leurs articles de blog et même de revenir aux versions précédemment enregistrées si nécessaire. Indépendamment de la façon dont vous méprisez ou non cette fonctionnalité étonnamment géniale, voici quelques définitions de configuration qui peuvent s’avérer utiles pour vous 😉

Limiter le nombre de révisions sauvegardées

define('WP_POST_REVISIONS', 3); // any integer, but don't get too crazy

Désactiver la fonctionnalité de post-révision

define('WP_POST_REVISIONS', false);

Spécifier l’intervalle d’enregistrement automatique

Dans une veine similaire à la fonctionnalité de post-révision, il y a la fonctionnalité d’enregistrement automatique de WordPress, réellement utile. Par défaut, WordPress sauvegarde votre travail toutes les 60 secondes, mais vous pouvez tout à fait modifier ce paramètre comme vous le souhaitez. Ne soyez pas trop fou cependant, à moins que vous ne vouliez stresser votre serveur 😉

define('AUTOSAVE_INTERVAL', 160); // in seconds

Déboguer WordPress

Depuis la version 2.3.1 de WordPress, les utilisateurs peuvent afficher certaines erreurs et avertissements pour aider au débogage de leur site. Depuis la version 2.5 de WordPress, l’activation de l’affichage des erreurs fait passer le niveau d’affichage à E_ALL et active les avertissements pour les fonctions dépréciées. Par défaut (c’est-à-dire si aucune définition n’est spécifiée dans le fichier wp-config.php), le signalement des erreurs est désactivé.

define('WP_DEBUG', true); // enable debugging modedefine('WP_DEBUG', false); // disable debugging mode (default)

Configuration du journal des erreurs

Voici un moyen facile d’activer le journal des erreurs de base pour votre site alimenté par WordPress. Créez un fichier appelé « php_error.log« , rendez-le inscriptible sur le serveur, et placez-le dans le répertoire de votre choix. Modifiez ensuite le chemin d’accès de la troisième ligne du code suivant et placez-le dans votre fichier wp-config.php:

@ini_set('log_errors','On');@ini_set('display_errors','Off');@ini_set('error_log','/home/path/domain/logs/php_error.log');

Augmenter la mémoire PHP

Si vous recevez des messages d’erreur vous indiquant que votre « Taille de mémoire autorisée de xxx octets épuisée », ce paramètre peut aider à résoudre le problème. À partir de la version 2.5 de WordPress, la définition WP_MEMORY_LIMIT vous permet de spécifier la quantité maximale de mémoire qui peut être utilisée par PHP. Par défaut, WordPress tentera automatiquement d’augmenter la mémoire de PHP jusqu’à 32 Mo, ce paramètre n’est donc nécessaire que pour les valeurs supérieures à 32 Mo. Notez que certains hébergeurs désactivent votre capacité à augmenter la mémoire PHP, vous devrez donc peut-être les supplier pour qu’ils le fassent. Voici quelques exemples:

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

Enregistrer et afficher les requêtes de base de données pour analyse

Cette technique est parfaite pour enregistrer les requêtes de base de données et afficher les informations pour une analyse ultérieure. Le processus enregistre chaque requête, sa fonction associée et son temps d’exécution total. Ces informations sont enregistrées sous forme de tableau et peuvent être affichées sur n’importe quelle page de modèle de thème. Pour ce faire, ajoutez d’abord la directive suivante à votre fichier wp-config.php:

define('SAVEQUERIES', true);

Puis, dans le pied de page de votre thème actif, placez le code suivant:

// display the query array for admin onlyif (current_user_can('level_10')) {global $wpdb;echo "<pre>";print_r($wpdb->queries);echo "</pre>";}

Voici une version à une ligne de cette fonction:

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

Contrôle de l’accès au proxy

Depuis WordPress 2.8, le fichier de configuration peut être utilisé pour définir les constantes impliquées dans le blocage, l’autorisation et le filtrage de l’accès à des hôtes spécifiques derrière un serveur proxy. Par exemple, si vous hébergez votre site WordPress sur un réseau intranet, vous pouvez empêcher l’accès à tous les hôtes externes et n’autoriser que les requêtes provenant de localhost et de votre blog en utilisant la première définition ci-dessous. Vous pouvez également autoriser l’accès à des hôtes spécifiques avec une liste de noms d’hôtes autorisés séparés par des virgules, comme le démontre la troisième définition ci-dessous.

define('WP_HTTP_BLOCK_EXTERNAL', true); // block external requestsdefine('WP_HTTP_BLOCK_EXTERNAL', false); // allow external requestsdefine('WP_ACCESSIBLE_HOSTS', 'api.wordpress.org'); // whitelist hosts
Notez que vous devriez autoriser l’accès api.wordpress.org pour assurer la bonne fonctionnalité des fichiers de base et des plugins.

Ouf ! Je suis essuyé. Il est temps de faire une petite pause 🙂

Notes

  • * Indique que le code est inclus dans le fichier wp-config.php par défaut
  • Traduction portugaise brésilienne (par Tárcio Zemel)

.