Kommentare verschwinden immer noch
Reizend finde ich, daß dieser Fehler nie die vielen Car-Insurance-Spams trifft, die seit Wochen nerven. Nein, es sind immer nur die "echten" Kommentare.
Hab mir mal den Quelltext des Blogs angesehen und dort ist, hm, sagen wir, ein recht kreativer Einsatz von HTML in Gebrauch. Es spricht prinzipiell nichts dagegen, den DOCTYPE auf html5 umzustellen (das habe ich auch in meinem Blog), aber die massive Verwendung nicht standardgemäßer Attribute z.B. im html-, meta-Tag, aber auch in DIVs und SPANs ist mindestens mal sehr sportlich, wenn man sich überlegt, dass der ein oder andere ältere Browser nach einigen Analyseversuchen evtl. entsetzt das Kommentieren verweigert.
Wenn man also nicht von einem schnöden Datenbankfehler ausgehen möchte, wäre das mal eine Arbeitshypothese, dass das sehr umfassende und manchmal etwas eigenwillige OpenGraph-Coding zu Irritationen bei einer 13 Jahre alten Blogsoftware auf Transitional-XHTML-Basis führt, die von HTML5 oder OpenGraph noch nicht einmal zu träumen wagte.
Die Hypothese wird dadurch gestützt, dass auf meiner HTML5-Blogseite z.B. auch der Standard-Twoday-Export fehlerfrei durchläuft. Für eine bessere Analyse wäre es auch wichtig, die Konfiguration des Anwenders zu kennen, dessen Kommentar nicht durchging (Betriebssystem, Browser+Version, etc.).
Noch was: Diese "[unhandled macro]"-Fehlermeldungen machen es nicht einfacher. Obwohl auskommentiert, versucht die Antville-Software, jedes gefundene <% macro %> aufzulösen. Die Verwendung von story.url bzw. story.topic ist an der Stelle aber unzulässig (das müsste dann schon in einen story-Skin hinein).
Besser also ganz entfernen anstatt nur per HTML-Kommentar zu deaktivieren.
Nicht standardgemäß?
Das ist aber auch alles nebensächlich und nur Kosmetik: Beim Übermitteln eines Kommentars per POST werden ja nur die Nettodaten übertragen, wenn ich mich jetzt nicht sehr täusche. Das heißt: Rundherum kann Plain Text oder HTML5 oder fehlerhaftes HTML 4.01 oder sonst was stehen. Der Browser kann an der Darstellung der Seite komplett scheitern. Das alles macht nichts, wenn schließlich beim Absenden des Formulars der Kommentartext *ohne* den ganzen Spaß rundherum übermittelt wird.
Es ist auch nicht der Browser, der "entsetzt" das Kommentieren verweigert; es ist der Server, der den nachweislich bereits empfangenen Kommentar sofort wieder löscht oder sonstwie entsorgt.
Ein zeitliches Zusammentreffen zwischen dem Aufbohren der Skins mit etwas lustigerem HTML (laufend seit 2012, zuletzt im Sept. 2015) und den Problemen beim Kommentieren, die erst in den letzten Wochen auftreten, gibt es nicht.
Wir haben eine Theorie
Der "Allgemeine Fehler" tritt dann auf, wenn der Benutzer von seinem Handy aus kommentiert und dabei ein Emoji verwendet.
Wir konnten nachvollziehen, daß der Fehler beim Reinkopieren des immer gleichen Textes mit Emoji verläßlich auftauchte. Kaum war das Emoji weg, ging auch der Kommentar problemlos durch. (Was natürlich fehlt, ist die Verifizierung in die andere Richtung: Tritt der Fehler jetzt wider Erwarten noch bei einem Kommentar auf, bei dem kein Emoji im Spiel war?)
Daß das jahrelang nicht passiert ist und seit einiger Zeit gehäuft vorkommt, ist meine Schuld: Ich selbst habe begonnen, Emojis in Artikel und Kommentare einzufügen - allerdings als XML-Entities und nicht direkt über die (Handy)-Tastatur. Das geht. Offenbar hat das Leser dazu ermutigt, selbst auch "bunt" zu schreiben... Tja. Und dann schmeißts das System.



Bestätigt.
antworten