Beiträge von toscho

Eigentlich brauchst du in UTF-8 keine Maskierungen. Benutze zur Eingabe einfach einen Browser, in dessen Name nicht »Internet Explorer« vorkommt, und kopiere sicherheitshalber nicht einfach Texte aus Word oder so.

Wenn du das getan hast, sollte nach dem nächsten Crwl wieder alles in Ordnung sein. Wenn der Fehler weiterhin auftritt, schubse diesen Thread einfach nochmal hoch.

Da war wohl der Titel während des Crawls falsch kodiert. Oder Google hat aufgrund der falsch kodierten anderen Elemente – [FONT="Courier New"]<meta name="description"[/FONT] und [FONT="Courier New"]<meta name="abstract"[/FONT] – vermutet, daß die Seite doch kein UTF-8 ist und selbständig die Kodierung gewechselt.

Repariere alle Inhalte, und warte den nächsten Crawl ab.

Dann hast du das BOM wahrscheinlich noch in der wp-config.php.

Verfahre mal nur mit deinem Stylesheet nach dieser Anleitung. Konvertiere danach wieder nach UTF-8 zurück; das ist langfristig die Zeichenkodierung schlechthin.

Alle anderen Dateien sollten in UTF-8 kodiert bleiben. Und bitte: Vergiß ISO-8859-15! Das ist ein Irrläufer, der mal eine Weile in E-Mails benutzt wurde. Generell halte dich an UTF-8 oder – wenn es gar nicht anders geht – an Windows-1252. Diese beiden Kodierungen lösen die wenigsten Probleme aus.

Was ist ein »geschlossener Post«? Soll der ganze Beitrag gelöscht werden?

Das BOM hat dein Editor wahrscheinlich eingefügt, als du das Stylesheet bearbeitet hast. Speichere sie mal ohne BOM, wenn der Editor das hergibt.

Wenn du keine Umlaute im Stylesheet verwendest und dein Editor wenig taugt, speichere die Datei nicht als UTF-8 ab, sondern als ANSI bzw. Windows-1252.

Eigentlich sollte das BOM aber keinen Browser stören; Darstellungsfehler im IE können viele Ursachen haben, allen voran die Tatsache, daß es eben IE ist.

Vielleicht hast du eine Kategorie oder einen Artikel, in dessen URL-Form die Zeichen »kontakt« schon auftauchen? Wie im oben verlinkten Artikel beschrieben, ist der nackte %postname% einfach keine gute Form für WordPress-URLs.

Das hat es schon. :) Ist ja im Thread verlinkt.
Aber mach es bitte wie ich, und piesacke Strato nochmal deswegen. Vielleicht höhlt der stete Tropfen doch den Stein, und Strato stellt mal jemanden ein, der einen Webserver einrichten kann.

Versuch doch mal einen etwas besseren Aufbau für deine Permalinks. Funktioniert die Seite dann wieder? Funktionieren andere Einzelseiten?

Wenn deine feste Adresse auf eine Domain ohne www. zeigt, dann könnte es dieses Problem sein. Das ist ein alter Strato-Fehler, der nichts mit Fremdsoftware zu tun hat, sondern allein mit der Inkompetenz bei Strato.

Freu dich schon auf die »Performance« der Datenbankverbindung. Bei zwei Blogs, die ich dort noch betreue, kann man beim Aufruf inzwischen jedes Bit einzeln begrüßen … :(

Ich glaube nicht, daß die .htaccess Schreibrechte braucht, wenn sie alle nötigen Angaben enthält. Eher liegt es daran, daß sich die Seiten-URLs mit der Permalinkstruktur beißen.
Nur der Postname alleine ist schon aus Performancegründen knifflig. Hat die Seite »Kontakt« wirklich die URL-Form kontakt? Ist sie veröffentlicht und sicher nicht als »Privat« markiert?

Kurz vorm Schlafengehen habe ich das Ergebnis dieses Threads noch schnell in einen Artikel gegossen: Magic Quotes entfernen. Da kann man das Plugin(chen) auch herunterladen.

Genau. Und nichts anderes, damit du keine zusätzlichen Fehlerquellen hinzufügst.

Da gehört mindestens dieses rein:

DirectoryIndex index.php
Options +MultiViews -Indexes
AddDefaultCharset utf-8


# WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

Wenn es immer noch nicht geht, dreh mal das Vorzeichen bei [FONT="Courier New"]-Indexes[/FONT] um: [FONT="Courier New"]+Indexes[/FONT]. Wenn du dann eine Verzeichnisansicht bekommst, geht mod_rewrite nicht.

Ist mod_rewrite aktiviert, und wurde die .htaccess richtig geschrieben?

Genauer bitte.

Dann hat sich irgendeine Leerzeile oder ein Leerzeichen eingeschlichen. Wirf einfach das letzte ?> weg; das ist dort ohnehin optional.

Der Fehler wird in der oben genannten Datei multibox.php in Zeile 700 erzeugt. Die änderst du zuerst, dann alle Aufrufe der Funktion im gleichen Verzeichnis. Der Autor freut sich bestimmt, wenn du ihm Bescheid gibst; vielleicht paßt er den Code dann selber an.

Ist doch offensichtlich: In der Multibox wird eine Funktion namens getcount() erstellt und im folding_category_widget auch.

Schlampig programmiert. Benenne die Funktion und all ihre Aufrufe in einem der beiden Codes (ich kenne sie nicht) um, beispielsweise in wxyz_getcount().

Hm, ich vermute, der Haken sitzt in diesem Brett:

Directive	Local Value	Master Value
magic_quotes_gpc	Off	On

Der lokale Wert stimmt zwar, wird aber ignoriert, wenn PHP über CGI läuft. Eine zusätzliche php.ini darfst du auch nicht verwenden … da wird es eng. Entweder probierst du mein oben hingehämmertes Plugin, oder du stellst PHP so um, daß es als Modul läuft (das zumindest erlaubt fast jeder Hoster).