Languages: English • Deutsch • Français • Hrvatski • Italiano • の編集 日本語 Português do Brasil • Русский • ไทย • 中文(简体) • (Add your language)

Un des fichiers les plus importants de votre installation de WordPress est le fichier wp-config.php. Ce fichier est situé le répertoire de base de WordPress et contient les principales directives de configuration de votre site, comme les informations de connexion à la base de données.

Lorsque vous télécharger WordPress pour la première fois, le fichier wp-config.php n'est pas présent. C'est le processus d'installation de WordPress qui créera le fichier wp-config.php en fonction des informations que vous fournirez.

Les utilisateurs expérimentés peuvent créer manuellement le fichier wp-config.php en utilisant le fichier wp-config-sample.php (qui se trouve dans le répertoire de base), en l'éditant comme nécessaire, puis en l'enregistrant sous wp-config.php.

Pour modifier le wp-config.php pour votre installation, vous aurez besoin de cette information :

Database Name 

Nom de la base de donnée utilisée par WordPress

Database Username 

Compte utilisateur utilisé pour accéder à la base de donnée.

Database Password 

Mot de passe du compte utilisateur utilisé pour accéder à la base de donnée.

Database Host 

Le nom d'hôte du serveur de votre base de donnée. Un numéro de port, le chemin du fichier Unix socket ou le pipe peut être également nécessaire.

Si votre hébergeur a installé WordPress pour vous, vous pourrez obtenir ces informations de leur part. Si vous gérez votre propre Serveur web (en anglais) ou un compte d'hébergement, vous aurez cette information à la suite de Créer la base de données et l'utilisateur (en anglais).

Configurer les Paramètres de la Base de Données

Important : Ne jamais utiliser un traitement de texte comme Microsoft Word pour modifier des fichiers WordPress !

Localisez le fichier wp-config-sample.php à la racine de votre répertoire WordPress ouvrez-le dans un éditeur de texte (en anglais).

wp-config-sample.php par Défaut

Ceci est un exemple de fichier wp-config-sample.php par défaut. Ces valeurs sont des exemples pour vous montrer quoi faire. Vous devez faire les changements sur votre propre site web et pas ici. Si vous apportez des modifications en cliquant sur le bouton d'édition, cela ne fonctionnera pas et vous montrerez votre mot de passe à tout le monde.

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

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

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

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

Configurer le Nom de la Base de Données

Remplacez votre_nom_de_bdd, avec le nom de la base de données, exemple MyDatabaseName.

define( 'DB_NAME', 'MyDatabaseName' ); // Example MySQL database name

Configurer le Compte Utilisateur de la Base de Données

Remplacez votre_utilisateur_de_bdd, avec le nom de l'utilisateur de la base de données, exemple MyUserName.

define( 'DB_USER', 'MyUserName' ); // Example MySQL username

Configurer le Mot de Passe de la Base de Données

Remplacez votre_mdp_de_bdd, avec votre mot de passe, exemple MyPassWord.

define( 'DB_PASSWORD', 'MyPassWord' ); // Example MySQL password

Configurer l'Hôte de la Base de Données

Remplacez localhost, avec le nom d'hôte de votre serveur de base de données, exemple MyDatabaseHost. Un numéro de port ou le chemin du fichier de socket ou Unix chemin du fichier de socket peut être également nécessaire.

define( 'DB_HOST', 'MyDatabaseHost' ); // Example MySQL Database host

Valeurs Possibles du DB_HOST

Différents hébergeurs utilisent des paramètres réseau différents pour leurs bases de données MySQL. Si votre hébergeur est indiqué ci-dessous dans la colonne de gauche, la valeur de droite est similaire à la valeur correcte pour DB_HOST. Contactez votre support technique et / ou rechercher dans la documentation en ligne de votre hébergeur pour en être sûr.

Port Alternatif de MySQL

Si votre hébergeur utilise un numéro de port alternatif pour votre base de données, vous aurez besoin de changer la valeur DB_HOST dans le wp-config.php pour tenir compte du port alternatif fourni par votre hébergeur.

Pour localhost

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

Autre

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

Replacez 3307 avec la valeur du port fournie par votre hébergeur.

Sockets MySQL ou Pipes

Si votre hébergeur utilise des sockets Unix ou des pipes, ajustez la valeur DB_HOST dans le wp-config.php en conséquence.

   define ('DB_HOST', 'localhost:/var/run/mysqld/mysqld.sock');

Remplacez /var/run/mysqld/mysqld.sock avec les informations de socket ou de pipe fournies par votre hébergeur.

Jeux de Caractères de la Base de données

Depuis WordPress, Version 2.2 (en anglais), DB_CHARSET est disponible afin de permettre de choisir le jeu de caractère (en anglais) de la base de données (par exemple tis620 pour TIS620 Thai) à utiliser lors de la définition des tables de la base de données MySQL.

La valeur par défaut utf8 ([Unicode] [UTF-8]) est presque toujours la meilleure option. UTF-8 prend en charge n'importe quelle langue, vous voudrez typiquement laissez la valeur DB_CHARSET à utf8 et utiliser à la place la valeur DB_COLLATE (en anglais) pour votre langue.

Cet exemple montre que utf8 est considéré par WordPress comme sa valeur par défaut :

define('DB_CHARSET', 'utf8');

Collation de la Base de Données

Depuis WordPress version 2.2 (en anglais), DB_COLLATE a été mis en place pour permettre le choix de la collation (en anglais) de la base de données (par exemple l'ordre de tri du jeu de caractères). Dans la plupart des cas, cette valeur doit être laissé vide (null) ainsi la collation de base de données sera automatiquement attribuée par MySQL à partir de la valeur de caractère de la base de données spécifié par DB_CHARSET. Définissez DB_COLLATE parmi l'une des quelconques valeurs UTF-8 définies dans jeux de caractères UTF-8 (en anglais) pour la plupart des langues d'Europe occidentale.

La valeur DB_COLLATE par défaut de WordPress :

define('DB_COLLATE', ); 

UTF-8 Unicode collation général

define('DB_COLLATE', 'utf8_general_ci');

UTF-8 Unicode collation turc

define('DB_COLLATE', 'utf8_turkish_ci');

Clefs de Sécurité

Dans la version Version 2.6, trois (3) clefs de sécurité, AUTH_KEY, SECURE_AUTH_KEY et LOGGED_IN_KEY, ont été ajoutées pour assurer un meilleur cryptage des informations stockées dans les cookies des utilisateurs. (Ces dernières venaient remplacer une clef unique introduite dans la Version 2.5.) Dans la Version 2.7 une quatrième clef, NONCE_KEY, a été ajoutée. lors de la création des clefs, une clef de 'salage' correspondante a été ajoutée : AUTH_SALT, SECURE_AUTH_SALT, LOGGED_IN_SALT et NONCE_SALT.

Vous n'avez pas à vous rappeler des clefs, il suffit de les générer de bonne longueur, aléatoire et complexe - ou, mieux encore, utilisez le générateur de clef en ligne. Vous pouvez modifier celles-ci à n'importe quel moment pour invalider tous les cookies existants. Cela signifie que tous les utilisateurs devront se connecter à nouveau.

Exemple (N'utilisez pas ces clefs !) :

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

Une clef secrète rend votre site plus difficile à pirater plus difficile à casser en ajoutant des éléments aléatoires dans le mot de passe.

En des termes simples, une clé secrète est un mot de passe avec des éléments qui font qu'il est plus difficile de générer suffisamment d'options pour percer vos barrières de sécurité. Un mot de passe comme "mot de passe" ou "test" est simple et se cassent facilement. Un mot de passe construit de manière aléatoire et imprévisible tel que "88a7da62429ba6ad3cb3c76a09641fc" prend des années pour percer la bonne combinaison. Un salage est utilisé pour améliorer davantage la sécurité du résultat généré.

Les quatre clefs sont nécessaires pour améliorer la sécurité. Les quatre salages sont recommandés, mais ne sont pas nécessaires, parce que WordPress va générer des salages pour vous, si aucun n'est fourni. Ils sont inclus dans wp-config.php par défaut pour l'inclusion.

Pour plus d'informations sur l'environnement technique et la répartition des clés secrètes et mots de passe sécurisés, voir :

• Ryan Boren - SSL et Cookies dans WordPress 2.6 (en anglais)
• WordPress Support Forum - HOWTO: Configurer les clefs secrètes dans WordPress 2.6+ (en anglais)
• Wikipedia's explanation of Password Cracking (en anglais)
• Lorelle VanFossen - Protéger sont Blog avec un mot de passe solide (en anglais)
• Astuces de Yahoo pour la sécurité des mots de passe (en anglais)
• Toutes les informations sur le WP-Config (en français)

Options avancées

Les sections suivantes peuvent contenir des informations avancées / non prises en charge, s'il vous plaît, assurez-vous que vous pratiquez des sauvegardes régulièrement et que vous savez comment les restaurer avant d'expérimenter ceci sur une installation en production.

Préfixe des tables

Le $table_prefix est la valeur placée devant les tables de votre base de données. Modifiez la valeur si vous souhaitez utiliser autre chose que wp_ pour le préfixe de votre base de données. Typiquement, cette valeur a été modifiée si vous faites l' installation de plusieurs blogs WordPress (en anglais) dans la même base de données.

  Vous pouvez avoir plusieurs installations dans une même base de données si vous donnez à chacune d'entre elles un préfixe unique   $table_prefix = 'r235_'; // Uniquement des chiffres, des lettres, et souligné s'il vous plaît !

L'installation d'un second blog en utilisant la même base de données peut être fait simplement en utilisant un préfixe différent de vos autres installations   $table_prefix = 'y77_'; // Uniquement des chiffres, des lettres, et souligné s'il vous plaît !

Adresse WordPress (URL)

WP_SITEURL, définie depuis WordPress Version 2.2, autorise la définition de l'adresse (URL) de WordPress. La valeur définie correspond à l'adresse où vos fichiers de base de WordPress résident. Il doit inclure également le http://. N'ajoutez pas de "/" à la fin. Définir cette valeur dans wp-config.php se substitue à la valeur siteurl dans la table wp_options et désactive le champ 'Adresse web de WordPress (URL)' dans le Tableau de bord > Réglages > Général (en anglais).

Si WordPress est installé dans un répertoire nommé "wordpress" pour the domaine example.com, définissez 'WP_SITEURL' comme cela :

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

WP_SITEURL défini dynamiquement à partir de $_SERVER['HTTP_HOST']

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

WP_SITEURL défini dynamiquement à partir de $_SERVER['SERVER_NAME']

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

Adresse du Blog (URL)

WP_HOME est une autre option du wp-config.php ajoutées dans WordPress Version 2.2. Similaire à WP_SITEURL, WP_HOME se substitue à la valeur home dans la table wp_options dans la base de données, mais ne la change pas de manière permanente.. C'est l'adresse que vous souhaitez voir tapée dans le navigateur par les utilisateurs pour accéder à votre site. Il doit inclure également le http:// et ne pas avoir de slash "/" à la fin.

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

Si vous utilisez la technique décrite dans donner à WordPress son propre dossier suivez l'exemple ci-dessous. Rappelez-vous, qu'il vous faudra également placer un index.php dans votre répertoire racine si vous utilisez un paramètre comme celui-ci.

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

WP_HOME défini dynamiquement à partir de $_SERVER['HTTP_HOST']

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

Déplacer le Répertoire wp-content

Depuis la Version 2.6, vous pouvez déplacer le répertoire wp-content, qui contient vos thèmes, vos extensions et téléchargements, à l'extérieur du répertoire applicatif de WorddPress.

Paramétrez WP_CONTENT_DIR vers le chemin local complet de ce répertoire (pas de slash à la fin), comme par exemple :

define( 'WP_CONTENT_DIR', $_SERVER['DOCUMENT_ROOT'] . '/blog/wp-content' );

Paramétrez WP_CONTENT_URL vers l'URL complète de ce répertoire (pas de slash à la fin), comme par exemple :

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

Déplacer le Répertoire plugins

Paramétrez WP_PLUGIN_DIR vers le chemin local complet de ce répertoire (pas de slash à la fin), comme par exemple :

define( 'WP_PLUGIN_DIR', $_SERVER['DOCUMENT_ROOT'] . '/blog/wp-content/plugins' );

Paramétrez WP_PLUGIN_URL vers l'URL complète de ce répertoire (pas de slash à la fin), comme par exemple :

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

Si vous rencontrez des problèmes de compatibilité avec des extensions, paramétrez PLUGINDIRvers le chemin local complet de ce répertoire (pas de slash à la fin), comme par exemple :

define( 'PLUGINDIR', $_SERVER['DOCUMENT_ROOT'] . '/blog/wp-content/plugins' );

Déplacer le Répertoire themes

Déplacer le Répertoire uploads

Paramétrez UPLOADS à :

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

Modifier l'Intervalle de Sauvegarde Automatique

Lorsque l'on modifie un article, WordPress utilise Ajax (en anglais) pour faire des sauvegardes automatique de l'article que vous modifiez. Si vous pourriez avoir envie d'augmenter le délai entre 2 sauvegardes, ou au contraire le diminuer pour être sûr de na pas perdre de changements. Le durée est par défaut de 60 secondes.

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

Révisions des Articles

Par défaut, WordPress va sauvegarder des copies de chaque modification faite sur un article ou une page, offrant ainsi la possibilité de revenir à une ancienne version de votre article ou page. La sauvegarde des révisions peut être désactivée ou peut être limitée à un nombre de révisions par articles ou page spécifié.

Désactiver la Révision des Articles

Si vous ne définissez pas cette valeur, la valeur WP_POST_REVISIONS est positionnée par défaut par WordPress à true (active les révisions). Si vous voulez désactiver cette fonctionnalité, utilisez ce paramétrage :

define('WP_POST_REVISIONS', false );

Spécifier le Nombre de Révisions des Articles

Si vous voulez spécifier un nombre maximum de révision, remplacer false par un entier/nombre (exemple : 3 ou 5).

define('WP_POST_REVISIONS', 3);

Définir les Cookies de Domaine

Le domaine défini dans les cookies pour WordPress peut être spécifiée pour les personnes ayant des configurations inhabituelles de domaine. Une des raisons est que si les sous-domaines sont utilisés pour servir du contenu statique (en anglais). Pour éviter aux cookies WordPress d'être envoyé avec chaque requête au contenu statique sur votre sous-domaine, vous pouvez définir le domaine de cookie seulement pour votre domaine non-statique.

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

Activer le Multisite / Network Ability

WP_ALLOW_MULTISITE est une fonctionnalité introduite dans WordPress Version 3.0 pour activer les fonctionnalités multisites (en anglais) fonctionnant auparavant avec WordPress MU. Si ce réglage est absent du wp-config.php sa valeur est par défaut false.

define('WP_ALLOW_MULTISITE', true);

Déboggage

L'option WP_DEBUG, ajoutée dans WordPress Version 2.3.1, contrôle l'affichage des messages d'avertissements et d'erreur. Si ce réglage est absent du wp-config.php sa valeur est par défaut est false.

define('WP_DEBUG', true);
define('WP_DEBUG', false);

De plus, si vous avez décidé de modifier certaines de WordPress intégré JavaScript (en anglais) ou CSS (en anglais), vous devez ajouter le code suivant à votre fichier de configuration :

define('SCRIPT_DEBUG', true);

Ensuite, toutes les modifications apportées aux fichiers nom_fichier_script.dev.js and nom_fichier.dev.css dans les répertoires wp-includes/js, wp-includes/css, wp-admin/js, et wp-admin/css seront reportées sur votre site.

WordPress depuis la version 2.3.2, n'affiche les erreurs concernant la base de données que si WP_DEBUG est paramétré à true. Dans les versions antérieures les messages d'erreurs concernant la base de données étaient systématiquement affichés. (Les erreurs de base de données sont gérées par la classe wpdb et ne sont pas affectés par les paramètrages d'erreur PHP.)

Dans WordPress version 2.5, la mise à true de WP_DEBUG augmente aussi le niveau de rapports d'erreurs (en anglais) à E_ALL et active des avertissements lorsque des fonctions obsolètes ou fichiers sont utilisés ; autrement, WordPress définit le niveau de rapport d'erreur à E_ALL ^ E_NOTICE ^ E_USER_NOTICE.

Désactiver la Concaténation Javascript

Pour prmettre de rendre la zone d'administration plus performante, tous les fichiers Javascript sont concaténés (en anglais) dans une URL. Si Javascript ne fonctionne pas dans votre espace d'administration, vous pouvez essayer de désactiver cette fonction :

define('CONCATENATE_SCRIPTS', false);

Configurer le Journal d'Erreur

Parce que wp-config.php est chargé à l'affichage de chaque page et nest pas chargé à partir d'un fichier de cache, c'est une excellent idée de définir les paramètres ini de php qui contrôlent votre installation de PHP. Ceci est utile si vous n'avez pas accès à un fichier php.ini, ou si vous voulez juste changer quelques réglages à la volée.

Si vous activez la journalisation des erreurs, n'oubliez pas de supprimer le fichier après. Comme il sera souvent dans un lieu accessible au public, n'importe qui pourrait accéder à votre journal.

Voici un exemple qui active l'error_logging PHP et stocke les informations un fichier spécifique. Si WP_DEBUG est défini à true, les erreurs seront également enregistrées dans ce fichier. Il suffit de placer ceci au-dessus de toutes commandes require_once ou include.

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

Un autre exemple de l'enregistrement des erreurs, comme suggéré par Mike Little sur wp-hackers email list : (en anglais)

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

Une version affinée de Mike Little sur Manchester WordPress User Group : (en anglais)

/**
 * This will log all errors notices and warnings to a file called debug.log in
 * wp-content only when WP_DEBUG is true. if Apache does not have write permission, 
 * you may need to create the file first and set the appropriate permissions (i.e. use 666).
 */

define('WP_DEBUG', true); // or false
if (WP_DEBUG) {
  define('WP_DEBUG_LOG', true);
  define('WP_DEBUG_DISPLAY', false);
  @ini_set('display_errors',0);
}

Augmenter la Mémoire Allouée à PHP

Également mis en place avec la Version 2.5, l'option WP_MEMORY_LIMIT vous autorise à définir une quantité maximum de mémoire pouvant être utilisée par PHP. Ce paramétrage peut être nécessaire lorsque vous recevez un message du type "Allowed memory size of xxxxxx bytes exhausted".

Ce paramètre permet d'accroître la mémoire PHP uniquement pour WordPress et pas les autres applications. Par défaut, WordPress va tenter d'augmenter la mémoire allouée à PHP à 40 Mo (le code est au début du wp-settings.php), de sorte que la configuration dans wp-config.php devrait correspondre à une valeur supérieure à 40 Mo.

WordPress va vérifier automatiquement s'il a été attribué à PHP moins de mémoire que la valeur saisie avant d'utiliser cette fonction. Par exemple, si la mémoire allouée à PHP est de 64 Mo, il n'est pas nécessaire de définir cette valeur à 64M puisque WordPress utilise automatiquement les 64 Mo en cas de besoin.

Notez que ce paramètre peut ne pas fonctionner si votre hébergeur ne permet pas d'augmenter le plafond de la mémoire alloué à PHP - dans ce cas, contactez votre hébergeur pour augmenter le plafond de la mémoire allouée de PHP. Notez également que de nombreux hébergeurs définissent la limite à 8Mo.

Augmenter la mémoire PHP à 64 Mo

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

Augmenter la mémoire PHP à 96 Mo

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

Cache

Lorsque le paramètre WP_CACHE, a la valeur true, il charge le script wp-content/advanced-cache.php, lors de l'exécution de wp-settings.php.

define('WP_CACHE', true);

Tables User et Usermeta Personnalisées

CUSTOM_USER_TABLE et CUSTOM_USER_META_TABLE sont utilisés pour dire que les tables "user" et "usermeta" normalement utilisés par WordPress ne le sont pas et qu'il faut utiliser à la place ces valeurs / tableaux pour stocker les informations de vos utilisateurs.

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

Notez que les autorisations dans les tables user_meta sont enregistrés avec le préfixe de la table du site. Ainsi, dans le CUSTOM_USER_META_TABLE il doit y avoir des entrées pour chaque site utilisant cette table. Au minimum, pour l'administrateur, afin d'éviter le message d'erreur "vous n'avez pas les permissions" vous devriez avoir :

prefix1_capabilities = a:1:{s:13:"administrator";b:1;} et prefix2_capabilities = a:1:{s:13:"administrator";b:1;} etc...

Lorsque vous utilisez CUSTOM_USER_TABLE pendant la configuration initiale il est plus facile de : Configurez votre première instance de wordpress. La définition des états du wp-config.php sur la première instance pointant vers l'emplacement actuel où sont stockées les données utilisateur par défaut "wp_user", puis de copier ce wp-config.php fonctionnel vers votre prochaine instance qui ne nécessite de ne changer que le $ table_prefix = variable comme indiqué précédemment. À ce stade, l'installation se déroulera comme prévu, mais n'utilisez pas une adresse e-mail déjà utilisée par votre installation d'origine. Utilisez une autre adresse e-mail. Une fois que vous avez terminé le processus de configuration connectez-vous avec le compte admin généré automatiquement et mot de passe. Ensuite, donnez à votre compte normal un profil administrateur. Déconnectez-vous du compte admin et connectez-vous sous votre propre compte. Supprimez le compte admin et modifier le profil des autres comptes utilisateurs autant que nécessaire.

Langage et Répertoire Language

WPLANG définit le nom du fichier (.mo) de traduction linguistique. WP_LANG_DIR définit dans quel répertoire le fichier "WPLANG" .mo se situe. Si "WP_LANG_DIR" n'est pas précisé, WordPress regarde en premier dans "wp-content/languages" puis ensuite dans "wp-includes/languages" pour le fichier "WPLANG".mo défini.

define('WPLANG', 'de_DE');
define('WP_LANG_DIR', $_SERVER['DOCUMENT_ROOT'].'wordpress/languages');

Pour connaître le code de langue "WPLANG", veuillez vous référer à WordPress dans votre langue (en anglais). Le code entre parenthèses après chaque titre langage est le code dont vous avez besoin.

Sauvegarder les Requêtes Pour Analyse

Le paramètre SAVEQUERIES sauvegarde les requêtes dans un tableau qui peut-être affiché pour aider à l'analyse de ces requêtes. Cela permet de sauvegarder chaque requête, la fonction appelante et le temps d'exécution.

Ajouter d'abord dans votre wp-config.php :

define('SAVEQUERIES', true);

Mettez ensuite dans le pied de page de votre thème :

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

Remplacer les Permissions des Fichiers par Défaut

Les paramètres FS_CHMOD_DIR et FS_CHMOD_FILE permettent remplacer les permissions par défaut des fichiers. Ces deux variables ont été développés en réponse au problème avec la fonction de mise à jour automatique du cœur chez certains hébergeurs (comme par exemple certains hébergeurs italiens) fonctionnant sous suexec. Si un hébergeur utilise des autorisations de fichiers restrictives (par exemple 400) pour tous les fichiers de l'utilisateur, et refuse l'accès à des fichiers qui ont des permissions pour le groupe ou pour tous le monde, ces paramètre pourraient résoudre le problème. Notez que le ' 0755' est une valeur octale. Les valeurs octales doivent être précédées d'un 0 et ne sont pas délimitées par des apostrophes ('). Voir aussi : Modifier les permissions sur les fichiers

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

Exemple avec le setgid :

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

Les Constantes des Mises À Jour WordPress

Vous devez définir quelques-unes des constantes ci-dessous pour corriger vos problèmes de mise à jour.

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

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

Les informations ci dessous sont des constantes valables pour les mises à jour de WordPress :

• FS_METHOD force la méthode du filesystem. Cela peut être uniquement "direct", "ssh2", "ftpext", or "ftpsockets". En règle générale, vous ne devez modifier cette option que si vous rencontrez des problèmes de mise à jour, si vous le changez, et cela ne vous aide pas revenez en arrière / enlevez-le. Dans la plupart des cas, le mettre à 'ftpsockets' ne fonctionnera que si la méthode choisie automatiquement ne fonctionne pas.
  • (Premier choix) "direct" oblige à utiliser des requêtes I/O directes depuis PHP, c'est responsable de l'ouverture de problèmes de sécurité sur les hôtes mal configurés. C'est choisi automatiquement le cas échéant.
  • (Second choix) "ssh2" oblige à utiliser l'extension SSH de PHP si elle est installée.
  • (3eme choix) "ftpext" oblige à utiliser l'extension FTP de PHP pour l'accès FTP, et enfin
  • (4eme choix) "ftpsockets" utilise la classe de Sockets PHP pour l'accès FTP.
• FTP_BASE is the full path to the "base"(ABSPATH) folder of the WordPress installation.
• FTP_CONTENT_DIR indique le chemin complet vers le répertoire wp-content de l'installation WordPress.
• FTP_PLUGIN_DIR indique le chemin complet vers le répertoire folder de l'installation WordPress.
• FTP_PUBKEY indique le chemin complet vers votre clef publique SSH.
• FTP_PRIKEY indique le chemin complet vers votre clef privée SSH.
• FTP_USER indique à la fois le compte utilisateur FTP ou le nom d'utilisateur SSH. La plupart du temps ils sont identiques, mais utilisez celui qui convient pour le type de mise à jour que vous souhaitez faire.
• FTP_PASS est le mot de passe pour le compte utilisateur entré pour FTP_USER. Si vous utilisez SSH, ceci peut être omis.
• FTP_HOST est la combinaison Nom_d_hote:port pour votre serveur SSH/FTP. Le port FTP par défaut est 21 et le port par défaut SSH est le 22. Ces derniers n'ont pas besoin d'être mentionnés.
• FTP_SSL TRUE pour une connexion SSL si supporté par underlying transport. Ce n'est pas disponible sur tous les serveurs. Ceci est utilisé pour "Secure FTP" et non pour SSH SFTP.

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

Activer les Accès SSH Pour les Mises à Jour

Il y a deux façons de faire les mises à jour en utilisant SSH.

La première est d'utiliser l'extension de support SSH SFTP des mises à jour (en anglais). La seconde est d'utiliser le SSH2 "upgrader" intégré, qui nécessitant que l'extension pecl SSH2 soit installée.

Pour installer l'extension pecl SSH2, vous aurez besoin d'une commande semblable à celle ci-dessous ou demandez à votre hébergeur pour obtenir son installation :

pecl install ssh2

Après avoir installé l'extension pecl SSH2, vous aurez besoin de modifier la configuration de PHP pour charger automatiquement l'extension.

pecl est fournie par le paquet Pear dans la plupart des distributions Linux. Pour installer pecl dans Redhat/Fedora/CentOS :

yum -y install php-pear

Pour installer pecl dans Debian/Ubuntu :

apt-get install php-pear

Il est recommandé d'utiliser une clef privée qui n'est pas protégée par une "pass-phrase". Il y a eu de nombreuses remontées signalant des dysfonctionnements avec des clefs privées protégées par "une pass-phrase". Si vous décidez d'essayer avec une clef privée protégée par "une pass-phrase", vous devrez entrer la "pass-phrase" de la clef privée comme FTP_PASS, ou en la renseignant dans le champ "Password" des informations d'identification s'affichant lors de l'installation des mises à jour.

Si vous n'êtes toujours pas sûr de la façon d'utiliser SSH pour la mise à jour ou l'installation de WordPress / extensions, lisez ce tutoriel (en anglais).

Alternative à Cron

Utilisez ceci, si par exemple, les articles planifiés ne sont pas publiés. Selon les explications d'Otto's forum explanation (en anglais), "Cette méthode alternative utilise une approche par redirection, qui génère dans le navigateur de l'utilisateur une redirection lorsque le cron a besoin de se lancer, de sorte qu'il revienne immédiatement sur le site tandis que le cron continues de s'exécuter dans la connexion qui vient juste d'être abandonnée. Cette méthode est parfois un peu hasardeuse, ce qui explique que ce ne soit pas la valeur par défaut."

define('ALTERNATE_WP_CRON', true);

Autres Constantes Définies

Voici les constantes supplémentaires qui peuvent être définies, mais dont vous ne devriez pas avoir besoin. Les définitions des cookies sont particulièrement utiles si vous avez une configuration de domaine inhabituel.

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

Vider la Corbeille

Ajoutée avec la Version 2.9, cette constante contrôle le nombre de jour avant que WordPress ne détruise de façon permanente articles, pages, pièces-jointes, et commentaires, de la poubelle. par défaut, cette valeur est de 30 jours :

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

Pour désactiver la corbeille, mettez le nombre de jours à zéro. Notez que WordPress ne demandera pas de confirmation lorsque quelqu'un cliquera sur "Supprimer définitivement".

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

Optimisation Automatique de la Base de Données

Avec la Version 2.9, a été ajouté un support de l'optimisation automatique de la base de données, pouvant être activée en ajoutant la ligne ci-dessous dans votre fichier wp-config.php file uniquement lorsque la fonctionnalité est nécessaire :

 define('WP_ALLOW_REPAIR', true);

Le script peut être trouvé dans {$your_site}/wp-admin/maint/repair.php

Notez que cela active la fonctionnalité. L'utilisateur n'a pas besoin d'être connecté pour accéder à cette fonctionnalité lorsque cela a été paramétré. Ceci parce que le but principal est de réparer une base de données endommagée et que les utilisateurs ne peuvent souvent pas se connecter lorsque la base de données est corrompue.

Ne Pas Mettre à Jour les Tables Globales

Le paramètre DO_NOT_UPGRADE_GLOBAL_TABLES empêche dbDelta() et les fonctions de mise à jour des requêtes coûteuses dans les tables Globales.

Les sites ayant de volumineuses tables globales (particulièrement users et usermeta), ainsi que les sites partageant leur table user avec bbPress et d'autres installations WordPress peuvent empêcher la modification de ces tables lors de la mise à jour en définissant DO_NOT_UPGRADE_GLOBAL_TABLES. Étant donné qu'une instruction ALTER, DELETE ou UPDATE, peut prendre beaucoup de temps avant de se terminer, les sites importants veulent habituellement éviter qu'elles ne s'exécutent pendant la mise à jour pour le faire eux-mêmes. En outre, si les installations se partagent les tables utilisateurs entre plusieurs installations bbPress et WordPress, il peut être nécessaire de vouloir définir un site comme étant le maître des mises à jour.

  define('DO_NOT_UPGRADE_GLOBAL_TABLES', true);

Voir Toutes les Constantes Définies

PHP a une fonction qui retourne un tableau contentant l'ensemble des constantes actuellement définies avec leurs valeurs.

 print_r(@get_defined_constants());

Désactiver l’Éditeur d'Extension et de Thème

Occasionnellement, vous pouvez désactiver l'éditeur d'extension ou de thème pour empêcher les utilisateurs trop zélés d'être en mesure de modifier les fichiers sensibles et provoquer un crash du site. La désactivation de celles-ci fournit également une couche de sécurité supplémentaire si un pirate parvenait à accéder à un compte utilisateur privilégié.

   define('DISALLOW_FILE_EDIT',true);

Note : certaines extensions peuvent voir leurs fonctionnalités compromises par l'utilisation de current_user_can('edit_plugins') dans leur code. L'auteur d'extensions doit éviter la vérification de cette capacité, ou du moins vérifier si cette constante est définie et afficher un message d'erreur approprié. Les utilisateurs doivent être conscients que si une extension ne fonctionne pas ceci peut en être la cause.

Désactiver l’Installation d'Extensions et de Thèmes

Cela permet de bloquer la capacité des utilisateurs à utiliser les fonctionnalité d'installation / mise à jour des extensions et thèmes du tableau de bord WordPress. La définition de cette constante désactive également l'éditeur d'extensions et de thèmes (vous n'avez donc pas besoin de définir DISALLOW_FILE_MODS et DISALLOW_FILE_EDIT, DISALLOW_FILE_MODS aura le même effet).

   define('DISALLOW_FILE_MODS',true);

Double Vérification Avant de Sauvegarder

Assurez-vous de vérifier la position et / ou les espaces autour de chacune des valeurs ci-dessus que vous avez entrées, et NE SUPPRIMEZ PAS les guillemets simples !

Avant d'enregistrer le fichier, assurez-vous de faire une double-vérification que vous n'avez pas accidentellement supprimé un des guillemets simples autour des valeurs des paramètres. Assurez-vous qu'il n'y a rien après la balise de fermeture PHP dans le fichier. La dernière chose que dans le fichier doit être  ?> et rien d'autre. Pas d'espaces.

Pour enregistrer le fichier, choisissez Fichier > Enregistrer sous> wp-config.php et enregistrez le fichier à la racine de votre installation de WordPress. Téléchargez le fichier sur votre serveur web et vous êtes prêt à installer WordPress !

Voir Également

• Backups WordPress
• Installer des blogs multiples requiert un wp-config.php particulier (en anglais)
• Dépannage d'installations (en anglais)
• Sécuriser votre installation (en anglais)

Retour à la page d'accueil en français