Serendipity Forums

[Lux]

Hi,

ich stehe auf dem Schlauch.

An diesem Wochenende habe ich drei Blogs auf s9y-2k11 umgestellt. Dabei habe ich nicht die Entwicklerversion benutzt, sondern die, die bei der 1.6.2 dabei war.

Bei zweien der Blogs validieren alle Feeds nicht, weil die Entity (anscheinend) erst in der zweiten Zeile definiert wird.

http://validator.w3.org/feed/check.cgi? ... index.rss2
http://validator.w3.org/feed/check.cgi? ... index.rss2

Habt Ihr Ideen?

Danke!

DIrk

[yellowled]

An diesem Wochenende habe ich drei Blogs auf s9y-2k11 umgestellt. Dabei habe ich nicht die Entwicklerversion benutzt, sondern die, die bei der 1.6.2 dabei war.

Ich habe gerade die Feeds von 4 anderen 2k11-Blogs durch den Validator geschickt. Alle validieren. Alles andere hätte mich auch gewundert, da 2k11 keine Feed-Templates enthält. Die Feeds müssten auch mit einem anderen Template invalid sein.

Was mir spontan auffällt: Beide Blogs laufen auf iso-8859-1. Alle Blogs, deren Feeds ich zum Vergleich getestet habe, laufen auf UTF-8. Eventuell spuckt da irgendetwas™ in die Suppe, vielleicht sogar in den Feed-Templates von default? Unerwartetes BOM in den Feed-Templates oder sowas wildes?

YL

[Lux]

Was mir spontan auffällt: Beide Blogs laufen auf iso-8859-1. Alle Blogs, deren Feeds ich zum Vergleich getestet habe, laufen auf UTF-8. Eventuell spuckt da irgendetwas™ in die Suppe, vielleicht sogar in den Feed-Templates von default? Unerwartetes BOM in den Feed-Templates oder sowas wildes?

Was ist BOM?

Gruss

Dirk

[Lux]

Hi,

es liegt wirklich an iso8859-1, wenn ich auf UTF-8 umstelle, sehe ich auch die Feeds.

Was ist der schlaueste Weg, alle Tabellen auf UTF8 umzustellen?

Das per SQL-Befehl zu machen ist kein Problem, ich möchte allerdings nicht alle Postings von Hand anfassen müssen, um die Umlaute zu ändern.

Das wäre doof.

Gruss

Dirk

[Lux]

Gestern standen wir am Abgrund. Heute sind wir einen Schritt weiter.

In der rss.php scheint UTF-8, fest einkodiert zu sein.

Code: Select all

<?php # $Id: rss.php 2707 2010-10-12 12:40:32Z garvinhicking $
# Copyright (c) 2003-2005, Jannis Hermanns (on behalf the Serendipity Developer Team)
# All rights reserved.  See LICENSE file for licensing details

header('Content-Type: text/xml; charset=utf-8');
session_cache_limiter('public');

Ich habe es mal (ohne Änderung) auf "iso-8859-15" gesetzt. Ist das überhaupt die richtige Stelle?

Gruss

Dirk

[garvinhicking]

Hi!

Ich denke das Problem ist, dass ihr mal alle *.tpl und manuell geänderten Dateien durchsuchen müsste nach der UTF-8 BOM:

http://en.wikipedia.org/wiki/Byte_order_mark

Diese kann PHP nicht ordentlich verarbeiten; Editoren dürfen diese BOM *NICHT* in Dateien schreiben, weil sie sonst zu den genannten Fehlern und "Headers already sent" und so sachen führen können.

Per RFC sind RSS-Feeds immer in UTF-8 zu halten, daher konvertiert s9y die RSS-Feeds eigentlich alle ins UTF-8 Format; Dein Patch dürfte dann eigentlich zu doppelt kodierten Umlauten führen; das BOM-Problem dürfte dadurch auch eigentlich nicht behoben sein, wenn es das ist?

LG,
GArvin

[Lux]

Ich denke das Problem ist, dass ihr mal alle *.tpl und manuell geänderten Dateien durchsuchen müsste nach der UTF-8 BOM:

Das ist genau die Herausforderung. Ich habe bis auf die user.css von 2k11 keine manuell geänderten Dateien.

Hier die zuletzt installierten Plugins:

Code: Select all

drwxr-xr-x  4 www-data www-data 4096 Jul 13 12:10 serendipity_event_template_editor
drwxr-xr-x  7 www-data www-data 4096 Jul 14 17:12 serendipity_event_gravatar
drwxr-xr-x  4 www-data www-data 4096 Jul 14 18:43 serendipity_event_xmlrpc
drwxr-xr-x  4 www-data www-data 4096 Jul 15 09:53 serendipity_event_spamblock_bee
drwxr-xr-x  4 www-data www-data 4096 Jul 16 12:10 serendipity_event_freetag

Die einzige TPL-Datei ist die vom freetag-Plugin.

Template ist 2k11 in der Standard-Variante, user.css wurde mit Matthias Tool erstellt.

Gruss

Dirk

[garvinhicking]

Hi!

Hast Du mal nach der UTF-8 BOM in allen Dateien gegreppt? Das ist ja ein spezieller Hex-Code der eigentlich sonst nicht vorkommen sollte.

Grüße,
Garvin

[Lux]

Hast Du mal nach der UTF-8 BOM in allen Dateien gegreppt? Das ist ja ein spezieller Hex-Code der eigentlich sonst nicht vorkommen sollte.

Ja, habe ich und reichlich Treffer gefunden, allerdings in htmlarea und trunk/htmlarea, dort dann in .svn-base- und in .js-Dateien ... also nichts kritisches (soweit ich das beurteilen kann).

Hier mal zu Referenzzwecken die Kommandozeile dafür:

Code: Select all

grep -rl $'\xEF\xBB\xBF' . | egrep -v "\.(jpg|png|gif|psd)$"

Gruss

Dirk

[Lux]

Ich bin ratlos und für jede Idee dankbar.

Die Daten in der Datenbank sind - anders als bei meinem Blog - sauber kodiert.

Die folgenden Plugins werden verwendet:

Code: Select all

Avatar Plugin - serendipity_event_gravatar
Sample! - serendipity_event_head_nugget
Textformatierung: Serendipity - serendipity_event_s9ymarkup
Textformatierung: NL2BR - serendipity_event_nl2br
Textformatierung: Smilies - serendipity_event_emoticate
Spamschutz Biene (Honeypot, Verstecktes Captcha) - serendipity_event_spamblock_bee
Spamschutz - serendipity_event_Spamblock
Statistiken - serendipity_event_statistics
Smilie-Auswahlleiste - serendipity_event_emoticonchooser
Suchmaschinen-Sitemap Generator - serendipity_event_google_sitemap
Dashboard - serendipity_event_dashboard
Markup: Auto-Titel - serendipity_event_autotitle
Spamschutz (Bayes) - serendipity_event_spamblock_bayes
Template-Editor - serendipity_event_template_editor
Spartacus - serendipity_event_spartacus

Aktuell - serendipity_html_nugget_plugin
Von lesen bis hören - serendipity_html_nugget_plugin
Blog abonnieren - serendipity_syndication_plugin
Verwaltung des Blogs - serendipity_superuser_plugin

[garvinhicking]

Hi!

Aber der Feed validiert jetzt?!?

LG,
Garvin

[Lux]

Grmpf!

Ich scheine die Artikelvorschau nicht abgesendet zu haben.

Nur zwei Konfigurationsänderungen führten zum Ziel, aber ich habe ein "komisches Gefühl" dabei.

Datenbank-Zeichensatzkonvertierung aktivieren auf Ja
Zeichensatz-Auswahl auf UTF-8

Danach validierte der Feed.

Gruss

Dirk

[garvinhicking]

Hi!

Das ist korrekt so; das "dbNames" klingt etwas misleading, aber das ist, was MySQL defaultmäßig seit 5.1 tut. Es gibt leider genügend Fälle in denen man die Option mal braucht und mal nicht, abhängig von eingesetzten Datenbanktypen, Default Collations und so - es ist aber kein Grund für ein mulmiges Gefühl, das läuft korrekt.

LG,
Garvin

[Lux]

Das ist korrekt so; das "dbNames" klingt etwas misleading, aber das ist, was MySQL defaultmäßig seit 5.1 tut. Es gibt leider genügend Fälle in denen man die Option mal braucht und mal nicht, abhängig von eingesetzten Datenbanktypen, Default Collations und so - es ist aber kein Grund für ein mulmiges Gefühl, das läuft korrekt.

Dann bin ich jetzt beruhigt.

Danke Garvin.

Dirk