Beiträge (RSS)
Ein paar Grundregeln für die Theme-Erstellung
Die Anforderungen an ein zur allgemeinen Benutzung freigegebenes Theme sind etwas anders – strenger – als jene für das Theme, welches man für seine eigene WordPress-Installation in Gebraucht hat. Das Theme soll schließlich auf den unterschiedlichsten WordPress-Installationen lauffähig sein.
Da ich ja nun schon ein bißchen Erfahrung in der Theme-Erstellung gesammelt habe, möchte ich die nun hier weitergeben.
Alle HTML-Tags in der style.css berücksichtigen
Ganz besonders wichtig sind natürlich jene Tags, die standardmäßig im Beitragseditor als Quicktag angezeigt werden. Aber auch alle anderen HTML-Tags sollte man nicht außer acht lassen, denn Nutzer mit HTML-Kenntnissen nutzen häufig weitere Tags, die sie ggfls. dann auch in ihre Quicktag-Bar einbinden. Bei den zu formatierenden Tags auch die HTML-Tabelle nicht vergessen!
Widget-Unterstützung
Die erst als PlugIn erhältliche und seit Version 2.1 fest implementierte Widget-Funktion erfreut sich wachsender Beliebtheit, so dass eigentlich kein Theme mehr ohne Widget-Unterstützung “ausgeliefert” werden sollte. Insbesondere unerfahrenen Usern wird hier ein komfortables Werkzeug an die Hand gegeben, um seinen Blog auch ohne Kenntnisse in der Theme-Erstellung individuell anzupassen.
Kompatibilität auch für ältere Versionen
Je mehr Versionen und hauseigene Funktionen das Theme abdeckt, umso besser: Das Theme einem möglichst großen Kreis von Usern zugänglich machen. Nicht alle Nutzer bloggen stets mit der aktuellen Version von WordPress, insbesondere wenn Umstellungen an der Datenbank angekündigt werden. Da habe ich besonders bei den nicht so erfahrenen Usern in öfters Zurückhaltung bemerkt. Aber auch versierte User halten sich zurück, weil beispielsweise einige wichtige PlugIns mit der neueren Version (noch) nicht funktionieren. Ferner pflegt WordPress nach wie vor den Versionsstrang 2.0*
Unabhängigkeit von PlugIns
PlugIns erweitern die Funktionalität von WordPress und es gibt viele von diesen kleinen Zusatzprogrammen, die wirklich überaus nützlich sind. Teilweise funktioinieren PlugIns jedoch nur, wenn neben der Aktivierung im PlugInbereich auch eine Anpassung bzw. Ergänzung im Theme vorgenommen wird. Die Versuchung ist groß, das eigene LieblingsplugIn ins Theme zu implementieren. Grundsätzlich ist davon dringend abzuraten, denn wenn das PlugIn nicht vorhanden oder aktiviert ist, steigt meist der ganze Blog mit einer Fehlermeldung aus. Der unbedarfte User ist nicht in der Lage, per Direkteinstieg in sein Adminmenü zu gelangen und dort das fragliche PlugIn nachzuinstallieren bzw. zu aktivieren.
Umgehen kann man das Problem, indem man das Vorhandensein eines PlugIns (beispielsweise die beliebte Seitennavigation Pagebar, die das hauseigene NächsteSeite/Vorherige Seite
ersetzt) mit einigen Zeilen PHP-Code abfragt:
<?php
if (function_exists('wp_pagebar')) {
wp_pagebar(array('before'=> 'Seiten: '));
}
else { ?>
<div class="prev"><?php previous_posts_link('« Neuere Einträge ') ?></div>
<div class="next"><?php next_posts_link('Frühere Einträge »') ?></div>
<?php } ?>
Trotzdem damit bitte sparsam sein – der Themecode wird dadurch immer mehr aufgebläht, was sich dann irgendwann zwangsläufig auf die Performance auswirkt.
Nicht sparsam sein mit Kommentaren
Ein gewissenhafter Programmierer macht es immer: Den Quelltext ausreichend dokumentieren. “Ausreichend” bedeutet: Dass man 1.) sich selbst auch nach langer Zeit schnell wieder im Code zurechtfindet und 2.) der Code auch für Außenstehende nachvollziebar ist. Insbesondere wenn man das Theme gewerblich für einen Kunden erstellt, spart gut dokumentierter Code bares Geld, weil Zeit für redundante Recherchen und Tests eingespart wird.
Mehrsprachen-Fähigkeit
Hierüber mögen sich die Geister scheiden, aber eines ist sicher: Mit einem lokalisierten Theme spricht man noch mehr WordPress-User an – nämlich weltweit. Wenn man sich für die Lokalisation entscheidet, sollte die Ausgangssprache Englisch sein und eine deutsche Sprachdatei beigelegt werden. Englisch deswegen, weil WordPress selbst englischsprachig ist (auch das deutsche WP spricht ja bekanntermaßen nur über eine Sprachdatei deutsch mit uns) und Englisch im Gegensatz zu Deutsch in vielen Ländern der Welt verstanden wird und somit ohne weiteres in die eigene Muttersprache übersetzt werden kann.
Zwei Sidebars im WordPress anzeigen
Diese Frage taucht ab und zu mal wieder im Wordpres-Forum auf – es war auch meine erste Frage dort, als ich vor fast zwei Jahren meine ersten Gehversuche mit WordPress machte. Im deutschen WordPress-Forum habe ich dazu mehrere Lösungsansätze gefunden, einmal z.B. diesen hier und dann noch diesen.
Wirklich elegant finde ich keine der beiden Lösungen, weil in beiden Fällen in einer Struktur ein Element somit doppelt vorkommt. Ich löse das Ganze lieber über css.
Zunächst lege ich in der sidebar.php die Struktur fest, indem ich folgende id’s einfüge:
<div id="sidebar">
<div id="rechte_seite">
...
</div><!--Ende rechts Seite-->
<div id="linke_seite">
...
</div><!--Ende linke Seite-->
</div><!--Ende Sidebar-->
Um die Sidebar als rechte und linke Spalte nebem dem Inhaltsbereich anzeigen zu lassen, weise ich den beiden id’s “rechte_seite” und “linke_seite” folgende Formateigenschaften zu:
#rechte_seite {
float: right;
}
#linke_seite {
float: left;
}
Über die id #sidebar kann ich dann Formatierungen vornehmen, die für die gesamte Sidebar gelten sollen.
Dieser auf diese Art zweigeteilten Sidebar kann man dann auch zwei Widgetbereiche zufügen:
<div id="sidebar">
<div id="rechte_seite">
<?php if ( function_exists('dynamic_sidebar') && dynamic_sidebar('rechte_sidebar') ) : else : ?>
...
<?php endif; ?>
</div><!--Ende rechts Seite-->
<div id="linke_seite">
<?php if ( function_exists('dynamic_sidebar') && dynamic_sidebar('linke_sidebar') ) : else : ?>
...
<?php endif; ?>
</div><!--Ende linke Seite-->
</div><!--Ende Sidebar-->
… und so sieht das für die beiden Widgets in der functions.php aus:
<?php
if ( function_exists('register_sidebar') )
register_sidebar(array(
'name' => 'linke_sidebar',
'before_widget' => '',
'after_widget' => '',
'before_title' => '<h2>',
'after_title' => '</h2>',
));
if ( function_exists('register_sidebar') )
register_sidebar(array(
'name' => 'rechte_sidebar',
'before_widget' => '',
'after_widget' => '',
'before_title' => '<h2>',
'after_title' => '</h2>',
));
?>
Nur zu Weihnachten: Template XmasCat
Passend zur Weihnachtszeit gibt es ein neues Template:
“XmasCat” hat ein fixes Layout ab Fenstergröße 800×600 und ist mit ein paar technischen Raffinessen ausgestattet. Die Menüboxen lassen sich einklappen und an beliebige Stelle innerhalb des Menüs verschieben. Realisiert wird das Ganze mit JavaScript und die Technik wird von Browsern der neueren Generation (ab IE 6) und eingeschaltetem JavaScript unterstützt. Für alle, die mit älteren Browsern oder ohne JavaScript-Unterstützung unterwegs sind, gibt es keine Einschränkung für die Nutzung der Inhalte – das Menü ist lediglich fest.
Das XHTML-Gerüst des Templates ist valide nach den gültigen Regeln des W3C. Das CSS-Layout verwendet für die Transparenz der Menüboxen die CSS3-Eigenschaft opacity und validiert daher nicht. Für die Nutzbarkeit des Templates ist dieses jedoch ohne Belang.
XmasCat ist widgetfähig und bringt für eine schönere Darstellung einige eigene Widgets mit. Die Bezeichnung beginnt mit XmasCat [...] und ist den hauseigenen Widgets vorzuziehen.
Template Chestnut
“Chesnut” hat ein halb-fluides Layout. Bis zu einer gewissen Größe paßt sich das Layout der Größe des Browserfensters an, danach ändert sich die Breite nicht mehr. Somit werden bei sehr großen Auflösungen die Zeilen nicht zu lang. Ältere IE-Browser unterstützen die css-Angabe maxwidth jedoch nicht und zeigen daher immer Vollbild an. Enthalten ist ein spezielles Seitentemplate zur Darstellung einer Tag-Wolke für die in WordPress 2.3 neue Tagging-Funktion.
“Chestnut” funktioniert mit allen bei WordPress Deutschland erhältlichen Versionen ab 1.5.2 
Das Template ist valide im Sinne des W3C.
Änderungen an den Templates
Ich habe nun alle Templates vorbereitet für die neue Tagging-Funktion in WordPress, nun sind sie von Version 2.0 bis einschließlich Version 2.3 voll nutzbar.
Update auf WordPress 2.3
Seit gestern ist WordPress Version 2.3 in der deutschsprachigen Version bei WordPress Deutschland erhältlich.
Der Versionssprung von 2.2.* auf 2.3 zeigt an, dass es sich dieses Mal um ein echtes
und größeres Update handelt und nicht nur um ein Sicherheits- und Fehlerbereinigungsupdate. Es werden auch Veränderungen an der Datenbank vorgenommen, unter anderem ist die Tabelle wp_post2cat weggefallen, deswegen funktionieren Tag-Plugins wie Simple Tagging und Jerome Keywords zur Zeit nicht mehr. Da hilft nur Abwarten, bis die PlugIn-Autoren tätig werden oder man nutzt die neu hinzugekommende Tag-Funktion von WordPress.
Dieser Blog läuft seit soeben unter der neuen Version 2.3 und meine Templates funktionieren alle
WordPress- Version 2.2.1
Nun ist sie schon einige Tage “draußen” und meine Blogs laufen prima und stabil. Auch an die neue Vorschau-Funktion – die Vorschau öffnet sich jetzt im neuen Fenster und erscheint nicht mehr unten auf der Beitragschreiben-Seite – habe ich mich gewöhnt.
Ganz neu seit Version 2.2 ist die standardmäßige Unterstützung von Widgets, man braucht hierfür nun kein PlugIn mehr.
Neue Updates für WordPress: 2.1.3 und 2.0.10
“Eins, zwei drei im Sauseschritt…”
ist der Beginn eines alten Kinderliedes und manchmal glaube ich, es ist auch die Hymne der WordPress-Programmierer – der Intervall der WordPress-Updates im letzen halben Jahr gleicht fast einem Maschinengewehrfeuer 
Seit einigen Tagen stehen auf der deutschen WordPress-Homepage die aktuellen Installationspakte zur Verfügung und Upgrade-Pakete für bestehende Installationen.
Es handelt sich diesmal um reine Sicherheits- und Fehlerbereinigungsupdates, Veränderungen an der Datenbank finden nicht statt. Trotzdem: Vorheriges BackUp nicht vergessen!
Hier und da wurde über die häufigen Updates schon etwas Unmut geäußert. Klar, es ist immer wieder ein Angehen mit dem Update, aber der Feind schläft nunmal nicht und es gibt immer wieder neue Angriffsmöglichkeiten auf die Systeme. Und das macht den Angreifern umso mehr Spaß, je populärer die Software ist. WordPress ist inzwischen ziemlich populär und ich bin den Programmierern dankbar, dass sie Ihr “Baby” so sorgfältig pflegen und beschützen.
Flexibilität für meine Templates
Meine Templates waren bislang alle für WordPress ab Version 2.1 ausgestattet, doch nun funktionieren sie auch mit WordPress ab 2.0.
In der 2.1er Version hatte es ja einige Neuerungen gegeben. Perun hat eine kleine PHP-Abfrage entwickelt, um beide Versionen bedienen zu können. Vielen Dank dafür! 
Template Grape
“Grape” hat ein halb-fluides Layout. Bis zu einer gewissen Größe paßt sich das Layout der Größe des Browserfensters an, danach ändert sich die Breite nicht mehr. Somit werden bei sehr großen Auflösungen die Zeilen nicht zu lang. Ältere IE-Browser unterstützen die css-Angabe maxwidth jedoch nicht und zeigen daher immer Vollbild an.
Teile des Templates ist transparent. Das wird von Opera kleiner 9.0 und IE kleiner 5.5 nicht angezeigt und ist auch nicht valid im Sinne des W3C. Die Nutzbarkeit wird dadurch nicht eingeschränkt.
Wegen dieser Transparenz eignet sich das Template nicht für sehr foto- und grafiklastige Blogs – es sei denn, du entfernst die Transparenz im css, diese Veränderung des Layouts ist in diesem speziellen Fall erlaubt.
Ebenso wie alle anderen Templates ist auch “Grape” mehrsprachenfähig (Standardsprache ist englisch), die deutsche Übersetzung ist bereits enthalten. Die mitgelieferte Datei im .pot-Format erlaubt die Übersetzung des Templates in weitere Sprachen.