25. January 2009

WordPress: Unterschiede bei Template Tags und die Unstrukturiertheit des Codex

Dieser Beitrag wird wohl wieder etwas technischer… Das was im WordPress-Codex als Template Tags beschrieben wird, sind in PHP lediglich Funktionen. Es gibt ziemlich viele Template Tags, die allerlei Optionen aus WordPress herauskitzeln können. Für die Theme-Entwicklung sind die Template Tags unheimlich wichtig. Ich möchte hier auf einige gravierende Unterschiede zwischen Template Tags zu sprechen kommen, die es einem bei der Entwicklung nicht immer leicht machen.

Da ich seit ungefähr einer Woche fast täglich an der Entwicklung eines Themes für Mobile Helden bastle, sind mir einige Dinge untergekommen, die natürlich nicht unproblematisch sind. Ein Kumpel wies mich an, ich sollte doch bitte ein Template-System benutzen, um hinter den Kulissen den HTML-Code vom PHP-Code zu trennen. Gesagt – getan?! So einfach ist das leider nicht. Denn während ich normalerweise alle Template-Tags direkt ausführen kann, geht das über den Umweg des zwischengeschobenen Template-Systems nicht so ohne weiteres.

Wenn man normalerweise PHP-Anweisungen in den Quellcode einer *.php-Datei schreibt, werden diese zur Laufzeit interpretiert und die Ergebnisse abgebildet. Die Verwendung des Template-Systems KTemplate erfordert es (wohlgemerkt ist hier nicht die Rede vom WordPress-eigenen Template-System), mit bereits fertigen Ergebnissen umzugehen. Denn im PHP-Code muss ich zunächst die KTemplate-Klasse “inkludieren” und dann eine Vorlagen-Datei für KTemplate einbinden:

$artikel_tmp = new KTemplate(TEMPLATEPATH . "/artikel.html");

In der Vorlagen-Datei findet sich “nur” HTML gepaart mit ein paar Platzhaltern, die gerade die Stellen mit dem PHP-Code ersetzen sollen. Wenn ich jetzt normalerweise den Template Tag the_permalink(); von WordPress einsetze, um den Link eines Artikels damit auszustatten, dann wird das mit dem Template-System leider nicht funktionieren. Denn das versteht nur Text, oder Code-Anweisungen, die aber in Form von Text (String-Variablen) ausgegeben werden. Zum Glück gibt es “get_permalink();” als zusätzliches Template Tag von WordPress. Das liefert mir lediglich den Link als Ergebnis und macht ihn nicht außerdem klickbar.

Die Linkfunktionalität muss ich dann mit einem anchor-tag im HTML-Code selbst berücksichtigen und habe es somit zunächst nicht so einfach gehabt. Es soll sich lohnen, hat man mir gesagt. Ich selbst kann aber sagen, dass Theme-Entwicklung für WP “mir” schneller von der Hand geht, wenn ich nicht noch versuche, einem Template-System wie KTemplate gerecht zu werden.

Doch was ist mit Template Tags (kurz TT), die Parameter übergeben bekommen. Es gibt den TT edit_posts_link();. Dieser Liefert einem einen Link zurück, sobald man als Nutzer an WordPress angemeldet ist. Irgendwo in den Metainformationen des Artikels versteckt, kann man so komfortabel aus dem “Frontend” von WordPress sofort auf die Eingabemaske weitergeleitet werden, den Artikel zu verändern. Der Link wird nur angezeigt, wenn man eingeloggt ist. Der TT hat außerdem 3 Parameter. Man kann einen Linktext und Zeichen für davor und für danach angeben. In der Verwendung mit dem Template-System allerdings klappt das nicht. Es gibt natürlich auch ein “get_edit_posts_link();”. Das kann nur nicht dieselben Parameter übernehmen. Es verfügt sehr wohl über zwei Parameter, die allerdings nicht direkt übergeben werden, sondern einem Array zugeordnet werden, das offenbar global in WordPress die Filter und Einstellungen mancher Funktionen beinhaltet. Über diesen Weg verändert man quasi Standardwerte. Die Parameter für get_edit_posts_link(); sind indes sehr technisch und haben nichts mit der Ausgabe zu tun.

Das hat zur Folge, dass ich nun zweierlei nachholen muss. Zum einen muss ich überprüfen, ob der Autor eingeloggt ist. Dafür bietet WordPress zum Glück einen Befehl an. Zum anderen muss ich entsprechende der Überprüfung eine andere Ausgabe erstellen. Denn mal soll ja der Link angezeigt werden, mal nicht. Es ist schade, dass man für den “get_edit_posts_link();”-Tag oder -Hook nicht die gleichen Parameter zur Verfügung hat. Außerdem ist mir bei der ganzen Arbeit und Recherche aufgefallen, dass die Dokumentation von WordPress “durchaus” lückenhaft zu nennen ist. Manche Seiten sind z. B. nicht verlinkt, obwohl vorhanden. Über die normale Navigation hat man dann keinen Zugriff darauf. Das ist ein wenig so, wie wenn in einem Geschäft bestimmte Waren in einem anderen Raum lagern, es aber keine Tür für den Raum gibt. Der WordPress-Codex ist auf der einen Seite sehr hilfreich, auf der anderen Seite recht umständlich. Er ist eines auf jeden Fall nicht, ein Nachschlagewerk, ähnlich wie vielleicht CSS4you oder die PHP-Dokumentation. Mit beiden Ressourcen komme ich wesentlich besser zurecht. Die Strukturierung des Codex bedarf in meinen Augen dringend der Überarbeitung. Denn Beiträge, die auf andere Beiträge verweisen und diese wieder auf jene zurück, nicht immer allerdings mit demselben Linktext, sie verwirren den Suchenden. Er dreht sich manchmal im Kreis und merkt es gar nicht.

Hinzufügen zu del.icio.us, Mr. Wong, LinkARENA, SEOigg
Tags , , , ,
Kategorie Media · Autor · Keine Kommentare


Schreibe einen Kommentar


Top