Sonstiges

IE 6 und Kommentarfelder

19. Sep 2007

habe Michael Wöhrer wegen folgenden Problem angemailt:
es kommt hin und wieder vor, dass man einen Kommentar schreibt, dann aber beim Abschicken vergessen hat, das Spamfeld „Berechne Ergebnis aus x+y“ auszufüllen. Es erscheint eine Fehlermeldung mit dem Hinweis, das Feld ebenfalls auszufüllen. Dann geht man wieder zurück und der Kommentartext ist weg.

So wie es aussieht, liegt es nicht am Template oder einem Plugin wie zB Edit Comments, sondern am IE6-Browser. Dazu Michael:

Unter Firefox konnte ich es nicht reproduzieren, im IE6 schon.

Ich hab also erstmal Edit Comments XT und Math Comment Spam deaktiviert. Wenn ich nun einen im IE6 Einzelbeitrag öffne, nur einen Kommentar eingebe und z.B. den Namen weglasse und Senden anklicke, dann sagt WordPress „Error: please fill the required fields“, geht man zurück, so ist der Kommentar weg.

Dies ist aber NICHT ein Plugin- oder Theme-Problem, sondern – soweit ich das blicke – eine Inkompatibilität WordPress mit dem IE6. Siehe übrigens auch diesen Kommentar von damals

IE7 scheint nicht betroffen zu sein.

Können es Deine Leser eingrenzen, dass dies nur beim IE6 aufgetreten ist?

Merkwürdigerweise habe ich von dem Problem beim alten Template nie etwas seitens eines Lesers gehört. Vielleicht hatte sich aber auch keiner die Mühe gemacht vorher, mir das zu mailen. Kann auch sein. Können diejenigen mit einem IE6 Browser das reproduzieren oder haben auch diejenigen mit anderen Browsers das gleiche Problem?

1. Kommentarformular ausfüllen inkl. kurzem Testkommentar
2. Rechenergebnisfeld ignorieren
3. speichern
4. Fehlerhinweis abwarten
5. zurück
6. ist Kommentartext weg?

Unsere Empfehlungen für dich

Über den Autor

Robert Basic

Robert Basic ist Namensgeber und Gründer von BASIC thinking und hat die Seite 2009 abgegeben. Von 2004 bis 2009 hat er über 12.000 Artikel hier veröffentlicht.

Zu allen Artikeln

29 Kommentare

  • Also ich hab das Problem auch im Firefox 2.0.0.6 und das von Anfang an. Beim Safari für Windows tritt das ganze Problem nicht auf.

  • Ja, im Firefox gibt’s das Problem offensichtlich auch.

    Und vielleicht liegt es doch an Dir, denn Du sendest folgende Header bei Aufruf der wp-comments-post.php mit:

    Cache-Control: no-cache, must-revalidate, max-age=0
    Pragma: no-cache

    Ich meine mich erinnern zu können, dass wir hier im Haus mal ähnliche Probleme hatten mit Mantis (http://www.mantisbt.org) hatten…

  • aha, ich habe nämlich den Header bis dato seit dem REdesign noch nicht angefasst. Ok, werde das mit dem no-caching deaktivieren, hört sich nämlich ganz nach der Ursache an! Danke!! Test kommt sofort.

  • Hmmm,

    kommentier‘ mal in der wp-comments-post.php testweise die Zeile 10

    nocache_headers();

    aus.

    Edit: Urgs, das ist natürlich vermutlich Unsinn, weil die Seite, die nicht gecached wird, ja die Beitragsseite selbst ist. Die hat auch einen nocache-Header 🙁

    Also müsste wohl der Header schon dort abgeschaltet werden….

  • ahso, direkt in der Funktion? Aber haben dann nicht alle WordPress-Blogs das gleiche Problem? Zuvor im alten Template und unter WordPress 2.1x war dem zumindest nicht so. Muss also neu sein das Prob bzw. im Rahmen dieses Parameters oder?

  • Siehe meinen Edit oben….

    Das muss man doch irgendwo generell abschalten können?!

    Muss ich nochmal die Sourcen durchwühlen….

  • hatte gerade eben auf Deinem Blog einen Kommentar abgefeuert, ohne das Pflichtfeld Mail auszufüllen. Nach der Fehlermeldung wieder back und der Kommentartext war noch da! Nutze Firefox. Welche WP-version hast Du am Laufen? Ah, 2.2.3, die gleiche Version wie hier. Hm… hast Du was geändert?

  • Ich habe nichts geändert…

    Wenn man sich das mit HTTP Live HEaders im Firefox anguckt, sind bei mir beim Artikelaufruf aber keine Nocache-Header dabei, bei Dir allerdings schon.

    Also scheint es offensichtlich wirklich daran zu liegen.

    Wir müssen nun also raus bekommen, durch welche Modifikation und/oder Plugin bei Dir auch auf den Artikelseiten die NoCache-Header generiert werden…

    Ich schau mal noch ein bischen durch die Sourcen, die Header-Definition erfolgt wohl über send_headers() aus der classes.php….

  • Danke, Robert, dass Du Dich um dieses Problem kümmerst: Noch verliere ich meinen Kommentar, wenn ich im Firefox vergesse, das Rechenergebnis einzutragen. Das passiert mir wirklich oft, weil mir Firefox die anderen Felder vorausfüllt.

  • Das Firefox auch nicht funktioniert, schrieb ich doch oben schon 😉

    Es liegt definitiv am NoCache-Header, und um das Ganze noch absurder zu machen, der Header kommt definitiv nicht aus dem Original-Wordpress.

    Denn dort wird als Expires: -Zeile explizit folgendes angegeben:

    @header(‚Expires: Wed, 11 Jan 1984 05:00:00 GMT‘);

    Robert (bzw. sein Blog 😉 sendet aber

    Expires: Thu, 19 Nov 1981 08:52:00 GMT

    im Header.

    Also bleibt als Aufgabe, herauszubekommen, welches Plugin oder sonstige Komponente Deines Systems diesen Header generiert.

    Womit cachest Du, Robert?

    Und falls das Expires ebenfalls fest verdrahtet sein sollte, hilft vielleicht ein grep über den WordPress-Baum mit Suchbegriff „Expires: „. Da dürfte es regulär eigentlich nur 2 Treffer in der functions.php geben.

  • expires in der functions.php? Ok, werde mal die Files danach durchsuchen. Explizit ist mir nicht bewußt, irgendein Caching-Plugin zu nutzen, noch habe ich diese eine Methode direkt in WP aktiviert, die Seiten nicht/doch zu cachen.

  • das steht in der include/functions.php
    function nocache_headers() {
    @ header(‚Expires: Wed, 11 Jan 1984 05:00:00 GMT‘);
    @ header(‚Last-Modified: ‚ . gmdate(‚D, d M Y H:i:s‘) . ‚ GMT‘);
    @ header(‚Cache-Control: no-cache, must-revalidate, max-age=0‘);
    @ header(‚Pragma: no-cache‘);
    }

    function cache_javascript_headers() {
    $expiresOffset = 864000; // 10 days
    header(„Content-type: text/javascript; charset=“ . get_bloginfo(‚charset‘));
    header(„Vary: Accept-Encoding“); // Handle proxies
    header(„Expires: “ . gmdate(„D, d M Y H:i:s“, time() + $expiresOffset) . “ GMT“);
    }

    weitere Stellen habe ich in dieser Datei nicht mehr gefunden. Werde jetzt die Plugins nach dem anderen String (s.o.) durchsuchen.

  • Ja, die include/functions.php ist i.O.

    Da siehst Du auch das Datum, was Dein Server nicht sendet, also liegt die Ursache für den NoCache-Header definitiv woanders.

    Ich schaue gerade mal, wo das überall herkommen kann…

  • aha, in der CFORMS.PHP finde ich das:
    header(„Pragma: public“);
    header(„Expires: 0“);
    header(„Cache-Control: must-revalidate, post-check=0, pre-check=0“);
    header(„Content-Type: application/force-download“);
    header(„Content-Type: application/octet-stream“);
    header(„Content-Type: application/download“);
    header(„Content-Disposition: attachment; filename=“formconfig.txt““);
    header(„Content-Transfer-Encoding: binary“);
    header(„Content-Length: “ .(string)(strlen($buffer)) );
    Dieses File ist Bestandteil des CForms Plugins, das in der Sidebar als Kontaktformular eingebunden ist und immer auftaucht, egal ob Startseite oder aber Einzelansicht.

    Zudem finde ich expires noch in diesen CForm-Files:
    Cforms-Captcha.php, das captcha ist aber nicht aktiv, dürfte also nicht greifen:
    switch ($output_type) {
    case ‚jpeg‘:
    Header(‚Expires: Mon, 26 Jul 1997 05:00:00 GMT‘);
    Header(‚Cache-Control: no-cache, must-revalidate‘);
    Header(‚Content-type: image/jpeg‘);
    ImageJPEG($im,NULL,100);
    break;

    case ‚png‘:
    default:
    Header(‚Expires: Mon, 26 Jul 1997 05:00:00 GMT‘);
    Header(‚Cache-Control: no-cache, must-revalidate‘);
    Header(‚Content-type: image/png‘);
    ImagePNG($im);
    break;
    }

    Und in der CFORMSADMIN.SRC.JS:
    document.cookie = ‚dbx-cforms=cformsfieldsbox:’+order+‘; expires=’+now.toGMTString()+‘; path=/‘;

    hm… da das Kontaktformular sich superb bewährt hat, mag ich das nicht ausschalten. Werde mal den Plugin-Autor fragen, wie ich das umstellen kann.

  • Hmmmm, bin noch unsicher, so 100%ig glaube ich noch nicht, dass Du das Problem damit vollständig erwischt hast…

    Hast Du ’ne Testinstallation, auf der Du die Zeilen

    header(„€?Pragma: ….
    header(„€?Expires: ….
    header(„€?Cache-Control: ….

    testweise auskommentieren kannst?

    Und immer beim Testen daran denken, Du musst von WordPress ABGEMELDET sein; bei angemeldeten Benutzern wird IMMER ein NoCache-Header mitgeschickt!

    Nur noch mal so als Hinweis…

    Ansonsten kannst Du mir natürlich auch Deine Telefonnummer mailen,
    dann kann man ggf. interaktiver basteln, sofern noch Bedarf ist; allerdings dann auch nur nach „Feierabend“ 😉

  • *verbeug* danke für dieses Angebot. Warten wir erstmal ab, habe Oliver angeschrieben, der CForms entwickelt hat, ob er einen Ansatz sieht und ob das damit zusammenängt. Denn, weitere Fundstellen gab es nicht außer CForms bei der Suche in den Plugins.

    Wenn dem aber so ist, erklärt das auch den sehr langsamen Seitenaufbau der Sidebar nach dem Absenden eines Kommentars. Hat mich seit der Umstellung ziemlich gewundert, warum das so lahm ist.

  • Test: ich schalte jetzt das Kontaktformular in der Sidebar gleich ab. Kann dann bitte kurz einer testen zu kommentieren und dabei das Rechenfeld außen vor lassen, um zu sehen, ob dann der Kommentartext nach dem Absenden immer noch da ist?

  • test, Kontaktformular ausgebaut, CFOrms-Plugin komplett deaktiviert
    Klappt… shit… das wars. es liegt am CForms Plugin. Es bringt also null, das Konktaktformular aus der Sidebar zu verbannen, man muss die Parameter in CFOrms bzgl. caching anpassen. Sonst kann ich ganz Cforms rauskicken. Was ich ungerne tue. Da es ziemlich gut ist an sich.

  • Jau, das war’s tatsächlich 😉

    Na, dann kann ich mich ja wieder dem Dienstlichen widmen; ist immerhin auch PHP…

  • Kann ich voll und ganz bestätigen. Als ich mir ein Plugin gebastelt hatte, stand ich ebenfalls vor der Frage wie man es mit dem Backbutton bzw. einer Fehlermeldung löst. Der FF zeigte den Text hemmungslos wieder an, der IE6 hingegen löschte alles.

    Eine Javascript-Lösung wäre ganz hilfreich. Also mit OnSubmit prüfen ob das Feld ausgefüllt ist und wenn nicht, mittels alert einen Hinweis ausgeben.