Gabis Wordpress-Templates

Themes und nützliche Tipps für WordPress-Weblogs

Archiv: Dezember 2007

Dez 292007

Das Template Kitchen habe ich in den letzten Tagen optisch und technisch ein bißchen überarbeitet.

Screenshot Kitchen
Download

Auf der Startseite wird nun der erste Beitrag in vollem Umfang angezeigt, die weiteren Beiträge werden als Auszüge in zwei Spalten angezeigt als sogenannte “Teaser”. Ferner habe ich ein extra Stylesheet für den Ausdruck eingefügt: Es wird nur der Beitrag ausgedruckt, keine Navigation, kein Kopf- und Fußbereich, die für einen Ausdruck ohnehin nicht wichtig sind.

Das Theme hat nun ein festes Layout für eine Auflösung ab 1.024 x 768px, sonst funktionieren die beiden Spalten im Inhaltsbereich nicht richtig.

Dez 242007

<?php if (have_food()) : while (have_food()) : the_food(); ?>
<?php the_food('Eat the rest of the food &raquo;'); ?>
<?php endwhile; else: ?>
<?php include (TEMPLATEPATH . "/searchfood.php"); ?>
<?php endif; ?>

Fundstück im WordPress-Forum von Barbara :smile:

Dez 232007

WordPress Deutschland hat vor kurzem den Themepool relauncht. Dieser ist nun nicht nur wesentlich komfortabler für diejenigen, die ein Theme suchen, sondern auch für diejenigen, die ein Theme dort veröffentlichen möchten.

Deswegen habe ich es nun auch einmal gewagt und mein neuestes Theme SquareRoot und das hier beliebteste Theme Nature dort angemeldet. Beide wurden aufgenommen *freu* und auch im Theme-Pool erfreut sich “Nature” recht guten Zuspruchs ;-)

Dez 232007
Screenshot Streetlife
Download

“Streetlife” hat ein ein halbfluides Layout, das von modernen Browsern unterstützt wird. Ältere IE-Browser bekommen ein fixes Layout in der Auflösung 1.024×768 angezeigt.

Enthalten ist ein spezielles Seitentemplate zur Darstellung einer Tag-Wolke. Ferner wird ein eigener Standard-Gravatar mitgeliefert, der im Admin-Bereich ausgewählt werden kann. Unterstützt wird auch die Funktion, auf Kommentare zu antworten und natürlich die hauseigene Galerie-Funktion.

“Streetlife” funktioniert ab WordPress Version 2.3.

Dez 192007
Screenshot SquareRoot
Download

“SquareRoot” 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 für diese Browser habe ich die Breite auf 1000px festgesetzt. Enthalten ist ein spezielles Seitentemplate zur Darstellung einer Tag-Wolke für die in WordPress 2.3 neue Tagging-Funktion.

Das Template ist valide im Sinne des W3C.

Dez 132007

Im Beitrageditor in der Code-Ansicht von WordPress sind beide Quicktags standardmäßig integriert und im visuellen Editor zumindest der more-Tag. Grund genug, beiden bei der Theme-Erstellung etwas Aufmerksamkeit zu schenken.

<!--more--> wird eingesetzt, um einen Artikel an einer beliebigen Stelle zu teilen und mit einem “weiterlesen…”-Vermerk zu versehen sowie gleichzeitig dem Link zum vollständigen Artikel.

Mit <!--page--> lässt sich ein Artikel auf mehrere Seiten aufteilen, unter dem Beitrag stehen dann die Seitenzahlen. Jede Zahl ist mit einem Link zum zur jeweiligen Seite des Artikels versehen.

Sowohl the_content als auch wp_link_pages lassen sich mit Parametern (zwischen den Klammern) erweitern:


<?php the_content('weiterlesen... &raquo;); ?>
<?php wp_link_pages('Seiten:'); ?>

<?php the_content('weiterlesen... &raquo;); ?> wird überhaupt erst nutzbar, wenn man dort was eingibt, während (‘Seiten’) in <?php wp_link_pages(); ?> lediglich das Wort “Seiten” vor die Seitenzahlenfolge stellt.

Die beiden Template-Tags werden in in den jeweiligen Template-Dateien teilweise unterschiedlich behandelt. In der index.php und deren Verwandte, wie z.B. eine archive.php und search.php, werden beide Quicktags angezeigt.

In der single.php und der page.php wird nur <?php wp_link_pages(); ?> angezeigt, denn ein “weiterlesen…” – Vermerk macht hier logischerweise wenig Sinn.

Dez 102007

WordPress liefert für alle hauseigenen Template-Tags in der Sidebar (Suche, Kategorien, Tags, Archiv, Kalender, Links, RSS, Seiten und Meta) eigene Widgets mit. Diese Widgetfunktionen sind in der Datei includes/widgets.php verankert. Wenn man ein widgetfähiges Theme erstellt und das Layout-Gerüst für die Standard-Sidebar soweit steht, sollte man auf jeden Fall eine “Widget-Probe” machen, indem man sie einmal alle in die Sidebar zieht und sich das Ganze dann ansieht.

Die standardmäßige HTML-Struktur eines von WordPress erzeugten Widgets ist folgende:


Überschrift
<ul>
<li>...</li>
<li>...</li>
</ul>

In der funktions.php kann man ein wenig Einfluß auf die Struktur nehmen, man kann HTML-Code vor und hinter dem Widget einfügen, sowie den Titel in HTML-Tags auszeichnen.

Möchte man diese Strukur im Widget ausgeben (Beispiel Archiv):


<div class="box">
<h2>Archiv</h2>
<ul>
<?php wp_get_archives(); ?></ul>
</div><!--Ende box-->

… notiert man in der funtions.php wie folgt:


'before_widget' => '<div class="box">',
'after_widget' => '</div><!--Ende box-->',
'before_title' => '<h2>',
'after_title' => '</h2>',

Soweit, so gut – aber was ist, wenn die HTML-Strukur in der Sidebar sich mit den vorhandenen Möglichkeiten nicht abbilden lässt, wie etwa diese hier:


<div id="archives" class="dbx-box">
<h2 class="dbx-handle">Blog-Archiv</h2>
<div class="dbx-content">
<ul><?php wp_get_archives('type=monthly&limit=12'); ?></ul>
</div>
</div>

Die unglücklichste Lösung ist, die Struktur in der widgets.php anzupassen, es ist nicht zu empfehlen, die Core-Dateien von WordPress zu modifizieren, spätestens beim nächsten Update ist nämlich alles wieder beim Alten und die widgets.php muß erneut editiert werden. Und für Themes als Download-Angebot geht das logischweise schon gar nicht.

Dann bleibt noch die Möglichkeit, eigene Widgets zu erstellen. Das geschieht ebenfalls in der functions.php. Diese Widgets tauchen dann im Widget-Bereich zwischen all den anderen auf und man erkennt am Namen, welche zum Theme gehören. Für das oben genannte Beispiel sieht das so aus:


<?php function widget_meintheme_archives() {
?>
<div id="archives" class="dbx-box">
<h2 class="dbx-handle">Blog-Archiv</h2>
<div class="dbx-content">
<ul><?php wp_get_archives('type=monthly&limit=12'); ?></ul>
</div>
</div>
<?php
}
if ( function_exists('register_sidebar_widget') )
register_sidebar_widget('MeinTheme Archiv', 'widget_meintheme_archives');
?>

Erklärung der Einzelschritte:

Zuerst rufe ich das Widget ins Leben mit dem Aufruf:

function widget_meintheme_archives()

Dann folgt meine HTML-Struktur, die genauso aufgebaut ist wie in der normalen Sidebar:


<div id="archives" class="dbx-box">
<h2 class="dbx-handle">Blog-Archiv</h2>
<div class="dbx-content">
<ul><?php wp_get_archives('type=monthly&limit=12'); ?></ul>
</div>
</div>

…und zum Schluß frage ich ab, ob die Funktion vorhanden ist und wenn ja, rufe ich sie auf:


if ( function_exists('register_sidebar_widget') )
register_sidebar_widget('MeinTheme Archiv', 'widget_meintheme_archives');

Nun ist beim Einsatz des Themes im Widget-Bereich ein Archiv-Widget mit dem Namen MeinTheme Archiv zu finden. Dieses Widget bildet bei Verwendung die Struktur genauso ab wie in der ursprünglichen Sidebar – auch die Anzeige der Monate ist, wie im Original, auf 12 begrenzt.

Ferner hat man noch die Möglichkeit, die WordPress-Widgets mit individuellen css-Klassen zu versehen. Hierfür verwendet man in der functions.php als class und id eine Variable, das Ganze sieht dann so aus:


'before_widget' => '<li id="%1$s" class="widget %2$s">',
'after_widget' => '</li>',
'before_title' => '<h2 class="widgettitle">',
'after_title' => '</h2>',

Die auf diese Art erzeugten Bezeichnungen für ID’s und Klassen erfährt man, wenn man einfach mal sämtliche Widgets ins Theme zieht, speichert und sich dann den Quellcode der Seite anzeigen läßt. Nun kann man diese ID’s und Klassen in die style.css übernehmen und ihnen dort Formateigenschaften zuweisen.

Dez 102007

Wenn zu einem Beitrag die Kommentare geschlossen sind, erscheint bei vielen Themes statt eines deutschen “Kommentare geschlossen” “Comments off”. Die Ursache hierfür liegt in den nicht vollständig ausgefüllen Template-Tag für Kommentare.

Dieser Template- Tag ist zwar in der deutschen WordPres-Dokumentation aufgeführt, aber viel zu selten wird er in dieser Form genutzt.

Wenn man ein englischsprachiges Theme erstellt und es lokalisert, sieht der Template-Tag fogendermaßen aus:

<?php comments_popup_link(__('No Comments'), __('1 Comment'), __('% Comments'), '', __('Comments off')); ?>

“Comments off” darf man hier nicht weglassen (in der Meinung, urprünglich ist es ja sowieso auf Englisch), sonst kann man es für die Lokalisierung nicht ansprechen.

Dez 102007

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('&laquo; Neuere Eintr&auml;ge ') ?></div>
<div class="next"><?php next_posts_link('Fr&uuml;here Eintr&auml;ge &raquo;') ?></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.

Dez 092007

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>',
));
?>

Gabis Wordpress-Templates läuft unter Wordpress 3.0.1
Anpassung und Design: Gabis Wordpress-Templates
33 Verweise - 1.273 Sekunden.