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 : Fichier gettext l10n.php de Wordpress (297) 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 !
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 !
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!!!!!!
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.
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 ^^
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 :
// LOCALIZATIONload_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?
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!!!!!!
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…
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 ?
/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…
dit :Alors pour l’instant on patch avec la tnciehque de Robio ?$charset = str_replace(?,?,? ,$_POST['charset']);if(is_array($charset)) { exit; }
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.
et oui voila l’un des problèmes. en faisant un refresh ca passe pas ?
Non, j’ai beau actualiser, la page, cela reste ainsi, regardez :
http://additifstabac.free.fr/index.php/sgbd-sql-requete-fictive-compte-absence-enregistrements-base-donnees/
Dans l’admin, les accents sont bien présents, le problème ne se pose que pour les accents des noms des mois dans les articles et uniquement à cet endroit là, c’est étrange.
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
Download monitor est assez gourmand oui mais il fait aussi bien plus de choses (la page download par eexemple plutot bien faite).
Mais comme j’ai pas de souci de mémoire j’hésite pas a utiliser ce genre de choses
Ah ah. C’est vrai que Download M est vraiment très bien fichu. Et quelle bonne traduction !
ouaip et il m’a jamais fait un bug, il marche bien en multisite, le pied quoi ^^
xnkown sur le forum WordPress m’a dit que :
« Bon, votre thème, qui n’est pas très bien fait, est la cause du problème. Dans le fichier index.php (et probablement dans les autres pages aussi) changez
par
»
J’ai modifié cette ligne dans les fichiers :
index.php
archive.php
search.php
Et maintenant ça fonctionne.
Bon, le code n’est pas passé, je retente :
par
dit
onc, pour bien ptacher, on mettrai qqch du genre$Charset = $ _POST [ 'charset'];if(is_array($charset)) { exit; }$charset = str_replace(?,?,? ,$charset);Correct ?
ATTENTION
ces patch ne sont plus d’actualité et concernent une ancienne version de WP. A vérifier si applicable avec les nouvelles versions….
Mais est-ce que c’est intéressant pour les hébergements qui ont suffisamment de mémoire ?
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
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é.
plugin ??? lequel donc ? le patch ?
Non, pas le patch. Le plugin Download Monitor.
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
J’ai encore le problème de la traduction non immédiate.
Pour le download oui c’est tout simplement Download Monitor qui gère cela, celui utilisé dans la section « traductions » !
Espèrons alors que xknown rendra le code plus propre.
J’installe Download monitor dès aujourd’hui,
merci.