WordPress aus Anwendersicht

Frontend-Nutzung

…

Backend-Nutzung

Custom Fields

Custom Fields sind Textfelder die der Schreiber füllen kann. Ich habe sie auch hier aufgeführt, da man mit diesen die Erscheinung des Blogs oder auch des Quelltextes im Header beeinflussen kann, ähnlich wie bei den Template Tags – nur dass man die Fields dann im Backend beim Schreiben eines Beitrages erst mit Inhalten füllt.

Quicktags

Quicktags sind bestimmte Kommentare im HTML Quelltext die nachdem Sie vom Editor abgeschickt werden, eine bestimmte Aktion in WordPress auslösen. Die Eingabe von <(!–nextpage–)> führt zu einem Seitenumbruch und die Eingabe von <(!–more–)> bestimmt die Länge des Auszugs. Die Klammern müssen weg, ich schrieb sie nur, damit mir WordPress hier nicht wirklich einen Seitenumbruch oder ein “weiterlesen” reinklatscht. Im Codex findet man eine Übersicht zu allen Quicktags und gerade für den Kommentierenden bieten sie die Chance deren Text zu formatieren.

WordPress aus Entwicklersicht

WordPress-Architektur und Abläufe

Conditional Tags

Mit den Conditional Tags kann man eine Unterscheidung treffen, beispielsweise ob es sich um eine Seite handelt oder nicht. Conditional-Tags kommen im Loop vor und auch bei der Gestaltung des Titels kann man damit spielen. Laut Codex kann man diese Tags benutzen, um die aktuelle Seite in der Navigationsleiste hervor zu heben. Ein weiterer Einsatz ist eine Prüfung bei der Veröffentlichung eines Kommentars, ob der Beitragsautor den Kommentar geschrieben hat und daraufhin das Format ändern. Des Weiteren kann man bestimmte Seiten von Suchrobotern ausschließen und andere nicht.

Loop

Der Loop ist das Kernstück in WordPress und dort gibt es eine Vielzahl der Conditional Tags. Im Loop kann man einige sinnvolle Ergänzungen einbauen: ich werde einen Verweis zum Glossar einbauen und ein Plugin (‘Share this’) liefert einen Link, mit welchem der Leser ein ‘Social Bookmark’ setzen kann oder den Feed des Blogs abonniert. Der Loop kann sinnvoll ergänzt werden und so kann man mit diversen Hintergrundfarben und Grafiken spielen. Bei Yaml bietet es sich an, dass man aus Suchmaschinensicht den Inhalt in der Col1, welche im Quelltext ganz oben steht einspeist. Ich muss mir das mal durch den Kopf gehen lassen und in der Yaml-Doku nachlesen, was da die Vor- und Nachteile sind.

Templates

Templates sind Dateien, die im Verzeichnis des Themes liegen und von WordPress inkludiert werden, so holt die Funktion get_header() die Datei ‘header.php’ und setzt diese in die aufgerufene ‘index.php’. Neben der Methode per Funktion die Templates einzubinden, kann man den Pfad auch direkt angeben. Mit der Konstanten ‘TEMPLATEPATH’ wird automatisch der Pfad zum Theme-Verzeichnis gelegt. Mit der Variable ‘ABSPATH’ zum WordPress-Wurzelverzeichnis. So kann man jedes beliebige PHP-Skript in WordPress laden.

Die Templates werden in einer bestimmten Hierachie angelegt, so wird erstmal geschaut, ob die aufgerufene Seite vorhanden ist und falls nicht die ‘index.php’ geladen. Ein Bild im Codexbeitrag verdeutlicht das Zusammenspiel ganz gut. Neu war für mich, dass es eine extra ‘attachment.php’ und eine ‘author.php’ gibt und dass ein Druck auf ein Schlagwort die ‘category.php’ lädt.

Template Tags

Template Tags sind PHP-Funktionen, die in die Templates geladen werden. Diese Template Tags steuern dann das Erscheinungsbild des Blogs. Einer Funktion kann man möglicherweise Parameter zuwerfen. Diese Funktionsparameter sind Variablen, die diese Funktion benötigt.

Es gibt eine Übersicht über die Template Tags in deutsch und eine Codex-Kategorie. Grundsätzlich muss man sich oft im Sourcecode orientieren und will vielleicht mal die Funktion genau unter die Lupe nehmen, hier entdeckte ich eine Onlineansicht des WordPress Codes mit Syntax-Highlighting. Man sieht sich also den Code der ‘index.php’ an, dort steht der Loop, dort steht die Funktion ‘the_content’, ein Mouseover zeigt den Ort der Funktion an, hier die ‘wp-includes/post-template.php’.

Es gibt drei Arten von Template Tags: einmal haben wir welche die keine Parameter benötigen, einmal haben wir welche die Parameter, wie gewöhnliche PHP-Funktionen akzeptieren (Function-Style-Parameter). Es gibt Funktionen, die Parameter erwarten und dabei einen Query-String nutzen, das funktioniert ähnlich, wie wenn man Variablen via GET-Methode von Skript zu Skript schickt. Diese Funktionen sind meist nur Wrapper für die Funktionen, die Parameter und zwar sehr viele Parameter erwarten.

Frank Bültge nennt in seinem Buch das Beispiel wp_get_archives und get_archives: wp_get_archives ist die gleiche Funktion wie get_archives nur mit Parametervoreinstellung und einer kleinen Abfrage, ob eine Änderung zur Voreinstellung mitgeliefert wurde. Als Programmierlaie klingelt bei mir bei der GET Methode gleich immer die Sicherheitsrassel, dafür ist dann wohl auch die wpspecialchars – Funktion da.

Template Tags können auch ineinander verschachtelt werden, also ein Template Tag ist sozusagen ein Parameter eines anderen Template Tags. So binden viele Template Tags wiederum andere Funktionen aus dem WordPress-Kern ein.

Eigene Funktionen kann man auch definieren und als Plugin andocken. Die so definierten eigenen Funktionen stehen dann in der Datei ‘functions.php’ im Themeordner und werden von WordPress eingebunden.

Theme-Entwicklung

Eine Internationalisierung kann man durch das voranstellen der Funktion _e(‘blabla’) erreichen oder wenn man einen Text im Funktionsnamen ändern will mit ‘__(‘blabla’)’. Das System dahinter nennt sich gettext.

Durch eine Funktion muss eine Anfrage an den Server gestellt werden – das ist schlecht, wenn es um die Performance geht und so macht es Sinn das eigene Theme nicht zu internationalisieren. Ich kann nicht einschätzen, wieviel Zeit ein internationalisiertes Theme länger für einen Seitenaufruf braucht als ein lokalisiertes.

Das Gleiche ist mit den Angaben im Header, man kann dort viele Sachen via Funktion abfragen (Spracheinstellung, Zeichensatz und Schreibrichtung, ‘lang’- und ‘dir’-Attribut des HTML-Tags im Header) – gut fürs öffentliche Theme, das eigene tackere ich lieber fest. Die Voreinstellung ist bei den Suchrobotern index follow, somit kann man sich diese Angabe sparen, bzw. muss extra eine Angabe setzen, wenn man das indizieren verhindern will. Das hat sich mittlerweile denke ich geändert.

Das xfn im Header fördert das semantische Web, ist wohl ein Microformat, und im Backend kann man seiner Blogroll erweiterte Angaben machen. Eine ähnliche Geschichte sind die Geotags, so kann Google diese Angabe beispielsweise nutzen und bei der Eingabe der dazugehörigen Stadt die Seite höher bewerten.

Die Weiterblättern-Funktion zwischen den Seiten gibts ein Plugin namens ‘Pagebar’, und eine Funktion die ich mir da mal ansehe ist die ‘posts_nav_link’ und die ‘previous_post_link’ und die ‘next_post_link’.

Bei den Funktionen muss man aufpassen, so liefern die Funktionen eine ID nun zweimal, sofern man ein Layout nutzt, welches auf Yaml setzt, nämlich die ID “navigation” – eine Lösung beschreibt Michael Preuß.

Neben der Weiterblättern-Funktion am Seitenende kann eine sogenannte Breadcrumbnavigation sinnig sein. Ich werde noch darauf verzichten, da ich versuche stark verschachtelte Seitenhierachien zu vermeiden und denke in meinem Fall besteht da vorerst kein Bedarf.

Widgets und eine händische Sidebar müssen sich nicht ausschließen. Man kann die Widgets-Funktion also auch erst ab halber Sidebar aufrufen. Gerade wenn man ein Yaml-Theme nutzt ist es für den Laien oftmals schwierig zu entscheiden, ob nun eher in der Yaml-Dokumentation oder im WordPress-Codex nachgesehen werden soll.

Einige Blogs legen viele Funktionen in den Footer, wie das geht beschreibt Perun und erklärt auch gleich wie er via Plugin ‘Get Recent Comments’ die Trackbacks von den Kommentaren trennt.

Bei der Sicherheit sollte man darauf achten, die Funktion wpspecialchars zu nutzen, wenn etwa Daten über die URL reinkommen.

Bei jedem Theme hat man eine Lizenz, die es zu respektieren gilt, beispielsweise ist WordPress zwar OpenSource, aber Yaml steht beispielsweise unter einer CreativeCommons. In jedem der Projekte stecken wohl tausende von Stunden und so sollte der Link am Ende nicht fehlen, sofern er verlangt wird.

Plugin-Entwicklung

…

Tools um WordPress herum

Als Zusatz nutze ich das Programm Gimp für die Bildbearbeitung und Inkscape für Zeichnungen, falls ich es mit Gimp nicht hinbekomme. Bei Vektorgrafiken bin ich kein Spezialist, wie man sich aus dieser Äußerung denken kann. Als Betriebsystem habe ich Ubuntu. Alles in allem kostet mich also das Bloggen nur die Gebühr für meinen Webspace.

Yaml stellt für die Navigation bereits einige Möglichkeiten vor, eine Liste der WordPress-Seiten bietet sich an und gerade wenn es dann verschachtelt wird, wirds tricky. Michael hat sich da schon einen Kopf gemacht.

Yaml bedient mit einem Stylesheet den Internet Explorer mit einem Conditional Comment, gerade die Pfadangaben können bei Yaml Probleme bereiten und so sollte man gegenprüfen ob alle Stylesheets fassen. Die Angabe ‘/’ beim Start des Pfades lässt die Suche im Wurzelverzeichnis starten und, die WordPress-Variable ‘ABSPATH’ und ‘TEMPLATEPATH’ wurden oben bereits erwähnt.

Theme-Style-Guide

WordPress Nutzer werden oftmals auf den WYSIWYG-Editor “TinyMCE” setzen. Nun hat der manchmal seine Schwächen und wenn man einige Regelmäßigkeiten beachtet, kann man den Quelltext gleich selber schreiben. WordPress liefert standardmäßig XHTML aus und dies bietet eine Vielzahl logischer Auszeichnugnsmöglichkeiten. Ebenfalls macht der Styleguide Sinn um ein Theme zu testen- schnell sieht man, wo nach und nach Hand ans Theme oder die CSS-Datei zu legen ist.

Überschrift ersten Grades

Immer bedenken, dass nur die Tags verwendet werden, welche der Doctype zulässt. Gebräuchliche Doctypes sind “HTML 4.01″ “XHTML1.0″ und “XHTML1.1″.
“XHTML1.0″ erlaubt die gleichen Tags wie “HTML4.01″ und es gibt die gleichen Ausprägungen “transitional”, “strict” und “frameset”. “XHTML1.1″ ist als Neuanfang zu sehen: es gibt weder die Variante “transitional” noch einen Doctype. HMTL5 ist im Kommen, das neue Standardtheme etwa setzt auf HTML5.

WordPress nutzt XHTML1.0 transitional, hier sind 89 Tags erlaubt, die Tags in Klammern sind in der XHTML1.0 Variante “strict” verboten, und alle Tags, welchen ein “-” angestellt ist, haben keinen schließenden Tag, wie beispielsweise bei einem Zeilenumbruch <br /> .
Hier nun die Aufzählung der Tags: a, abbr, acronym, address, (applet), area-, b, base-, (basefont-), bdo, big, blockquote, body, br-, button, caption, (center), cite, code, col, colgroup, dd, del, dfn, (dir), div, dl, dt, em, fieldset, (font), form, h1, h2, h3, h4, h5, h6, head, hr-, html, i, (iframe), img-, input-, ins, (isindex-), kbd, label, legend, li, link-, map, (menu), meta-, (noframes), noscript, object, ol, optgroup, option, p, param, pre, q, (s), samp, script, select, small, span, (strike), strong, style, sub, sup, table, tbody, td, textarea, tfoot, th, thead, title, tr, tt, (u), ul, var.

Größtenteils reichen zum Bloggen ja die Überschriften h1 bis h6, die Absätze und die Inlineelemente, dazu noch ein paar Listen für die Aufzählungen und manchmal eine Tabelle, gerade da nervt es, dass der WordPresseditor da standardmäßig streikt. Wenn was größeres ansteht, muss man dann bei SelfHTML nachgeschlagen.

P steht für einen Absatz und sollte auch nicht anders verwendet werden. Es ist ein Blockelement, diese erzeugen einen Bruch im Textfluss. XHTML bietet eine Reihe von Elementen zur logischen Textauszeichnungen. Bei den logischen Auszeichnungen greift die Standardeinstellung des Browsers, sofern diese nicht via CSS verändert werden.

In diesem Absatz hier sind Elemente untergebracht die das Absatzgefüge nicht durchbrechen, daher werden diese als Inlineelemente bezeichnet. Es gibt logische, physische und rein präsentative Inlineelemente zur Textauszeichnung.
Logische und Elemente sind beispielsweise
das em-tag für emphatisch oder betont, das strong-Tag als Steigerungsform des em-Tags für stark betont, das code-Tag für die Angabe von Quellcode , das samp-tag für die Ausgabe eines Beispiels, das kbd-tag für Tastatureingaben , das var-Tag für dies ist eine Variable, das cite-tag für dies ist ein Zitat , das dfn-tag für dies ist eine Begriffsdefinition , das acronym-tag formatiert eine Abkürzung und das das q cite=”http://www.xyz.de zeigt ein Zitat an, welches sich auf folgende Quelle bezieht.

Weitere empfehlenswerte Inlineelemente sind das span-tag als inhaltsleeres Element, sozusagen als sonstiges Element für alles, was in keine andere logische Kategorie passt,
das a-tag in Verbindung mit href als Anker samt Verknüpfung, weitere Attribute sind accesskey, name, tabindex, target, title. Links können mit einer class versehen werden, somit ist es möglich per CSS, beispielsweise die internen von den externen Links abzuheben oder PDF-Downloads mit einer Grafik als Hintergrund zu versehen.

Soweit möglich sollte logisch ausgezeichnet werden, andernfalls sollten Elemente genutzt werden, welche mit dem Doctype vereinbar sind, WordPress nutzt hier derzeit “XHTML 1.0 Transitional”. Einige Beispiele für physische und rein präsentative Tags zum Theme-CSS-Test, wie das btag um Text fett zu machen, das i-tag um Text kursiv erscheinen zu lassen, das tt-tag bewirkt diktengleichen Text ähnlich eines Fernschreibers, das u-tag erzeugt einen unterstrichenen Text, das strike-tag bewirkt einen durchgestrichenen Text, das s-tag bewirkt ebenfalls einen durchgestrichenen Text , das big-tag bewirkt größer formatierten Text , das small-Tag bewirkt kleiner formatierten Text, das ^{sup-tag bewirkt hochgestellten} , das _{sub-Tag bewirkt tiefgestellten Text}, das blink-tag bewirkt blinkenden Text.

Überschrift zweiten Grades

Neben den Inline-Elementen gibt es noch die Blockelemente, diese erzeugen einen eigenen Textabsatz im Element und können Inlineelemente enthalten, einige Blockelemente können sogar weitere Blockelemente enthalten, im Bedarfsfall einfach nachlesen. Mit CSS kann man anschließend ggf. noch etwas Tricks und Inlineelemente als Block anzeigen lassen oder Blockelemente inline. Blockelemente sind beispielsweise Absätze, Listen, Tabellen und Formulare.

Überschrift dritten Grades

Hier kommen die Listen, es gibt geordnete, ungeordnete und Definitionslisten. Ungeordnete haben Bullets als Aufzählungszeichen, geordnete Zahlen und Definitionlisten erhalten Einrückungen.

• erstes ungeordnetes Listenelement
• zweites ungeordnetes Listenelement
• drittes Element mit Unterliste
  1. erstes verschachteltes geordnetes Element
  2. Achtung bei verschachtelten Listenelementen
  3. das erste Listenelement bleibt geöffnet, es folgt das ol bzw ul
  4. und nach dem schließenden ol bzw ul der verschachtelten Liste
  5. wird erst das li Element der Hauptliste geschlossen
• hier steht das letzte Element der Hauptliste, samt dem Listenschluss

Das dl kündigt die Definitionsliste an, das dt das erste Element

das dd ist die Defintion zum ersten Listenelement

es kann auch mehrere Defintionen zum ersten dt geben

Überschrift vierten Grades

Jetzt geht es um die Tabellen. WordPress bietet in der Version standardmäßig keine Tabellenunterstützung. Grund also, schnell die nötigen Tags zu erklären.
Pflichtmäßig braucht man nur die Tags “table” für den Tabellencontainer, “tr” für tabelrow als Zeilencontainer und “td” für die Datenzeile. Es gibt dann noch das “td” für eine Kopfzeile und einige weitere Tags und Attribute, falls die Tabelle etwas anspruchsvoller sein soll.

Überschrift fünften Grades

Letzter Punkt sind die Formulare. Hier gibt es für WordPress-User die Anwendung als Kommentarbox. Und da die Formularelemente recht großen Spielraum bieten, gehe ich auch nur auf diese ein. “form” für den Formularcontainer, dann das input Element, das braucht das Attribut “type”, denn es gibt zehn Möglichkeiten zur Auswahl, beispielsweise eine Textbox (text) oder ein Feld zum Anhaken (checkbox). Für mehrzeilige Eingabefelder steht das Container-Element “textarea” zur Verfügung.
Zusätzlich muss es noch ein “action”-Attribut geben, damit das Formular weiß, wo es die Daten hinschicken soll. Barrierefreier werden die Formulare, wenn die Eingabefelder mit dem Tag “label” logisch verknüpft werden, und das Attribut “acceskey” verwandt wird – so werden die Input-Felder über Tastenkürzel ansprechbar. Bisschen blöd ist, dass die Inputfelder Inline-Elemente sind, somit muss man, um eine Zeilenstruktur sicher zu stellen mit dem “br”-Tag werkeln oder das Formular in eine Tabelle klatschen – oder mit CSS-Tricks die zeilenweise Anzeige sicher stellen, beispielsweise kann man auch Inlineelemente als Block anzeigen lassen. Formular sieht man unten.

Überschrift sechsten Grades

Sodala, dann bin ich fertig, meine Seiten sind noch keinesfalls passend ausgezeichnet, wobei ich da nach und nach schon mal etwas nachlegen werde. Ich bin für Kommentare zur Ergänzung dankbar, wenn ich mal falsch liege, oder es etwas zu ergänzen gibt.