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.
Wo sind da nicht standardgemäße Attribute? Ich hab Deine Antwort zum Anlaß genommen, die verbleibenen OG-Reste komplett zu entfernen (OG ist nämlich tatsächlich nicht standardgemäß und Facebook sowieso a Bledsinn). Ansonsten erklären mir diverse Validation-Tools, daß die Seite sauber ist. (Bis auf die border-Attribute im HTML aus uralt-Bausteinen, die ich unverändert in der Seitenleiste übernommen habe.)
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.
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.