Les secrets du fichier wp-config.php

Avec la version 3.0 de WordPress (téléchargeable ici en français) arrive le multiblog, qui doit impérativement être activé via le fichier wp-config.php, et non par une option du tableau de bord.

Pour les impatients, la ligne à ajouter pour activer le multi-site est :

define('WP_ALLOW_MULTISITE', true);

C’est l’occasion de faire un tour d’horizon des constantes qui peuvent être paramétrées dans le fichier wp-config.php, dont certaines sont moins connues que d’autres.

Les paramétrages indispensables du fichier wp-config.php

Ce sont les paramètres présents par défaut. Ils concernent :

la liaison avec la base de données

avec les constantes DB_NAME, DB_USER, DB_PASSWORD et DB_HOST, qui parlent d’elle mêmes, et donc les valeurs sont fournies par votre hébergeur. (Si c’est déjà du chinois, allez lire la série « WordPress pour les nuls », et laissez tomber la suite de cet article).
Plus bas se trouve la variable $table_prefix qui va permettre d’avoir plusieurs blogs stockés sur la même base de données. Personnellement, je gère 6 blogs sur la même base sans problème.

le renforcement de la sécurité

avec les quatres clés de sécurités, AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY et NONCE_KEY qui doivent, dans l’idéal, être des chaines de caractères longues et complexes. Le plus simple est d’utiliser le site indiqué dans le fichier wp-config.php pour générer automatiquement ces clés. Elles peuvent être modifiées sans gêner en quoi que ce soit l’accès au site.

les options de langues du blog

WPLANG permet de définir la langue du blog. La valeur de la constante doit être sous la forme en_UK ou fr_FR.

Il est possible de définir le répertoire où seront stockés les fichiers de langues avec LANGDIR :
define('LANGDIR', 'mylanguagedirectory');, si cette constante n’est pas définie, WordPress recherchera les fichier .mo d’abord dans wp-content/languages puis dans wp-includes/languages.

L’ordre de tri de la base de données est par défaut celui correspondant à la définition du charset de la base de données :
define('DB_COLLATE', );
Si on veut une valeur différente (par exemple avec des blogs dans plusieurs langues sur la même table, il faut renseigner le paramètre, avec le nom utilisé dans mysql, par exemple :
define('DB_COLLATE', 'utf8_general_ci');

L’url du site et les répertoires par défaut

Adresse du site et adresse du blog WordPress

L’url du blog WordPress et l’url du répertoire WordPress, si elle est différente, est normalement modifiée via le dashboard, dans les options générales. Elle est stockées dans la table wp_options.

Le grand classique, c’est le site qu’on déménage, on n’a pas modifié l’adresse du site, et on se retrouve incapable d’accéder à l’admin.

Pour ceux qui ne souhaitent pas faire la modif via phpmyadmin (ou qui n’y ont pas pas accès dans le cas d’installation automatisée sur une base virtuelle, chez OVH ou 1&1 par exemple), il est possible de fixer cette valeur dans le fichier wp-config avec les constantes
WP_SITEURL et WP_HOME (qui ne modifieront pas les valeurs dans la base de données).

Pour ceux qui ont un serveur local qui est la copie de leur serveur de production, il est aussi possible de définir l’adresse à partir de la racine du serveur, avec $_SERVER['HTTP_HOST'] ou $_SERVER['SERVER_NAME']
define('WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST'] . '/path/to/wordpressp'); qui permet de ne pas se poser de questions quand on passe le site de local à public.

wp-content et wp-content /plugins

Il est possible de stocker les dossiers de contenu en dehors de l’architecture WordPress classique.
Il suffit de définir leur chemin d’accès, soit par rapport au serveur (wp_content_dir et wp_plugin_dir), soit avec leur adresse complète (wp_content_url, etc…)
define( 'WP_CONTENT_DIR', $_SERVER['DOCUMENT_ROOT'] . '/blog/wp-content' );

ou

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

Il n’y a pas de constante spécifique pour les thèmes. Donc on peut fixer au choix :

  • un répertoire pour tout le contenu de wp-content
  • un répertoire pour wp-content et un autre répertoire pour wp-plugin -> cela affecte les thèmes (on peut aussi déplacer le dossier de langues, on l’a vu plus haut, et le dossier d’upload se détermine dans les options de l’admin)

Enfin, pour ceux qui intègrent WordPress avec un autre CMS ou avec un site fait maison, il est possible de stocker les templates et/ou les feuilles de styles dans un répertoire différent avec TEMPLATEPATH et STYLESHEETPATH.

Sauvegardes automatiques, versions des posts et corbeille.

Ce sont deux fonctionnalités différentes qui ont pour objectif de nous éviter de perdre nos textes.

La sauvegarde automatique des posts

Comme son nom l’indique, elle enregistre automatiquement à intervalle régulier l’article ou la page que vous êtes en train de rédiger. En bas de l’espace de rédaction, apparaît « Brouillon enregistré à xx  » avec l’heure de la dernière sauvegarde.
C’est un très bon garde fou, notamment contre les plantages d’un navigateur qui feraient disparaître un article presque fini de rédiger, comme par exemple celui-ci.
Il est possible de changer de rythme de sauvegarde (par défaut 60 secondes) avec
define('AUTOSAVE_INTERVAL', 160 );
où 160 représente un nombre de secondes.

La gestion des révisions

La gestion des révisions, c’est WordPress qui stocke chaque état du post, à chaque fois que l’on clique sur sauvegarder. Pour un peu que l’on mette un peu de temps à rédiger un article, ou qu’on le modifie après l’avoir publié, suite à des commentaires, cela peut rapidement faire gonfler le nombre de posts.
Personnellement, je ne pense pas que cette fonctionnalité soit utile si on a un seul rédacteur sur un blog.
On peut donc la désactiver avec
define('WP_POST_REVISIONS', false );
ou au moins limiter le nombre de versions qui seront stockées avec
define('WP_POST_REVISIONS', 3);
(ou 2 ou 5 ou ce que vous voulez).

La corbeille

Depuis la 2.9, les articles ne sont plus supprimés directement, mais mis en stockage intermédiaire dans la corbeille (statut dans wp_posts : trash). Par défaut, WordPress conserve les articles pendant 30 jours avant de les supprimer définitivement.
On peut diminuer ce laps de temps avec
define('EMPTY_TRASH_DAYS', 30 );
où 30 est le nombre de jours.
En mettant 0 on désactive complétement la corbeille. Mais attention, il n’y a plus d’avertissement avant la suppression du post, c’est donc un réglage dangereux.

La performance du blog

Taille mémoire pour php

Un problème récurrent est la taille de la mémoire allouée à php.
Selon les hébergeurs, il est possible de modifier cette valeur via le php.ini (par exemple, chez 1&1, il est possible de créer un fichier php.ini à la racine du site), mais si on n’a pas cette possibilité, le wp-config permet de modifier l’allocation mémoire uniquement pour WordPress avec
define('WP_MEMORY_LIMIT', '96M');

Activer le cache

WordPress dispose d’un script de cache, qui permet d’améliorer la performance en cas de nombre de visites important. On l’active avec la ligne
define('WP_CACHE', true);

Enfin WordPress permet un certain nombre de réglages pour les développeurs, avec le débugage, la concaténation ou pas des javas, etc. Le détail se trouve dans l’article du codex sur le fichier wp-config.

54 commentaires

  1. bruno bichet Auteur juin 21, 2010 (2:07 )

    Salut,

    Cet article tombe vraiment bien : je me posais justement la question de savoir quelles étaient les options disponibles dans ce fichier.

    La même chose avec functions.php (genre activer les menus, toussa) ?

    Merci ;)

    Répondre à bruno bichet
  2. Laurent DEMONTIERS Auteur juin 21, 2010 (3:02 )

    Merci pour cet article très clair. Effectivement, je me posais la même question que Bruno sur le fichier « fonctions.php ».

    Répondre à Laurent DEMONTIERS
  3. Marie-Aude Auteur juin 21, 2010 (3:58 )

    @bruno/laurent… a vos ordres chef(s) ^^

    :)

    Cela dit certaines options (comme la gestion de la mémoire php) peuvent aussi être paramétrées dans le fichier functions.php ^^

    Répondre à Marie-Aude
  4. Philippe Cadu Auteur juin 21, 2010 (5:22 )

    Bonjour,
    il y a aussi cette de ligne de commande
    qui est pour est pour nettoyer la base de données des requetes non utilisées

    define(‘WP_ALLOW_REPAIR’, true);

    merci pour ce récap très utile
    cordialement
    Phil

    Répondre à Philippe Cadu
  5. Marie-Aude Auteur juin 21, 2010 (6:42 )

    Oui, mais à ne pas laisser en permanence :)

    Répondre à Marie-Aude
  6. Lorand Auteur juin 21, 2010 (11:04 )

    Merci pour ces infos, j’avais oublié de mettre à jour mon config.php après la mise à jour 3.0 :)

    Répondre à Lorand
  7. Dric Auteur juin 22, 2010 (8:01 )

    Sur un mutualisé 1&1 on peut effectivement augmenter la mémoire via un php.ini (qui n’est actif que pour le répertoire courant et pas pour les sous-répertoires d’ailleurs), mais dans les faits elle restera à 32Mo : http://faq.1and1.fr/scripts/php/6.html

    Répondre à Dric
  8. Marie-Aude Auteur juin 22, 2010 (9:05 )

    @Dric il faut quand même le faire, car selon la même faq ^^ passer à php5 (qui est une nécessité absolue avec WordPress) fait retomber la mémoire php à 8 mega.

    Répondre à Marie-Aude
  9. Philippe Cadu Auteur juin 22, 2010 (9:32 )

    bonsoir
    Merci Marie Aude pour l’info parce je l’avais mis en permanence
    et pour la mémoire php
    est il nécessaire que je mette cette ligne
    define(‘WP_MEMORY_LIMIT’, ’96M’);
    alors que j’ai les chiffres ci-dessous
    # Limite de la mémoire PHP : 128M
    # PHP : Taille maximum de l’envoi : 64M

    Répondre à Philippe Cadu
  10. Olivier Auteur juin 25, 2010 (12:01 )

    Est-ce possible d’utiliser ce fichier pour désactiver les balises d’URL canonique ? Si oui comment ?

    Merci d’avance !

    Répondre à Olivier
  11. Marie-Aude Auteur juin 26, 2010 (2:06 )

    Que je sache, les balises d’url canonique sont à mettre dans le fichier du thème, donc il suffit de les désactiver en les enlevant. Mais je peux me tromper. En revanche, il n’y a pas de constante pour cela dans le fichier wp-config, ni de hook pour les enlever.

    Répondre à Marie-Aude
  12. Julien Appert Auteur juin 26, 2010 (5:56 )

    Pour répondre à Bruno et Laurent, concernant le functions.php : c’est beaucoup plus compliqué. En fait ce fichier se comporte plus ou moins comme une extension. Pour savoir ce qu’on peut y mettre, il faut donc commencer par apprendre à faire des extensions. Mais là ce n’est plus de l’intégration ou de la configuration, c’est du développement ;-)

    Répondre à Julien Appert
  13. Olivier Auteur juin 26, 2010 (9:22 )

    Non la balise d’URL canonique n’est pas dans le template, elle semble générée par la fonction wp_head()

    En fait bizarrement j’ai un double slash avant le début d’une catégorie (et pas les autres), j’ignore pourquoi.

    En attendant j’ai supprimé l’URL canonique dans le fichier includes/default-filters

    Répondre à Olivier
  14. Marie-Aude Auteur juin 27, 2010 (10:30 )

    Effectivement, il y a une fonction qui est apparue récemment.

    Essayez de faire (justement dans le fichier functions.php)

    remove_action(‘wp_head’, ‘rel_canonical’);

    Répondre à Marie-Aude
  15. Amaury Auteur juin 27, 2010 (12:03 )

    Sauf erreur de ma part, tu as oublié de parlé de WP_DEBUG, the CONSTANTE pour les développeurs de plugins !

    La constante permet d’affiche les erreurs, warnings et notice PHP, chose très utile pour peaufiner le code d’un plugin !

    Répondre à Amaury
  16. Marie-Aude Auteur juin 27, 2010 (1:16 )

    C’est vrai que cette constante (et quelques autres…) sont super utiles pour les développeurs :)
    Mais comme ce n’était pas à eux que ça s’adressait
    Enfin WordPress permet un certain nombre de réglages pour les développeurs, avec le débugage, la concaténation ou pas des javas, etc.

    :)

    Répondre à Marie-Aude
  17. Olivier C Auteur juin 29, 2010 (12:48 )

    Bonjour,
    En essayant la fonction : « define(‘WP_POST_REVISIONS’, false ); », tous mes articles et pages sont passés à la poubelle. C’est normal ?

    Ce genre de fonction serait pourtant intéressant pour moi car pour une raison qui m’échappe ma base MySQL grossit de manière exponentielle : je l’ai déjà effacé et rétablie par une sauvegarde xml (sans problème) mais j’ai l’impression que le phénomène recommence. Je n’ai pourtant qu’une centaine d’articles et trente commentaire…

    Répondre à Olivier C
  18. Marie-Aude Auteur juin 29, 2010 (9:28 )

    @Olivier, non ce n’est pas « normal », car le changement ne s’applique que sur les nouveaux articles, en plus il faut purger la base des révisions existantes via phpmyadmin.

    Pour la taille de la base, les révisions ne sont normalement pas un facteur gênant. En revanche, les plugins de stats, oui

    Répondre à Marie-Aude
  19. Olivier C Auteur juin 29, 2010 (11:50 )

    « … il faut purger la base des révisions existantes via phpmyadmin. »

    C’est ce que j’avais fait hier et la taille de la base MySQL était redevenue très acceptable (4 Mo). Mais après reconfiguration de WordPress la taille est déjà repassée à plus de 11 Mo… je n’y comprends rien.

    Je me pencherais sur la question des stats, sur des forums d’autres signalent effectivement ce problème, mais qu’ils influencent la taille de la base en si peu de temps cela m’étonne…

    Si je trouve un jour la solution à ce problème je vous le ferais savoir, mais vu mes connaissances en BDD ce n’est pas gagné !

    Bien à vous

    Répondre à Olivier C
  20. Marie-Aude Auteur juin 29, 2010 (1:00 )

    Les plugins de stats génèrent des tables énormes. De toute façon c’est assez simple à voir, il suffit de regarder dans la base quelles sont les plus grosses tables. J’ai du mal à croire que les révisions puissent générer 7 mégas en une journée.

    En revanche, rien qu’en allant voir votre code source, je vois un truc étrange, avec des SSID dans les liens des catégories. Je ne sais pas ce qui peut le générer, mais c’est peut être l’explication.

    Répondre à Marie-Aude
  21. Olivier C Auteur juin 29, 2010 (1:17 )

    En fait j’ai déjà repéré la table qui je pense me pose problème : c’est celle qui garde en mémoire les configurations de WordPress (wp_options). Mon problème est de comprendre pourquoi, les données qui y sont stockées ne me semble pas anormales…

    PS : Que voulez-vous dire par SSID dans les liens de catégories ?

    En tout cas merci pour vos éclairages.

    Répondre à Olivier C
  22. Lorand Auteur juin 29, 2010 (1:36 )

    @Olivier C : il y a un plugin pour nettoyer la table « Options », il se nomme Clean Options. A utiliser avec beaucoup de prudence évidemment mais ça permet de faire un peu de nettoyage surtout au niveau des restes de plugins désinstallés. je l’utilise une fois par mois, sinon je le désactive.

    Répondre à Lorand
  23. Olivier C Auteur juin 29, 2010 (5:42 )

    Merci du tuyau Lorand, je viens de l’essayer…

    En fait une réparation et optimisation de la base n’a pas d’effet conséquent sur la taille du fichier incriminé. J’avais déjà essayé en direct à partir de phpmyadmin sans passer par un plugin (quoi qu’il en soit je garde ton plugin sous le coude : j’évite les plugins mais ça peut servir pour des amis !).

    Et surtout je voudrais agir en amont : sur la cause du problème, que je ne connais toujours pas…

    Répondre à Olivier C
  24. Lorand Auteur juin 29, 2010 (10:54 )

    @Olivier C : quelle est la taille actuelle de ta table « Options » ?

    Répondre à Lorand
  25. Olivier C Auteur juin 30, 2010 (9:50 )

    Actuellement : 335,0 Mio…

    Répondre à Olivier C
  26. Lorand Auteur juin 30, 2010 (11:39 )

    Ah… en effet !

    Ma table fait 1.2 Mo
    Tu as regardé ce qu’elle contient pour arriver à 335 Mo?

    Répondre à Lorand
  27. Olivier C Auteur juin 30, 2010 (12:17 )

    Ben justement… il me semble que rien n’est anormal : juste des éléments de configuration WordPress, le nom du site, les mots de passes, etc.

    Après, je passe peut-être à côté du problème, après tout je n’y connais rien…

    Répondre à Olivier C
  28. Lorand Auteur juin 30, 2010 (1:09 )

    Je t’ai envoyé un e-mail il y a quelques heures Olivier, si éventuellement je peux t’aider n’hésite pas à y répondre.

    Répondre à Lorand
  29. Olivier C Auteur juin 30, 2010 (1:47 )

    Merci Lorand je viens de m’en apercevoir.

    PS : je me suis trompé : il s’agissait en fait de 335ko (d’ailleurs mon hébergeur n’aurait jamais accepté au-delà de 35 Mo). En fait c’est le total des tables qui est bizarre, et non une table en particulier.

    Répondre à Olivier C
  30. Olivier C Auteur juin 30, 2010 (5:53 )

    Un petit retour, et surtout un grand remerciement à Lorand :

    Lorand m’a écrit en MP : « La taille de ta BDD augmente et c’est normal. Principalement au niveau de la table wp_posts qui grossit au fur et à mesure de tes publications. Dans cette table, tu verras que la colonne post_status indique « Publish » (pour les articles publiés) mais également « Inherit ». C’est ce dernier statut qui peut-être supprimé et qui concerne les sauvegardes automatiques faites par WordPress. »

    Et bien merci Lorand : j’ai suivis tes instructions à la lettre et ma base est redevenue normale. Il s’agissait donc bien des sauvegardes des articles : contrairement à beaucoup de bloggeurs j’ai la fâcheuse habitude de les rectifier/améliorer certains articles sans cesse. Et tu viens de me donner le remède pour le gonflement de ma base SQL… moins radical et fastidieux qu’une RAZ totale de la base !

    (le gonflement exponentiel de ma base MySQL hier provient je pense du déplacement de tout le site à la poubelle puis son rétablissement en manuel, cela a dû générer une sauvegarde automatique conséquente)

    Encore merci pour tout Lorand, grâce à toi je viens de commencer à comprendre un peu du fonctionnement d’une base MySQL. Tiens : du coup ça m’a donné envie de lire le site du zéro au sujet du PHP et MySQL ! un peu de formation en la matière ça ne me fera pas de mal…

    Bien à toi

    Répondre à Olivier C
  31. Lorand Auteur juin 30, 2010 (9:00 )

    Content d’avoir pu t’aider ne serait-ce qu’un minimum :)

    J’ai aussi tendance à modifier régulièrement une grande partie de mes billets et ça va donc très vite dans la base de données.

    Pour ma part, j’ai réglé mon config.php comme ceci pour limiter un peu :

    /* disable post-revisioning nonsense */
    define(‘WP_POST_REVISIONS’, 2);

    Répondre à Lorand
  32. Olivier C Auteur juin 30, 2010 (9:10 )

    Bien reçu. Merci encore à toi !

    Répondre à Olivier C
  33. Marie-Aude Auteur juin 30, 2010 (9:20 )

    Merci à vous deux :)

    Répondre à Marie-Aude
  34. BreiZh SEO Auteur juillet 3, 2010 (2:08 )

    Très bon résumé des possibilités offertes par le wp-config.php. Je le mets en marque-page. Ça me permettra de toujours l’avoir sous la main. Je connaissais déjà quelques fonctions.

    Merci bien ;-)

    Répondre à BreiZh SEO
  35. Marie-Aude Auteur juillet 3, 2010 (6:58 )
  36. Jacques Auteur juillet 12, 2010 (7:38 )

    Merci Marie-Aude pour ce très bel article.
    La discussion entre Olivier C et Laurent me laisse un peu perplexe, pourquoi ne pas utiliser tout simplement le plugin « wp-optimize » ?
    Y voyez-vous un inconvénient ?

    Répondre à Jacques
  37. Olivier C Auteur juillet 12, 2010 (7:56 )

    Bonjour Jacques,

    Personnellement : je raison je n’en ai pas, il y a juste que je connais WP depuis seulement quelques mois et que je ne connais pas très bien tous les plugins, et c’était le cas alors pour le plugin cité.

    Mais surtout je n’aime pas trop les utiliser, même si l’on peut les désactiver entre deux utilisations. Je préfère soit taper du code (pour remplacer un plugin), soit comprendre le fonctionnement de ma base sans passer par un intermédiaire (dans le cas d’un plugin d’administration).

    Comme ça si je décide un jour de m’initier à d’autres CMS de ne suis pas complètement tributaire de WordPress.

    Bien à vous

    Répondre à Olivier C
  38. jacques Auteur juillet 12, 2010 (8:06 )

    C’est un point de vue respectable.

    Cordialement

    Répondre à jacques
  39. Joao Leitao Auteur juillet 29, 2010 (8:27 )

    Très bon article sur une partie très important de wordpress et wp3.0. c’est vrai que une chose a voir très important avec wordpress c’est la question de sécurité de pas avoir quelqu’un entre dans votre système.

    Merci et un salut d’Ouarzazate, encore votre travaille est très bien.
    cordialement João Leitão

    Répondre à Joao Leitao
  40. Jesse Auteur août 15, 2010 (3:53 )

    bonjour,

    vos billets sont passionnants et sont d’une grande aide. J’ai un souci avec Wpmu3.01 en multisites sur un serveur dédié 1&1. Je n’ai que 7 extensions actives et je sèche sur ce pb d’allocation de mémoire.

    Le plugin cité plus haut (WP-Memory-Usage) me donne les indications suivantes :

    * PHP Version : 5.1.6 / 64Bit OS
    * Memory limit : 32 MByte
    * Memory usage : 31.72 MByte

    Par exemple en essayant autoblog j’ai

    Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 7680 bytes) in /var/www/vhosts/xxx/httpdocs/wp-content/plugins/autoblogincludes/classes/autoblogprocess.php on line 73

    Je me demande si un fichier php.ini comme indiqué par 1&1 règlerait le problème, si ça vient bien de là d’ailleurs, d’autant que 32M est un plafond …et il est atteint.

    J’avais ce pb sur un autre serveur dédié mais sur lequel il y avait pas mal d’appli. Pour éviter de tout planter j’ai tout installé sur une nouvelle machine où ne tourne que ce site, vide et n’est pas en exploitation

    Avant de faire une mauvaise manip (n’étant pas un programmeur) pourriez-vous m’indiquer une solution ou une piste à explorer?

    Merci

    Répondre à Jesse
  41. Marie-Aude Auteur août 15, 2010 (6:14 )

    Bonjour, je ne suis pas une spécialiste du multisite, mais il me semble que l’autoblogging peut être très consommateur de ressources ?

    Par ailleurs, cela me surprend que vous ayez ce plafond de 32m sur un serveur dédié ?

    Répondre à Marie-Aude
  42. Jesse Auteur août 15, 2010 (6:44 )

    Le problème se pose avec d’autres plug in également à vrai dire.
    Pour la limite des 32M j’ai vu ça dans un article à partir d’ici.

    J’appellerai 1&1 demain mais je pense que ça va coincer car dès qu’on a un serveur dédié pfuitt…plus personne

    Répondre à Jesse
  43. Marie-Aude Auteur août 15, 2010 (7:16 )

    Le commentaire concernait les serveurs mutualisés

    Répondre à Marie-Aude
  44. Jesse Auteur août 16, 2010 (4:52 )

    Pb de mémoire résolu. Je partage l’info si ça peut aider pour WPMU3 en multisites.
    Config : Serveur dédié 1and1 – Plesk – CentOS

    1 – Modification de la valeur du php.ini en passant par une connexion SSH
    redémarrage du serveur par la console client
    redémarrage de Apache

    2 – Ajout dans le wp-config d’une ligne pour caler la mémoire avec une nouvelle valeur

    3 – Ajout dans le .htaccess d’une ligne du même genre.

    Have fun

    Répondre à Jesse
  45. Marie-Aude Auteur août 16, 2010 (6:17 )

    Merci pour l’info :)

    Répondre à Marie-Aude
  46. Olivier C Auteur octobre 11, 2010 (10:35 )

    Un petit retours avec la fonction « define(‘WP_POST_REVISIONS’, false ); » pour laquelle j’avais eu des problèmes (cf. plus haut) :

    En fait il ne faut pas placer ce code n’importe où dans le fichier wp-config, tout simplement (et surtout pas à la fin, cela fait planter le site, chez moi en tout cas, pour d’autres emplacement il ne se passe rien, aucun effet du code).

    Je l’ai mis avant les clefs d’identification et c’est ok.

    Répondre à Olivier C
  47. e-oster Auteur novembre 15, 2010 (7:14 )

    Bonjour,

    Merci pour cette explication qui est très claire et j’ai une question subsidiaire: j’ai réussi à installer WP mu mais depuis mes flux RSS merdent (la page monsite/feeds/ a disparu). Je pense donc qu’il faut que j’aille intervenir sur les fichiers php. Avez vous une idée duquel? Et avez vous un code à me donner?
    Merci d’avance de votre aide car moi je ne m’en sors pas mais je débute avec WP.

    Répondre à e-oster
    • Marie-Aude Auteur novembre 15, 2010 (7:29 )

      Je suis désolée mais je ne connais pas WPmu (qui en plus est remplacé par le multiblog dans la 3.0) Ce n’est pas le plus simple de commencer par mu :)

      Répondre à Marie-Aude
  48. samsab Auteur décembre 11, 2010 (9:44 )

    bonjour
    merci pour ce billet, super utile.
    le fait d’activer le cache a quelle conséquence:
    1. en terme de référencement: est il facilité, amélioré?
    2. en terme de mise à jour des pages mises en cache: comment se fait se fait elle lorsqu’un nouveau billet est publié. autrement dit y a t il une action à faire pour rafraichir le cache régulièrement, ou plus précisément à chaque nouveau billet?

    merci pour tes réponses.
    A+

    Répondre à samsab
    • Marie-Aude Auteur décembre 11, 2010 (12:22 )

      Le cache améliore la vitesse de chargement, qui est maintenant un critère pour Google.

      Il est mise à jour automatiquement, à intervalles réguliers. Les pages impliquées par la publication d’un nouvel article sont automatiquement mises à jour. C’est plus pour les modifications que les délais peuvent apparaître, mais on peut toujours forcer la mise à jour de la page en rajoutant un ? à la fin de l’url

      Maintenant le cache est inutile pour des trafics petits à moyens :)

      Répondre à Marie-Aude
  49. staff Auteur janvier 20, 2011 (6:15 )

    Bonsoir,
    Pour ma part, la ligne : define(‘WP_POST_REVISIONS’, false); ne fonctionne pas, je ne comprend pas pourquoi.
    Je l’ai ajouté au fichier config.php, mais les révisions s’effectuent toujours.

    Répondre à staff
  50. Olivier C Auteur janvier 21, 2011 (1:57 )

    @ staff said,

    Personnellement j’ai mis des semaines avant de trouver la soluce : en fait, cela dépend de l’emplacement de la ligne de code dans le fichier wp-config, un mauvais emplacement peu même aller jusqu’à mettre tous vos articles à la poubelle de WordPress ! (cf. mes messages plus hauts).

    Essayez de mettre le code juste avant vos clefs d’identification.

    Répondre à Olivier C
  51. staff Auteur janvier 25, 2011 (9:22 )

    @ Olivier C said,

    Effectivement, de cette façon ça à l’air de fonctionner ! :)
    Merci Olivier ;)

    Répondre à staff

Commenter

*

*

*Informations requises Merci de donner les informations requises

VotreNom@VotreMotClé, à utiliser avec tact et modération ! ( De toute façon, les spammeurs sont blacklistés )