Beiträge von codestyling

    So, hab auch mal ne Weile debugt, da mein Blog auch mit dem Fehler "Type V: not enough input, need 4, have 0 [...]" ausgestiegen ist. Das Problem trat erst nach einer Weile auf und hing davon ab, was auf meinen anderen Seiten los war (gleiche Installation). Für mich sieht es nach einem Fehler von substr() aus.

    Und hier ein passender PHP Bug, der schon gemeldet wurde: PHP Bugs: #40754: substr() checks overflow

    Zitat


    <?php

    $v = 2147483647; # INT_MAX on 32bit Linux

    # Tries to allocate too much memory
    var_dump(substr("abcde", 1, $v));

    var_dump(substr_replace("abcde", "x", $v, $v));

    Allerdings immer byteweise zu vergrößern, wäre ein Performance Problem, denn ein de_DE.mo enthält > 2000 Textpaare, von den int's mal ganz abgesehen !

    Lösch mal die vorkomprimierten Editorfiles auf der Domain, meist ist dieses Caching Schuld am nicht anzeigen.

    Code
    wp-content\uploads\js_cache\tinymce(md5).gz


    Danach Shift+Reload im FireFox und es sollte jetzt drin sein.
    Wenn es dennoch nicht angezeigt wird, blendet ein anderes Plugin oder dein Theme dort sein Stylesheet ein.

    Das kommt ganz darauf an, wer die Stylesheet Benutzung in den Editor einblendet. Zum einen kann TinyMCE Advanced ein Stylesheet File in den Editor einblenden (dort in Dokumentation nachzulesen), weiterhin gibt es Themes, die ihr Stylesheet dort einblenden und es gibt wie in deinem Fall vermutlich Shutter Reloaded Plugin, das ebenfalls ein Stylesheet dort einblendet.
    Wenn sich mehrere drum schlagen, wer sein Stylesheet dort einblenden darf, kann das schon mal nach hinten losgehen.
    Zu diesem Thema hab ich ein Mini-Plugin geschrieben, das ebenfalls ein Stylesheet einblenden kann, wenn der Benutzer keinen "aufgeblasenen" Editor für seine Kunden haben will (also ohne Themeunterstützung und ohne TinyMCE Advanced). Du kannst dir das auch gern codetechnisch ansehen, in deinen Plugins und Themes danach suchen und dich dann entscheiden, wessen Styleerweiterung du benutzen willst.

    Schau dir mal den Call Stack an: http://www.zoosau.de/wp_error/

    Es wird die komplette Gettext Bibliothek geladen. Daher nachwievor mein Verdacht, dass es einfach an PHP Limits liegt. Habe gerade geschaut, ich habe auch 30 Sek. als max_execution_time. Interessant wäre daher nochmal die phpinfo, welchen Wert er bei Memory Limit hat.

    Einspruch, Euer Ehren!
    Der translate() Aufruf erfolgt in der Mapper Klasse class gettext_reader, die wiederum ihre Implementation auf einen Member der Klasse class CachedFileReader aufsetzt. Dieser wird bei Initialisieren die de_DE.mo komplett in den Speicher laden und alle seek, tell und sonstigen Aufrufe basieren auf dem $this->_str Inhalt, der ja schon gelesen wurde (binärer, kompletter Fileinhalt).

    Wenn ich also einen int auspacken lassen will, ist die Data schon im Speicher, es sei denn ich hab nur die Table of Contents Struktur aus der de_DE.mo lesen können und der seek weis zwar wohin er soll, aber da ist nix mehr.

    Und wie gesagt, der Aufruf und Aufbau der Admin Seite zum Editieren der Posts verbraucht mehr Speicher als der Aufruf der Ajax Funktion, die maximal einen Text String returned.

    mit AVG ist auch nix auffällig ;-)


    Was hab ich gemacht:

    1. eingeloggt mit info/info
    2. Schreiben -> neuer Artikel
    3. rechte Maustaste im FireFox -> Quelltext anzeigen

    Ergebnis: Avira heult auf mit Warnung vor o.g. Trojaner. Konnte bloss keinen Schadcode finden.

    Hast du irgend eine Begrenzung angegeben oder hat das Plugin tatsächlich alle Posts, die du je gemacht hast auf deiner Hauptseite verlinkt und nur per Javascript "versteckt"? Ohne Begrenzung hast du Google eben mal alle >2000 Links auf der Main Page präsentiert, was bei einer Domain, die schon Google gut bekannt ist, dazu führen kann, dass der Bot alle >2000 Seiten am Stück besucht !

    Das führt zu > 2000 heftigen Datenbankabfragen, ich denke du wirst damit eher die DB Server lahmgelegt haben als den WebServer.

    Was Caching angeht, das ist nicht mein Gebiet, sorry. Du könntest höchstens das Plugin per FTP löschen (dessen Pluginorder) dann läuft es nicht mehr und dann den Provider bitten, wieder zuzuschalten.

    Kann es sein, das bei dir die Speichern/Publizieren Buttons vor sich hinblinken die ganze Zeit ?

    Dann wäre es sinnvoll, mal das autosave interval hochzusetzen in der wp-config.php

    PHP
    define('AUTOSAVE_INTERVAL', 180);

    Das wären dann alle 3 Minuten zwischenspeichern. Ich habe das auf 1 Sekunde bei mir mal testhalber gestellt und dann speichert der bei jedem Tastendruck im Editor dessen gesamten Inhalt. Bei im Speicher des Apache ausgeführtem PHP kann das dann leicht zur Überlastung desselben führen, denn du bombardierst mit Text-Tippen den Server mit immer mehr Post requests, die vom Autosave Script ausgelöst werden.

    Falls es das auch nicht ist, muß ich noch mal in mich gehen. Vielleicht fällt mir noch was ein, aber dann ist es eine harte Nuss.

    ... und nimm den Link zu phpinfo wieder raus, ist nicht 100% safe das Ganze. :)

    Aber nochmal zurück zu dem Patch: Es könnte vielleicht doch noch klappen. Ich war ein bisschen voreilig und habe vergessen den Browsercache zu leeren. Ich denke er hatte dann noch die gecachte stream.php beansprucht. Hab´s gerade nachgeholt und beobachte es nochmal.


    Also der Browsercache hat da nix mit zu tun, wenn dann der WP Cache, falls du den aktiviert hast oder ein Caching Plugin läuft. Und falls dein Server nicht PHP als CGI sondern als fast-cgi oder mod_php ausführt, kann der Apache und/oder cgi Manager noch die alte php gecached haben. Bei mir läuft leider alles über php cgi pur, sodas ich dies derzeit nicht nachstellen kann.

    PS: Screenshot oben mit eingefügt, nur der Vollständigkeit halber.

    Also auf mich wirkt das wie ein simples PHP Memory Problem, was wir hier ja schon öftter hatten durch die recht große Sprachdatei.

    Die dritte Fehlermeldung spricht ja eine eindeutige Sprache. Die ersten beiden Meldungen könnten Resultate daraus sein. Die gettext Bibliothek erwartet offenbar einige Bytes mehr, die aber aufgrund des Prozedurabbruchs nicht übertragen wurden...

    Schon das PHP-Limit bzw. Execution Limit erhöht?


    Schon klar, aber der Damage tritt ein, wenn der Ajax Text benutzt werden soll. Im Falle des Ajax Calls (autosave), wird ja wesentlich weniger geladen als es brauchte, die gesamte Admin Seite zu beschriften. Bei einem de_DE.mo mit 224 KB, das maximal 4 mal größer werden kann, komme ich auf 1MB. Zur Darstellung und Beschriftung des Admin Bereichs wird die Datei ja auch geladen, warum sollte es da gehen und bei Ajax, der weniger macht nicht ?

    Zusatz: Wenn ich den Ajax Call zu autosave modifiziere und dies hier testhalber darin als Response ausführen lasse:

    Code
    echo "Jetzt ist Schluss hier!";die(0);

    Dann bekomme ich eine rot umrandete Box mit meinem Text innerhalb des schwarzen Kastens. Also ist definitiv irgendwas im Ajax call nicht so, wie es sollte.

    Nach deinem Bild zu urteilen, ist das der schwarze "Kasten" mit dem Speichern/Publizieren Buttons, der nach x Sekunden dann die Autosave Mitteilung reinschreiben will, wenn er zwischengespeichert hat:

    Code
    <p class="submit">
    <input type="submit" class="button button-highlighted" tabindex="4" value="Speichern" id="save-post" name="save"/>
        <input type="submit" value="Publizieren" accesskey="p" tabindex="5" id="publish" class="button" name="publish"/>
    <br class="clear"/>
    <span id="autosave">[COLOR=Red][B]Entwurf gespeichert am 10:36:05.[/B][/COLOR]</span>
    </p>

    Dazu muß Autosave natürlich in die Übersetzung schauen, also das *.mo File aufmachen. Danke für den Hinweis, werd das mal weiter auseinandernehmen, warum er hier wieder mit der Übersetzung scheitert.
    Da der Text impliziert, das da noch ein Datum rein müsste (am benutzen und nur Uhrzeit zeigen, ist blöd) kann es entweder ein Übersetzungfehler sein oder ein sprintf Bug an dieser Stelle im Code. Werd mal englisch testen...

    Hab mal reingesehen, das ist ja geil. Avira springt erst an, wenn man sich auf der Seite für neue Posts den Quelltext anzeigen lässt. Aber ich konnte überhaupt nichts finden.
    Sehe da zwei Möglichkeiten:

    1. ich hab Tomaten auf den Augen oder
    2. ein Fehlalarm von Avira.

    Könnte sich um diesen PHP Bug handeln, der u.a. hier auch aufgetreten ist: #1484880 (Attachments get corrupted on Ubuntu server 64bit 6.06.2 LTS) - RoundCube Webmail - Trac
    -> PHP Bugs: #35859: fread limited to 8K

    Das *.mo File wird am Stück geladen, wie dieser Auszug aus dem WP Core zeigt:

    Laut dem, was man in den Bugbeschreibungen im Netz findet (dazu gibt es eine Menge und auch neueren Datums!), gibt es einen Bug in PHP 5.1.1 (und höher ?) der statt der gesamten File Größe nur die ersten 8192 Bytes liest. Dies würde auch den Fehler erklären, warum dann 0 Bytes übrig sind, für die du eine Warnung bekommts.

    Die WP Core Entwickler haben das auch für eine andere Klasse berücksichtigt und sogar kommentiert:

    Ich werde mal die Datei patchen und das blockweise Lesen auch in den CachedFileReader einbauen, testen und bereitstellen.
    Mal sehen, ob das des Pudels Kern ist.

    [COLOR=Red] getesteter Patch [/COLOR]
    Datei: /wp-includes/streams.php
    Zeile: 148 ff.
    WP Version: 2.5.1

    Im Normalfall liest dieser Patch weiterhin das File am Stück, aber in dem Moment, wo das 8192 Bytes Limit Problem erscheint, wird das jetzt blockweise trotzdem komplett gelesen.

    Das klingt interessant. Es gab einen Patch in der gettext Implementierung, der sich mit der Erkennung von 64Bit Systemen auseinandersetzte. Mal so aus dem Bauch heraus: Wenn PHP meint, es wäre ein 64Bit Machine und deshalb den gettext magic 64bit machen will, obwohl das OS nur 32 Bit ist, dann könnte das in die Hose gehen.
    Wenn du Lust auf Probieren hast, würde ich mit im Laufe des Tages mal die Stellen in WP ansehen (ist jetzt zu spät zum Denken) und testhalber dir den einen oder anderen Patch schicken. Wäre das ein Option, um das zu testen ?

    Nun ja, es gibt mehrere davon:

    Die mit explizit _runtime am Schluss ist ein Problem mit den *.mo Files.
    Zwei Fragen noch:

    1. Sicher, das auch die mit _runtime aus ist ?
    2. Ist die Server Machine 64bit ?

    Hast du die Möglichkeit bei deinem Webspace irgendwo die php-Fehlermeldungen zu aktivieren? Die sehen dann zum Beispiel so aus wie es bei mir mal der Fall war hier http://forum.wordpress-deutschland.org/konfiguration/…html#post104996 und zumindest Leute mit Ahnung werden dir damit weiter helfen können, wo der Hund genau begraben ist.


    Was du mit diesem Link zeigst, ist ein gehacktes Blog, das Werbung und/oder Trojaner ausliefert. Diese zusätzlichen, mystisch erstellten Zeilen stellen den Trojanercode bereit.


    Hat jemand eine Idee?


    Wenn du ebenfalls eine ältere Version hattest (laut deiner Angabe 2.0.11), dann kann es schon möglich sein, das dir was gefangen haben könntest. Wie weit das geht, kann ich nicht sagen, weil man auch Daten bis in die DB einschleusen konnte. Das kann eine neue Version evtl. ebenfalls beeinträchtigen.

    Original ist ok, wenn es Royal Blue ist, wie im ersten Post zu vermuten ist (page.php)