Der folgende Screenshot zeigt die Seite der Einstellungen, auf der man die Tiefe der verschachtelten Kommentare einstellen kann:

Was aber, wenn man nachträglich bereits vorhandene Kommentare hierarchisch organisieren möchte?

Das Aktivieren der Option für hierarchische Kommentare alleine reicht noch nicht aus. Das aktuell verwendete Theme muss die Verschachtelung von Kommentare ebenso unterstützen und diese auch hierarchisch anzeigen.

Unschön ist nur, wenn Kommentare bereits ohne diese Einstellung abgegeben wurden und in der Datenbank daher gar nicht hierarchisch abgelegt wurden. Die Kommentare sind dann lediglich flach organisiert und man kann nicht direkt erkennen, was die Antwort zu einem anderen Kommentar sein soll.

Die Frage ist, wie man nachträglich vorhandene Kommentare hierarchisch organisieren kann?

Das Umorganisation im Nachhinein ist im Prinzip nicht so schwierig, kann aber je nach Anzahl der Kommentare aufwändig werden.

WordPress organisiert alle Informationen zu Kommentaren in der Datenbank innerhalb der Tabelle wp_comments. Jeder Kommentar besitzt hier eine eindeutige ID, die in der Spalte comment_ID gespeichert ist.

Zu jedem Kommentar gibt es die Information, wer diesem Kommentar übergeordnet ist. Diese findet man in der Spalte comment_parent. Hier ist dann die comment_ID des übergeordneten Kommentars eingetragen.

Die Struktur der Datenbank kann man z.B. über phpAdmin einsehen und bearbeiten. Möchte man die Kommentare im Nachhinein hierarchisch organisieren, muss man sich leider die Mühe machen und jedem untergeordneten Kommentar, die entsprechende ID des Vater-Kommentars über die comment_parent Spalte zuordnen.

Falls dieser Beitrag hilfreich war, bitte ein Feedback über das Sterne-Rating unten oder einen Kommentar abgeben!

Dieses Mal hatte ich Probleme im Zusammenhang mit der implode()-Funktion.

Solche Effekte sind wir ja alle schon wohnt

Nach diesem Update erschien also in meiner Sidebar im Abschnitt Kategorien folgende Fehlermeldung:

Die Fehlermeldung ist neu, die hatte ich noch nie.

Zusätzlich waren meine statischen Seiten im Archiv der Artikel-Kategorie “Allgemein” aufgeführt, was auch nicht sein sollte. Beide Fehler sind nicht akzeptabel und sollten behoben werden.

Wie immer geht erst mal die Suche nach der Ursache des Problems los. Zum ersten Fehler ist zu sagen, dass es interessant ist, dass in meinen Dateien die implode()-Funktion nirgends aufgerufen wird. Da das Problem in der Sidebar bei den “Kategorien” auftrat, habe ich mir zunächst das “Kategorien” Sidebar-Widget vorgenommen. Auch hier war die implode()-Funktion nicht zu finden. Allerdings trat das Problem nicht mehr auf, als ich den Beitrags-Zähler neben den Kategorien deaktiviert habe. Soweit so gut – wenn keine implode-Funktion verwendet wird, muss der Fehler eben woanders liegen.

Generell ist zusagen, dass es nach einem WordPress-Update naheliegend bzw. sogar sehr wahrscheinlich ist, dass Plugins die Probleme verursachen. Daher macht es erst mal Sinn, gezielt Plugins zu deaktivieren. Tritt das Problem nicht mehr auf, hat man den Übeltäter gefunden. Bei mir könnte es also eines der Kategorien-Plugins sein, da in diesem Zusammenhang auch mein Problem auftrat.

Nach dem Deaktivieren des Plugins “Page Category Plus” (Produces a list of tags in the write/edit post pages) hatte ich die Ursache gleich für beide Probleme gefunden. Sowohl die Warnung mit der implode()-Funktion, als auch das Problem der statischen Seiten in meinem Artikel-Archiv waren verschwunden!

Tipp:

Allen Update geplagten kann ich nur raten: bei Problemen nach einem Update gezielt Plugins deaktivieren!

Wenn dann das/die schuldige(n) Plugin(s) gefunden ist/sind, muss man darauf hoffen, dass bald ein Update von den Autoren kommt. Glücklicherweise traten bei Updates von Plugins bei mir in der Regel keine/kaum Fehler auf. Hoffentlich bleibt das auch in der Zukunft so

Für diejenigen, die mit dem Firefox arbeiten, gibt es zumindest ab Browser Version 2.0 eine integrierte Rechtschreibprüfung. Diese prüft in allen Eingabefeldern (z.B. auch in Kommentarfeldern auf Blogseiten) auf Tippfehler und unterringelt falsch geschriebene Wörter rot. Über das Kontextmenü bekommt man dann Korrekturvorschläge zu einem falsch geschriebenen Wort angezeigt:

Mit Firefox werden allerdings keine Wörterbücher in der Standard-Installation ausgeliefert, so dass die Rechtschreibprüfung erst funktioniert, wenn Wörterbücher separat nachgeladen und als Add-On installiert werden.

Wörterbücher in diversen Sprachen findet man auf der entsprechenden Add-On Seite in der Rubrik Wörterbücher und Sprachpakete.

Nach der Installation und dem Neustart des Browsers kann man die Rechtschreibkorrektur dann in WordPress während dem Schreiben/Bearbeiten von Artikeln verwenden.

WordPress Plugin: “After the Deadline”

Neben der Rechtschreibprüfung mit Hilfe der Firefox-Wörterbücher gibt es auch noch ein nettes WordPress-Plugin Namens After the Deadline. Ein interessanter Name für ein Plugin, aber naja

Dieses Plugin führt nicht nur eine Rechtschreibprüfung durch, sondern überprüft auch gleichzeitig die Grammatik und den Schreibstil. Der Text wird, ähnlich wie in Word, für Anmerkungen zu Grammatik & Stil grün hervorgehoben und für falsch geschriebene Wörter in rot:

Nach der Installation des Plugins benötigt man einen API-Key, den man nach einer Registrierung auf der Plugin Profil-Seite kostenlos erhält. Nachdem das Plugin aktiviert wurde und der API-Key in den Plugin-Einstellungen hinterlegt wurde, findet man im WordPress HTML-Editor einen neuen Button proofread. Nachdem dieser angeklickt wurde, werden Rechtschreibung, Grammatik und Stil überprüft und man bekommt zur einfacheren Korrektur in einem unterteilten Editor-Fenster den original Text, sowie den Text mit den Korrektur-Vorschlägen angezeigt.

Ein Nachteil des Plugins ist allerdings, dass es momentan nur Englisch unterstützt. Bei der Firefox-Variante konnte man zumindest diverse Wörterbücher nachladen.

In den FAQs des Plugins konnte man aber auch folgendes lesen:

…
6. Will After the Deadline support other languages?
We’re working on it.
…

Dann hoffen wir mal, dass sich hier recht zügig etwas diesbezüglich tut. Denn im Grunde ist dies ein nettes Feature während dem Schreiben…

Offensichtlich hat sich hier seit WP 2.8 etwas an den URLs in einem der letzten WordPress-Updates geändert und diese Bereiche wurden beim Update nicht berücksichtigt.

Fehlerbehebung:

Im WordPress-Forum unter WP 2.8: Feeds im Dashboard findet sich die Lösung für beide Probleme:

Fehlermeldung:

Lösung: Austausch der URL in eine der folgenden URLs

Für den zweiten Fehler scheint auch ein Fehler in der URL verantwortlich zu sein:

Fehlermeldung:

Lösung: Entferne den “/” (Slash) am Ende der Feed-URL

Bei mir tauchen die Fehlermeldungen jetzt jedenfalls nicht mehr auf!

Danke an die Forum-User orpheus und cat1261.

In diesem Beispiel zeige ich, wie man die ID zweier Kategorien vertauschen kann. Anhand dieses Beispiels lässt sich dann auch die ID einer einzigen Kategorie abändern.

Das Beispiel beschreibt welche Schritte man durchführen muss, damit eine Kategorie mit der ID 35 später die ID 36 hat und die Kategorie mit der ID 36 stattdessen die ID 35 bekommt.

!! Bevor wir aber Änderungen an der WordPress Datenbank vornehmen, sollte diese unbedingt gesichert werten. !!

ID einer Kategorie ermitteln

Bevor wir die IDs zweier Kategorien tauschen können, müssen wir zunächst einmal deren ID ermitteln. Diese bekommt man relativ leicht heraus, indem man in der WordPress Admin-Oberfläche über Artikel > Kategorien zu der Übersicht aller Kategorien wechselt. Dort werden alle Kategorien mit ihrem Namen aufgelistet. Bewegt man die Maus über einen der Artikel-Namen sieht man in der Statusleiste des Browsers den Link zu dieser Kategorie. Die Links der Kategorien enden hier mit der ID der Kategorie, z.B. cat_ID=35.

Relevante Datenbank-Tabellen

WordPress benutzt zur Speicherung und Verknüpfung der Kategorien drei verschiedene Tabellen:

Ein ER-Diagramm mit den Beziehungen zwischen allen WordPress DB-Tabellen findet man unter WordPress Database Description.

Update relevanter Tabellen

Zum Vertauschen der IDs von Kategorien müssen wir die relevanten Tabellen der Reihe nach mit unseren gewünschten IDs updaten. In unserem Beispiel wollen wir die Kategorie mit der ID=35 und die Kategorie mit der ID=36 vertauschen. Hierzu ändern wir zuerst die ID=35 auf eine nicht benutze Kategorie-ID. In diesem Beispiel verwende ich dafür die ID=1035.

Tabelle ‘wp_terms’:

Zum Tauschen der IDs zweier Kategorien führen wir nacheinander folgende SQL-Statements auf der Tabelle wp_terms aus:

UPDATE `wp_terms`
SET `term_id` = 1035
WHERE `term_id` = 35

UPDATE `wp_terms`
SET `term_id` = 35
WHERE `term_id` = 36

UPDATE `wp_terms`
SET `term_id` = 36
WHERE `term_id` = 1035

Update der Tabelle ‘wp_term_taxonomy’:

In der Tabelle wp_term_taxonomy führen wir alle Schritte analog zu den Schritten in der Tabelle wp_terms aus. Um die Konsistenz zu wahren werden aber beide relevanten Felder der Tabelle, also sowohl term_id, also auch term_taxonomy_id getauscht:

UPDATE `wp_term_taxonomy`
SET `term_id` = 1035
WHERE `term_id` = 35

UPDATE `wp_term_taxonomy`
SET `term_id` = 35
WHERE `term_id` = 36

UPDATE `wp_term_taxonomy`
SET `term_id` = 36
WHERE `term_id` = 1035

UPDATE `wp_term_taxonomy`
SET `term_taxonomy_id` = 1035
WHERE `term_taxonomy_id` = 35

UPDATE `wp_term_taxonomy`
SET `term_taxonomy_id` = 35
WHERE `term_taxonomy_id` = 36

UPDATE `wp_term_taxonomy`
SET `term_taxonomy_id` = 36
WHERE `term_taxonomy_id` = 1035

Update der Tabelle ‘wp_term_relationships’:

Zu guter Letzt korrigieren wir in der Tabelle wp_term_relationships alle term_taxonomy_id Felder auf die neuen Feldwerte. Hier muss also auch die term_taxonomy_id=35 auf term_taxonomy_id=36 und die term_taxonomy_id=36 auf den Wert term_taxonomy_id=35 abgeändert werden:

UPDATE `wp_term_relationships`
SET `term_taxonomy_id` = 1035
WHERE `term_taxonomy_id` = 35

UPDATE `wp_term_relationships`
SET `term_taxonomy_id` = 35
WHERE `term_taxonomy_id` = 36

UPDATE `wp_term_relationships`
SET `term_taxonomy_id` = 36
WHERE `term_taxonomy_id` = 1035

Nach dem Durchführen der obigen Schritte sollen die IDs der Kategorien nun die gewünschten ID haben.

Falls Euch dieser Artikel geholfen hat, dürft Ihr gerne eine Bewertung über das Star-Ranking abgeben. Bei Fragen oder Anmerkungen bitte ich Euch einen Kommentar zu hinterlassen!

In diesem Beitrag möchte ich über meine Erfahrungen mit der Konfiguration eines mehrsprachigen Blogs berichten.

Zunächst hatte ich mir zum Umschalten der Sprache das WordPress Plugin Language Switcher von Poplar ProductivityWare angeschaut. Eine sehr ausführliche Installations-/Konfigurationsanleitung dazu in Englisch gibt es direkt auf der Plugin-Seite. Auf Angi’s Blog findet man auch eine passende Übersetzung in Deutsch.

Leider hat die Konfiguration bei meinem Theme nicht so reibungslos funktioniert, wie ich mir das vorgestellt hatte. Ich hab mich daher dann irgendwann etwas genervt nach alternativen Plugins umgesehen. Vielleicht reiche ich aber später noch eine Anleitung zum Einrichten des Language Switcher Plugins nach.

qTranslate

Bei meiner Suche nach Alternativen bin ich auf das Plugin qTranslate von Qian Qin aufmerksam geworden. Nach dem Upload und Aktivieren des Plugins findet man unter Einstellungen > Sprachen eine sehr intuitive Oberfläche, um die gewünschten Sprachen hinzuzufügen. Per Default sind hier Deutsch, Englisch und Chinesisch eingestellt. Wer dem Chinesisch nicht mächtig ist, kann die Sprache auf dieser Seite auch wieder deaktivieren.

Nachdem die gewünschten Sprachen aktiviert wurden, findet man zu jeder Sprache ein eigenes Eingabefeld für den Title des Artikels bzw. der Seite:

Im Editorfenster sieht man zusätzlich zu jeder Sprache eine Kapitelkarte, über die man den Text in der Sprache eintragen kann. Wie gewohnt ist es weiterhin möglich zwischen einem grafischem Modus und dem HTML-Modus umzuschalten:

Multilinguale Permalink-Struktur

Unterhalb der Artikel-Überschrift der Standard-Sprache befindet sich zusätzlich ein Feld, um die letzte Ebene der Permalink-Struktur für den aktuellen Artikel zu bearbeiten. Diese Möglichkeit finde ich generell sehr gut und praktisch, allerdings hätte ich mir gewünscht, dass man dies für jede Sprache unterschiedliche definieren kann. Ich habe das bereits beim Autor des Plugins angeregt und hoffe, dass es nicht allzu kompliziert wird und mit dieser Erweiterung irgendwann zu rechnen ist.

Widget zur Auswahl der Sprache

Damit die Besucher des Blogs zwischen den angebotenen Sprachen umschalten können, bringt qTranslate noch ein Widget mit. Das Widget qTranslate Language Chooser-Widget findet man wie gewohnt unter Darstellung > Widgets > qTranslate Language Chooser. Nachdem Aktivieren des Widget in der Seitenleiste hat man mehrere Optionen zur Darstellung der aktivierten Sprachen – “Nur Text“, “Nur Bilder“, “Text und Bilder” und “DropDown Box“. Ich persönlich finde es eigentlich immer ganz nett und intuitiv, wenn man zumindest die Landeflagge der angebotenen Sprache in einem Blog sieht. Von daher blieben für mich nur die Optionen “Nur Bilder” oder “Text und Bilder” offen. Das muss aber letztlich jeder für sich entscheiden.

Multilingualität bei Plugins

Viele Plugins bieten in ihren Einstellungen verschiedene Eingabefelder für benutzerdefinierte Meldungen. Die grafische Oberfläche von qTranslate kann sich natürlich in die Oberfläche dieser Plugins nicht integrieren, bietet aber dennoch für solche Fälle eine interessante Möglichkeit. Die Mehrsprachigkeit wird hier dadurch erreicht, dass jeder Text der Meldung in bestimmte Sprach-Tags eingeschlossen wird. Im folgenden Beispiel kann man sehen, wie man seine Texte für die Sprachen Deutsch und Englisch vorbereiten muss, damit sie von qTranslate gemäß der eingestellten Sprache angezeigt werden:

<!--:de-->Dieser Text wird in Deutsch angezeigt<!--:-->
<!--:en-->This text will be shown in English<!--:-->


Multilinguale Artikelbeschreibung

Dieses Sprach-Tag ist insbesondere in Kombination mit den Spezialfeldern eines Artikels interessant. Jedem Artikel kann über Spezialfelder, die man ganz unten auf der bearbeiteten Artikelseite findet, zum Beispiel eine Beschreibung gegeben werden. Dieser Text wird von Suchmaschinen verwendet, um eine Kurzbeschreibung des Artikels anzuzeigen. Über das Sprachen-Tag <!–:de–& … <!–:–> ist es auch hier möglich, eine multilinguale Kurzbeschreibung des Artikels zu erzeugen. In Abhängigkeit von der Sprache, die bei der Suchmaschine für die Suche verwendet wurde, wird eine andere Sprache für die Kurzbeschreibung angezeigt.

Vorbereiten der Sprachdatei(en)

Da jedes Theme und jedes Plugin seine eigenen Meldungen mitbringt, muss man diese auch separat übersetzen. Manche Texte überschneiden sich sicherlich und werden von mehreren Plugins genutzt, doch in der Regel muss man hier seine eigenen Übersetzungen definieren.

WordPress hat hierfür Sprachdateien mit der Endung .mo und .po vorgesehen. Die Datei mit der Endung .po ist im Klartext lesbar und ist dafür gedacht, seine eigenen Übersetzungen zu machen. Die andere Datei muss durch ein Programm, wie zum Beispiel poEdit ins Binärformat übertragen werden. WordPress interessiert sich logischerweise nur für die Binärdatei (.mo), so dass auch nur diese unbedingt auf den Server hoch geladen werden muss.

Der Editor poEdit ist recht intuitiv aufgebaut. In der Liste oben sieht man alle Zeichenketten, die in der .po-Datei definiert wurden. In der Spalte daneben deren Übersetzung. Klickt man eine der Zeichenketten an, kann man in den Textfeldern darunter den gesamten Text der Zeichenkette sehen und entsprechend dann die Übersetzung hinterlegen.

Nachdem alle Meldungen übersetzt wurden, Speichert man den Katalog (Datei > Speichern oder in der Symbolleiste den zweiten Button anklicken) und überträgt ihn damit in das Binärformat. Nach dem Speichern erhält man dann die .mo-Datei.

Falls eine Meldung und deren Übersetzung fehlen sollte, kann man diese im folgenden Format in der .po-Datei hinzufügen:

#: Kommentar mit Pfad zur Datei mit der Meldung und deren Zeilennummer
#: wp-content/themes/myTheme.php:10
msgid "Original Message"
msgstr "Übersetzung"


WordPress nutzt für Übersetzungen eine globle Sprachdatei, die man im Verzeichnis ../wp-content/languages/ findet. Diese hat in der Regel einen Dateinamen abhängig vom Ländercode in der Form “de_DE.po” oder “en_EN.po“. Wie der Dateiname für das Länderkürzel aufgebaut sein muss, steht in der Datei wp-config.php unter WPLANG. In aller Regel ist das aber für die globale Sprachdatei ein Format, wie zum Beispiel “de_DE.mo” und für zusätzliche Sprachdateien, die in das Theme-Hauptverzeichnis gelegt werden müssen, das Formt “de.mo”.

Da ich nur eine globale Sprachdatei bearbeiten möchte, habe ich mir angewöhnt diese Datei anzupassen. Es gibt aber ebenfalls Leute, die das gerne alles getrennt halten. Hierzu sollten die Dateien in das Hauptverzeichnis de Themes gelegt werden, damit sie gefunden werden können.

Zusammenfassung und Ausblick

Der Artikel hat einen Einblick in das WordPress-Plugin qTranslate gegeben und beschrieben, wie man es mit Hilfe von Sprachdateien so konfigurieren kann, dass das Umschalten der Sprache problemlos funktionieren sollte.

Falls etwas gefehlt haben sollte, oder unklar war, bitte ich Euch einen Kommentar zu hinterlassen, damit ich auf den ein oder anderen Punkt nochmals genauer eingehen kann.

Ansonsten, falls Euch der Beitrag gefallen hat, bitte ich Euch eine Bewertung über die Post-Ratings abzugeben.

Ergänzen könnte ich diesen Beitrag noch mit der Vorstellung von anderen Plugins, wie zum Beispiel dem Language Switcher. Da ich persönlich aber mit qTranslate bisher sehr zufrieden bin, kann ich das auch nur sehr empfehlen.

So praktisch solche Funktionen oft sein können, sie können aber auch an mancher Stelle richtig nerven. Da jede Revision in der Datenbank gespeichert werden muss, bläht diese sich mit der Zeit auf. Ausserdem wird ein bearbeiteter Artikel mit der Zeit immer unübersichtlicher.

WordPress bietet aber auch Möglichkeiten, um die Anzahl der Revisionen zu begrenzen oder diese Funktion komplett abzuschalten. Hierzu bearbeitet man einfach die Datei ‘wp-config.php‘ im ‘wordpress’ Verzeichnis und fügt den entsprechenden Abschnitt hinzu bzw. ändert ihn entsprechend ab:

Anzahl der Revisionen begrenzen:

// Erstellt maximal 5 Revisionen
define(‘WP_POST_REVISIONS’, 5);

Autosave/Revisionierung abschalten:

define(‘WP_POST_REVISIONS’, false);

Revisionierte Einträge werden in der Tabelle wp_posts in der Spalte post_type verwaltet. Zum Löschen der bisherigen Revisionen führt man daher über phpMyAdmin den folgenden SQL-Befehl zum löschen aus:

DELETE FROM `wp_posts`
WHERE post_type = ‘revision’