WordPress und der Speicherverbrauch

Von Vladimir am 07. 09. 2009 um 22:53

WordPress-Anleitung für Autoren & Redakteure als E-Book oder als PDF
WordPress-Handbuch für Admins & Webmaster als E-Book oder als PDF
300+ Professionelle WordPress-Themes, 38 davon mit deutschem Support
Empfehlenswerte Premium-Plugins für WordPress
Hinweis in eigener Sache

Ich habe schon von mehreren Kollegen und Lesern gehört … eigentlich gelesen in denen man sich über den PHP-Speicherverbrauch von WordPress 2.8.x beschwert hat. Irgendwie konnte ich das nicht ganz nachvollziehen, weil bei mir so weit alles in grünem Bereich lag. Der Speicherverbrauch lag bei meinem Weblog trotz mittlerweile 28 Plugins und der deutschen Sprachdatei bei lediglich 22,69 MByte und damit bei einer Auslastung von 35%.

Der Speicherverbrauch von WordPress

Ich habe das Thema eigentlich schon vergessen, bis ich Gestern auf ein paar Lesezeichen gestoßen bin, welche ich vor mehreren Wochen in den Ordner "Noch zu lesen" abgelegt habe. So viel zum Thema Informations-Management.

Der erste Link führt zum Beitrag von Dieter Welzel. Dort werden zwei Gründe aufgeführt warum eine WordPress-Installation verhältnismäßig viel Speicher in Anspruch nehmen kann. Zum einen wird auf Servern mit 64-Bit Systemen in manchen Fällen fast der doppelte Speicherverbrauch vermeldet.

Interessant in diesem Zusammenhang ist auch der Beitrag bei WordPress-Deutschland.org.

Eine weitere Ursache ist auch die nicht ganz optimale Verarbeitung der deutschen Sprachdatei (de_DE.mo) durch die Datei /wp-includes/pomo/mo.php. Je nach Installation kann man hier zwischen mehreren hundert KByte bis ein paar MByte an beanspruchten PHP-Speicher frei schaufeln, wenn man die optimierte mo.php von Heiko Rabe benutzt.

Speicherverbrauch von WordPress nach Austausch der Datei

Durch den Austausch der mo.php konnte ich gut 830 KByte bzw. 1%-Punkt an PHP-Speicherbedarf einsparen. Das ist nicht die Welt, aber in den Kommentaren bei Heiko sieht man, dass bei manchen Leuten der Speicherbedarf um mehrere MByte runter gegangen ist. Je höher der ursprüngliche Speicherverbrauch um so höher das Einsparpotential.

Eine weitere Maßnahme, die bei der Reduzierung des PHP-Speicherbedarfs helfen soll (ich habe es noch nicht getestet) ist der Einsatz von Caching-Plugins. Was an sich logisch ist, weil diese aus den einzelnen Artikeln statische HTML-Dokumente machen und dadurch, bei der Auslieferung der entsprechenden Artikel, PHP nicht beansprucht wird.

Diesen Artikel weiterempfehlen oder später lesen:

auf Kindle (später) lesen

29 Kommentare

1. – Dieter

Kommentar vom 07.09.2009 um 23:12

1. Danke für die Nennung und Verlinkung meines Blogbeitrags.
2. Danke für den Hinweis auf reduzierten Speicherbedarf durch Caching-Plugins. Leuchtet ein, kannte ich aber noch nicht. Werde ich mal ausprobieren. 8)
2. – Tweets zu diesem Artikel

Pingback vom 07.09.2009 um 23:15

[...] This post was mentioned on Twitter by Vladimir Simovic. Vladimir Simovic said: Peruns Weblog: WordPress und der Speicherverbrauch: Ich habe schon von mehreren Kollegen und Leser.. http://bit.ly/1543Kc [...]
3. – Jeriko

Kommentar vom 07.09.2009 um 23:18

Anzumerken ist noch, dass WP-Memory-Usage (also das Plugin in deinen Screenshots) nur den aktuell verbrauchten Speicher anzeigt, was ich de facto nutzlos finde. Viel wichtiger ist doch der Peak-Wert, also wieviel Speicher maximal pro Aufruf benötigt wird, ist der doch ausschlaggebend für Fehler a la "Memory exhausted, trying to allocate…". Solange eine Instanz in das Speicherlimit von PHP passt ist mir alles andere eigentlich recht egal.
4. – Perun

Kommentar vom 07.09.2009 um 23:22

@Jeriko,

Viel wichtiger ist doch der Peak-Wert, also wieviel Speicher maximal pro Aufruf benötigt wird, ist der doch ausschlaggebend für Fehler a la "Memory exhausted, trying to allocate…".

Da hast du Recht. Werde mal mit WP System Health testen.
5. – Dieter

Kommentar vom 07.09.2009 um 23:31

Ich weiß zwar nicht, ob WP System Health Peak-Werte anzeigt, aber da es im Administrationsbereich den Speicherverbrauch anzeigt und dort meistens das Speicherproblem auftritt, ist der dort angezeigte Wert wohl nahe am Peak dran.
Im Übrigen kann ich WP System Health auch wegen der vielen weiteren Infos wie bspw. 32- oder 64-Bit System nur empfehlen.
6. – Perun

Kommentar vom 07.09.2009 um 23:33

@Dieter,

WP System Health zeigt leider keine Peak-Werte an, lediglich mehr Infos.
7. – Julian

Kommentar vom 08.09.2009 um 01:58

Die Werte des Backends sind doch für den Betrieb der Seite relativ egal. Aber gehen wir man davon aus, dass der gleiche RAM auf für jeden Seitenaufruf benötigt wird. Das würde dann heißen, wenn 2 GB RAM nur für WordPress zur Verfügung stehen, wäre es nicht möglich mehr als etwa 100 Requests gleichzeitig zu verarbeiten. Okay, das mag jetzt viel erscheinen, doch für 2 GB RAM finde ich das dann doch etwas sehr wenig…
8. – Stefan

Kommentar vom 08.09.2009 um 08:12

Das Plugin TPC! Memory Usage zeigt eigentlich alles an was man braucht: Speicherverbrauch, Peak, History Peak und den zugewiesenen Speicher laut php.ini bzw wp-config.php

Danke für den Tip mit der optimierten mo.php, hat mir 3MB Speicher gespart!
9. – Björn

Kommentar vom 08.09.2009 um 08:16

Hallo, interessanter Beitrag.
Ich habe das Problem, dass ich seit Version 2.8 nicht mehr die Autoupdate Funktion nutzen kann. Allerdings habe ich auch ein MemoryLimit von 20 MB

Ich werde mal testen, ob es mit der Sprachdatei geht ansonsten muss ich mal meinen Hoster fragen, ob der das etwas erhöhen kann!

Gruß
Björn
10. – Tom

Kommentar vom 08.09.2009 um 09:39

Das mit dem Speicher ist schon manchmal merkwürdig. Da spielen auch OS und PHP Version. Die gleiche WP-Installation braucht bei mir mal 15,5 und mal 20 MB. Aber die optimierte mo.php nutze ich auch. Mit Erfolg.
11. – nastorseriessix

Kommentar vom 08.09.2009 um 10:47

Laut dem Plugin "Memory Overwiew" was bei mir schon länger mitläuft, sind es bei mir bis dato 38% und das hält sich bisher so!

Die optimierte "mo.php" werde ich aber trotzdem mal ausprobieren.
12. – Ben

Kommentar vom 08.09.2009 um 11:27

Was mich wundert, dass ich 50.13 % Auslastung im Dashboard habe, obwohl ich ne Menge Widgets deaktiviert habe.

Möchte gerne mal wissen, wo dass alles her kommt, denn mein Backend ist mehr als langsam, was aber auch nen Grund vom schlechten, bzw. zu voll gemüllten CORE hat.

LG
13. – Frank

Kommentar vom 08.09.2009 um 12:22

Es lohnt den Ordner cache (777) in wp-content anzulegen, wenn man Heikos Lösung einsetzt, dann werden die Mehsprachigkeits-Themen gecacht; zu erkennen, wenn im Ordner cache der Ordner mo entstanden ist.
14. – Wordpress: modifizierte mo.php : powerbook_blog

Pingback vom 08.09.2009 um 18:59

[...] Mit einer modifizierten Sprachdatei den Speicherverbrauch minimieren. Soll funktionieren, ist aber beta. Wenn mal Zeit ist. via Perun [...]
15. – Parkrocker

Kommentar vom 08.09.2009 um 22:51

Ich empfehle DB Cache. Hat einen interessanten Ansatz nicht komplett statische Seiten zu cachen sondern nur die DB-Abfragen.
http://wordpress.org/extend/plugins/db-cache/
16. – Frank

Kommentar vom 09.09.2009 um 10:51

@perun @Jeriko: a href="http://wordpress.org/extend/plugins/tpc-memory-usage/">TPC Memory Usage gibt maximum und Peak zurück.
17. – icognito01

Kommentar vom 09.09.2009 um 17:59

Hatte bei 2.8.x auch Speicherprobleme mit der Datenbank. Nach einem Update von php ist aber alles wieder gelaufen!
Aber vielen Dank jedenfalls für den Link zur modifizierten mo.php!
18. – Bange Zukunft von WordPress? | Dackworld

Pingback vom 09.09.2009 um 19:01

[...] mache mir Gedanken. Auch Praegnanz nimmt sich des Themas an. Über den Speicherverbrauch schreibt Perun. Dieser Eintrag wurde veröffentlicht in WP&so. Bookmarken: Permanent-Link. Kommentieren oder [...]
19. – Paul

Kommentar vom 09.09.2009 um 22:15

Ich muss sagen das ich keine Probleme mit der Geschwindigkeit habe. Allerdings bin ich auch erst seit Version 2.7 dabei und finde das es normal ist wenn man etwas vom Server abruft, dies nun mal etwas länger dauert.

Haben die Entwickler sich bereits dazu geäußert? Ich meine sie hätten gesagt, das es auf keinen Fall weniger werden wird.
20. – Tom

Kommentar vom 10.09.2009 um 13:15

Die %-Zahlen sagen ja mal gar nichts aus, da doch jeder ein anderes Limit hat. Also besser die MB angeben.
21. – Markus

Kommentar vom 11.09.2009 um 09:25

Vielen Dank für den Beitrag. Das hier ist wirklich immer eine tolle Anlaufstelle für Probleme, die mal auftreten und wieder in Vergessenheit geraten, aber von einem selbst nicht lösbar sind.
<3
22. – Bange Zukunft um WordPress? | Dackworld

Pingback vom 12.09.2009 um 13:58

[...] mache mir Gedanken. Auch Praegnanz nimmt sich des Themas an. Über den Speicherverbrauch schreibt Perun. Dieser Eintrag wurde veröffentlicht in WordPress. Bookmarken: Permanent-Link. Kommentieren oder [...]
23. – ichselbst

Kommentar vom 14.09.2009 um 10:02

Interessanter Beitrag, Danke.
24. – Update auf WordPress 2.8.4 | TimmBlog

Pingback vom 14.09.2009 um 19:22

[...] Speicherverbrauch der deutschen Sprachdatei kann man übrigens mit diesem Tipp [...]
25. – Susi

Kommentar vom 17.09.2009 um 13:05

Danke für die Info. Ich hatte mit dem Speicherplatz nur einmal Probleme. Da hatte ich noch kein Anti-Spam Blugin. Unglaublich wieviel MB Spam Eintrage man da in ein paar Wochen zusammen hat.
26. – Luca

Kommentar vom 29.09.2009 um 11:51

Warum ist der optimierte Sprachparser denn noch nicht in WordPress integriert? Anstatt das System mal schneller zu machen, blähen sie es leider nur immer weiter auf… Gibts da denn Hoffnung?

Danke für die Infos, bei mir hat der Einsatz der PHP ganze 3MB gebracht.

Hast du noch andere Optimierungsmöglichkeiten?
27. – PHP-Speicher frei schaufeln | Rappelsnut

Pingback vom 08.10.2009 um 19:46

[...] Vladimir Simovic weist aktuell auf den erhöhten PHP-Speicherbedarf von WordPress 2.8.x hin und benennt unter Anderem die nicht ganz optimale Verarbeitung der deutschen Sprachdatei (de_DE.mo) durch die Datei /wp-includes/pomo/mo.php als mögliche Ursache. Also ersetzte der mensch diese durch die empfohlene, optimierte mo.php von Heiko Rabe und präsentiert anbei das Ergebnis. [...]
28. – thomas

Kommentar vom 09.07.2010 um 23:49

Leider wird das Projekt mit der beta mo.php wegen dem reduzieren der Speicherfressenden deutschen Sprachdatei nicht vorangetrieben – oder auch sonstwo weiter bearbeitet…..sic!

Diese beta mo.php läuft auch in WP3 allerdings kann dann im Adminbereich die Seite mit den installierten Plugins nicht aufgerufen werden:

Es gibt da die Fehlermeldung:
Fatal error: Call to a member function on a non-object (wegen translations.php on line 108)

Deswegen habe ich in der translations.php die Zeilen 107 – 109
=foreach( $other->entries as $entry ) { $this->entries[$entry->key()] = $entry; }

ausgetauscht mit:$this->entries = array_merge($this->entries, $other->entries);

siehe auch: http://core.trac.wordpress.org/ticket/11832

Jedenfalls läuft so die beta mo.php wieder ohne Probleme außer das ein etwas älterer Code wieder eingefügt wurder der folgenden kleinen Fehler verursachen kann falls man es gebraucht:
It creates problems with numeric keys. For example, _e(’2′) outputs 4 on a localized version, regardless of the value in a .mo file.

Denke das wäre aber zu vernachlässigen…..

Schön wäre allerdings eine Überarbeitung der beta mo.php

grüsse
thomas
29. – Hody - Diary Of A Fatman

Kommentar vom 07.04.2011 um 23:13

Hallo,
Ich habe ständig das Problem mit dem Speicher. Ich habe nun irgendwo gelesen ich soll in der wp-config.php Die Zeile define (’WPLANG’, ‘de_DE’); mit der Zeile define (’WPLANG’, ”); ersetzen – seit ich das gemacht habe funktioniert es wieder. Was kann ich ansonsten noch tun? (Hoster 64bit System, akuell 64MB zugewiesen für mich).
Zielt die Lösung mit der mo.php auf das Selbe ab und viel wichtiger gibt es seine überarbeitete mo.php für WordPress 3.1.1.

Hinweis:
WordPress 3.5 für Admins & Webmaster (pdf)
Ausdruckbar, Volumenlizenzen zu sehr fairen Preisen.

Tut mir Leid, aber die Kommentar-Funktion ist momentan deaktiviert.

Weblog der perun.net webwork gmbh mit Artikeln zum Thema WordPress, Webwork, und Internet.

1. – Dieter

Kommentar vom 07.09.2009 um 23:12

1. Danke für die Nennung und Verlinkung meines Blogbeitrags.
2. Danke für den Hinweis auf reduzierten Speicherbedarf durch Caching-Plugins. Leuchtet ein, kannte ich aber noch nicht. Werde ich mal ausprobieren. 8)

2. – Tweets zu diesem Artikel

Pingback vom 07.09.2009 um 23:15

[...] This post was mentioned on Twitter by Vladimir Simovic. Vladimir Simovic said: Peruns Weblog: WordPress und der Speicherverbrauch: Ich habe schon von mehreren Kollegen und Leser.. http://bit.ly/1543Kc [...]

3. – Jeriko

Kommentar vom 07.09.2009 um 23:18

Anzumerken ist noch, dass WP-Memory-Usage (also das Plugin in deinen Screenshots) nur den aktuell verbrauchten Speicher anzeigt, was ich de facto nutzlos finde. Viel wichtiger ist doch der Peak-Wert, also wieviel Speicher maximal pro Aufruf benötigt wird, ist der doch ausschlaggebend für Fehler a la "Memory exhausted, trying to allocate…". Solange eine Instanz in das Speicherlimit von PHP passt ist mir alles andere eigentlich recht egal.

4. – Perun

Kommentar vom 07.09.2009 um 23:22

@Jeriko,

Viel wichtiger ist doch der Peak-Wert, also wieviel Speicher maximal pro Aufruf benötigt wird, ist der doch ausschlaggebend für Fehler a la "Memory exhausted, trying to allocate…".

Da hast du Recht. Werde mal mit WP System Health testen.

5. – Dieter

Kommentar vom 07.09.2009 um 23:31

Ich weiß zwar nicht, ob WP System Health Peak-Werte anzeigt, aber da es im Administrationsbereich den Speicherverbrauch anzeigt und dort meistens das Speicherproblem auftritt, ist der dort angezeigte Wert wohl nahe am Peak dran.
Im Übrigen kann ich WP System Health auch wegen der vielen weiteren Infos wie bspw. 32- oder 64-Bit System nur empfehlen.

6. – Perun

Kommentar vom 07.09.2009 um 23:33

@Dieter,

WP System Health zeigt leider keine Peak-Werte an, lediglich mehr Infos.

7. – Julian

Kommentar vom 08.09.2009 um 01:58

Die Werte des Backends sind doch für den Betrieb der Seite relativ egal. Aber gehen wir man davon aus, dass der gleiche RAM auf für jeden Seitenaufruf benötigt wird. Das würde dann heißen, wenn 2 GB RAM nur für WordPress zur Verfügung stehen, wäre es nicht möglich mehr als etwa 100 Requests gleichzeitig zu verarbeiten. Okay, das mag jetzt viel erscheinen, doch für 2 GB RAM finde ich das dann doch etwas sehr wenig…

8. – Stefan

Kommentar vom 08.09.2009 um 08:12

Das Plugin TPC! Memory Usage zeigt eigentlich alles an was man braucht: Speicherverbrauch, Peak, History Peak und den zugewiesenen Speicher laut php.ini bzw wp-config.php

Danke für den Tip mit der optimierten mo.php, hat mir 3MB Speicher gespart!

9. – Björn

Kommentar vom 08.09.2009 um 08:16

Hallo, interessanter Beitrag.
Ich habe das Problem, dass ich seit Version 2.8 nicht mehr die Autoupdate Funktion nutzen kann. Allerdings habe ich auch ein MemoryLimit von 20 MB

Ich werde mal testen, ob es mit der Sprachdatei geht ansonsten muss ich mal meinen Hoster fragen, ob der das etwas erhöhen kann!

Gruß
Björn

10. – Tom

Kommentar vom 08.09.2009 um 09:39

Das mit dem Speicher ist schon manchmal merkwürdig. Da spielen auch OS und PHP Version. Die gleiche WP-Installation braucht bei mir mal 15,5 und mal 20 MB. Aber die optimierte mo.php nutze ich auch. Mit Erfolg.

11. – nastorseriessix

Kommentar vom 08.09.2009 um 10:47

Laut dem Plugin "Memory Overwiew" was bei mir schon länger mitläuft, sind es bei mir bis dato 38% und das hält sich bisher so!

Die optimierte "mo.php" werde ich aber trotzdem mal ausprobieren.

12. – Ben

Kommentar vom 08.09.2009 um 11:27

Was mich wundert, dass ich 50.13 % Auslastung im Dashboard habe, obwohl ich ne Menge Widgets deaktiviert habe.

Möchte gerne mal wissen, wo dass alles her kommt, denn mein Backend ist mehr als langsam, was aber auch nen Grund vom schlechten, bzw. zu voll gemüllten CORE hat.

13. – Frank

Kommentar vom 08.09.2009 um 12:22

Es lohnt den Ordner cache (777) in wp-content anzulegen, wenn man Heikos Lösung einsetzt, dann werden die Mehsprachigkeits-Themen gecacht; zu erkennen, wenn im Ordner cache der Ordner mo entstanden ist.

14. – Wordpress: modifizierte mo.php : powerbook_blog

Pingback vom 08.09.2009 um 18:59

[...] Mit einer modifizierten Sprachdatei den Speicherverbrauch minimieren. Soll funktionieren, ist aber beta. Wenn mal Zeit ist. via Perun [...]

15. – Parkrocker

Kommentar vom 08.09.2009 um 22:51

Ich empfehle DB Cache. Hat einen interessanten Ansatz nicht komplett statische Seiten zu cachen sondern nur die DB-Abfragen.
http://wordpress.org/extend/plugins/db-cache/

16. – Frank

Kommentar vom 09.09.2009 um 10:51

@perun @Jeriko: a href="http://wordpress.org/extend/plugins/tpc-memory-usage/">TPC Memory Usage gibt maximum und Peak zurück.

17. – icognito01

Kommentar vom 09.09.2009 um 17:59

Hatte bei 2.8.x auch Speicherprobleme mit der Datenbank. Nach einem Update von php ist aber alles wieder gelaufen!
Aber vielen Dank jedenfalls für den Link zur modifizierten mo.php!

18. – Bange Zukunft von WordPress? | Dackworld

Pingback vom 09.09.2009 um 19:01

[...] mache mir Gedanken. Auch Praegnanz nimmt sich des Themas an. Über den Speicherverbrauch schreibt Perun. Dieser Eintrag wurde veröffentlicht in WP&so. Bookmarken: Permanent-Link. Kommentieren oder [...]

19. – Paul

Kommentar vom 09.09.2009 um 22:15

Ich muss sagen das ich keine Probleme mit der Geschwindigkeit habe. Allerdings bin ich auch erst seit Version 2.7 dabei und finde das es normal ist wenn man etwas vom Server abruft, dies nun mal etwas länger dauert.

Haben die Entwickler sich bereits dazu geäußert? Ich meine sie hätten gesagt, das es auf keinen Fall weniger werden wird.

20. – Tom

Kommentar vom 10.09.2009 um 13:15

Die %-Zahlen sagen ja mal gar nichts aus, da doch jeder ein anderes Limit hat. Also besser die MB angeben.

21. – Markus

Kommentar vom 11.09.2009 um 09:25

Vielen Dank für den Beitrag. Das hier ist wirklich immer eine tolle Anlaufstelle für Probleme, die mal auftreten und wieder in Vergessenheit geraten, aber von einem selbst nicht lösbar sind.
<3

22. – Bange Zukunft um WordPress? | Dackworld

Pingback vom 12.09.2009 um 13:58

[...] mache mir Gedanken. Auch Praegnanz nimmt sich des Themas an. Über den Speicherverbrauch schreibt Perun. Dieser Eintrag wurde veröffentlicht in WordPress. Bookmarken: Permanent-Link. Kommentieren oder [...]

23. – ichselbst

Kommentar vom 14.09.2009 um 10:02

Interessanter Beitrag, Danke.

24. – Update auf WordPress 2.8.4 | TimmBlog

Pingback vom 14.09.2009 um 19:22

[...] Speicherverbrauch der deutschen Sprachdatei kann man übrigens mit diesem Tipp [...]

25. – Susi

Kommentar vom 17.09.2009 um 13:05

Danke für die Info. Ich hatte mit dem Speicherplatz nur einmal Probleme. Da hatte ich noch kein Anti-Spam Blugin. Unglaublich wieviel MB Spam Eintrage man da in ein paar Wochen zusammen hat.

26. – Luca

Kommentar vom 29.09.2009 um 11:51

Warum ist der optimierte Sprachparser denn noch nicht in WordPress integriert? Anstatt das System mal schneller zu machen, blähen sie es leider nur immer weiter auf… Gibts da denn Hoffnung?

Danke für die Infos, bei mir hat der Einsatz der PHP ganze 3MB gebracht.

Hast du noch andere Optimierungsmöglichkeiten?

27. – PHP-Speicher frei schaufeln | Rappelsnut

Pingback vom 08.10.2009 um 19:46

[...] Vladimir Simovic weist aktuell auf den erhöhten PHP-Speicherbedarf von WordPress 2.8.x hin und benennt unter Anderem die nicht ganz optimale Verarbeitung der deutschen Sprachdatei (de_DE.mo) durch die Datei /wp-includes/pomo/mo.php als mögliche Ursache. Also ersetzte der mensch diese durch die empfohlene, optimierte mo.php von Heiko Rabe und präsentiert anbei das Ergebnis. [...]

28. – thomas

Kommentar vom 09.07.2010 um 23:49

Leider wird das Projekt mit der beta mo.php wegen dem reduzieren der Speicherfressenden deutschen Sprachdatei nicht vorangetrieben – oder auch sonstwo weiter bearbeitet…..sic!

Diese beta mo.php läuft auch in WP3 allerdings kann dann im Adminbereich die Seite mit den installierten Plugins nicht aufgerufen werden:

Es gibt da die Fehlermeldung:
Fatal error: Call to a member function on a non-object (wegen translations.php on line 108)

Deswegen habe ich in der translations.php die Zeilen 107 – 109
=foreach( $other->entries as $entry ) { $this->entries[$entry->key()] = $entry; }

ausgetauscht mit:$this->entries = array_merge($this->entries, $other->entries);

siehe auch: http://core.trac.wordpress.org/ticket/11832

Jedenfalls läuft so die beta mo.php wieder ohne Probleme außer das ein etwas älterer Code wieder eingefügt wurder der folgenden kleinen Fehler verursachen kann falls man es gebraucht:
It creates problems with numeric keys. For example, _e(’2′) outputs 4 on a localized version, regardless of the value in a .mo file.

Denke das wäre aber zu vernachlässigen…..

Schön wäre allerdings eine Überarbeitung der beta mo.php

grüsse
thomas

29. – Hody - Diary Of A Fatman

Kommentar vom 07.04.2011 um 23:13

Hallo,
Ich habe ständig das Problem mit dem Speicher. Ich habe nun irgendwo gelesen ich soll in der wp-config.php Die Zeile define (’WPLANG’, ‘de_DE’); mit der Zeile define (’WPLANG’, ”); ersetzen – seit ich das gemacht habe funktioniert es wieder. Was kann ich ansonsten noch tun? (Hoster 64bit System, akuell 64MB zugewiesen für mich).
Zielt die Lösung mit der mo.php auf das Selbe ab und viel wichtiger gibt es seine überarbeitete mo.php für WordPress 3.1.1.

WordPress & Webwork - perun.net