Dashboard: Fehlerhafte Umlaute in Newsfeeds

Sind es jeweils die selben Feeds? Wahrscheinlich liegt es an der Kodierung der Feeds. Bist du sicher, dass die Feeds UTF-8 kodiert sind?

 

Laufen auch beide Blogs als UTF-8 oder ist eines aus "Altersgründen" im ISO Mode verblieben nach einem Update ?

 

das kannst du im Seitenquelltext in den Meta-Angaben finden:

Code:

Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!

 

Ein ähnliches Problem habe ich auch.

Ich lasse mir auf meiner Webseite den RSS-Feed der Artikel eines Wordpress-Blogs eines Freundes anzeigen. Auch hier habe ich Probleme, wenn im Artikel-Namen Umlaute vorkommen. Beide Blogs laufen mit UTF-8.

Gleiches tritt auch im Dashboard auf, wenn ich die News von WP-Deutschland sehe.

Auch mein Blog wurde damals mit einer 2.3.x-Version aufgesetzt.

 

Wie liest du den Feed aus? Widget oder eigenes PHP-Script. Ein

PHP:

Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!

hilft da meistens.

 

Das läuft über ein tolles Widget

 

Was steht in der wp-config bei diesen Werten?

PHP:

Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!

 

Die fehlerhafte Darstellung der Feed Inhalte im DashBoard und auch in den Widgets geht auf jeweils einen Bug zurück, den die Entwickler übersehen haben. Im nicht deutsch-sprachigen Raum tritt dieser Fehler nicht auf und wird sicher in den Tests in "Übersee" auch nicht registriert worden sein (US hat keine Umlaute).
Es sind 2 Core Dateien betroffen, die man wie folgt reparieren kann (WP2.6.1):

wp-admin/includes/dashboard.php Zeile: 431

Code:

Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!

wp-includes/widgets.php Zeilen: 1130 und 1132

Code:

Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!

Ich werde diesen Bug noch an WP-Trac weiterreichen, hier nur vorab die Bereinigung.

Hintergrund: Bei der Dekodierung der im Feed enthalten Sonderzeichen, wird der optionale Parameter der Funktion html_entity_decode charset nicht gesetzt, weshalb als Standardwert ISO-8859-1 angenommen wird. Allerdings muß sich die Konvertierung nach dem vom Blog vorgegebenen charset richten, was ich als rot markierte Ergänzungen in den o.g. Codeausschnitten hinzugefügt hab.

 

Verlinke nach dem Eröffnen bitte mal das Trac-Ticket.

 

Hier die eingereichte Bug-Trac Nummer: #7563 (html_entity_decode at RSS Feed import doesn't respect charset of Blog) - WordPress Trac - Trac

 

codestyling, offenbar kommt es damit bei PHP4-Versionen zu Fehlern:

dank diesem PHP-Bug: PHP Bugs: #27626: html_entity_decode bug - cannot yet handle MBCS in html_entity_decode()! und der Funktion html_entity_decode()

Auf PHP5-Versionen läufts prima.

 

Dann sollte für PHP4 (kann ich leider nicht testen) ein vorangestelltes @ reichen, um die Warnung zu unterdrücken, da es ja offensichtlich keine Bereinigung mehr für PHP4 geben wird :cry:

Code:

Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!

... hab das mal im Bug-Trac Eintrag mit hinzugefügt als Randnotiz.

 

Erstmal freue ich mich natürlich über so viel Feedback zu dem Problemchen.

Nachdem ich beide Dateien entsprechend angepasst habe (auch mit dem "@") ergeben sich jedoch noch folgende Fehlermeldungen
im Dashboard:

im Widget auf meiner Seite:

Edit: PHP Version : 4.4.8

 

Du könntest vor den bisherigen Änderungen noch folgende Zeile einfügen:

PHP:

Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!

Hässlich, okay, aber...

 

Es gäbe auch noch eine andere Lösung, die in PHP4 funktioniert, aber bei "Gemischtwarenladen" (sprich deutsch/englisch gemischt und Sonderzeichen in englisch wie ´) dann passiert das:

Code:

Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!

Dann stimmen zwar die deutschen Umlaute aber die puren Zeichen im englischen Zusatz werden zerlegt.

 

Das Sinnvollste ist eine Umstellung auf PHP5 denn: heise Security - 04.01.08 - Support für PHP 4 eingestellt

Also alle Termine bereits überschritten!

Zusatz: Es gibt jetzt eine letzte Release PHP 4.4.9 seit 07.08.2008, die definitiv die letzte Security/Bugfix Version ist: PHP: News Archive - 2008

Unter anderem ist darin auch der leidige all-inkl.com Bug mit den Sprachdateien durch globale Umschaltbarkeit der mb_str Funktionen behoben. Nur wann und ob die Provider das noch einspielen, who knows ...