Kategorie-Archiv: WordPress

Nix deutsch hier!

Frage des Tages: Wenn die deutsche WordPress-Version installiert ist und die deutschen Sprachdateien an der richtigen Stelle liegen und in der Konfigurationsdatei de_DE eingetragen ist (und es auch sonst immer funktioniert hat), sollte doch eigentlich der gesamte Blog in deutsch sein oder? Also sowohl alle Beitragsinfos (Anzahl Kommentare, Datum, Link-Beschreibungen, …) als auch der Admin-Bereich.

Genau hier verzweifle ich gerade. Alle Vorraussetzungen sind erfüllt und bis gestern war auch noch alles auf deutsch und jetzt nicht mehr. GRRRR. WARUM?!?!

FEHLER GEFUNDEN!!! Es liegt an PHP5! Bei meinem neuen Provider kann ich einstellen, welche PHP-Version ich möchte. Als ich das gerade auf PHP4 zurückgestellt habe, ging es wieder.

Neues Dilemma: Deutsch und altes PHP oder englisch und neues PHP!

Counterize II XHTML valid

Das Plugin Counterize II (deutsch, englisch) liefert alle möglichen nützlichen Statistiken und ist sicherlich bei vielen WordPress-Nutzern im Einsatz. Seit einiger Zeit gibt es auch die Möglichkeit, eine öffentlich zugängliche Statistik-Seite zu erstellen (hier sieht man meine).

Die Idee ist toll, doch leider gibt es einen kleinen Nachteil: die Seite validiert nicht[1].

Ich habe mir die Mühe gemacht, die Datei counterize.php standardkonform umzuändern. Das wird natürlich bei jedem Update wieder nötig und ist etwas ärgerlich. Der Autor des Plugins hat mich nun gebeten, meine geänderte Datei hier anzubieten, damit auch andere, denen ein valider Code wichtig ist, sich nicht die Mühe machen müssen.

Die Datei gibt es in zwei Versionen:

  • Version 1, wo alle “alten” Html-Elemente auf den neuesten Stand gebracht wurden, damit die Seite auch XHTML 1.1 valide ist.
  • Version 2, wo zusätzlich einige eigentlich falsche Tags eingefügt sind, die aber nötig sind, weil WordPress beim Speichern einer Seite automatisch Tags hinzufügt.

PS: Diesen Beitrag hatte ich gestern schon einmal veröffentlicht, aber der ist beim Providerwechsel verschütt gegangen. Genauer gesagt, ich hatte das Datenbank-Backup VOR dem Verfassen des Beitrags angelegt….

  1. Warum ist das wichtig? Bei der Checkliste für Webstandards heißt es eine den Webstandards entsprechende Seite sollte im Idealfall schlank, aufgeräumt, CSS-basierend, zugänglich, nutzer- und suchmaschinenfreundlich gestaltet sein. und Valider Coder wird schneller und besser gerendert als invalider Code mit Fehlern. Browser werden standardkonformer und valider Code bekommt einen immer größeren Stellenwert. []

Maintenance-Ärger

Eigentlich wollte ich dieses Wochenende noch die Fortsetzung meines Artikels über An Inconvenient Truth fertigstellen. Leider habe ich vorher begonnen, meinen Blog ein bisschen auf Vordermann zu bringen. Intern zumindest. Plugins aktualisieren und so. Überprüfen, ob einige Ungereimtheiten, die sich hier intern abspielen durch ein bestimmtes Plugin verursacht werden. D.h. jedes Plugin einzeln deaktivieren, prüfen, gucken, wieder aktiveren. Im Zuge dessen, habe ich die Gelegenheit genutzt und überall die Idiotensicherung eingebaut:

if(function_exists('plugin_funktion') : plugin_funktion(); endif;

Aber das ging natürlich völlig schief. Erst verabschiedete sich langsam das SBM-Plugin, was sich dadurch bemerkbar machte, dass ich keine Änderungen mehr vornehmen konnte. Das rief unangenehme Erinnerungen wach. Und irgendwann waren dann auch alle Sidebar-Elemente verschwunden und ich musste wieder von vorne anfangen. Bzw. mühsam Modul für Modul aus dem Backup wiederherstellen. GRRRR. Aber irgendwann war wieder Schluss! Keine Änderungen mehr möglich. Außerdem traten im Admin-Bereich weitere Unregelmäßigkeiten auf, die ich mir nicht erklären konnte. Das war gestern nachmittag und ich hab dann irgendwann frustriert aufgegeben.

Heute morgen hatte ich plötzlich die Eingebung, dass es sich evtl. um das gestern neu installierte Plugin handeln könnte. BINGO! Nach der Deaktivierung ging alles wieder. Leider brauche ich das Plugin. Heißt das jetzt in Zukunft, dass ich für jede Änderung an den Modulen solange das fragliche Plugin deaktivieren muss? Blöd!

Tja, geschafft habe ich sozusagen nix, denn die Maintenance-Aktion ist natürlich noch lange nicht abgeschlossen und den Artikel habe ich nur grob zusammengeschustert. Nicht mal den GSDS-Trostpreis (Glühweinjunkies-Tasse) habe ich gewonnen, schnief.

Sidebar wieder so wie ich wohl will!

Jaha! Vor gut einer Woche war ich noch abgrundtief enttäuscht, dass ich wegen WordPress 2.2 wieder auf die WP-eigenen Sidebar Widgets zurückgreifen musste. Doch im Scribbleblockg-Beitrag WordPress 2.2 und das SBM Modul: Workaround & Lösung habe ich endlich gefunden, wonach mein Herz verlangte.

Ich habe es kurz ausprobiert und es funktioniert tatsächlich. Leider, leider geht die Umstellung nicht so schnell, wie ich das wohl will. Das liegt daran, dass ich die Datenbank bei meinem Versuch, das SBM-Plugin doch zum Laufen zu bringen wohl etwas durcheinander gebracht habe. Ich musste also alle Spuren löschen und nun dementsprechend alle Module neu erstellen. Bzw. mühsam alles von den Widgets kopieren. Das ist ein wenig mehr Aufwand, den ich aber gerne auf mich nehme, damit ich wieder die völlige Modul-Freiheit erleben darf. Hach, wie schön.

Wer mich jetzt für völlig bekloppt hält, hat die Freiheit noch nicht gekostet. In obigem Beitrag hatte ich einige Vorzüge der Module versucht aufzuzeigen. Wer noch nicht überzeugt ist, sollte das hurtig (in einer ruhigen Minute) mal ausprobieren, es lohnt sich wirklich. Und jetzt geht es auch wieder in der aktuellen WP-Version.

Wie gesagt, bei mir dauert das Zurück-Umstellen ein paar Minuten länger, weswegen ich das am Wochenende machen werde. Ich wollte nur schon mal die frohe Botschaft verkünden.

Sidebar auf Umwegen

Mit der neuen Version 2.2. von WordPress ergaben sich ungeahnte Probleme. Seit dieser Version sind die Sidebar Widgets auch ohne das entsprechende Plugin verfügbar. Das heißt aber andererseits, dass das unübertroffen geniale Plugin Sidebar Modules (SBM) nicht mehr nutzbar ist. Da es standardmäßig in dem beliebten Theme K2 eingebaut ist, betraf das eine Menge Nutzer. Ein Workaround in Form eines weiteren Plugins wurde angeboten. Dieses unterdrückt die eingebaute Widgets-Funktionalität, aber das nützt nichts. Denn man kann keine neuen Module erstellen und keine bestehenden bearbeiten.

Der geneigte und evtl. unwissende Leser wird sich nun fragen, was denn nun so toll an den SBMs ist. Nun, man kann alle Arten von Modulen erstellen. Mit alle meine ich neben HTML-Widgets und allen sonst verfügbaren vor allem die PHP-Widgets. Sozusagen Exec-PHP für die Sidebar[1]. Weitere Vorteile sind, dass man den Titel des Widgets ausblenden und eine zusätzliche CSS-Datei verwenden kann. Und man kann sehr feinkörnig bestimmen, auf welchen Seiten das Modul erscheinen soll. Es ist sogar möglich, einzelne Beiträge ein- oder auszuschließen. Geradezu perfekt. Deshalb plädierten auch viele dafür, dass dieses Plugin statt des WP-Widgets-Plugin in die neue Version übernommen werden soll. Schade, wäre so schön gewesen.

Denn die Arbeit mit den Modulen ist wesentlich stressfreier als mit Widgets. Das Drag & Drop geht flüssiger und die Bearbeitung der Widget-Eigenschaften ist übersichtlicher gestaltet. Die Bearbeitung geschieht in einem eigenen Bereich statt durch ein Popup, was sehr viel schneller geht. Die Änderung der Reihenfolge muss nicht mit einem Buttonklick aktiviert werden (= keine lange Wartezeit, bis sich das Ding berappelt hat), sondern die Sidebar wird sofort in der neuen Reihenfolge dargestellt.

Localization von Themes und Plugins – Eine Einführung

Mit diesem Beitrag möchte ich eine möglichst kompakte und doch umfangreiche Anleitung geben, wie man sowohl seinen Blog als auch seine Plugins lokalisiert. Und das getrennt. Dies ist recht kompliziert und man muss sich die Informationen nach und nach zusammenpuzzlen. Vor allem die offiziellen WordPress-Dokumentationen gibt es in mehreren verschieden ausführlichen Versionen und Aktualisierungsstadien (zum Teil noch vom Stand WP 1.2 statt WP 2.1). In der Hoffnung, das Zusammensuchen dem Einen oder Anderen zu ersparen, hier eine Zusammenfassung meiner zusammengetragenen Erfahrungen.

Was genau soll das jetzt?

Dies hier soll eine Hilfe zum Lokalisieren von WordPress und speziell von Plugins sein. Es richtet sich sowohl an lernwillige Anfänger als auch an Fortgeschrittene, die aber noch nicht alles im Griff haben. Deshalb gibt es die Möglichkeit einzelne Abschnitte zu überspringen. Wer schon den Üblick hat, aber einen Merkzettel zum Ablauf der Lokalisierung sucht, dem empfehle ich die Zusammenfassung.

Inhaltsverzeichnis

  1. Voraussetzungen
  2. Grundprinzip der Lokalisierung
  3. Besonderheit bei Plugins
  4. Einrichten von poEdit
  5. Erstellen/Bearbeiten einer Sprachdatei
  6. Bedienung von poEdit
  7. Zusammenfassung

Voraussetzungen

Folgende Vorraussetzungen werden benötigt für die eigentliche Übersetzungsarbeit und das anschließende ungefährliche Testen.

  1. Entweder eine lokale Installation von WordPress ODER eine Testinstallation auf einem entfernten Server[1].
    • Entscheidet man sich für erstere Variante, empfehle ich die Anleitung im Mediengestalter-Blog.
    • Die zweite Variante ist für Leute geeignet, die Zugriffsrechte auf ihre entfernten Daten per FTP haben. Man erstellt eine Kopie seines WordPress-Ordners (z.B. als wordpress-test) auf dem Server.
      Wichtig: in wp-configdie Zeile

      $table_prefix  = 'wp_';

      ändern zu

      $table_prefix  = 'wp_test_';

      (wahrscheinlich Zeile 9), damit eine parallele WordPress-Installation erstellt werden kann.

500 EOF when chunk header expected

Notstand!!!

Warum keine Sidebar? Tja, da gibt es wohl einen Fehler und die Seite wird ab da nicht mehr geladen. Unabhängig vom Theme. Sehr seltsam. Hatte das Problem vor Kurzem schon einmal. Da hat es sich aber nach wenigen Minuten wieder gegen. Das hier hält jetzt seit über zwei Stunden an.

Update: ich konnte es zurückverfolgen auf ein Sidebar-Widget. Aber auf eins, das automatisch bei der Standard-Installation von WordPress dabei ist! Die neueste Version des Widget-Plugins soll WP 2.1 kompatibel sein.

Mein Problem tauchte im Category-Widget auf. Dort wird noch die als deprecated eingestufte Funktion wp_list_cats verwendet. Ich habe mal ausprobiert und die neue Funktion wp_list_categories eingesetzt. Geht rudimentär auch. Die Anzahl der Beiträge pro Kategorie wird nicht angezeigt. Kreuze ich das im Widget an, dann gibt es wieder den EOF-Fehler. Meine Annahme, dass es daran lag, dass das Argument optioncount durch show_count ersetzt wurde, konnte sich nicht bestätigen. Also habe ich den Funktionsnamen und die Argumentbezeichnung wieder zurückgesetzt.

Immerhin habe ich jetzt auch rausgefunden, dass man mit dieser Funktion auch den Feed pro Kategorie anzeigen lassen kann. Ganz noch das Argument feed_image=/pfad/zum/rss/icon einfügen.

Vielleicht stellt sich ja auch hier raus, dass das gar nicht der Fehler war, aber immerhin weiß ich jetzt wieder ein wenig mehr über die WordPress-Funktionen… Vielleicht reicht es irgendwann dazu, mein eigenes Theme zu gestalten. Wir werden sehen.

Update: Es liegt bei mir definiv an den Sidebar-Widgets. Mittlerweile musst ich das Pandora-Widget aus diesem Grund deaktivieren.

Hallo an WordPress: Beitragskategorien != Blogrollkategorien

FRUUUUUUUUUUUUUUUUUUUUUUUUST!!!

Das muss ich jetzt mal loswerden. Gestern (bzw heute gegen Mitternacht) kam WordPress 2.1 raus. So viel besser, so viel einfacher, so viel einfach alles. HA! Erst sollen gar nicht alle Plugins funktionieren (naja für mich irrelevant, aber trotzdem) aber ansonsten soll es gaaaaanz einfach gehen.

Also ich frisch ans Werk und brav die Instruktionen ausgeführt und auch Backup gemacht. Und dann wieder brav alle deaktivierten Plugins aktiviert. Es ging soweit ganz gut bis ich zur Auflistung meiner Blogroll-Kategorien komme:

WordPress database error: [Unknown column 'link_count' in 'where clause']
SELECT * FROM wp_categories WHERE cat_ID > 0 AND link_count > 0 ORDER BY cat_name ASC

Begeisterung pur. Irgendwas stimmt also nicht mit der Zuordnung der Links meiner Blogroll zu Kategorien (Tabelle wp_link2cat). Das gleiche Bild im Admin-Bereich. Aber beheben kann ich das auch nicht! Beim Verfassen dieses Beitrags lacht mich die gleiche Fehlermeldung an, da wo es um die Zuordnung des Beitrags zu einer Kategorie geht.

Und hier liegt auch der Grund: ab Version 2.1 sollen Beitrags- und Blogroll-Kategorien ein- und dasselbe sein. Pech nur, dass ich das ganz anders organsiert habe. Man sollte erwarten, dass dies beim Upgrade beachtet wird, aber Pustekuchen. GRUML. In der Admin-Übersicht meiner Beiträge werden die Kategorien schön ordentlich aufgeführt. Und bei meinen Links gibt es auch eine Zuordnung, die allerdings etwas gewöhnungsbedürftig ist. Ich nehme an, es liegt daran, dass die Kategorien per ID angesprochen werden und deshalb etwas seltsam anmuten.

Localization wenn man kein PHP kann

Ich habe nun schon unzählige Stunden in die Internationalisierung meines Blogs gesteckt, insbesondere die Plugins vom Englischen ins Deutsche zu übersetzen. Am Anfang habe ich das immer schön im Quelltext durch direktes Suchen und Ersetzen gemacht – worüber man wirklich die Hände über dem Kopf zusammenschlagen sollte!!! Dann bin ich durch die Lokalisierung von WordPress auf die Idee gekommen, dass ich das doch auch machen könnte. Hab also schön brav einige Phrasen gettext (soll das Verb gettext in der Vergangenheit sein) mit __("Translate Me") und _e("Translate Me"). Hat aber nüscht gebracht!

Dann bin ich auf die Idee gekommen, mit poEdit die sogenannten .po Dateien zu bearbeiten. Ich habe aber einfach nicht herausbekommen, wie man Einträge hinzufügt. Das wäre aber natürlich notwendig gewesen, um die gettexten Phrasen zu übersetzen. Bis mir dann irgendwann (nach mehreren Stunden) aufgegangen ist, dass ich den Quelltext durchsuchen muss. Bis ich dann auf der deutschen WP-Doku-Seite zum Erstellen der Sprachdatei mit poEdit [Edit: geänderten Link angepasst] gefunden habe, wie man poEdit so einstellt, dass die Quellen durchsucht werden. Und tatsächlich wurden dann auch die von mir geänderten Einträge neu aufgenommen! Von da war es nur noch eine Frage der Ausdauer und guter Augen, dass ich alle Textstückchen finde, die übersetzt werden sollen. Hat auch fast komplett alles geklappt.

Nur bei den kniffligeren PHP-Sachen hat es mich dann aus der Bahn geworfen. Ich möchte eine Variable ($time_period) auch übersetzen. Das kann mal year, mal month sein und da soll dann logischerweise Jahr bzw. Monat draus werden. Ok, man kann Parameter z.B. mit der Funktion sprintf() übergeben, wie ich mir dann zusammengelesen und -gereimt habe, aber was ist mit Variablen? Geht das gar nicht? Muss ich eine Fallunterscheidung machen? Hüülfe!