Les secrets du fichier wp-config.php

Logo WordPress et couteau suisse
Le paramétrage de WordPress

Marie-Aude

J'ai fait de la compta, de la finance, du juridique, j'ai été chef de projet SAP, j'ai fait de la photo, des voyages. Depuis 2007, je fais avec amour des sites webs pour les utilisateurs, qui se référencent bien et je vous aide à acquérir du trafic pertinent.

Vous aimerez aussi...

56 réponses

  1. bruno bichet dit :

    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 ;)

  2. Laurent DEMONTIERS dit :

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

  3. Marie-Aude dit :

    @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 ^^

  4. Philippe Cadu dit :

    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

  5. Marie-Aude dit :

    Oui, mais à ne pas laisser en permanence :)

  6. Lorand dit :

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

  7. Dric dit :

    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 :

  8. Marie-Aude dit :

    @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.

  9. Philippe Cadu dit :

    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

  10. Olivier dit :

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

    Merci d’avance !

  11. Marie-Aude dit :

    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.

  12. Julien Appert dit :

    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 ;-)

  13. Olivier dit :

    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

  14. Marie-Aude dit :

    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’);

  15. Amaury dit :

    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 !

  16. Marie-Aude dit :

    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.

    :)

  17. Olivier C dit :

    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…

  18. Marie-Aude dit :

    @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

  19. Olivier C dit :

    “… 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

  20. Marie-Aude dit :

    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.

  21. Olivier C dit :

    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.

  22. Lorand dit :

    @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.

  23. Olivier C dit :

    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…

  24. Lorand dit :

    @Olivier C : quelle est la taille actuelle de ta table “Options” ?

  25. Olivier C dit :

    Actuellement : 335,0 Mio…

  26. Lorand dit :

    Ah… en effet !

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

  27. Olivier C dit :

    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…

  28. Lorand dit :

    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.

  29. Olivier C dit :

    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.

  30. Olivier C dit :

    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

  31. Lorand dit :

    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);

  32. Olivier C dit :

    Bien reçu. Merci encore à toi !

  33. Marie-Aude dit :

    Merci à vous deux :)

  34. BreiZh SEO dit :

    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 ;-)

  35. Jacques dit :

    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 ?

  36. Olivier C dit :

    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

  37. jacques dit :

    C’est un point de vue respectable.

    Cordialement

  38. Joao Leitao dit :

    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

  39. Jesse dit :

    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

  40. Marie-Aude dit :

    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é ?

  41. Jesse dit :

    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

  42. Marie-Aude dit :

    Le commentaire concernait les serveurs mutualisés

  43. Jesse dit :

    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

  44. Marie-Aude dit :

    Merci pour l’info :)

  45. Olivier C dit :

    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.

  46. e-oster dit :

    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.

  47. samsab dit :

    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+

    • Marie-Aude dit :

      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 :)

  48. staff dit :

    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.

  49. Olivier C dit :

    @ 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.

  50. staff dit :

    @ Olivier C said,

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

  51. JP dit :

    Bonjour,

    Merci de votre tutoriel. Mais j’au une autre question. Lorsque nous ouvrons l’inspecteur d’éléments Google ou firefox, je constate que dans la section “sources” nous voyons wp-content et l’orsqu’on developpe on voit les plugins etc. En bref comment bloquer ça ?

    A bientôt.

    • Marie-Aude dit :

      C’est difficile. Vous pouvez, comme indiqué dans l’article, changer certaines urls, mais pas empêcher le chargement des fichiers nécessaires aux plugins. Et ça ne sert pas à grand chose en plus

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *