content top

Traduction WordPress : réduire (énormément) l’utilisation de la mémoire PHP

Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 368640 bytes)

C’est énervant hein ?

Pour tous ceux qui hébergent un blog wordpress sur des hébergement limité, cette erreur revient souvent. Cela est due à un paramètre du serveur, qui limite la mémoire utilisable pour l’exécution de scripts PHP, afin de préserver les ressources serveur.

La limite est fréquemment de 32  Mo ce qui est TRES insuffisant pour un blog wordpress un peu élaboré, 64 serait le minimum vital, 128 le confort, 256 la sécurité totale. Mais ces valeurs sont très rares sur les hébergements mutualisés.

L’une des raisons de cette utilisation de la mémoire par WordPress : la traduction. Et oui ! Après une discussion sur le forum francophone de wordpress, l’un des membres signale cet état de fait :

WordPress utilise théoriquement la technique dite « gettext », uniformisée et largement utilisée par les développeurs, car c’est une fonction native du langage php.

Mais curieusement, WordPress utilise son propre système, via des scripts php et donc tout le système de traduction utilise la mémoire php ! L’un des membres du forum signale une solution intéressante : modifier le fichier wordpress faisant appel a cette fonction, afin de réduire de 75% l’utilisation de la mémoire et la libérer pour d’autres scripts !!!!

Ce « patch » a été signalé sur le site officiel wordpress (http://core.trac.wordpress.org/ticket/17268) et en voici la version finale du fichier l10n.php qui se trouve dans /wp-include/

===========================

Télécharger le fichier : [download id="22"] pour wordpress 3.1.3 UNIQUEMENT

Comment ca marche ?

Le nouveau fichier va créer un dossier /wp-lang/ à la racine de votre site, dans lequel il va transférer des fichiers de langue .mo réduits en taille. Il ne traduit QUE ce qui est utilisé. (pour tout ! thèmes, plugins, wordpress). De fait, le temps que la traduction limitée soit réalisée votre interface peut s’afficher en anglais quelques secondes. Rafraîchissez simplement l’écran et la traduction sera appliquée.

Ce problème me fait dire qu’il est peu probable que ce « patch » soit officiellement appliqué sous cette forme car du coup cela peut être très surprenant pour un utilisateur qui se retrouve avec une interface en anglais pendant quelques secondes ! Ca reste donc une solution « de l’extrême » pour ceux qui ont des problèmes de mémoire php.

/!  la ligne 377 a été modifiée par nos soins en rajoutant un @ devant la fonction mkdir car sur certains serveurs (le mien…) sous Cpanel la création des dossiers n’est pas acceptée selon les droits chmod. Le problème à été signalé.

Pour parer à ce problème, si les nouveaux dossiers ne sont pas créés automatiquement, avec votre logiciel FTP créez un dossier /wp-lang/ à la racine de votre site avec les droits chmod 775

Attention toutefois avant d’utiliser ce fichier : faite une sauvegarde de l’original avant de le remplacer par celui ci !

Ce fichier est utilisé sur cette plateforme avec succès et j’ai pu constater une véritable amélioration des performances de l’ensemble.

Merci à Xknown du forum français pour cette trouvaille, et à Naruto pour l’intégration du fichier  !







29 réponses à “Traduction WordPress : réduire (énormément) l’utilisation de la mémoire PHP”

  1. luciole135 dit :

    Excellent article,
    Je viens de le faire sur mon monosite et aucun problème d’affichage.
    Le gain de RAM est de 4Mo sur mes 32 Mo de FREE max, soit un gain de 12,5%.
    merci

    p;s : je vois que vous avez un compteur de téléchargement très astucieux.
    Est-ce un plugin qui le fait ? Si oui, pouvez-vous m’indiquer lequel car j’ai moi aussi quelques petits fichiers en téléchargements sur mon site et le compteur que j’utilise ne fonctionne pas toujours très bien lorsque j’installe d’autres extensions.
    merci

  2. alex dit :

    luciole135, je ne pense pas toucher ce code, au moins pas pour le moment. Espèrons que la personne qui l’as proposé continuera à l’améliorer. Je concentre mes efforts sur un autre sujet de WordPress. :)

    Par ailleurs, en regardant vite fait le plugin dont vous parlez, il semblerait avoir des défaillances de sécurité.

  3. Li-An dit :

    Mais est-ce que c’est intéressant pour les hébergements qui ont suffisamment de mémoire ?

    • aphrodite dit :

      Ben écoute il est en test sur cette plateforme, franchement la vitesse d’affichage de l’admin est vraiment différente. Mais le code comme le dit notre ami est pas très clean, il faut faire évoluer la solution. La merdouille de delai de traduction est vraiment chiante. Par exemple :)

  4. luciole135 dit :

    Merci pour le conseil,
    Après essai de Download Monitor, il s’avère à l’usage trop gourmand en mémoire (2,5 Mo, soit environ 62,5 % du gain des 4 Mo du patch).
    Alors j’ai réactivé mon compteur « cimy-counter » qui lui n’en consomme que 0,17Mo : y’a pas photo.
    cordialement

  5. luciole135 dit :

    Bonjour,
    Je viens de me rendre compte que les caractères accentués dans l’affichage du mois des articles est mal pris en compte :
    le é est remplacé par un point d’interrogation dans un losange.

    Existe-t-il un moyen quelconque de résoudre ce petit problème ?
    Merci,
    cordialement.

  6. chamomor dit :

    Ne me dis pas que tu as osé tester ça pour un réseau clients ? Si ?
    Le truc chiant est qu’il faut le changer pour chaque installation wordpress, ouch, y en a trop, attendons vois si la wp 3.2 n’inclut pas le patch ?

    • aphrodite dit :

      /me siffle en regardant le plafond

      Ben heu.. comment dire… en fait… ben…

      he he he

      SI !!! sur celui la. Mais je l’ai retiré après quelques heures pour les raisons mentionnées.

      J’ignore si ca sera intégré. A priori non, mais a voir…

    • Dimitris dit :

      dit :Alors pour l’instant on patch avec la tnciehque de Robio ?$charset = str_replace(?,?,? ,$_POST['charset']);if(is_array($charset)) { exit; }

  7. kilian dit :

    Bonjour, je viens de faire quand même le test sur une install en 3.2
    le résultat est vraiment impressionnant! la vitesse d’affichage des pages est bluffante, réactivité du site…
    mais plus moyen d’acceder à la partie admin (error 500) :(
    Ceci dit, il est clairement cité que c’est pour une version en 3.1.3 donc je me doutais bien qu’il y aurait un petit bémol mais si il existe une actualisation de ce fichier pour la dernière version de WP je suis preneur!!!!!!

    • aphrodite dit :

      En effet il faut le modifier certainement. D’autre part cette solution est un peu « artisanale » car du coup les traductions ne se font pas imediatement, pour un utilisateur non averti cela peut être très déroutant…

  8. Bertrand dit :

    Whaouh! Merci pour l’article. En remontant au ticket d’origine, on trouve un patch actualisé pour 3.2.X : http://core.trac.wordpress.org/attachment/ticket/17268/wp_gettext_v3.patch

    En ce qui me concerne, passage de 62Mo consommés en moyenne à… 44Mo

    TROP TOP! MERCI! MERCI MERCI! et encore MERCI!!!!!!

    • Bertrand dit :

      Je tempère mon enthousiasme : cela créé un problème avec le plugin WP Event Manager.

      Devant chaque nom d’élément, j’ai maintenant ceci qui s’affiche :

      Project-Id-Version: WordPress 3.2 Report-Msgid-Bugs-To: wp-polyglots@lists.automattic.com POT-Creation-Date: 2011-07-03 19:13:09+00:00 PO-Revision-Date: 2011-07-04 22:52+0100 Last-Translator: WordPress Francophone Language-Team: WordPress Francophone MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Plural-Forms: nplurals=2; plural=n>1 X-Poedit-Language: French X-Poedit-Country: France X-Poedit-SourceCharset: utf-8 X-Poedit-Bookmarks: -1,430,-1,-1,-1,-1,-1,-1,-1,-1

      Je cherche d’où cela peut venir, ou plutôt comment m’en débarrasser.

      • aphrodite dit :

        je ne l’ai pas testé en 3.2 mais l’astuce passait plutot bien en 3.1. Mais bon… ca reste une bidouille un peu ^^

      • Bertrand dit :

        Bien que tout fonctionne avec les autres plugins dont les .mo ont été déplacés, je me suis dit que le problème devait être que Events Manager ne retrouvait pas son fichier .mo.

        Alors, j’ai eu l’idée de modifier le fichier « events-manager/events-manager.php », et notamment les lignes concernant la localisation et le langage qui sont :

        // LOCALIZATION
        load_plugin_textdomain('dbem', false, dirname( plugin_basename( __FILE__ ) ).'include/languages');
        }
        add_filter('plugins_loaded','em_plugins_loaded');

        Mais ça n’a rien changé. Il me semble avoir a peu près tout essayé pour le faire remonter à /wp-lang/fr_FR/LC_MESSAGES/.

        Quelqu’un a-t-il une idée?

  9. Amaury dit :

    Si WordPress utilise une librairie PHP, c’est parce qu’il propose de nombreuses fonctions plutôt avancée concernant la traduction.. (contexte, multiple, etc)

    Donc c’est clairement handicapant d’un point de perf, mais ca facilite le travail des traducteurs !

Trackbacks/Pingbacks

  1. Limiter l’utilisation mémoire PHP sur WordPress » Blog Informatique - [...] fonction native Gettext pour traduire mais son propre système, qui assez gourmand. Il existe un patch pour réduire l’utilisation de la …
  2. Le blog a retourné des données non valides. Et moi j’ai retourné le blog. | Le blog de Michaël - [...] plug-ins et extensions (ou le système de traduction du blog, d’après ce que je peux lire sur cette page …

Laisser une réponse !

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

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>