"wp-config.php"

die Zeile

define('WP_DEBUG', false);

ändert.
Folgende Zeilen müssen stattdessen eingefügt werden:

// Turns WordPress debugging on
define('WP_DEBUG', true);

// Tells WordPress to log everything to the /wp-content/debug.log file
define('WP_DEBUG_LOG', true);

// Doesn't force the PHP 'display_errors' variable to be on
define('WP_DEBUG_DISPLAY', false);

// Hides errors from being displayed on-screen
@ini_set('display_errors', 0);

Eine gute Idee ist natürlich, vorher eine Sicherungskopie der Datei anzulegen.

Wenn diese Einstellungen gemacht sind, erhält man zum Beispiel eine solche Meldung in der neu angelegten Datei /wp-content/debug.log:

[15-Feb-2011 20:09:14] PHP Notice: get_usermeta is deprecated since version 3.0! Use get_user_meta() instead. in C:\Code\Plugins\wordpress\wp-includes\functions.php on line 3237

Die Datei “debug.log” gibt also eine gute Hilfe bei der Entwicklung.

Will man nun eigene Meldungen ausgeben, benötigt man folgende Funktion in den PHP-Dateien:

function log_me($message) {
	if (WP_DEBUG === true) {
		if (is_array($message) || is_object($message)) {
		error_log(print_r($message, true));
	} else {
		error_log($message);
		}
	}
}

Die Funktion ruft man in dieser Form auf:

log_me(array('This is a message' => 'for debugging purposes'));
log_me('This is a message for debugging purposes');

Gefunden bei www.smashingmagazine.com

Mit WPML erscheint wie in Teil 1 schon erwähnt in der Artikelübersicht eine neue Spalte mit den Symbolen + oder Bleistift zum hinzufügen oder bearbeiten einer Sprachvariante eines Artikels. Ist noch kein Inhalt in der neuen Sprache angelegt, wählt man das Plus-Symbol, möchte man eine Übersetzung anlegen, wählt man den Bleistift. Man gelangt auf die leicht veränderte Eingabeseite von WordPress.Hier gibt es oben rechts ein neues Feld: “Sprache”, in dem man einstellen kann, in welcher Sprache der aktuelle Artikel angelegt ist und welche weiteren Übersetzungen dieses Artikels es gibt. Man kann in diesem Feld auch angeben, zu welcher Sprache der aktuell bearbeitete Artikel gehören soll und welcher Artikel die “Mutter” ist.
Der ursprüngliche Inhalt (also die erste Sprachfassung) wird hier aber nicht angezeigt, so dass es sinnvoll ist ein zweites Fenster oder einen Tab mit dieser Fassung zu öffnen. Hat man in dem Artikel auch Bilder eingebettet, sollte man den kompletten Inhalt des Eingabefelds aus Fassung A in die neue Fassung hineinkopieren. So hat man die einmal angelegte Formatierung vorliegen und kann den Text einfach “überschreiben”  und Bilder einfach an ihrem einmal zugewiesenen Platz belassen. Das erleichtert die Übersetzungsarbeit und verhindert, Bilddaten eventuell doppelt hochzuladen.
Leider wird die Auswahl der Kategorie nicht von der einen in die andere Fassung übernommen. Meiner Meinung nach ist das ein Manko von WPML. Ich würde es begrüßen, wenn die Struktur eines Artikels komplett sprachunabhängig angelegt und so in allen Sprachvarianten gleich wäre. Wenn ich aber in jeder Variante eine andere Strukturierung anlegen kann, ist die Gefahr gross, hier etwas durcheinander zu bringen.
Dies zeigt sich auch in der Verwaltung der Kategorien: anders als bei den Artikeln gibt es hier nicht die Symbole “Plus” und “Bleistift”, sondern oberhalb der Liste die Sortierung nach den verschiedenen Sprachen. In meinem Fall war die zweite Sprache gleich der schwerste Brocken: chinesisch! Hier fällt natürlich die Zuordnung eines Artikels zu einer Kategorie schwer, wenn man der Sprache nicht mächtig ist. Es wäre sinnvoll, wenn wenigstens die gleiche Kategorie in allen Sprachen schon angewählt wäre, oder man irgendwie erkennen könnte, welche Kategorien zusammengehören. Das relativiert sich natürlich etwas, wenn man beide Sprachen beherrscht.

Auch der “Slug”, also die Kurzfassung einer Kategorie darf nicht die gleiche sein. Dies betrifft zwar in erster Linie die Programmierung der Templates und wird durch den Automatismus in WPML abgefangen, erleichtert aber nicht unbedingt den Umgang mit einem multilingualen Blog.

<?php _e('STRING'); ?>

.

Was fehlt ist aber immer noch die Übersetzung fester Begriffe aus WordPress. Es können an keiner Stelle die Begriffe “more…” (für den automatischen Link zum Weiterlesen) oder für die Links zum Blättern in den Artikeln ersetzt werden. Diese kann man zwar in den Templates definieren, lassen sich aber nicht wie oben beschrieben maskieren (sie stehen ja schon in einer php-Funktion). Hier sehe ich noch Verbesserungspotential und habe noch keine Lösung für diesen Umstand gefunden. Hier sollte WPML noch eine Lösung anbieten. Man kann sich behelfen, indem man eine if/else-Abfrage schreibt, die aufgrund der URL einen anderen Code ausführt. Da man die Template-Tags durch Variablen ändern kann, ist eine Übersetzung über diesen Weg möglich.
Auch das Verfahren, jeder Sprachfassung eines Posts eine neue ID zu geben und nur über die Funktion “icl_link_to_element” den Eintrag sprachneutral verlinken zu können, macht mehr Arbeit als notwendig. Hier geht das PlugIn “qTranslate” einen anderen Weg und speichert zunächst einmal einen Artikel, den man dann in verschiedenen Sprachvarianten anlegt. Ob die Übersetzung und Programmierung der Templates nun mit “qtranslate” besser als mit WPML funktioniert, kann ich leider nicht beurteilen. WPML kann ich aufgrund der Erfahrungen eigentlich schon empfehlen, gerade wenn man die hier beschriebenen Kniffe kennt.

Die Webseite, die aufgebaut werden sollte, hat eine dreistufige Menüstruktur. In einer Hauptnavigation im Kopfbereich stehen Links zur ersten Ebene, in einem Submenü auf der linken Seite Links zu Seiten der zweiten und dritten Ebene.
Die erste Ebene zu verlinken ist eigentlich kein Problem, hier reicht die Codezeile:

<?php wp_list_pages('title_li=&child_of=0&depth=1'); ?>

, um Links zur ersten Ebene zu erzeugen. Für das Submenü (2. und 3. Ebene) habe ich zuerst auf die Funktion “wp_list_pages” zurückgegriffen, was auch grundsätzlich funktioniert. Jedoch wurden mit dem Script, welches ich verwendete, ab der dritten Ebene die Links zu den Seiten der zweiten Ebene nicht mehr angezeigt.

Hier bietet das PlugIn “Fold Page List” Abhilfe. Mit diesem PlugIn können Navigationen realisiert werden, die erst auf Klick die Unterseiten anzeigen.
Trotzdem ist auch hier noch eine etwas komplexere PHP-Abfrage notwendig, um die Navigation korrekt hinzubekommen.

<?php
$g_page_id = $wp_query->get_queried_object_id();
$ancestorIDs = _wswwpx_page_get_ancestor_ids($g_page_id);
$grandParent = $ancestorIDs[1];
wswwpx_fold_page_list("title_li=&sort_column=menu_order&child_of=".$grandParent);?>

fragt zunächst alle Page-IDs ab, ermittelt daraus alle IDs der Unterebenen und gibt dann alle “Kinder” über das PlugIn aus. Das Schöne daran ist, dass die Links zur dritten Ebene auch erst nach Klick angezeigt werden, also sich erst “aufblättern”, wenn es notwendig ist.

Als weiteres Problem stellte sich heraus, dass ich veränderbare Inhalte zu den Seiten hinzufügen wollte. Wie oben schon beschrieben, hat WordPress keine Funktion, mehrere Spalten in der Eingabemaske zu verwalten. Es gibt aber die “Spezialfelder”, mit denen man eine ähnliche Funktion einbauen kann. Für Text ist das kein Problem, hier kann man auf “<?php the_meta(); ?>” zurückgreifen, welches alle Inhalte der Spezialfelder als Liste ausgibt. Der Name des Spezialfeldes wird dabei auch mit ausgegeben und mit einer Span-Klasse markiert. So konnte ich zum Beispiel einen Kasten in einer Spalte aufbauen, auch wenn dabei noch ein klein wenig Code in der Eingabe notwendig war.

UPDATE: Für die Einbindung von weiterem Content bietet sich übrigens auch das PlugIn “Secondary HTML Content” an! Dieses PlugIn einfach installieren und man hat eine komfortable Möglichkeit, Text in einen weiteren Inhaltscontainer einzuladen. Im Template muss dann über die Funktion “get_secondary_content()” der Inhalt eingebunden werden. Somit entfällt der bei umfangreicheren Texten doch recht mühselige Umgang mit den “Custom fields”.

Ein Nachteil dieser Lösung ist aber, dass die Funktion von WordPress alle Spezialfelder in einer Liste ausgibt. Nun sollte aber jede Seite auch noch mit einer individuellen Kopfgrafik aufgebaut werden, die VOR der Seitenüberschrift im Quelltext auftauchen sollte. Ich konnte diese Bilder also nicht über den Artikel einfügen, denn damit hätte ich das gewünschte Layout nicht hinbekommen und das Bild erschien unterhalb der Seitenüberschrift.

Mit dem PlugIn “Get Custom Field Values” kann man Werte aus den Spezialfeldern auslesen und innerhalb eines Loops verwenden. So hatte ich die Möglichkeit, je ein Spezialfeld für die individuellen Kopfbilder und die rechten Spalten anzulegen, ohne daß über “the_meta()” gleich alle Inhalte angezeigt werden.

Innerhalb des Loops gebe ich dann Folgendes über der Seitenüberschrift aus:

<?php echo c2c_get_custom('NameDesFeldes', '<img class="NameDerKlasse" src="PfadZuDenBildern', '.jpg" />', 'blank'); ?>

Damit lese ich das Feld “Name des Feldes” aus und erzeuge den Quelltext für die Einbindung des Bildes. Im Spezialfeld für das Kopfbild braucht man jetzt nur noch den Bildnamen einzugeben. Ach ja, die Bildverwaltung mache ich dann über das sehr schöne PlugIn “NextGEN Gallery“. In der Albumübersicht kann der Pfad und auch der Bildname sehr einfach ermittelt werden.

Hier ein Link zur Webseite, um die es dabei ging: www.susan-reinhold.de

Ein besonderer Gag des neuen Designs ist der Farbwähler oben links. Hier kann man sich seine Lieblingsfarbe einfach auswählen. Das wollte ich schon immer einmal nutzen. Ich würde mich über Kommentare zu meinem Design freuen.