@font-face auf uteles Blog

So ganz allmählich lassen sich Schriftarten sinnvoll einsetzen, die nicht auf dem Rechner des jeweiligen Nutzers installiert sind.  Es gibt viele freie Schriften, die dafür genutzt werden können, jedoch für deutschsprachige Blogs eignen sich nicht alle.

uteles Blog als erste Testecke, siehe Screenshot.

Um einen Überblick über die Schriften zu haben und weil ich eine eigene Auswahl aus Schriften mit Umlauten wollte, habe ich mir eine eigene Seite für Schriften angelegt. Vorsicht, es dauert einen Moment bis die Seite vollständig geladen ist (eher nicht mobil geeignet): http://www.miradlo.info/schriften/

Es gibt Browser – insbesondere manche ältere Browser – die die Schriften nicht darstellen können. Für die Schriftenseite ist das natürlich ungeschickt, aber für den Alltagseinsatz ist es kein Problem, denn mit Angabe von Alternativschriften wird alles korrekt angezeigt, nur eben nicht so hübsch.

@font-face

Die Einbindung der Schriften, die dann vom jeweilien Browser runtergeladen und angezeigt werden, mache ich mit @font-face im CSS. Im Internet Explorer sollte es wohl bereits ab IE 6 klappen, zumindest bei meinen Tests. Aktuelle Browserversionen von Opera, Safari, Chrome usw. kommen gut damit zurecht, der Firefox kann es seit Version 3.5. Der Konqueror mag bei mir nicht, obwohl ich die Einbindung so mache wie auch empfohlen. Unterm Strich sind die Schriften für mich ein zusätzlicher Hingucker, schön wenn es angezeigt wird, aber wenn es halt mal nicht klappt ist es auch nicht schlimm.

Ladezeit für Schriften

Auf einem üblichen Rechner mit DSL fällt es kaum auf und durch Angabe etwaige bereits vorhandener Systemschriften muss auch nicht in jedem Fall die Schrift geholt werden. Der Browser speichert die Schriften, damit ist es schlimmstenfalls beim ersten Aufruf nötig die Schriften zu holen. Für den üblichen Webeinsatz spricht also nichts dagegen es zu nutzen.

Mobile Geräte

uteles Blog brauchte im explizit abgewählten mobile-Theme auf dem iphone im lokalen Netz rund 3 Sekunden, mit ein bissel weniger starkem Zugang ist das dann keine so gute Idee. Sprich beim Einsatz im Alltag wäre es sinnvoll mobile Themes anzubieten, die ohne die speziellen Schriften auskommen.

Freie Schriften und Umlaute

font-squirrel bietet eine große Auswahl und eine Schrift kann mit einem Kit runtergeladen werden, mit dem die Einbindung dann recht einfach klappt, siehe auch: @font-face-Tipp
Leider ist in der Übersicht nicht erkennbar, ob eine Schrift mit Umlauten zurecht kommt, das lässt sich mit dem Testdings probieren, da wird angezeigt, was man eingibt. Es gab einige Schriften, die mir gut gefallen haben, die jedoch deshalb nicht in Frage kommen, weil sie keine Umlaute darstellen. Die ein oder andere, die ich jetzt mit eingebunden habe, kommt mit dem “ß” nicht zurecht. Je nach Einsatzzweck, kann das für Überschriften jedoch trotzdem noch akzeptabel sein. Keine Umlaute sind dagegen ein klares no-go.

Effekte und Probleme

Einige Schriften sind sehr verspielt und damit schwer lesbar, aber für spezielle Überschrifteneffekte oder andere spezielle Ansichten ist das ja durchaus mal akzeptabel. Die ein oder andere Schrift bietet nicht alle Font-Formatierungen an, die CSS an sich kennt. Teils übernimmt dann der Browser die Darstellung, das klappt nicht überall so hübsch, wie bei Schriften, die selbst einen fetten oder kursiven Stil anbieten.

Alles wird gut

Noch ist nicht alles gut, ein Browser ist nach wie vor keine Textverarbeitung mit allen Möglichkeiten von Schriften. Aber aus meiner Sicht ist es ein großer Schritt weg von Webseiten, die nur mit den paar üblichen Schriften auskommen müssen, die bislang im Web einigermaßen übergreifend unterstützt wurden. Was mir gut gefällt ist das problemlose Fallback auf Alternativen und dass eine Schrift nicht jedesmal runtergeladen werden muss. Ein klarer Vorteil für Stammleser einer Seite. Wenn sich die Schriften verbreiten, wird es auch seltener, dass eine Schrift noch nicht installiert ist.

Es ist noch nicht alles gut, es braucht noch intensives Testen im Umgang damit, aber ich bin fürs Erste völlig zufrieden, dass es jetzt einen Weg gibt, der ohne Flash, Bilder oder sonstige Krücken auskommt um eine besondere Schrift anzubieten.

Wann genau es passierte, weiß ich im Nachhinein nicht mehr, aber plötzlich fehlte die Transparenz meiner Kontrollleiste (Ubuntu und KDE 4). Ich suchte in den Systemeinstellungen vergeblich, weder in den allgemeinen Einstellungen noch in denen des genutzten AIR-Themes änderte sich das Problem beim Ausprobieren.

Miniprogramme in der Kontrollleiste

Erstmal ließ ich es, und vermutete es wäre nach dem nächsten Booten weg. Das klappte jedoch nicht, also suchte ich nochmals unter anderem in den Einstellungen der Miniprogramme, aber auch da änderte sich zunächst nichts. Eher zufällig fand ich die Lösung, beim Sperren der Miniprogramme hatte sich wohl was verschluckt. Die Lösung war einfach:

• Miniprogramme entsperren
• Transparenz ist wieder das
• Miniprogramme wieder sperren
• Transparenz bleibt da

Manche Lösungen sind sehr einfach!

Nach und nach kamen Logo, Texte und weitere Infos. Ich schob deshalb so ziemlich alles was ich geplant hatte und kümmerte mich um die Seite: nein-zu-klein-venedig.de

Das Ganze ist mit Serendipity aufgebaut, ist also ein Blog für die jeweiligen Neuigkeiten und hat außerdem statische Seiten zu einigen Hauptthemenpunkten:

• Offener Brief zum KKH
• Stimmen zum KKH
• Wir sind viele
• Warum wir dagegen sind
• Werden Sie aktiv!

Ein bisschen mehr Zeit hätte nicht geschadet, doch da der Bürgerentscheid bereits am 21. März stattfindet, war es sehr dringend so schnell wie möglich die wichtigsten Infos und Grundlagen online zu haben. Worum es geht steht auf der Seite und auch wir haben bereits privat darüber gebloggt:

• Quorum erklärt auf uteles Blog
• uteles Blog
• Guggat emol Blog
• Piraten zum Konzerthaus

Schön, wenn es bei solch zeitkritischen Projekten nur ein bisschen was schief geht. Hier fing es mit der Umleitung von Strato aus an, da klappte trotz oder gerade wegen DNS-Umleitung nicht alles auf Anhieb.

Aber Serendipity war überwiegend gut zu handhaben und ließ sich meist recht problemlos so anpassen, wie ich das wollte. Einfacher wurde das natürlich auch mit einem bekannten schon mehrfach genutzten Grund-Theme und vielen Einstellungen, die ich mehrfach schon genutzt und angewendet hatte.

Beim nächsten Mal installierte ich erstmals ernsthaft lokal, mit den Daten, die dann live auch genutzt werden sollen. Ich nahm die fortgeschrittene Installation, um auch gleich mal genauer zu sehen, was sich so einstellen lässt, da S9y für mich ja noch neu ist.

Schritt für Schritt änderte ich die Rechte, um auch da gleich zu testen, ob Serendipity da alle Probleme anzeigt. Bis zum Ende der Installation und dem Hinweis alles habe geklappt lief es problemlos.

• Adminbereich eines Redakteurs bei S9y

Doch dann…

Erster Aufruf des neuen Blogs

Ups, tja nur weil da keine Warnungen waren, war es wohl doch übertrieben direkt Umlaute zu nutzen. Ein abgeschnittener Blogtitel und ein ebenso beschnittener Untertitel sehen schon mal nicht so hübsch aus.

Auf der Seite gibt’s ein Login, nette Idee, mal sehen was sich da versteckt, denn das Forum empfiehlt bei Umlautproblemen den Titel erneut zu setzen.

Huch, “/serendipity/admin die Seite kann nicht gefunden werden“, hm, das ist ein bisschen unpraktisch, denn alle Tipps basieren darauf, erstmal im Admin irgendwas anzupassen. Ein bisschen recherchieren bringt wenig, denn der Admin-Benutzername war schon frei von Umlauten und auch bei erneutem Setzen mittels einer extra erstellten recover.php ändert sich nichts.

Also gut, dann nochmal in die Schritt-für-Schritt-Doku schauen und da mal genauer lesen und prüfen:

“…You can do that by calling your URL http://yourdomain.com/serendipity/serendipity_admin.php” Hm, wie jetzt serendipity_admin.php? Nun gut, die hätte den Vorzug, dass sie existiert, denn mir war schon klar, dass /admin nicht klappen konnte, weil es nicht vorhanden war, allerdings wusste ich ja nicht, ob da nicht beim Installieren versehentlich was nicht angelegt wurde.

Juhu, ein Erfolg: serendipity_admin.php lässt sich aufrufen und sieht aus wie eine Adminoberfläche, wenn auch ohne jedwedes Styling, das war beim ersten Testen noch anders… Na denn, weiter geht’s…

Admin ohne Styles

Keine Ahnung was ich falsch gemacht habe, aber mein Adminbereich lässt sich nicht nur nicht per Link aufrufen, er findet auch die CSS-Dateien nicht… Klar, gut ist, dass er trotzdem nutzbar ist, aber so ganz ohne Styles ist es schon sehr spartanisch.

Die nächste Installation

Bei einer weiteren Installation nahm ich nicht die fortgeschrittene, sondern die einfache Variante, da ich vermutete, dass irgendeine Einstellung schuld war, am Problem der fehlenden Styles. Stimmte auch, denn mit der einfachen Variante hatte der Admin Styles und auch das Login klappte wie gewünschte über die Blog-Oberfläche.

Allerdings auch hier gab’s wieder das Umlautproblem, trotz angegebener Sprache Deutsch fraß s9y alles ab einem Umlaut. In den Einstellungen läßt sich das zwar wieder ändern, aber es stört schon.

Einstellungen

Ich würde ja erwarten, dass ein bereits gespeichertes Passwort und eingeloggt sein ausreicht, aber das stimmt so nicht. Bei den eigenen Einstellungen läßt sich auch das Passwort ändern, falls man etwas anderes ändern will, muss trotzdem das Passwort zweimal angegeben werden, sonst beschließt Serendipity, dass das keine korrekte Eingabe war, löscht alles Eingegebene und beschwert sich übers fehlende Passwort.

Ignoriert wird zunächst alles ab einem Umlaut und auch die Sprachangabe deutsch führt nicht dazu, dass das bereits eingestellt ist, sondern muss in den persönlichen Einstellungen wiederholt werden.

Administration | Konfiguration | Generelle Einstellungen

Na bravo, hier wollte ich den – schon gewohnt gefressenen – Blogtitel mit Umlauten einstellen.

->  Seite wählen -> Blogtitel ändern -> Speichern -> alle Umlaute kaputt und Titel mit kaputten Umlauten

nächster Versuch:
->  Seite wählen -> Blogtitel ändern -> Zeichensatz ändern -> Speichern -> alle Umlaute doppelt kaputt und Titel ebenfalls mit kaputten Umlauten

ein weitererVersuch:
->  Seite wählen -> Blogtitel ändern -> Zeichensatz ändern wieder UTF8 -> Speichern -> alle Umlaute weiter kaputt und Titel wieder abgeschnitten

noch ein Versuch:
->  Seite wählen -> Blogtitel ändern -> Zeichensatz nicht ändern -> Speichern -> alle Umlaute weiter kaputt aber Titel stimmt

weiter geht’s:
-> Autorennamen wieder reparieren  -> Kategorien mit Umlauten wieder reparieren -> neuen Beitrag schreiben -> alte Beiträge reparieren

Taraa, tröööt, jubelnde Webentwicklerin und überhaupt…

Ja, dieses Mal klappt es und scheint jetzt ok. Nochmal testen, ob sich der Blogtitel jetzt nochmal ändern lässt und sich alles auflöst:

Nein, dieses Mal bleibt alles soweit ok.

Was lerne ich daraus?

Zunächst einmal, dass es wohl nur mit der einfachen Installation sinnvoll ist. Wie ich inzwischen weiß, wird bei der fortgeschrittenen Installation nichts angegeben, was sich nicht nachher noch ändern ließe. Nachträgliches Ändern hat den Vorzug, dass ich immerhin weiß an welcher Ecke ich was eingestellt habe, was S9y nicht mag.

Beim vierten oder fünften  Versuch stellte ich während des Testens dann auch fest, dass es einen Zusammenhang zwischen einem Adminbereich ohne Styles und einigen Themes besteht, die plötzlich auch keine Styles mehr hatten.

Admin ohne Design und manche Themes funktionieren nicht

Also ging ich mal an die Stellen, die mir verdächtig erschienen und verglich Einstellung für Einstellung der Installationen. Pfade und so waren in Ordnung, aber da gab’s einen Unterschied, der mir schon wahrscheinlich erschien und der auch reproduzierbar den Fehler zeigt:

• URL-Formung hat drei Alternativen
  • Disable URL Rewriting
  • Use Apache errorhandling
  • Use Apache mod_rewrite

Die Einstellung bei einfacher Installation ist Disable, ich hatte wegen etwaiger Pfade und hübscher URLs mod_rewrite eingestellt, vielleicht würde das auf dem Server sogar klappen, denn lokal gibt es meist Schwierigkeiten beim Umschreiben. Jedenfalls kann ich auch bei anderen Installationen den Fehler erzeugen, wenn ich auf mod_rewrite umschalte und das Problem ist weg, wenn ich es anlasse.

Benutzergruppen

Wenn solch eine harmlos aussehende Drop-Down-Box solche Auswirkungen hat, dann fällt mir direkt ein, dass es doch gut wäre die Benutzerrechte einzuschränken. Hier war ich dann sehr angetan, denn wie das Bild zeigt, es gibt eine Rolle, die wirklich nur anzeigt, was jemand zum Schreiben braucht und nicht mit unzähligen Konfigurationsmöglichkeiten überfordert. Einstellbar einfach beim Benutzer anlegen mittels zuweisen der Rolle Redakteur z.B.

Als nächstes gehe ich dann morgen mal suchen, wie ich dem WYSIWYG-Editor abgewöhne die Option der Schriftartänderung anzuzeigen…

Ich habe heute in der Linkliste auf zwei Beiträge zu flexiblen Layouts hingewiesen.

• Flexible Layouts haben ihre Vorzüge, trotz Seitenzoom der Browser
• Ein weiterer Artikel meint es wäre gut nicht über die flexiblen Layouts zu streiten, sondern sie schlicht als Variante zu sehen.
• In obigem Artikel wird auf mehrere Videos zu YAML verlinkt, die gibt es auch als eine Präsentation, direkt bei Galileo

onli kommentierte daraufhin recht ausführlich. Beim Schreiben meiner Antwort fiel mir auf, dass es ein bisschen lang wird, deshalb jetzt als eigenen Artikel. onli schrieb:

“Ich bin über die Diskussionen über flexible Layouts immer wieder überrascht. Denn eigentlich führt die Diskussion am Thema vorbei. Das eigentliche Problem dürfte sein, dass CSS in derzeitiger Form ungeeignet ist für das, was ein dynamisches Layout erfordert. Man kann viele Dinge einfach nicht zuverlässig erreichen, die nötig wären: Elementen eine dynamische Größe zuordnen, aber mehreren Elementen immer die gleiche. Nachbarbeziehungen, die über ein float hinausgehen usw usf. Sicher, ich bin kein Profi, aber es scheint mir so, als sei die Ursache der Diskussion dergestalt, dass einige notwendige Layoutanforderungen mit dynamischen Layouts nicht oder nur schwer umsetzbar sind. Die Antwort sind dann aber nicht pixelgenaue Layouts, sondern Verbesserungen am Handwerkszeug.

Ich werde mir bei Gelegenheit die verlinkten Videos anschauen, vielleicht beinhalten diese ja Konzepte, die meine obige Argumentation ad absurdum führt, weil damit dann alles so umsetzbar ist wie ich es mir vorstelle. “

Ich habe ja schon mal recht ausführlich über flexible Layouts geschrieben, ein paar Bildbeispiele wie sich flexible Layouts auswirken habe ich anlässlich eines Wechsels des Hintergrunds mal beschrieben.

Meines Erachtens sind flexible Layouts nicht schwierig, wenn man von vorne herein flexibel denkt. Das Hauptproblem ist, dass ein Design auf Papier in fester Größe entworfen wird und dann eben häufig auch nicht mehr so einfach flexibel umgesetzt werden kann.

Design bedeutet häufig, es ist ein Entwurf eines Designers, der gestern einen Flyer in A5 entwarf, morgen ein Plakat in A0 und deshalb heute beim Entwurf einer Webseite in 1024*768 denkt. Solche Entwürfe können sehr schwierig umzusetzen sein und sind oft auch nicht flexibel lösbar.

Für mich ist jedoch die Grundlage des Webs, dass ich eben nicht weiß, welches System, welche Auflösung mein Nutzer gerade verwendet, dass ich nicht weiß, ob er Schriftgrößen ändert und und und.

Ich versuche deshalb Layouts von vorne herein so zu erstellen, dass es nicht wichtig ist,welche Voraussetzungen gegeben sind. Leider ist die Tendenz jedoch nach wie vor, das Optimieren auf eine Auflösung und nicht das Erstellen eines anpassungsfähigen Layouts.

Yaml von Dirk Jesse auf das sich die Videos beziehen ist ein Framework, was den Webautoren schon vieles abnimmt. Enthalten sind in Yaml bereits Definitionen um Browserfehler zu umgehen. Es gibt z.B. auch WordPress-Yaml-Themes, die sich recht einfach anpassen lassen, weil vieles eben bereits berücksichtigt wurde. Der Nachteil ist offensichtlich, ein Framework muss alles berücksichtigen und ist deshalb schon ein dickeres Ding.

Ich selbst nutze natürlich auch Vorlagen und fange nicht bei jedem Layout bei 0 an, aber ich nutze kein Framework. Für meine eigen Layouts kenne ich mittlerweile den größten Teil der möglichen Probleme und ihre Lösung.

Im Gegensatz zu fast allen Designern entwerfe ich Layouts nicht auf Papier, auch nicht in einem Bildbearbeitungsprogramm, sondern wirklich live auf einer Testseite. Ich sehe so viel schneller, welche Idee problematisch werden könnte und überlege mir Alternativen, noch bevor das erste Layout fertig ist.

Ist CSS ungeeignet für Layouts?

onli überlegt, ob CSS nicht einfach ungeeignet ist und sich das Handwerkszeug verbessern müsste. Nein, das glaube ich nicht. Das Hauptproblem bei CSS-Layouts ohne Tabellen und in modernem Design ist nicht das CSS. Die Realisierung für standardkonforme Browser wie Firefox, Opera, Safari usw. die ist nicht so schwierig. Es kommt selten vor, dass es spezielle Anpassungen braucht, um ein Layout für diese Browser wie gewünscht zu realisieren. Das eigentliche Problem sind die alten Versionen der Internet Explorer und leider in manchen Fällen sogar der aktuelle IE8.

Manches ist irgendwann bekannt und lässt sich recht schnell auch für die IEs anpassen. Aber immer mal wieder passiert es, dass wegen eines IE-Fehlers Stunden drauf gehen, um eine Lösung zu finden. Microsoft möchte, dass jeder ihrer Browser auch die Seiten korrekt darstellt, die für eine fehlerhafte Vorgängerversion optimiert wurden. Dabei entstehen immer wieder Probleme und noch hat jede IE-Version teils haarsträubende Fehler. Das kommt zwar auch bei anderen Browsern mal vor, nur falls Firefox 2.14 etwas falsch darstellt, dann ist es das heute beim Stand von Firefox 3 nicht so schlimm, denn nur wenige nutzen aktuell diese eine Version, wenn ein Layout trotzdem lesbar bleibt, käme kaum ein Webautor auf die Idee, wegen dieser einen Version etwas zu ändern. Beim IE hält eine Version “ewig” der immer noch stark verbreitete IE6 ist aus dem Jahr 2001, da gab es noch gar keinen Firefox…

Was ist die Lösung für dynamische Layouts?

Die eine ultimative Lösung gibt es nicht. Denn ein modernes Layout mit dem Anspruch das zu zeigen, was heute Stand der Technik ist, das passt zu modernen Browsern. Der IE6 kommt aus einer Zeit als ganz andere Designs entworfen wurden, für die Layouts seiner Zeit war er auch kein Traum, aber noch akzeptabel. Für heutige Layouts ist er einfach ungeeignet und das führt dazu, dass es sehr aufwändig wird, wenn ein besonderes, aktuelles Design umgesetzt werden soll.

Meine Layouts, die nicht darauf aufbauen, dass sie pixelgenaue Linienführungen haben, lassen sich schon deshalb viel einfacher umsetzen. Außerdem habe ich nicht den Anspruch, dass ein Layout in jedem Browser absolut identisch aussieht. Für mich genügt es, wenn alles lesbar ist und die Optik nicht völlig verschoben. Wenn der IE6 das “miradlo bloggt”-Bildle nicht genauso darstellt wie alle anderen, dann ist mir das egal, es ist nicht so hübsch, aber auch nicht kaputt, ich höre an dieser Stelle auf und bastele dann nicht noch Stunden weiter, um mit Tricks und Schlichen eine identische Optik zu bekommen.

Wozu auch? Denn mein sich anpassendes Layout sieht je nach Auflösung sowieso immer ein bisschen anders aus. Für mich ist es wichtig, dass Besucher in etwa ein Design bekommen, was aktuell ist, dass alles lesbar und bedienbar ist und möglichst wenig Scrollbalken hat. Dieses Ziel lässt sich mit CSS und flexiblen Layouts recht gut erreichen.

Manches lässt sich nicht dynamisch und zuverlässig erreichen?

onli fragt sich, ob nicht einfach was fehlt um zuverlässig z.B. Elementen eine dynamische Größe zuzuordnen, aber mehreren Elementen dabei immer die gleiche.

Auch das fällt für mich unter Browserprobleme. Es ist mit standardkonformen Browsern durchaus möglich solche Anforderungen zu erfüllen. Die Grenze dessen ist vor allem der IE6. Für mich kein Grund das nicht zu nutzen, denn ich mag die speziellen Stylesheets die per Conditional Comments z.B. nur genau dem IE6 sagen, was er zu tun hat. Damit bekommt der IE6 dann eben etwas was nicht so flexibel ist, aber für einen Browser der so alt ist, kann ich damit leben.

Falsch finde ich etwas nicht zu nutzen, nur weil der IE6 es nicht kann. Ebenso überflüssig finde ich es Tage in eine Lösung für den IE6 zu investieren, nur um irgendwas auch da noch hinzubekommen. Allerdings halte ich auch nichts davon, “das Kind mit dem Bad auszuschütten” und dem IE6 einfach gar kein Layout und Warnhinweise zu geben. Die Nutzer eines IE6 nehmen ihn entweder, weil er ihnen am Arbeitsplatz vorgeschrieben wird oder weil sie nicht in der Lage oder bereit sind einen anderen Browser zu installieren.

Insgesamt meine ich geht es um genau zwei Punkte:

• Das Web ist nicht aus Papier, ein Layout sollte daher nicht für “welche Auflösung auch immer” optimiert werden
• Eine Webseite muss nicht in jeder Umgebung identisch aussehen

Berücksichtigt man das, dann gibt es kein Problem mit flexiblen Layouts, so einfach ist das.

• Soll ich die Kategorien weiter pflegen?
• Wieso ist Navigation und Funktion miteinander in der gleichen Liste?
• Welches Layout sollte ich nun nutzen?
• Gefällt das alte Design den Kunden mehr als das Neue?

Solche Gedanken hat man ja immer, wenn man eine Webseite neu gestaltet.
Und deshalb bin ich auf folgende Idee gekommen:

Lass doch das Design vom Kunden auswählen

In bestimmten Rahmen kann man sich erlauben zwei- oder drei Designs anzubieten.
Wenn man auf die Seite kommt, erscheint das aktuelle Design.
Wenn man dann ein anderes Design, mit z.B. mehr Funkionalität, haben will, kann man dies auswählen.
Das Design wird gewechselt und der Kunde hat andere Möglichkeiten als zuvor.

Ja aber, dann muss man ja Kundendaten speichern!

Wenn man will, dass der Kunde beim nächsten Mal das gleiche Design vorfindet, muss man mindestens einen Cookie auf der Kundenmaschine abspeichern.
Oder noch komplizierter: Der Kunde muss sich am System anmelden.
Das wäre bei einem normalen Blog oder einer normalen Webseite wirklich ein Overkill.
Ich will einfach nur die Wahlmöglichkeit bereitstellen. Wenn ein Kunde dann das Design wechseln will, soll er hierzu eine Möglichkeit erhalten.
Falls der Kunde Cookies zulässt, kann man immer noch über eine permanente Umstellung nachdenken.

Ist das nicht eine halbherzige Idee?

Ich denke nicht. Es lässt dem Kunden die Freiheit, zwischen verschiedenen Designs auszuwählen.
Vielleicht ist der Kunde heute positiv eingestellt und will eine schöne, leuchtende Darstellung?
Vielleicht will er heute nur Text, da er schnell was suchen muss?
Wenn man sich den Mehraufwand leisten kann, dann wäre es vermutlich eine gute Idee mehr als ein Design zur Verfügung zu haben.

ohne CSS also nacktes HTML

Wie was kein Design? Warum, was ist los?

CSS Naked Day

Einen Tag lang sollen mit der Aktion keine Styles anzuzeigen, Webstandards gefördert werden. Denn ohne Styles, Bilder und Design sieht man den Seitenaufbau genauer. Manche Seiten nutzen den internationalen “ganzen Tag” das bedeutet das CSS bleibt für 48 Stunden aus, damit es weltweit alle sehen können, dann dauert der 9. April halt nicht nur 24 Stunden.

Wer sich an Webstandards hält nutzt valides und semantisches Markup in (X)HTML. Die Inhalte sind sinnvoll strukturiert, mit Überschriften, Absätzen, Listen usw. An diese Regeln sollte man sich natürlich immer halten, die Aktion ist nur ein Hinweis um darauf aufmerksam zu machen.

Wem helfen Webstandards?

Unterm Strich allen, denn eine sinnvolle Struktur und korrektes Markup sind ein grundsätzlicher Vorteil. Ansonsten nützen Webstandards:

• Suchmaschinen die sowieso kein Design sehen
• Tastaturnutzern siehe auch Navigieren mit der Tastatur
  • manche mögen keine Maus benutzen
  • manche können keine Maus benutzen
  • …
• es gibt Besucher mit sehr langsamer Internetverbindung, die schalten Styles und Bilder grundsätzlich ab
• Screenreader haben nichts von Styles (werden von Blinden genutzt)
• Menschen die schlecht sehen oder irgendeine Fehlsichtigkeit haben schauen sich Webseiten ohne oder mit speziell auf sie zugeschnittenen Stylesheets an
• Standards machen es leichter unabhängig von den genutzten Voraussetzungen gut funktionierende Webseiten zu erstellen
• überarbeitete oder neue öffentliche Seiten müssen sich an Webstandards und einen gewissen Stand der Barrierefreiheit halten
• Webstandards sind die Grundlage, um barrierefreie Seiten zu erstellen (nein, nicht jede standardkonforme Seite ist deshalb barrierefrei)
• für Stammleser die einen Feed ohne Design bevorzugen ist die Struktur einer gut aufgebauten Seite besser zu verstehen
• …

Es gibt viele Gründe, die dafür sprechen, es spricht nichts Nachvollziehbares dagegen (Webseitenerstellungsprogramm XY kann das nicht, ist für mich kein Argument). Trotzdem gibt es noch viel zuwenige Seiten, die sich an Webstandards halten.

Die meisten Redaktionssysteme, CMS (Content Management Systeme) und somit auch die bekannten Blogsysteme können mit Webstandards umgehen. Manche besser, manche schlechter, häufig entstehen die Probleme jedoch erst wenn die Autoren etwas eingeben oder bei Themes, die sich nicht daran halten.

Der CSS-Naked-Day ist eine gute Gelegenheit auch das eigene Blog, die eigenen Seiten mal kritisch zu betrachten. Wer das nicht gleich öffentlich tun möchte, dem kann ich für Firefox die Webdeveloper Toolbar empfehlen, da lassen sich alle Styles mal eben zum Nachsehen deaktivieren. Sowohl auf eigenen, wie auf fremden Seiten ab und zu mal ganz spannend… Für Seamonkey gibt es das auch, Opera bringt ähnliches grundsätzlich mit, für den IE (zumindest für Internet Explorer 7 und gibt es eine ähnliche Toolbar.

Wie lässt sich das für Besucher anzeigen?

Ich habe für CSS-Naked-Day das WP-Plugin genutzt, weil es einfach bequem ist und für einen Tag wollte ich jetzt nicht selbst basteln. Allerdings geht das Plugin soweit ich gesehen habe, dann eben nur von den 24 Stunden des 9. Aprils Ortszeit in Deutschland aus. Wer es lieber selbst ins Theme einbauen mag, findet die Anleitung dazu bei Frank. Eine Liste einiger teilnehmender Seiten gibts Dustin Diaz, in deutscher Version unter nakedcss.de. Auf diesen Seiten gibt es auch Hinweise, wie sich das automatisiert bei anderen Systemen realisieren lässt.

Ganz ohne Automatisierung bietet unser Styleswitcher ganzjährig auch eine Naked-Version. Viel Spaß beim Surfen heute, ich hoffe es wird auch hierzulande einige teilnehmende Seiten geben, schaut doch z.B. auch bei Dieter vorbei.

Je nach Blog fand ich die Idee, Links zu markieren, ob sie intern sind oder nach außen führen gut. Eine weitere nette, zusätzliche Möglichkeit, die es erleichtern kann, sofort einzuschätzen wohin ein Link führt. Ich testete das Link Indication Plugin, wie immer erst lokal, es klappte alles prima, es lief und zeigte im ein oder anderen Blog, wohin die Links führen, prima!

Zitate vorführen

Ein, zwei Tage später wollte ich jemand zeigen, wie die Zitate funktionieren, dass ein ganzer Kommentar zitiert wird, wenn man auf den Link klickt, bzw. eben nur Teile davon, wenn man den gewünschten Text markiert. Tja, wollte! Denn das klappte nicht, da kam kein Zitat, weder direkt, noch nach Markieren eines Textteils. Och nö, nicht schon wieder!

Inzwischen testete ich mal genauer. Zunächst suchte ich nach anderen Plugins, die sich auf die Kommentare beziehen, aber da gab es keinen Fehler. Daher suchte ich dann nach allem, was geändert war, seit ich das letzte Mal Quote Comments getestet hatte und fand dabei was nicht klappt:

Link Indication und Quote Comments vertragen sich nicht

Läuft nur eins von beiden ist alles gut, es tut was es soll. Sind beide aktiviert, dann läuft Link Indication weiterhin, aber Quote Comments zitiert nichts mehr. Ich weiß nicht, was sich da verhakt. Ich kann auch nicht einschätzen, welches der beiden “schuld ist” oder ob es einfach ein unglücklicher Zufall ist. Ich lasse jetzt mal verschiedene Kombinationen stehen und schreibe die Autoren an, vielleicht hat ja einer der beiden eine Idee. Sonst muss ich halt in Zukunft je nach Blog entscheiden, was wichtiger ist.

Eckpunkte

• alle getesten Blogs laufen mit WordPress 2.7
• am Theme liegt’s nicht auch mit dem Default-Theme läuft es nicht
• aktivieren und deaktivieren anderer Plugins hat keinen Einfluss auf das Verhalten der Zitate

Blogs und Varianten der Plugins

Aktiviert ist/sind:

• hier im Blog nur Quote Comments
  • und es funktioniert
• in Rolands Guggat emol Blog nur Link Indication
  • und es funktioniert
• in uteles Blog Link Indication und  Quote Comments [aktualisiert: 13.2. da mir dort die Zitate wichtig sind habe ich jetzt auch hier Link Indication deaktiviert]
  • damit läuft Link Indication weiterhin
  • Quote Comments zitiert nicht mehr

Jetzt bin ich mal gespannt, ob einer der Autoren eine Idee hat.  Ärgerlich finde ich einmal mehr, dass tatsächlich jede kleine Änderung sich an ganz anderer Stelle auswirken kann. In Kombination mit automatischen Aktualisierungen nicht nur von Plugins, sondern demnächst auch von WordPress selbst ist das ziemlich ungeschickt. Denn das automatische Aktualisieren führt noch leichter dazu, dass mal eben per Knopfdruck etwas geändert wird, mit dem Risiko, dass an anderer Stelle plötzlich irgendwas nicht mehr funktioniert.

So schön die vielen Möglichkeiten mit Plugins sind, wer Wert auf ein stabiles und funktionierendes System legt muss schon sehr intensiv testen, um sich das zu erhalten. Ich wünsche mir eine Sicherheitsschicht mit definierten Schnittstellen für Plugins, so dass die sich nicht in die Quere kommen können. Nö, mich interessiert dabei nicht, dass das so nicht machbar ist…

Wir nutzen inzwischen ein ganzes Basisprojekt, in dem die relevanten Templates und Strukturen bereits enthalten sind. Schritt für Schritt geht es um folgende Vorlagen:

CSS-Vorlage

Wohl die meisten, die häufiger ein neues Projekt beginnen, nutzen ein CSS-Template. Ich ändere diese Vorlagen immer mal wieder, aber im Grunde gehe ich prinzipiell immer von derselben Struktur aus:

• basis.css in dieser Datei definiere ich Grundelemente, wie z.B. Überschriften, Absätze usw.
• layout.css diese Datei ist fürs eigentliche Layout zuständig und enthält die Definitionen, der div-Container, wie sie bei uns möglichst immer eingesetzt werden. Ausnahmen gibt es nur, wenn es gar nicht anders geht, ansonsten nutzen wir:
• spezielles.css alle speziellen Definitionen stehen hier:
  • seien es genutzte Konstrukte, die stabil und browserübergreifend Bilder einbinden
  • die ein oder andere zusätzliche Klasse
  • ein spezieller zusätzlicher Container
• etwaige sonstige Stylesheets, z.B. für den Druck, zur Anpassung der Internet Explorer per Conditional Comments, oder was sonst eventuell nötig ist

In den Vorlagen dieser Dateien stehen Grundwerte, die so meist benutzt werden. Verändert wird das Layout, individuell sind Logo und Hintergrundbilder, angepasst werden noch Farben und einige weitere Kleinigkeiten pro Projekt.

Viel mehr ändert sich jedoch nur selten, denn der Hauptunterschied liegt ja im Layout des jeweiligen Projekts. Grundelemente werden immer benötigt und Farben eben ans Layout angepasst.

Der Vorzug einer Vorlage ist, dass ich es dort sofort nachziehen kann, wenn mir bei einem Projekt etwas spezielles auffällt, oder ich mal wieder was vereinfachen kann.

HTML-Vorlage

Eine Vorlage der Grundstruktur bieten natürlich auch bereits die meisten Editoren, z.B. der bei uns genutzte Quanta. Wir setzen jedoch so gut wie nie ausschließlich HTML ein. Meist gibt es entweder noch einige eigene Entwicklungen in PHP oder eine Software wird darüberhinaus eingesetzt.

Software-Vorlage ::: z.B. WordPress-Blog

Je nachdem, was man häufig nutzt, bei uns zur Zeit WordPress, ist es sinnvoll sich auch da die relevanten eigenen Anpassungen als Vorlage zu nutzen.

Es gibt eine Reihe von Plugins, die wir üblicherweise nutzen, da sich die jedoch sehr schnell ändern, packe ich ins Basisprojekt nicht alle relevanten Dateien. Keinesfalls gibt es dort das gesamte WordPress, sondern die jeweils aktuelle Version wird genutzt.

Extra sichere ich jeweils die in einem Plugin geänderten und angepassten Dateien, nur selten unterscheiden die sich pro Blog, meist sind diese Anpassungen für alle Blogs identisch.

Als Vorlage gibt es jedoch das Template, von dem ich üblicherweise ausgehe. Dieses habe ich mir aus der leeren und gut kommentierten Vorlage von texto.de erstellt. Bei gravierenden Änderungen in WordPress schaue ich mir die dort jeweils aktuelle Vorlage nochmal an und passe mein Template an. Das jeweilige Theme ist abhängig vom jeweiligen Blog, bzw. Webauftritt mit WordPress, die Grundstrukturen sind jedoch überwiegend wieder gleich.

PHP-Vorlage

Manches läuft bei uns auch in Projekten, die keine weitere Software einsetzen mittels PHP. Es ist einfach nicht sinnvoll reines HTML zu nutzen, da vieles automatisiert einfach besser geht. Jedes Projekt benötigt eine Navigation, automatisiert wird meist irgendwo ein Datum genutzt, Metadaten die nicht projektspezifisch sind werden für alle Seiten gleich eingebunden, es gibt ein Kontaktformular…

Diese Grundlagen, die immer dieselben sind, stehen in unserer PHP-Vorlage. Sobald wir Neues nutzen wird das auch hier nachgezogen, beispielsweise um Spam zu vermeiden, ändert sich regelmäßig etwas.

…noch eine Vorlage?

Ja, eine habe ich noch Nein, es ist nicht direkt “eine Vorlage” hilft aber trotzdem ungemein:

Layoutbildervorlage

Sinnvoll benannte Layoutbilder bilden zunächst einmal das Gerüst, mit dem bereits ein erstes Design möglich ist. Später können die Bilder einfach reinkopiert werden, unter demselben Namen, damit spart man sich das Anpassen der Pfade. Klappt auch für Favicons, Bilder auf Fehlerseiten und ähnliches, was man häufig nutzt.

Falls ich was vergessen hab, oder ihr noch einen praktischen Tipp habt, gerne…

Einige Funktionen und Plugins habe ich inzwischen beim ein oder anderen Blog hinzugefügt, manches Plugin fordert doch noch einige Anpassungen, bis es genau das tut, was ich wollte.

Im Großen und Ganzen hat nach ein bisschen Überredungskunst das meiste soweit geklappt. Mit dem Update-Hinweis hatte ich kein größeres Problem, der ließ sich leicht abstellen. Aber leider bleibt ein dickes Problem:

Wp 2.7 Adminbereich im Dashboard nur Menü, kein Inhalt

Ja, alles andere geht, ich kann hier schreiben, Kommentare funktionieren, Plugins de- und aktivieren geht usw.

Aber das Dashboard selbst, hat das Menü und die Kopfzeile und sonst nichts. Bei anderen Blogs mit denselben Dateien und ähnlichem Aktualsierungsverlauf geht es, hier geht es nicht.

Das Problem begann mit irgendeiner 2.6x glaube ich:

Mit 2.6 konnte ich noch den Link ändern, dann erschien der Inhalt. Klar, das war etwas lästig, aber möglich.

Seit 2.7 bleibt das Dashboard leer, da ist das Menü und sonst nichts. Bei anderen Installationen klappt alles, nur hier nicht

Gemeldet habe ich das inzwischen dickere Problem hier:

#8260 (A false linking to dashboard in the sidebar after upgrade) – WordPress Trac – Trac

Nach vergeblicher Suche einer Lösung habe ich mal in den relevanten Threads beim deutschen Wordpress-Forum um beim Supportforum von WordPress nachgefragt.

Vergebliche Lösungsversuche

Übrigens, ja ich habe alles versucht, was mir einfiel. Das Problem besteht sowohl bei der lokalen Installation als auch bei der Liveversion. Mir war es lokal nicht aufgefallen, da lokal das Dashboard ja nicht so wichtig ist, beim Testen nutze ich alle anderen Administrationsseiten stärker, als jetzt diese. Ursprünglich hatte ich gehofft, das Linkproblem wäre bei einer neuen Version dann weg. Dass es jetzt erst noch da war, aber kein Inhalt mehr ist lästig.

Nach dem Umbenennen aller leeren index.php-Dateien in index.html war tatsächlich das Linkproblem weg, das ist schön. Ich habe jedoch immernoch keinen Inhalt im Dashboard.

Ich habe Plugins de- und aktiviert, gelöscht neu hochgespielt.

Ich habe alle, aus meiner Sicht eventuell in Frage kommenden WP-Dateien nochmal geprüft, ob sie wirklich so sind, wie auf den Blogs, auf denen alles klappt.

Ich mit dem Adminize-Plugin gespielt, nicht nur mit de- und aktivieren, sondern auch mit den Menüeinstellungen, aber es half alles nichts.

Egal ob:

• mit oder ohne Plugins
• mehrfaches Hochspielen
• Themes und Einstellungen ändern
• Logfiles nach relevanten Einträgen absuchen
• …

die Seite bleibt leer.

Falls irgendjemand noch eine Idee hat, ich würde mich sehr freuen…

Bei Prinzzess gab es kürzlich ein Problem, als die Seiten zwar am Anfang brav:

<meta name=”robots” content=”index,follow” />

auslieferten, jedoch weiter unten im Header das Ganze überschrieben wurde:

<meta name=”robots” content=”noindex,nofollow” />

Damit wären die Seiten relativ bald nicht mehr von Suchmaschinen indiziert worden. Wer jedoch gefunden werden möchte, sollte das natürlich vermeiden.

Entdeckt hat es zufällig Michael, vielen bekannt von greensmilies, der jedoch auch noch das Blog niedermeyer betreibt.

Mir fiel direkt der Beitrag auf, weil sich Prinzzess fragte, ob ihr Blog wohl gehackt wurde. Ein erster Blick in Quelltext schien kein Problem zu zeigen, denn da war ja ein index, follow. Doch bei genauerem Suchen, sah ich dann, dass es überschrieben wurde.

WordPress Seitenaufbau

Nach einigen Installationen, Versuchen, Themes erstellen usw. habe ich gelernt, dass WordPress im Grunde sehr einfach aufgebaut ist. Der Hauptteil, der vom Theme kommt steht meist am Anfang, dann kommen die jeweiligen Einschübe der Plugins, da die sich ja nur an fest definierten Stellen anhängen können.

Die Zeile mit noindex, nofollow, stand im Quelltext direkt nach der Einbindung des Stylesheets des Hangman-Plugins, erst kurz danach folgten weitere Einschübe anderer Plugins. Bei Prinzzess liefen zu diesem Zeitpunkt immerhin 61 Plugins, deshalb ist der Quelltext nicht ganz trivial zu lesen.

Michael bekam von ihr Zugang und konnte schließlich bestätigen, dass es tatsächlich an dem Plugin lag. Nach einer Überarbeitung konnte es wieder aktiviert werden und verhindert nun nicht mehr, dass die Seiten indiziert werden.

Plugins vorsichtig nutzen

Für mich war dieser Vorfall ein weiterer Hinweis, dass es gut ist, vorsichtig mit Plugins umzugehen. Insbesondere, wenn viele Plugins eingesetzt werden, können auch Seiteneffekte entstehen, weil sich Plugins nicht vertragen. In unserem Mitarbeiterblog, welches nicht für die Öffentlichkeit sichtbar ist, bin ich etwas experimentierfreudiger, habe jedoch auch schon öfter Probleme festgestellt. Insbesondere, die sehr praktischen und einfach einzusetzenden Widgets, verursachen immer mal wieder Fehler.

In manch einer Situation ziehe ich Anpassungen am Theme vor, auf manches nette Feature, verzichte ich ganz bewusst. Nach meiner Erfahrung, sind insbesondere Plugins und Eigenschaften, die mittels JavaScript realisiert wurden, häufig eine Fehlerquelle. Nein, ich glaube nicht, dass JavaScript böse ist, allerdings bin ich sicher, dass es leider viele gibt, die mit JavaScript nicht sorgfältig umgehen. Ich kenne kaum eine Seite, die JavaScript einsetzt, bei der nicht zumindest einige Warnungen ausgegeben werden, selbst gemeldete Fehler kommen regelmäßig vor. Bei JavaScript ist das Problem ähnlich, wie bei PHP, vieles funktioniert noch, obwohl es nicht korrekt genutzt wird.

Im Web können sich Fehlerquellen so immens häufen, denn verziehen werden zunächst: Fehler im HTML, im CSS, im PHP und im JavaScript. Dass es da, ab und an auch mal richtig knallt, ist kein Wunder. Nicht selten werden ganze Systeme, wie z.B. WordPress genutzt, in denen, oft auch noch veraltete Versionen laufen, zuweilen kombiniert mit noch älteren oder ganz neuen Plugins. Im Grunde ist es eher erstaunlich wie häufig solche Kombinationen noch einen lauffähigen Webauftritt ergeben.

Meine Lösung

Ich werde weiterhin versuchen, so wenig Plugins wie möglich einzusetzen, mir sind die zur Zeit meist etwa 15-20 genutzten Plugins pro Blog im Grunde schon zuviel. Bei manchen kommt da ja noch Google Analytics hinzu, mehrere eingebundene Links und Bilder, wie z.B. zu Blogverzeichnissen oder geschaltete Werbeanzeigen. Insbesondere bei der Ladezeit einer Seite, macht es sich dann doch bemerkbar, was alles Zeit braucht, bevor die Seite vollständig angezeigt wird.

“eine neue Version 2.6.2 ist verfügbar“

Ja, ich finde es sinnvoll, wenn Fehler und Lücken so schnell wie möglich behoben werden, dieses Mal hat auch alles problemlos geklappt ***mal vorsichtshalber auf Holz klopfend***

Klasse finde ich die Geschwindigkeit der deutschen Entwickler, die die angepasste Version 2.6.2, wie gewohnt, innerhalb eines Tages zur Verfügung stellten.

Ein bisschen strukturierter und nicht ganz so häufige Aktualisierungen wären jedoch zuweilen schon nett.

Ich habe brav wie immer, erstmal lokal probiert, was passiert, anschließend alle Datenbanken gesichert und erst dann aktualisiert… Klar fange ich jeweils erstmal mit dem Blog an, bei dem es am wenigsten auffällt, falls was wiederhergestellt werden muss. Es folgen die eigenen Blog und erst wenn da alles ok ist, gehe ich an Kundenblogs.

Plugin quote-comments

Das Plugin quote-comments (Kommentare zitieren) von Peter Kröner läuft jetzt auch hier. Nach einigem Rumprobieren und nachfragen, kam ich beim ersten Blog lokal zu einer Lösung. Ich musste die comments.php meines Themes ein bisschen anpassen, um validen Code zu bekommen.

Im Plugin habe ich in der wp-quote-comments.php statt eines Paragraphs (p) auf <li class=”quote_comments”> umgestellt, sonst passte es nicht in meinen Themes. Das erste, ein internes Blog, lief nachdem ich den relativen Pfad in der wp-quote-comments.js  von ../../../wp-content/plugins/wp-quote-comments/ auf absolute Pfade vom root aus /bloggt/wp-content/plugins/wp-quote-comments/ geändert hatte.

Beim Rumprobieren hatte ich diverse Versionen und irgendwann wusste ich gar nicht mehr, was ich alles geändert hatte. Ich habe dann nochmal mit den Ursprungsversionen angefangen. Dabei fiel mir auf, dass die Seiten plötzlich nicht mehr valide waren. An der Stelle ist das Plugin noch empfindlicher als der Validator, bei mir verweigerte es bei jedem Fehler seinen Dienst. Da ich selbst auf validen Code achte, ist das kein Problem, aber ich hatte nicht damit gerechnet.

Hier hatte ich einen Fehler zwischen den lokalen Tests und dem Hochspielen eingebaut und suchte das Problem zunächst in den Pfaden, die waren es jedoch nicht, denn kaum war der Fehler weg, war auch das Plugin zufrieden und zitierte so, wie ich mir das vorgestellt hatte.

So ganz nebenbei tauchte noch ein Problem auf, welches viel Zeit kostete, für das ich noch keine Lösung habe, da ich die Ursache nicht kenne, welches aber nicht so gravierend ist. Erstmals hatte ich Unterschiede im Quelltext zwischen meiner lokalen und der Serverversion. Das Plugin schreibt mir lokal in jeden Kommentar:

id=”quote_comments_loader”

Sobald es auf dem Server ist, beschränkt es sich jedoch darauf, das exakt einmal zu tun.

Leider dauerte es ziemlich lang, bis ich kapiert habe, dass das so ist. Bis dahin hatte ich nach, mir unerklärlichen, Fehlern im Validator gesucht…

Nur dieser Bereich wäre ja nicht so schlimm, allerdings sind damit auch alle Angaben wie Datum und Texte, die direkt von WordPress kommen englisch. Ich recherchierte an verschiedenen Stellen, unter anderem in der FAQ des deutschen WordPress-Forums. Ich probierte alle Hinweise aus, aber nichts half. Als nächstes wollte ich wissen, ob das Problem in der Datenbank zu suchen ist. Zuerst schaute ich mal rein, ob es da weitere Sprachinformationen gibt, da war jedoch nichts.

Dann installierte ich lokal eine völlig neue Datenbank, denn mehrere andere neu aufgesetzte Blogs kamen ja mit derselben Kombination WP 2.6.1 und dieselben Plugins zurecht. Wieder kein Ergebnis, dieselben Dateien ergeben bei Neuinstallation wieder englische Ergebnisse.

Nächster Schritt alle Plugins deaktivieren, umstellen auf’s Standardtheme in deutscher Version und alle WordPress-Dateien aus einem Blog kopieren, die mit deutsch zurecht kommen. Vorher natürlich sicherstellen, dass auch die lokale Version gesichert ist, nicht dass die einzige Originalversion auf dem Server liegt.

Wieder kein Erfolg, alle geänderten Dateien von einem Blog, welches die deutsche Sprache anzeigt als Grundlage ändern nichts daran, dass wieder alles auf Englisch ist. So ganz allmählich gingen mir die Ideen aus, denn wenn es weder die Datenbank, noch die Dateien, noch das Theme, noch die Plugins waren, was könnte denn dann noch sein?

Nun, das einzige, was jetzt noch anders war, war die wp-config. Ich hatte zwischendurch schon einige Male mit Änderungen der Sprachangabe und verschiedenen Sprachdateinamen an unterschiedlichen Stellen experimentiert, da ja auch der Pfad zwischen WP 2.3 und WP 2.6.1 für Sprachdateien anders ist. Statt /wp-includes/languages findet man die Sprachdateien ja inzwischen unter: /wp-content/languages

Da ich von Hand schon einige Male probiert hatte, dachte ich, die einzige Chance ist noch, die relevanten Zeilen zu kopieren. Tja, und genau das war’s! Jetzt spricht alles wieder brav deutsch. Hätte ich die Kommentare in der Datei genau gelesen, hätte ich drauf kommen können. Nun, das hatte ich jedoch nicht.

Lösung des Sprachproblems

define (’WPLANG’, ‘de_DE’);
/* That’s all, stop editing! Happy blogging. */
define(’ABSPATH’, dirname(__FILE__).’/');
require_once(ABSPATH.’wp-settings.php’);
// define(’ABSPATH’, dirname(__FILE__).’/');
// require_once(ABSPATH.’wp-settings.php’);
// define (’WPLANG’, ‘de_DE’);

Na, seht ihr den Unterschied?
Ich habe es mehrfach nicht gesehen. Es gibt Definitionen, die dürfen stehen wo sie wollen, z.B.

define(’ABSPATH’, dirname(__FILE__).’/');

,

das gilt jedoch nicht für die Sprachdefinition, die muss vor dem folgendenKommentar stehen.

/* That’s all, stop editing! Happy blogging. */

Wie das passieren konnte?

Für die Umbennenung des Blogs musste ich in der wp-config folgende Zeile eingeben:

define(’RELOCATE’, true);

Dabei habe ich wahrscheinlich versehentlich den Spracheintrag um eine Zeile verschoben… Nun gut, wieder was gelernt, jetzt sind jedenfalls wieder alle Ausgaben deutsch und vielleicht hilft es ja noch jemand…