WordPress extrem beschleunigen – WP-Performance-Gettext-Patch
WordPress extrem beschleunigen mit Hilfe meines neuen WordPress Plugins WP-Performance-Gettext-Patch. Es implementiert dabei die native Gettext-Lib von PHP und ersetzt somit die in PHP geschriebene Gettext-Lib von WordPress.
Ich habe schon öfters WordPress mit xDebug Profiler und WinCacheGrind analysiert, weil mir die Ladezeit einfach zu lang war. Dabei ist mir immer wieder die Umsetzung der Internationalisierung von WordPress aufgefallen. Sie nutzt eine in PHP implementierte Gettext-Lib. Diese Implementierung ist leider sehr langsam und nimmt gut die Hälfte der Seitenaufbauzeit in Anspruch. Grund genug eine bessere Lösung zu suchen bzw. zu entwickeln.
Lösung: Die in PHP implementierte Gettext-Lib muss durch eine native Gettext-Lib ersetzt werden (wenn verfügbar). Oliver hat mich in PHP Internationalisierung (i18n) Benchmark darauf hingewiesen, dass es bereits einen Patch für WordPress gibt. Danke dafür.
Nach kurzer Analyse des Patches fielen mir aber paar unschöne Dinge auf, wie z.B., dass es kein Cache-Contolling gibt. Also habe ich den Patch performance-technisch etwas verändert und ein Cache-Controlling eingebaut. Dies habe ich dann noch konfortabel in ein Plugin mit einem Adminbereich verpackt und raus kam WP-Performance-Gettext-Patch.
Die Resultate können sich sehen lassen.
Benchmark:
- 50 Durchläufe mit den Apache Benchmarktool ab
- WordPress 3.3 DE
Testsystem:
| CPU | AMD Phenom II X4 965 |
| RAM | 8GB DDR3 CL7 |
| Mainboard | GA-890GPA-UD3 |
| HDD | SSD C300 RAID 1 Samsung F3 1TB |
| Energieoption | Höchstleistung |
| Betriebssystem | Windows 7 SP1 64Bit Ubuntu 10.04 32Bit (VM) |
| Software | Apache 2.2.17 PHP 5.3.5 |
Ergebnise:
Bilder von ab:
Wie man deutlich sehen kann ist die native Gettext Lib sehr schnell. Unter Windows mehr als doppelt so schnell und unter Linux so gar mehr als dreifach so schnell.
Ich finde bei diesen Benchmarks hat sich die Arbeit mehr als gelohnt. Ich hoffe, dass euch das Plugin/ Patch genau so gefällt wir mir.
Ich wünsche euch allen eine schöne Weihnacht.
Julius
Download:
- WP-Performance-Gettext-Patch 0.11 (11.12.2013)
- WP-Performance-Gettext-Patch 0.10 (16.10.2012)
- WP-Performance-Gettext-Patch 0.9 (01.10.2012)
- WP-Performance-Gettext-Patch 0.8 (29.08.2012)
- WP-Performance-Gettext-Patch 0.7 (20.08.2012)
- WP-Performance-Gettext-Patch 0.6 (15.07.2012)
- WP-Performance-Gettext-Patch 0.5 (14.07.2012)
- WP-Performance-Gettext-Patch 0.4
SVN: http://plugins.svn.wordpress.org/wp-performance-gettext-patch/
Changelog:
== 0.11 ==
- Kompatibel für WordPress 3.7.1
== 0.10 ==
- Bugfix
== 0.9 ==
- Bugfix
== 0.8 ==
- Der Plugin-Ordner ist nun klein geschrieben
- Ersetzt bitte daher den kompletten Ordner
== 0.7 ==
- LC_ALL zu LC_MESSAGES
== 0.6 ==
- Anonyme Funktionen in interface.php gelöscht
- Bugfix: Deinstallation
== 0.5 ==
- Kompatibel für WordPress 3.4.1
- Diverse Bugfixes
Wichtiger Hinweis:
Vor dem Updaten des Plugins unbedingt den Patch deinstallieren! Da es sonst zu einen PHP Fatal-Error kommen kann.
Update:
Wie einige sicher schon bemerkt haben, wurde mein Plugin leider von der Plugin-Seite gelöscht. Den SVN Zugang haben sie mir aber gelassen. Die Begründung des Admins war: „Dieses Plugin greift zu tief ins System ein“. Schade eigentlich, das Plugin wurde immerhin über 350 mal in 3 Tagen runtergeladen. Aber sei drum, ich werde das Plugin nun über meine Seite zum Download anbieten.
Frage von Linushoppe:
Linushoppe hatte mich gefragt: „Warum hast du eine zusätzlichen Cache-Control eingebaut? Der Gettext hat ja schon einen eigenen Cache.“
Ja, die Gettext-Implementierung hat einen eigenen Cache, aber das ist auch das große Problem. Denn man kann ihn nicht ohne weiteres löschen. Um den Cache zu löschen, muss ein restart des Servers erfolgen, was bei Webhosting-Angeboten schwierig sein könnte. Diese werden zwar auch regelmäßig neugestartet bzw. der Cache gelöscht. Das könnte aber einige Zeit dauern.
Wenn nun ein Plugin oder der Core geupdatet wird und eine oder mehrere neue/überarbeitete Übersetzungsdateien (*.mo) hinzukommen, wird diese nicht berücksichtigt.
Darum habe ich eine Kontrolle eingebaut. Es gibt einen globalen Salt (time), der hinter jeder *.mo Datei angefügt wird, z.B. default+2349234.mo (siehe Quellcode). Dadurch wird immer auf die aktuelle *.mo Datei verwiesen. Wird nun ein Plugin/Core geupdatet oder der Cache manuell gelöscht, dann wird der globale Salt geändert. Wodurch alle Dateien einen neuen Salt bekommen und danach von Gettext neu in den Cache aufgenommen werden.
Schlagwörter: gettext, Plugin, Wordpress
Voku sagt
am 28. Dezember 2011 @ 18:06
Danke für das Plugin! Ich werde es testen …
Mfg
Fabian sagt
am 17. Januar 2012 @ 00:15
Das Plug-in klingt sehr interessant und ich würde es gerne testen. Leider gehen die Downloadlinks auf WordPress.org nicht. Gibt es dafür einen Grund?
admin sagt
am 18. Januar 2012 @ 21:57
Hallo Fabian,
ja, mein Plugin wurde leider gelöscht. Die Begründung findest Du im Artikel.
Entschuldigt, dass ich mich jetzt erst melde. Hatte die letzten Tage viel zu tun.
SexyTime sagt
am 31. Januar 2012 @ 22:29
Hallo,
ich habe das Plugin aktiviert, aber bekomme folgende Meldung, wenn ich es installieren möchte:
—–
Cache-Verzeichnis besitzt nicht die nötigen Schreibrechte (755). Bitte erteilen Sie schreibrechte auf Ihren Server für das Verzeichnis: /XXX/wp-content/plugins/wp-performance-gettext-patch/wp-lang/
—–
Die Rechte sind eindeutig vergeben, daher weiß ich nicht woran es liegt.
admin sagt
am 1. Februar 2012 @ 08:03
Hallo,
es könnte an der Gruppenzugehörigkeit bzw. am Eigentümer der Datei/Ordner liegen.
Teste bitte einmal 0777
SexyTime sagt
am 1. Februar 2012 @ 22:08
Lag an der Großschreibung des Ordners.
PS: Kannst du die Adresse in der Fehlermeldung bitte unkenntlich machen?
admin sagt
am 2. Februar 2012 @ 09:41
Freut mich, dass es jetzt funktioniert.
Die Fehlermeldung habe ich für dich entschärft.
LG
Julius
SexyTime sagt
am 3. Februar 2012 @ 21:19
Vielen Dank.
Ressourcen Sparen bei Ajax Calls in Wordpress › Daniel Hüsken sagt
am 9. März 2012 @ 19:00
[…] Ich glaub das best ist es wenn in WordPress der WP-Performance-Gettext-Patch integriert wird. Nach meinen Tests bring das am meisten. Der Speicher verbrauch geht dann auf ca […]
Tom sagt
am 14. Juli 2012 @ 14:09
Ich hab das Plugin grad mal getestet.
Damit konnte ich den Speicherverbrauch von 38 auf 30 MB senken. Super, nur leider werden nicht alle WP-Dateien verarbeitet sondern nur die in meinem Fall de_DE.mo.
Aktuell gibts es ja noch admin-de_DE, admin-network-de_DE und ms-de_DE. Die noch mit einbauen und das „denglish“ im Backend dürfte Geschichte sein. 😉
Tom sagt
am 14. Juli 2012 @ 14:48
Anscheinend müssen ‚load_default_textdomain‘ und ‚load_textdomain‘ überarbeitet werden, da mehrere mo-Dateien als ‚default‘ gecached werden sollen, was nur bei der ersten funktioniert.
admin sagt
am 14. Juli 2012 @ 20:38
Sie werden es kaum glauben aber vor 2 Tagen ist mir dies auch aufgefallen.
Ich habe eine neue Version des Plugins hochgeladen (0.5).
Ab jetzt ist das Plugin voll 3.4.1 kompatibel.
P.S. Wichtiger Hinweis beachten
LG
Julius
Tom sagt
am 15. Juli 2012 @ 15:14
Sooo, lokal mit PHP 5.3.x ging es sofort. Wunderbar! 🙂
Aber online habe ich nur PHP 5.2.17 und die mag die anonymen Funktionen in der interface.php leider gar nicht. Die aus der 0.4 ist da kompatibler und läuft nun auch online bei mir.
Und dann fehlte beim Deinstallieren des Patches auch der erste < vorm ?php in der l10n.php. Juchu, Quelltext! Wahrscheinlich einfach 1 Zeichen zuviel gelöscht. 😉
Aber laufen tut es, mit rund 5 MB Speicherersparnis. Kann sich sehen lassen. Zeiten hab ich noch nicht gestoppt. 😉
admin sagt
am 15. Juli 2012 @ 16:04
Ja, da haben Sie Recht. Ich hatte zwei Versionen des Patches. Ich habe leider die Beta Version hochgeladen.
Mit Version 0.6 sollte es wieder Ordentlich laufen.
LG
Julius
Tom sagt
am 16. Juli 2012 @ 18:22
Wunderbar, funktioniert nun einwandfrei. Danke! 🙂
PS: gerne auch „Du“. 🙂
Björn sagt
am 27. Juli 2012 @ 12:30
Erstmal: Schöner Patch – ich ärgere mich auch schon länger über die lahme WordPress-Internationalisierung.
Ein kleines Problem gibt es im Patch allerdings: In get_locale sollte statt LC_ALL LC_MESSAGES verwendet werden, sonst gibt’s z.B. stellenweise Probleme mit Float-Werten in JavaScripts (ein Beispiel wäre das P3 Plugin).
Also statt:
setlocale(LC_ALL,$locale);
setlocale(LC_ALL, $locale);
besser:
putenv(‚LC_MESSAGES=‘.$locale);
setlocale(LC_MESSAGES,$locale);
admin sagt
am 20. August 2012 @ 15:30
Danke für den Hinweis.
Ich habe es in Version 0.7 geändert.
raikit sagt
am 24. August 2012 @ 10:57
Hallo, ich hab gerade das Plugin installiert. Leider bekomme ich folgende Meldung:
Cache-Verzeichnis besitzt nicht die nötigen Schreibrechte (755). Bitte erteilen Sie schreibrechte auf Ihren Server für das Verzeichnis: /****/htdocs/wp-content/plugins/wp-performance-gettext-patch/wp-lang/
Jedoch besitzt das Verzeichnis die Rechte 755. Auch mit 777 erscheint die Fehlermeldung. – mmhhh… Woran kann es liegen?
Viele Grüße
admin sagt
am 24. August 2012 @ 15:32
Hey,
mh ich kann Ihnen erstmal nur raten den Ordner zu löschen und mit einem FTP Client neu zu erstellen. Danach die Schreibrechte erneut einstellen.
Sie sind bei Strato oder?
PS
Ich hab die Fehlermeldung mal entschärft.
LG
Julius
raikit sagt
am 24. August 2012 @ 15:41
ok. Dank für die Entschärfung! – ja, wir sind bei Strato.
raikit sagt
am 24. August 2012 @ 15:55
Auch nach Löschen und Neuerstellung des Ordners kommt die gleiche Fehlermeldung. Auch manuelle Neuinstallation brachte nix.
Liegt es an Strato? Schade!
admin sagt
am 24. August 2012 @ 16:23
Ich habe gerade mal gegoogelt, es scheint wirklich an Strato zuliegen. Haben Sie noch andere Plugins installiert die Schreibrechte auf dem Server benötigen? Etwa wie „WP Super Cache“ oder ähnliches?
raikit sagt
am 24. August 2012 @ 16:47
Bis jetzt hatte ich noch keine Probleme mit Schreibrechten auf dem Server. Nutze Cachify und einige andere Plugins. Welche Serverkonfiguration ist dafür verantwortlich? – Nun gut, es ist nicht tragisch, aber eine Performance-Verbesseung ist ja auch nicht schlecht….
Viele Grüße
admin sagt
am 24. August 2012 @ 17:02
Mh, ich würde nochmal mit einem FTP Client (z.B. FileZilla) die Besitzer/Gruppe prüfen (nicht die Berechtigung) und mit den anderen Ordnern vergleichen (Am besten mit Ordnern wo die Schreibrechte funktionieren).
Mein Hoster biete im Adminmenü eine Option an, womit ich die Besitzrechte eines Ordners oder Datei ändern kann, z.B. auf den PHP-User.
Wenn Strato so etwas auch anbietet würde ich es damit mal Testen.
LG
Julius
Andreas sagt
am 28. August 2012 @ 14:32
So einfach wie genial. Geht einfach und macht WP spürbar schneller während in der WP Entwicklung noch herumdiskutiert wird.
Danke!
Andreas sagt
am 29. August 2012 @ 12:24
@raikit, deaktiviere mal das Plugin noch einmal und benenne den Plugin-Ordner von „WP-Performance-Gettext-Patch“ in „wp-performance-gettext-patch“ um. Dann wieder aktivieren und normal weitermachen. Das hat bei mir geholfen. Insofern war meine vorherige Aussage nicht ganz korrekt.
@admin, vielleich kann man das ja im nächsten Release gleich so ausliefern?
Bei 1&1 brachte der Einsatz des Patches ca. 8 MB freien Speicher.
admin sagt
am 29. August 2012 @ 12:50
Danke für den Tipp!
Auf meinem Server ist der Ordner auch klein geschrieben. Ich ersetzte immer nur die neuen Dateien. Daher ist mir der Fehler nie aufgefallen.
Aber klar, Linux ist case sensitive, Windows nicht.
Danke für deinen Hinweis, mir wäre es bestimmt nicht aufgefallen. *kopfkratz*
Ich habe es in Version 0.8 berichtigt.
LG
Julius
Andreas sagt
am 29. August 2012 @ 14:55
@admin, in der 0.8 stimmt die interne Versionsnummer nicht. Das Plugin meldet sich immer noch mit 0.7
MfG
admin sagt
am 29. August 2012 @ 15:59
So jetzt aber 🙂
LG
Julius
raikit sagt
am 5. September 2012 @ 21:03
jetzte funzt es…;-)… thanks!
admin sagt
am 11. September 2012 @ 09:56
Supi, das freut mich 🙂
P.S.
Wordpress-Version 3.4.2 wird weiterhin voll Unterstützt.
Dieter sagt
am 22. September 2012 @ 20:55
Vielen Dank für dieses geniale Plugin!
Das Problem mit dem englischsprachigem Backend ist aber noch nicht gelöst, oder?
admin sagt
am 22. September 2012 @ 21:46
Hallo,
normalweise sollte alles Funktionieren.
Hier auf meinem Linux Server und Windows Testserver läuft, mit der aktuellen Version 0.8, alles ohne Probleme.
Hast du einmal den Cache gelöscht bzw. nach einer Aktualisierung den Patch deinstalliert und wieder installiert (nicht das Plugin)?
Wenn das alles nichts hilft, bräuchte ich etwas mehr Infos:
– Server OS
– PHP Version
– usw. 🙂
LG
Julius
Dieter sagt
am 22. September 2012 @ 23:01
Danke für die schnelle Reaktion!
Erstmal bin ich kein Profi.. Vielleicht liegt da schon ein Fehler:
Ich nutze WP mit einem ursprünglich englischem Theme, dass ich mithilfe des Plugins CodeStyling Localization übersetzt habe.
Daraufhin dein Plugin installiert und aktiviert.
Seither ist Back- und Frontend Englisch.
Patch habe ich reinstalliert, Cache gelöscht, alles unverändert.
Server: Linux, Apache
PHP: v5.3.2-1ubuntu4.18
admin sagt
am 22. September 2012 @ 23:29
Ich habe mir gerade einmal „CodeStyling Localization“ angesehen, daran liegt es nicht.
Eine Idee hätte ich noch auf die schnelle.
Geh mal bitte in den Plugin „wp-performance-gettext-patch“ Ordner auf deinem Webserver (wp-content\plugins\wp-performance-gettext-patch) und füge in der Datei l10n_lib.php, in Zeile 69, folgendes hinzu:
putenv(‚LANG=‘.$locale);
putenv(‚LANGUAGE=‘.$locale);
Danach nochmal den Cache löschen und versuchen ob es funktioniert.
LG
Julius
Dieter sagt
am 23. September 2012 @ 00:03
Nach wie vor vielen Dank für die Hilfe!
Nachdem ich diese Änderung vorgenommen hatte, gab es nur noch weiße Seiten ohne Inhalt..
Habe die Änderungen wieder rausgenommen, jetzt ist alles wieder wie vorher, eben Englisch.
admin sagt
am 23. September 2012 @ 10:36
Nichts zu danken, das ist doch selbstverständlich.
Mh das alle Seiten weiß werden ohne Inhalt klingt irgendwie komisch. Denn es wurden ja nur 2 Umgebungsvariablen gesetzt.
Das einzige was ich dir noch raten könnte wäre mal alle anderen Plugins testweise zu deaktivieren um zu sehen ob es an irgendein Plugin liegt.
Wenn das auch nichts hilft musst du mal etwas Debuggen, d.h. gucken ob die *.mo Dateien wirklich im wp-lang Ordner gespeichert werden. In der l10_lib.php, Funktion get_locale(), einmal nachsehen ob die Variable $locale den Wert „de_DE“ hat.
Zu mehr kann ich dir erst mal nicht raten.
LG
Julius
Dieter sagt
am 26. September 2012 @ 05:28
Auch wenn sämtliche andere Plugins deaktiviert sind verhält sich die Seite wie gehabt.
Sämtliche .mo Dateien sind im Verzeichnis wp-lang/de_DE/LC_MESSAGES.
Habe leider praktisch kaum PHP Kentnisse, von daher wird es mit weiterer Recherche schwierig..
Trotzdem vielen Dank für deine Hilfe und gut, dass es wenigstens bei den anderen funktioniert.
Auf einer anderen WP-Installation (auch anderer Server) funktioniert das Plugin übrigens auch bei mir einwandfrei! 😀
admin sagt
am 26. September 2012 @ 20:08
Mh dann muss es wirklich an irgendeiner PHP-Einstellung, an deinem Server, liegen.
Ja, ohne PHP Kenntnisse wird es wirklich schwierig.
Tut mir leid das ich noch keine Lösung gefunden habe.
LG
Julius
Patschi sagt
am 30. September 2012 @ 23:36
Danke für das Plugin 🙂
Mein Plugin wurde in der Tat etwas schneller. Nur als unangenehmer Effekt wurde der Blog auch auf Englisch umgestellt… Aber nur, wenn ich den Patch aktiviere.
Kann man das verhindern?
Danke im Vorraus!
PS: Super Blog & großes Lob dafür! 🙂
admin sagt
am 1. Oktober 2012 @ 11:23
Hi,
ich konnte den Fehler nun lokalisieren und ausmerzen. Mit der Version 0.9 sollte nun alles korrekt funktionieren.
Vielen Dank Patschi. Ich geb mir immer große mühe. 🙂
LG
Julius
Patschi sagt
am 1. Oktober 2012 @ 17:53
Danke, funktioniert nun.
Hab es nun zweimal getest – einmal aktiviert und einmal deaktiviert.
Mit dem Plugin brauchte die Seite 4 Sekunden und ohne 3,71 Sekunden. Mit ist es langsamer?
Verwende nebenbei auch noch WP Super Cache, etc.
Könnte es damit zu tun haben?
admin sagt
am 1. Oktober 2012 @ 18:52
hi,
Mh langsamer dürfe es nicht werden.
Wie hast du das denn getestet? Wenn das Plugin frisch aktiviert wird, dann wird der Cache neu erstellt dadurch lädt die erste Seite etwas langsamer. Danach sollte es aber einen spürbaren Leistungsgewinn und einen verringerten Speicherverbrauch geben.
Bitte die Seite mindestens 10mal neu laden und daraus dann einen Mittelwert berechnen.
An WP Super Cache sollte es nicht liegen.
LG
Julius
Patschi sagt
am 2. Oktober 2012 @ 01:47
Habs nochmal getestet. Hab die Seite ca. 10x neugeladen und dann einen Test lassen machen. Danach hab ich es deaktiviert und erneut einen Test veranlasst.
Das Resultat war das gleiche – ohne ist es schneller. Die Sprache hat sich auch komischerweise nachdem ich die Seite oft neugeladen habe und mich durch die Homepage etwas durchgeklickt habe, auf Englisch geändert.
Berichte:
Mit: http://gtmetrix.com/reports/pkern.at/tpBCQgjP
Ohne: http://gtmetrix.com/reports/pkern.at/LIuJKPdr
Wüsste nicht an was es liegen könnte…
Hab PHP5.3.12 mit nginx und php5-fpm.
admin sagt
am 2. Oktober 2012 @ 10:49
Ich hab mir deine Resultate angeguckt. Die Werte sind eigentlich gleich. Denn man muss den ersten Eintrag beachten, nur dieser spiegelt den PHP-Parser-Prozess wieder. Alles anderen Request sind nur Bilder, css, js oder externe Seiten.
Das ein Unterschied zwischen den beiden Ergebnissen auftritt, liegt an der Anzahl der Request, mit Patch sind es 112 der ohne nur 106. Dadurch ist die unterschiedliche Seitenaufbauzeit zu erklären. Woher nun die weiteren 6 Request herkommen weiß ich nicht.
Wenn der Gettext Patch aktiviert wird, würde ich auf jeden Fall alle Caches löschen (WP-Super-Cache usw.).
Ich hab den Patch auf einigen Seiten in betrieb und bei mir hat es immer einen spürbaren Leistungsgewinn gegeben. Vielleicht liegt es wirklich an irgendein Plugin.
Den Test würd ich nochmal ohne Plugins oder zumindest ohne WP-Super-Cache wiederholen. Denn wenn WP-Super-Cache aktiviert ist wird ja nur die Cache-Dateiausgegen.
LG
Julius
Patschi sagt
am 3. Oktober 2012 @ 22:29
Bin jetzt auf W3 Total Cache umgestiegen. Ist schneller als WP-Super-Cache.
Beim Testen hatte ich dennoch das Problem, dass der Blog auf Englisch umgestellt wurde. Hab beim Update nur zwei veränderte PHP Files ersetzt (im Plugins Ordner)
Dieter sagt
am 8. Oktober 2012 @ 05:45
Es tut, wunderbar, vielen Dank!
admin sagt
am 11. Oktober 2012 @ 18:04
@Patschi
Dann weis ich leider auch erst mal nicht weiter. Ich werde das ganze nochmal ausführlich in meiner VM testen.
Freetagger sagt
am 11. Oktober 2012 @ 22:29
Das frontend von WordPress ist mit 3-4 sekunden „schnell“ aber das Backend ist bei mir extrem langsam (Admin Bereich). Ursache sind 3000 statische Seiten die das php_memory mit 140 MB RAM belasten. Beschleunigt das Plugin auch den Admin Bereich? Ich möchte es nicht unnötig installieren, deshalb würde ich mich über eine kurze Antwort freuen.
Lieben Gruß
admin sagt
am 11. Oktober 2012 @ 22:39
Hallo,
das Frontend und Backend wird gleichermaßen beschleunigt.
Bei mir bringt es ca. 3 Sekungen im Adminbereich.
LG
Julius
Freetagger sagt
am 12. Oktober 2012 @ 13:48
Hi,
habe es eben installiert. PHP_memory ist auf 123 MB gesunken. Fühlt sich auf jeden Fall etwas schneller an, also vorher. Nur ein Problem! Frontend und Backend ist jetzt englisch…
Freetagger sagt
am 12. Oktober 2012 @ 14:52
Habe mal
putenv(‘LANG=’.$locale);
putenv(‘LANGUAGE=’.$locale);
an die besagte Stelle eingefügt und danach ging absolut nichts mehr. error 500.
admin sagt
am 12. Oktober 2012 @ 20:12
Hast du einen Ubuntu Server? Da scheid es Probleme zugeben.
Ich werde das nochmal genau in der VM testen.
LG
Julius
Freetagger sagt
am 13. Oktober 2012 @ 18:41
PHP Version 5.3.3-7+squeeze14
Server Software Apache/2.2.16 (Debian)
Denke aber das die Tage ein Umzug erfolgt, bin gespannt ob es dann geht. LG
raikit sagt
am 14. Oktober 2012 @ 12:16
Gerade festgestellt, das nach der Installation des Plugins auf unserer Testseite ein kleiner Bug nach Neuinstallationen anderer Plugins auftritt:
Nach Installation anderer Plugins wird die Anzeige „Aktiviere dieses Plugin | Zurück zur Plugin-Installation“ nicht mehr angezeigt.
V. G.
admin sagt
am 16. Oktober 2012 @ 15:13
@Frettagger
Bin ich auch gespannt.
Würde mich freuen wenn du darüber berichtest.
@raikit
Danke für den Hinweis, in Version 0.10 habe ich diesen Fehler behoben.
LG
Julius
raikit sagt
am 16. Oktober 2012 @ 22:27
Thanks! ,-)
Freetagger sagt
am 17. Oktober 2012 @ 12:57
Seite ist jetzt umgezogen, Plugin aktiviert und Patch installiert.
Danach geht nichts mehr:
HTTP-Fehler 500 (Internal Server Error): Beim Versuch des Servers, die Anforderung zu verarbeiten, ist eine unerwartete Bedingung aufgetreten.
Idee?
Patschi sagt
am 17. Oktober 2012 @ 13:11
Ich habe es gerade eben auf einen etwas neueren Blog installiert: Ohne Probleme. Der Admin Bereich ging merkbar schneller, die Geschwindigkeit der Webseite änderte sich wegen Cache Plugin nicht – was auch logisch ist.
Nur ändert sich wirklich die Sprache noch immer auf Englisch um – warum, weiß ich leider nicht.
admin sagt
am 19. Oktober 2012 @ 15:52
@Freetagger
Bis jetzt habe ich noch keine Idee, ich bin aber dran.
@All
Ihr könnt einmal probieren in der Datei l10n_lib.php folgende Zeile (69-70) mit:
$v = setlocale(LC_MESSAGES, $locale.‘.UTF-8′, $locale, $locale.’@euro‘);
if($v !== false)
putenv(‚LC_MESSAGES=‘.$v);
zu ersetzen.
LG
Julius
Patschi sagt
am 21. Oktober 2012 @ 06:34
Hab es soeben getestet – Stell sich nach einem F5 leider wieder in Englisch um 🙁
Könnte es daran liegen, dass die Sprache meines Servers in Englisch ist?
admin sagt
am 24. Oktober 2012 @ 19:54
Mh schade
Ja, die locale muss auf den Server existieren.
Wenn du Root-Zugriff hast könntest du es mit:
less /usr/share/i18n/SUPPORTED
checken.
Aber wenn du bei einen deutschen Hoster biste und dort PHP mit dem Gettext Modul verfügbar ist. Sollte normalerweise auch die deutsche „Locale“ verfügbar sein.
Wenn du willst kann ich dir mal eine E-Mail schicken mit einer Gettext-Testdatei (php). Um einen Fehler in meine Plugin auszuschließen.
LG
Julius
Website beschleunigen: 6. Tipps für WordPress sagt
am 25. Oktober 2012 @ 09:04
[…] Sprachdatei WordPress um 44 Prozent langsamer machtAlternativ gibt es auch ein Plugin namens WP-Performance-Gettext-Patch, welches ich selbst bisher aber nicht ausprobiert habe. Wenn das Plugin wirklich funktioniert bzw. […]
Freetagger sagt
am 26. Oktober 2012 @ 17:09
Ich habe jetzt einfach meine „Pages“ in „Posts“ umgewandelt. Von 148 MB RAM auf 74 MB RAM. Kann mir vielleicht jemand erklären, wieso WordPress bei statischen Seiten so viel RAM verbraucht?
Jetzt ist zumindest der Admin Bereich wieder schön schnell 😉 wenn dein Plugin dann bei mir funktioniert, dann rennt die Seite wieder.
In dem Sinne schönes Wochenende
Patschi sagt
am 12. November 2012 @ 14:44
@admin: Dein Kommentar hab ich leider komplett übersehen… Sorry, dass ich jetzt erst darauf antworte 😀
Ja, die locale wird unterstützt:
http://pastebin.com/qZg8x0r7
Ich bin mein eigener Hoster 🙂 – und der Server steht bei OVH in Frankreich. Liegt es daran?
Die PHP Datei kannst mir gerne senden – die eMail Adresse siehst du ja schließlich beim Kommentar 🙂
Danke für deine Mühe!
admin sagt
am 12. November 2012 @ 19:57
Ok alles klar, ich denk mal ich werde dir das Skript in der laufenden Woche zu schicken.
LG
Julius
Patschi sagt
am 11. Dezember 2012 @ 19:58
Vor knapp einer Stunde wurde WordPress 3.5 released – Plugin scheint noch immer ohne Probleme funktionieren 🙂
DJ2LS sagt
am 1. Juni 2013 @ 16:47
Danke für das Plugin!
Benutze derzeit WP 3.5.2a und es hat eine 2 – 3 Fache Performancesteigerung gebracht! Test wurde mit „P3“ durchgeführt.
Danke dafür 🙂
73 de DJ2LS
Stefan sagt
am 15. August 2013 @ 01:59
Hallo Julius,
ich finde das Plugin toll. Aber in der Tat – es greift tief ein, und jetzt habe ich den Salat … Ich habe einen Multisite-Auftritt und in einem der Backends das Plugin deaktiviert. Dann habe ich es über FTP gelöscht.
Auf einer der anderen Websites in der selben Multisite-Installation war das Plugin allerdings noch aktiviert …
Und jetzt komme ich nicht mehr ins Backend, die Seiten werden nicht mehr angezeigt, und es kommen nur seltsame Fehlermeldungen.
Kannst du mir helfen?
Ich habe versucht, das Plugin via FTP wieder zu installieren. Hat nicht funktioniert. Dann habe ich via FTP WordPress neu installiert. Ich bekomme weiterhin die Fehlermeldung. Nicht einmal die Deaktivierung sämtlicher Plugins im wp-content-Ordner hat etwas geholfen.
Gibt es einen Trick, dass ich wieder an meine Seiten komme? Allmählich bin ich ziemlich verzweifelt. Es handelt sich um Produktivseiten, und ich lebe davon …
Irgendeine Idee? Ich wäre wirklich dankbar!
Liebe Grüße
S
Tom sagt
am 25. Oktober 2013 @ 11:11
Ab WordPress 3.7 gibt es einen Fehler wenn man die „Aktualisierungen“ aufruft. Die Seite bleibt weiß und es wird
PHP Fatal error: Call to undefined function wp_get_installed_translations() in ../wp/wp-includes/update.php on line 172
angezeigt.
Andere Seiten funktionieren allerdings.
Tom sagt
am 25. Oktober 2013 @ 11:26
OK, ich hab mal die beiden letzten, neuen Funktionen aus der wp-includes/l10n.php in die l10n_lib.php im Pluginverzeichnis kopiert, und es scheint zu laufen.
Die 2 Funktionen sind mit WordPress 3.7 neu hinzugekommen und dem Plugin natürlich noch unbekannt.
Simon Tretter sagt
am 27. Oktober 2013 @ 12:17
ist das plugin noch aktuell? Der Link zum Download ist tot? Wurde es eventuell in WordPress integriert?
lg
Simon
Andreas sagt
am 27. Oktober 2013 @ 19:13
Hallo, der Patch Version 0.10 scheint ein Problem mit WordPress 3.7 zu haben. Beim Aufruf der Plugin-Seite bekomme ich die Meldung: Fatal error: Call to undefined function wp_get_installed_translations() in /homepages/14/d29119663/htdocs/spieloase_de/wp-includes/update.php on line 172
Wird das Plugin deinstalliert funktioniert alles normal.
MfG Andreas
Tom sagt
am 28. Oktober 2013 @ 09:39
@Simon:
lade den Patch 0.10 von oben. das Plugin ist nicht mehr im WordPress Repository.
@Andreas:
war auch mein Problem 2 Kommentare früher. WordPress 3.7 hat zwei neue Funktionen, die übernommen werden müssen.
Andreas sagt
am 30. Oktober 2013 @ 20:43
@Tom
Danke, Dein Tipp hilft. Das ist der Nachteil, wenn man vom Handy aus supported, man übersieht vieles beim herumscrollen.
MfG
Ömer sagt
am 23. November 2013 @ 23:05
Hallo.
@Tom
War gerade am schreiben und fand die Lösung vom Tom.
Wir sagen im Türkischen „Sehr Sauber“ dazu. 🙂
Danke für die lösung. 🙂
admin sagt
am 11. Dezember 2013 @ 15:52
Hallo Leute,
entschuldigt bitte, dass ich mich erst jetzt melde.
Aber ich habe soeben die Version 0.11 veröffentlicht, diese ist voll kompatible mit der WordPress Version 3.7.1.
LG
Julius
Björn sagt
am 26. Februar 2014 @ 00:00
Ich habe quasi ein Konkurrenz-Plugin entwickelt (WP Performance Pack http://wordpress.org/plugins/wp-performance-pack/ ), das unter anderem die Implementierung von linushoppe verwendet. Es kommt im Gegensatz zu euren beiden Lösungen allerdings ohne Core-Patches aus und bietet eine alternative, falls keine gettext-Erweiterung verfügbar ist, die inzwischen fast genauso schnell ist wie natives gettext und deutlich weniger Speicher verbraucht, als die WordPress eigene Implementierung.
Ressourcen Sparen bei Ajax Calls in Wordpress › Daniel Hüsken sagt
am 18. September 2014 @ 07:40
[…] Ich glaub das best ist es wenn in WordPress der WP-Performance-Gettext-Patch integriert wird. Nach meinen Tests bring das am meisten. Der Speicher verbrauch geht dann auf ca […]
Andreas sagt
am 19. August 2015 @ 08:04
Hallo, seit WP Version 4.x verursacht das Plugin eine Fehlermeldung unter Dashbord/Einstellungen/Allgemein/Sprache der Webseite
Fatal error: Call to undefined function wp_dropdown_languages() in /homepages/…/wp-admin/options-general.php on line 355
MfG Andreas