codestyling localization scannt und bleib hängen

Dasselbe Phänomen tritt auch bei mir auf:

Beim „Einlesen der PHP Quelldateien“ bleibt der „Analyse Fortschritt“ beim Wert 100 hängen. Unter dem Balkendiagramm steht:

„Datei: bbpress/bb-includes/backpress/pomo/entry.php“

Weitere Angaben, die angezeigt werden:

„Pojekt-Id-Version: WordPress v3.0.1
Zielsprache: Deutsch/Deutschland
Betroffene Dateien: 479 / “

Leider lässt sich der Prozess auch nicht abbrechen. Ich muss das Browserfenster schließen und mich neu ins Backend meiner WordPress-Installation einloggen.

Ich hoffte endlich eine elegante und probate Alternative zum Dauerschock-Programm Poedit gefunden zu haben, komme aber über die 100-er-Hürde des „Analyse Fortschritts“ von „Codestyling Localization“ nicht hinaus.

 

Hast du das mit der heute neu veröffentlichten Version 1.98 auch schon getestet?

 

Bei mir das selbe. Bei mir ist es Zeile 160 / 270.

Ich habe eben gerade ein Update auf die allerneueste Version 1.99.1 gemacht.

Vorher habe ich dann noch alle Plugins deaktiviert, bis auf CodeStyling Localization und qtranslate

 

Ich bräuchte dann mal die Angaben zum PHP Memory, der seitens deines Hosters zur Ausführung von Scripts zur Verfügung steht.
Weiterhin wäre interessent, ob es ohne qtranslate funktioniert und qtranslate somit eine Unverträglichkeit für mein Plugin darstellt.

 

Also wenn ich bei NextGen Gallery auf den Überblick sehe dann zeigt er mir dieses.

qtranslate zu deaktivieren traue ich mich im Moment nicht, ich hab mir schon mal ein paar hundert Artikel zerschossen durch aktivieren und deaktivieren. Weis eigentlich nicht warum.

 

Die Servereinstellungen sollten ausreichend sein. Damit bleibt bei einer Installation, die nur aus WP selbst, gtranslate und meinem Plugin besteht nur eine Unverträglichkeit mit qtranslate übrig.
Von qtranslate weiss ich bereits, das es mit verkürzten Sprachdateikennungen arbeitet, also "de.mo" statt "de_DE.mo". Deshalb sind die Sprachdateien, die mein Plugin erzeugt, auch nicht sofort einsetzbar sondern müssen dann umbenannt werden.
Bleibt mir nix anderes übrig, als ein System aufzusetzen und qtranslate zu aktivieren. Wenn ich das jedoch nicht reproduzieren kann, dann habe ich alle Optionen ausgeschöpft.

... Thread wird nach dem Test fortgesetzt, kann 1 bis 2 Tage dauern.

 

Super, das ist ja klasse von dir.

Allerdings kann ich ja fast kaum glauben, dass niemand der Dein Plugin in Benutzung hat qtranslate benutzt und somit den selben Fehler hätte.

Aber ich kann es abkürzen, ich setze selbst mal schnell eins auf, ich habe noch einen Installation übrig. Melde mich gleich.

 

Nee, wie gedacht. Ichhabe das TwentyTen Theme und ein einziges Plugin (deins) genau das gleiche. Es sind 269 Betroffene Dateien und bei 60 hört er auf einzulesen (Datei: wp-admin/includes/continents-cities.php)

*grübel*

 

Ichhabe es nun auf einem anderen Server versucht (nicht 1und1) dort habe ich auch ein WP 3.01 am laufen. Ich nun dein Plugin installiert und es bricht wieder bei 20 ab, Tab muss geschlossen werden (Firefox 3.6.8)

Kann es sein das es an dem Theme liegt?

 

Es könnte sein dass der Wert des memory_limits, den die Übersicht der Galerie auspuckt nicht richtig ist. Lese das Speicherlimit mal mit der aktuellen Version des wp-memory-usage Plugins aus, oder per phpinfo Datei. Die Galerieübersicht zeigt bei mir auch 256 an, obwohl mir nur 64 zur Verfügung stehen. 256MB sind für einen Massenhoster (ich schätze mal, dass Du bei einem bist) schon recht unglaubwürdig...

 

Hallo Infected, ich habs gleich installiert. Siehe Anhang.
Die Seiten liegen bei 1und1 , ist ein Paket für 39 EUR monatl, (mit viel alles)

 

So, jetzt zeigt mir allerdings die info.php im root des Servers schlappe
40MB
memory_limit an

also funktioniert das Plugin wp_memory_usage wohl nicht richtig.

 

Doch, das Plugin funktioniert in der aktuellen Version (Version 1.2.0) eigentlich einwandfrei. Hattest Du die anderen Plugins auch alle deaktiviert und den Browsercache geleert? Naja, spielt ja nun auch keine Rolle, da Du den richtigen Wert ja nun kennst (40M, 32M effektiv).

 

liegt vielleicht daran, das ich die Datei php.ini mit 256MB überall reingestellt habe.

Ich habe alle Plugins zur Zeit aktiviert und den Browser Cache gelöscht, dann das Plugin Memory Usage aktiviert und es zeigt nach wie vor 256MB an.
Davon 22,89 MB in usage, so wie auf dem Bild.

 

Es gibt Neuigkeiten zu diesem Thema. Ich hab ein lokales Testsystem aufgesetzt und dem PHP eine memory_limit = 40MB gesetzt. Danach hab ich sowohl einige Plugins/Themes gescannt als auch WordPress selbst.
Während aller Scanprozesse war nur WP 3.0.1, TwentyTen und mein Plugin aktiv, alle anderen Plugins waren deaktiviert.

Ergebnisse:
1.) alle getesteten Plugins ließen sich scannen.
2.) alle getesteten Themes ließen sich scannen.
3.) WordPress blieb wie beschrieben beim Scannen hängen.

Ursache:
Der Scanprozess braucht für WordPress selbst seit Version 3.0 von WordPress offensichtlich mehr Speicher, denn er knallt an das memory_limit.

Untersuchung:
Also hab ich das Limit schrittweise auf meiner Apache Installation erhöht und siehe da, ab 58MB !!! geht das wieder wie gewohnt.

Lösung:
Es wird demnächst Version 1.99.2 meines Plugins geben, die nicht mehr einfriert aber dennoch nur mit einer Fehlermeldung den Scanprozess abbricht, wenn das Limit getroffen wird.
Im Moment habe ich keine Ahnung, warum sich dies so ab WP 3.0 äußert. Ich kann nur empfehlen, zum Scan von WordPress selbst mindestens die 58MB zu haben. In älteren WP Versionen hat dies nie ein Problem dargestellt.

 

Weil die Sprachdatei seit 3.0 um einiges voller geworden ist. Es wurden ja zusätzlich noch die ganzen Hilfetexte aufgenommen. Hätte man nicht die Multisite Strings in eine extra Sprachdatei gepackt, wäre sie sogar noch größer.

 

das ist schade. So ein Klasse Plugin und nun das :shock:

 

Frage.
Wenn ich auf einem anderen Server alles einlesen kann , kann ich dann die Dateien mit FTP auf den anderen Server übertragen und nutzen wenn die eingelesen sind? Ich habe Zugriff aus einen anderen Server der 64MB Memory hat. Man braucht ja nur einmla einlesen denke ich, oder braucht das zum Bearbeiten dann auch die 58MB ?

 

Ich habe getestet, ob 40 MB ausreichen, bereits eingelesene Sprachdateien zu bearbeiten (übersetzen). Dies ist mit 40MB Limit problemlos möglich. Getestet mit einer frisch eingescanten de_DE.po sowie einer vollständig übersetzten de_DE.po Datei.