codestyling localization scannt und bleib hängen

  • Hallo zusammen,

    Ich verwende das Plugin codestyling localization um meine Themes und pluins zu übersetzten.

    Jetzt hab ich mit einem Theme ein problem!

    Und zwar... wenn ich das theme scannen will fängt das plugin an zu scannen und bleibt bei der 100 file hängen und scannt nicht weiter!

    Ich hab bei meinem hoster das scriptlaufzeitlimit erhöhen lassen das hat aber auch nicht geholfen!

    An was könnte das liegen hat jemand eine Idee?

    LG

    Sascha

    • Anzeige

    Hallo!

    Wenn du gerade an deiner Website arbeitest oder dein aktuelles Hosting überdenkst: Wir betreiben mit NetzLiving eine Hosting-Plattform, die speziell auf Performance, Sicherheit und einfache Verwaltung ausgelegt ist.

    • ✔️ Schnelle Ladezeiten (optimiert für WordPress & Co.)
    • ✔️ Deutsche Server & DSGVO-konform
    • ✔️ Persönlicher Support (kein 0815-Ticket-System)

    Mehr erfahren

  • 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.

  • 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

  • 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...

  • 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 [COLOR=Red]58MB[/COLOR] !!! 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.

  • Im Moment habe ich keine Ahnung, warum sich dies so ab WP 3.0 äußert.

    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.

  • 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 ?

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!