Für’s erste muss ich die Kommentarfunktion etwas limitieren. Es scheint einen definitiven Bug zu geben, der aus einem HTML-Tag innerhalb eines Kommentars, im Backend und somit auch in der Datenbank schöne, wenn auch sinnlose HTML-Codes der jeweiligen Zeichen produziert. Aus den eckigen Klammern werden somit Zeichenfolgen wie „>“ und „<“. Es gab damit wohl mal einen bekannten Fehler, wenn man den überladenen internen Texteditor im Backend deaktiviert hat, angeblich schien dieser behoben, nun ja bei mir ist er wieder da. Ich weiß nur, dass es nicht das Markdown-Plugin ist.

Das ist auch wieder so eine Stelle, wo WordPress viel zu viel versteckt bzw. die normalen Optionen an der Oberfläche kratzen. Es gibt in Movable Type ein einfaches Dialogfeld, bei der auch der letzte Anwender einfach festlegen kann, welche Tags erlaubt sind. Um die gleiche Option in WordPress zu finden, muss man ein Text-File bearbeiten und dutzende Zeilen Text auskommentieren. Spaß.

Fazit: HTML-Tags in Kommentaren sind zwar aktiviert, aber auch irgendwie wieder nicht, da die Tags verschlüsselt werden. Eine Lösung sehe ich so schnell nicht. Extrem nervig.

Feedback: 0 Kommentare

Gestern gab es wieder ein ungeplante Pause der Seite. Eine misslungene WordPress-Installation hat aus der htaccess-Datei Geschnetzeltes gemacht. Merke: existiert bereits eine htaccess-Datei auf dem Server, schreibt WP bei einer Installation drüber und kreiert ein Zeichenchaos ohne Sinn und Verstand. Wer WP installieren möchte, sollte vorher seine htaccess-Datei löschen und anschließen die alten Befehle und die dann von WP erstellte htacess-Datei nachträglich einfügen.

Ich wollte die MT-Installation noch so weit wie möglich schützen und WP für die gleiche Domain, in eine zweite Datenbank installieren. Ich habe neben der cold-heat.de noch eine zweite Domain auf dem gleichen Server und somit auch eine zweite Datenbank. Eine WP-Installation in die separate Domain, läuft problemlos und was ich so gesehen habe gefällt. Dennoch gibt es bestimmte Details, die auch mit WP das gute alte Movable Type verlangen. Beispielsweise erlaubt WP nicht so einfach wie MT, das Führen mehrere Blogs mit nur einer Installation. Da MT und WP Installation auf verschiedenen Ebenen existieren und der Root der Seite zusätzlich noch umgestaltet ist, sollte es möglich sein, beide Systeme laufen zu lassen. WordPress für diesen Blog hier, MT für zwei andere kleine Seiten nebenher. MT dann auch nur zur Pflege der Daten, die ich mit WP nicht direkt aus der MT-Datenbank, sondern aus den von MT-generierte HTML/PHP/XML-Seiten.

Hinzu kommt WP’s noch nicht ganz so transparentes Template-Tag System. Also… bis auf weiteres bleibt hier wohl alles beim alten MT. Nebenbei bereite ich auf der zweiten Domain, unsichtbar für viele, den Wechsel auf WP mitn Sorgfalt vor. Neben dem Erstellen eines eigenes Themes, machen viele Kleinigkeiten, das Ganze aufwendiger als gedacht. Umlaute sind wie immer ein Problem, immer noch werden alle importierten Einträge mit dem 1. Januar 1970 datiert, Einträge werden einfach inhaltlich abgeschnitten, MT’s extendedEntry-Feld scheint komplett ignoriert zu werden. Die Markdown-Formatierung wird ebenfalls nicht wirklich konsequent umgesetzt. Problemlos dagegen sind die URLs, diese lassen sich wie jetzt weiterführen. Erstmal müssen die Kinderkrankheiten der Import-Funktion gelöst werden. Nervig.

Update und Frage

Eine Frage an die Leser, welche sicherlich mehr WordPress Erfahrung haben. Folgende Situation: der Import meiner alten Movable Type Einträge als Textfile zu WordPress führt zu faszinierenden Fehlern. Analytisch wie ich bin, hat es nur knappe 30 Minuten gedauert, um den Grund zu finden, wieso sämtliche importierten Einträge verstümmelt werden.

Sobald ein Umlaut im Zeichensatz eingelesen wird, bricht die Import-Routine sofort ab und springt zum nächsten Eintrag im Export-File. Dieses Export-File besitzt echt Umlaute, keine HTML-Codierungen, also statt „ü“ steht ein wirkliches „ü“ im Text. Damit verträgt sich WordPress, trotz umgestelltem Zeichensatz auf ISO-8859-1 definitiv nicht. Ändere ich die Umlaute in HMTL-Codes, funktioniert der Import lückenlos.

Wie kann ich echte Umlaute fehlerfrei nach WordPress importieren? Eine Umkodierung der Texte in HTML-Umlaute kommt eigentlich nicht in Frage, die Texte sollen in ihrem bisherigen Format bleiben. Jemand ne Lösung?

Wäre die einzige letzte große Hürde, ansonsten sind fast alle Fehler beseitigt.

Feedback: 7 Kommentare