Für das Versenden von E-Mails aus einem Theme oder Plugin heraus stellt uns WordPress die Funktion wp_mail() zur Verfügung. Diese ist der PHP-Funktion für den Mail-Versand sehr ähnlich, vereinfacht jedoch z. B. das Hinzufügen von Anhängen und ist durch Filter leicht veränder- oder erweiterbar.

Anwendung

Wie gesagt, ist die Funktion wp_mail() seinem ursprünglichen PHP-Pendant mail() sehr ähnlich und wird Euch daher bekannt vorkommen.

<?php wp_mail( $to, $subject, $message, $headers, $attachments ); ?>

• $to: mehrere Adressen durch Kommas trennen oder in einem Array übergeben
• $subject: Betreff als Text-String
• $headers: zumindest From: My Name <myname@mydomain.com> erforderlich
• $attachments: Array von Pfaden anzuhängender Dateien

Beispiel

Ein funktionierendes Beispiel von wp_mail() wäre folgendes:

<?php

    $mail_to = 'empfaenger@email.de';
    $subject = 'Betreffendes';

    $message = 'Ich will keine Message, ich will lieber ne Massage!';

    $headers = 'From: Dein Name <absender@email.de>' . "\r\n\";
    $attachments = array(WP_CONTENT_DIR . '/uploads/file_to_attach.zip');

    wp_mail($mail_to, $subject, $message, $headers, $attachments);

?>

Wichtig ist hierbei zu wissen, dass zum korrekten Versenden der Nachricht zumindest der zusätzliche Header From: mit der Absenderadresse nötig ist.

HTML-Mails

Standardmäßig ist der Content-type der durch wp_mail() versendeten E-Mails reiner Text (text/plain). Es ist also erstmal kein HTML möglich.

Mit dem Filter wp_mail_content_type kann man den Content-type verändern und auf text/html setzen:

<?php

    function wdm_contenttype($content_type) {
        return 'text/html';
    }

    add_filter('wp_mail_content_type','wdm_contenttype');

?>

Relevante Links

• WordPress Codex: wp_mail()
• PHP Manual: mail()

Seit der Version 2.7 steht uns in WordPress bei der Theme-Entwicklung die außerordentlich praktische und umfangreiche Funktion post_class() zur Verfügung. In komplexeren WordPress-Themes ist es manchmal nötig diese noch zu erweitern. Das ist auf verschiedene Arten möglich.

post_class() anwenden

Mit der WordPress-Version 2.7 wurde die Funktion post_class() eingeführt. Diese wird meist auf einen den Post im Loop umfassenden div-Container angewendet.

<div <?php post_class(); ?>>
    <!-- hier der post -->
</div>

Hier gibt die Funktion eine Reihe von CSS-Klassen aus, die für diesen Posts spezifisch sind (Post oder Page, Kategorie, Tags, sticky etc.).

post_class() erweitern

In komplexeren WordPress-Themes kann es nun vorkommen, dass diese Standardklassen nicht ausreichen und man den Post-Klassen weitere hinzufügen möchte.

Am einfachsten geht das wie folgt:

<?php post_class('meine-klasse noch-eine'); ?>

In diesem Fall würden die Klassen meine-klasse und noch-eine den Standardpostklassen hinzugefügt.

post_class() erweitern (functions.php)

Ein anderer Ansatz ist das Steuern der Post-Klassen zentral über die functions.php. Dafür bedienen wir uns dem WordPress-Filter post_class:

<?php

add_filter('post_class','my_post_classes');

function my_post_classes($classes) {
    $classes[] = 'meine-klasse';
    $classes[] = 'noch-eine';
    return $classes;
}

?>

Auch in diesem Fall würden die Klassen meine-klasse und noch-eine den Standardpostklassen hinzugefügt.

post_class() erweitern (functions.php & Conditional Tags)

Spannend wird es nun, wenn man die Post-Klassen mithilfe der Conditional Tags vom gezeigten Inhalt abhängig erweitert.

<?php

add_filter('post_class','my_post_classes');

function my_post_classes($classes) {
    if(is_front_page()) $classes[] = 'frontpage-klasse';
    if(is_singular()) $classes[] = 'singular-klasse';
    return $classes;
}

?>

Dieses macht Sinn, wenn man z. B. auf der Startseite Posts in mehreren Spalten anzeigen möchte. Dazu könnte man die Klassen z. B. um box erweitern.

Auch wenn man mit dem clearfix-Hack arbeitet, kann diese Funktion sehr nützlich sein.

<?php

add_filter('post_class','my_post_classes');

function my_post_classes($classes) {
    if(is_archive()) $classes[] = 'clearfix';
    return $classes;
}

?>

Relevante Links

• WordPress Codex: post_class()
• WordPress Codex: Conditional Tags

Bei der Erstellung von WordPress-Themes kommt es hier und da vor, dass z. B. für die Ermittlung eines Permalinks einer Seite die ID herausgefunden werden muss, wenn man nur den Titel zur Verfügung hat. Mit get_page_by_title() ist das ganz einfach zu lösen.

get_page_by_title() anwenden

Die Funktion kann wie folgt angewendet werden:

<?php get_page_by_title( $page_title, $output ) ?>

get_page_by_title() lässt zwei Parameter zu. Der erste dieser Parameter ist auf jeden Fall erforderlich. Dort wird der Titel der Seite als String angegeben, deren ID ich herausfinden möchte:

<?php get_page_by_title( 'Meine Seite' ) ?>

Optional kann man der Funktion einen zweiten Parameter mit auf den Weg geben. Dort lässt sich die Ausgabe der Funktion bestimmen. Standardmäßig liefert das obige Beispiel den Datensatz der Seite mit dem entsprechenden Titel als Objekt.

Ausgabe als Objekt

Die ID der Seite mit dem Titel Meine Seite könnte also wie folgt ausgegeben werden:

<?php
    $seite = get_page_by_title( 'Meine Seite' );
    echo $seite->ID;
?>

Ausgabe als numerischer Array

Eine weitere Möglichkeit ist die Ausgabe der Funktion als numerischer Array. Die ID der Seite mit dem Titel Meine Seite könnte damit wie folgt ausgegeben werden:

<?php
    $seite = get_page_by_title( 'Meine Seite', ARRAY_N );
    echo $seite[0];
?>

Ausgabe als assoziativer Array

Die letzte Möglichkeit für den zweiten Parameter ist der assoziative Array. Die ID der Seite mit dem Titel Meine Seite würde dann wie folgt ausgegeben werden:

<?php
    $seite = get_page_by_title( 'Meine Seite', ARRAY_A );
    echo $seite['ID'];
?>

Tabelle wp_posts

Natürlich lassen sich mit der Funktion get_page_by_title() auch andere Daten ausgeben. Besonders mit der Ausgabe als Objekt oder assoziativem Array ist es relativ leicht, darauf zuzugreifen. Eine Übersicht der zur Verfügung stehenden Daten kann im WordPress-Codex eingesehen werden.

Man könnte sich zum Beispiel die Anzahl der Kommentare damit wie folgt ausgeben lassen:

<?php
    $seite = get_page_by_title( 'Meine Seite' );
    echo $seite->comment_count;
?>

Neue Funktion get_page_id()

Wenn man die Funktion häufig und nicht den ganzen Datensatz sondern wirklich nur die ID benötigt und sich das Ganze noch einfacher machen möchte, kann man sich optional eine kleine Funktion schreiben und diese in der functions.php des Themes ablegen.

<?php
function get_page_id($page_name){
    $page = get_page_by_title($page_name);
    return $page->ID;
}
?>

Ich beschränke mit mit der Funktion auf einen Parameter (Titel der Seite) und verwende die Standardausgabe Objekt.

Diese Funktion verwende ich häufig in Verbindung mit Theme-Optionen, wo der Benutzer z. B. eine Seite aus einem Select-Dropdown auswählen kann, um optional einen Link unter einem Willkommenstext zu setzen. Dabei wird mir der Titel der Seite zurückgegeben.

Die ID erhalte ich mit der neuen Funktion get_page_id():

<?php
    $seiten_id = get_page_id( 'Meine Seite' );
?>

Um zum Beispiel einen Link mit einem Seitentitel zu generieren, kann ich meine neue Funktion in Kombination mit get_permalink() verwenden:

<a href="<?php echo get_permalink(get_page_id( 'Meine Seite' )); ?>">
    Meine Seite
</a>

Fazit

Man kann also mit WordPress-Boardmitteln und einer kleinen optionalen Erweiterung die ID einer Seite anhand ihres Titels sehr leicht herausfinden.

Relevante Links

• WordPress Codex: get_page_by_title
• WordPress Codex: Table – wp_posts
• WordPress Codex: get_permalink()

Um mit WordPress einen weiteren Schritt in Richtung CMS zu machen, kann man die Widgets der Sidebar oder jeder anderen Widget-Area in einem WordPress-Theme abhängig vom Inhalt anzeigen lassen. Im folgenden Beispiel unterscheide ich zwischen Sidebars für Startseite, Seiten, Artikeleinzelansichten und Kategorien.

Warum verschachtelte Widget-Areas?

Verschachtelte Widget-Areas bieten eine große Flexibilität. Man hat damit die Möglichkeit bspw. verschiedene Sidebars abhängig davon anzuzeigen, wo der Benutzer sich auf der Website befindet.

In meinem Beispiel werde ich abfragen, ob sich der User auf der Startseite, auf einer Seite, in einer Artikeleinzelansicht oder in einer Kategorie befindet. Um nicht obligatorisch für alle Fälle eine eigene Sidebar anlegen zu müssen, erstelle ich außerdem eine allgemeine Sidebar, die immer dann angezeigt wird, wenn für den jeweiligen Unterbereich keine Widgets definiert wurden.

Sprungmarken

• Erstellen einer Widget-Area
• Ausgabe der Widgets im Theme
• Erstellen mehrerer Widget-Areas
• Verschachteln der Widget-Areas

Erstellen einer Widget-Area

Zum Definieren der Widget-Area benötige ich die Funktion register_sidebar() (s.a. WordPress Codex). Der Funktionsname ist dabei ein wenig irreführend, da man damit nicht nur Widget-Areas in Sidebars, sondern natürlich auch im Footer oder sonstwo in den Theme-Dateien erstellen kann.

Folgenden Code trage ich in die functions.php im Theme-Ordner ein, um zunächst die allgemeine Sidebar namens Sidebar zu erstellen.

Code für functions.php

<?php
register_sidebar(array(
'name' => 'Sidebar',
'before_widget' => '<div id='%1$s' class='%2$s'>',
'after_widget' => '</div>',
'before_title' => '<h3>',
'after_title' => '</h3>'));
?>

Bemerkung:
Das Format für die Widgets ist somit festgelegt. Die Widget-Sidebar wird nun im WordPress-Admin bereits (wie oben im Bild zu sehen) angezeigt.

Ausgabe der Widgets im Theme

Jetzt muss dem WordPress-Theme noch gesagt, werden wo diese Widget-Area, wenn sie Widgets enthält (aktiv ist), angezeigt werden soll (s.a. Widgetizing Themes von Automattic).

Für den Aufruf der Widget-Area im Theme (in meinem Beispiel in der sidebar.php) wird die Funktion dynamic_sidebar() (s.a. WordPress Codex) verwendet.

Code für sidebar.php

<div id='sidebar'>

<?php if ( !dynamic_sidebar() ) : ?>

    <!-- hier werden die Widgets angezeigt -->
    <p>Inhalt der Sidebar, wenn keine Widgets aktiv sind.</p>

<?php endif; // endif dynamic sidebar ?>

</div><!-- end sidebar -->

Bemerkung:
In diesem Code liegt meine Sidebar in einem div mit der ID sidebar. Wenn mindestens ein Widget aktiv ist, wird dieses innerhalb der if-Abfrage angezeigt.

Erstellen mehrerer Widget-Areas

In der functions.php lege ich nun auch die übrigen Widget-Areas an, die wir dann später in der Sidebar verschachteln wollen.

Wie schon angesprochen möchte ich eine allgemeine Sidebar erstellen, die immer dann angezeigt wird, wenn für den jeweiligen Unterbereich kein Widget aktiv ist. Außerdem definiere ich die extra Widget-Areas für Startseite, Seite, Artikeleinzelansicht und Kategorie.

Code für functions.php

<?php

// Sidebar Nr. 1 - Allgemein
register_sidebar(array(
'name' => 'Sidebar',
'before_widget' => '<div id='%1$s' class='%2$s'>',
'after_widget' => '</div>',
'before_title' => '<h3>',
'after_title' => '</h3>'));

// Sidebar Nr. 2 - Startseite
register_sidebar(array(
'name' => 'Sidebar-Home',
'before_widget' => '<div id='%1$s' class='%2$s'>',
'after_widget' => '</div>',
'before_title' => '<h3>',
'after_title' => '</h3>'));

// Sidebar Nr. 3 - Seite
register_sidebar(array(
'name' => 'Sidebar-Page',
'before_widget' => '<div id='%1$s' class='%2$s'>',
'after_widget' => '</div>',
'before_title' => '<h3>',
'after_title' => '</h3>'));

// Sidebar Nr. 4 - Artikeleinzelansicht
register_sidebar(array(
'name' => 'Sidebar-Post',
'before_widget' => '<div id='%1$s' class='%2$s'>',
'after_widget' => '</div>',
'before_title' => '<h3>',
'after_title' => '</h3>'));

// Sidebar Nr. 5 - Kategorie
register_sidebar(array(
'name' => 'Sidebar-Category',
'before_widget' => '<div id='%1$s' class='%2$s'>',
'after_widget' => '</div>',
'before_title' => '<h3>',
'after_title' => '</h3>'));

?>

Bemerkung:
Alle für mein Beispiel benötigten Widget-Sidebars sind nun angelegt. Um das Ganze übersichtlich zu halten, habe ich sinnvolle Namen vergeben und die Sidebars zur Übersicht nummeriert (das brauchen wir später noch).

Verschachteln der Widget-Areas

Nochmal zur Verdeutlichung: Es soll erreicht werden, dass, wenn wir uns bspw. in einer Artikeleinzelansicht (Post) befinden, abgefragt wird, ob für diesen Unterbereich Widgets aktiv sind. Wenn das der Fall ist, werden diese in der Sidebar ausgegeben, wenn nicht, wird die allgemeine Startseite angezeigt. Die gleiche Abfrage soll für die Unterbereiche Startseite, Seite und Kategorie gemacht werden.

Wo sich der Benutzer auf der Website befindet, kann ich mit folgenden Conditional Tags (s. a. WordPress Codex) abfragen:

• is_front_page()
• is_page()
• is_single()
• is_archive()

Parallel dazu muss ich herausfinden, ob eine bestimmte Widget-Area aktiv ist, d. h. ob ihr Widgets zugewiesen wurden. Das mache ich mit dem Conditional Tag is_active_sidebar().

Die verschiedenen Sidebars werden durch den Namen, die ID oder der Nummer identifiziert. Ich habe mir für die eindeutige Zuordnung durch die Nummer (Reihenfolge) entschieden.

• Nr. 1 = Sidebar Allgemein
• Nr. 2 = Sidebar Startseite
• Nr. 3 = Sidebar Seite
• Nr. 4 = Sidebar Artikeleinzelansicht
• Nr. 5 = Sidebar Kategorie

Code für sidebar.php

<div id='sidebar'>

<?php
    if(is_front_page() &amp;&amp; is_active_sidebar(2)) : dynamic_sidebar(2);
    elseif(is_page() &amp;&amp; is_active_sidebar(3)) : dynamic_sidebar(3);
    elseif(is_single() &amp;&amp; is_active_sidebar(4)) : dynamic_sidebar(4);
    elseif(is_archive() &amp;&amp; is_active_sidebar(5)) : dynamic_sidebar(5);

    else : 

        if (!dynamic_sidebar(1)) : ?>

    	<!-- hier werden die Widgets angezeigt -->
    	<p>Inhalt der Sidebar, wenn keine Widgets aktiv sind.</p>

        <?php endif; // endif dynamic sidebar ?>

<?php endif; // endif active sidebars ?>

</div><!-- end sidebar -->

In Worten bedeutet dieser Code:

Wenn der User auf der Startseite ist und die Sidebar Nr. 2 aktiv ist, dann zeige diese an. Wenn sich der User auf einer Seite bewegt und die Sidebar Nr. 3 aktiv ist, dann zeige diese an. Wenn sich der User in einer Artikeleinzelansicht bewegt und die Sidebar Nr. 4 aktiv ist, dann zeige diese an. Wenn eine Kategorie angezeigt wird und die Sidebar Nr. 5 aktiv ist, dann zeige diese an.

Wenn all das nicht der Fall ist, wird abgefragt, ob die allgemeine Sidebar Nr. 1 aktiv ist. Wenn auch das nicht der Fall ist, dann wird der Text Inhalt der Sidebar, wenn keine Widgets aktiv sind. angezeigt.

Verbesserungsvorschläge?

Da es sich meines Erachtens um ein interessantes Feature für WordPress-Themes handelt, würde ich mich über Verbesserungsvorchläge freuen, sollte jemand eine einfachere oder bessere Lösung haben. Da ich kein PHP-Experte bin, kann es sein, dass dieser Code evtl. noch effektiver gestaltet werden kann.

Fazit

Mit verschachtelten Widget-Areas kann man schon ein gutes Stück an Flexibilität in einem WordPress-Theme gewinnen und sich somit weiter in Richtung CMS bewegen. Das Beispiel ist natürlich beliebig erweiterbar, da man alle möglichen Abfragen für die Anzeige verschiedener Widget-Areas verwenden kann. Hier ist Kreativität gefragt.

Relevante Links

• register_sidebar() – WordPress Codex
• dynamic_sidebar() – WordPress Codex
• Conditional Tags – WordPress Codex
• Widgetizing Themes von Automattic

Ab der WordPress-Version 2.8 haben wir die Möglichkeit, die Funktion body_class zu nutzen. Diese gibt dem Body-Tag eine Reihe von CSS-Klassen mit, die ziemlich genau bestimmen, wer sich wo und wie auf einer Website befindet. Damit öffnet sich der inhaltsabhänigen CSS-Formatierung Tür und Tor.

Ähnlich der Funktion post_class(), die in WordPress 2.7 hinzugekommen ist, bestimmt die Funktion body_class(), ob man sich gerade in einer Kategorie und wenn in welcher befindet, ob es sich um eine Post-Einzelansicht handelt, ob ein User eingeloggt ist oder auf welcher Seitennummer man sich bewegt und vieles mehr.

body_class() anwenden

Der Einsatz der Funktion ist denkbar einfach. Wir müssen diese lediglich dem Body-Tag hinzufügen, der sich bei den meisten Themes in der header.php befindet:

<body <?php body_class(); ?>>

Möchten wir die Kompatibilität unseres Themes auch auf Installationen unter WordPress 2.8 sichern, müssen wir zunächst abfragen, ob die Funktion überhaupt existiert. Wenn ja, kann diese zum Einsatz kommen:

<body <?php if(function_exists('body_class')) body_class(); ?>>

Haben wir unser Theme auf diese Art erweitert, sind wir auch schon fertig und können uns an die Formatierung mit CSS machen.

Ausgabe von body_class()

Wie schon angeprochen, generiert diese Funktion body_class() eine Reihe von CSS-Klassen, die uns möglichst viele Informationen darüber liefert, wo man sich auf einer Website befindet.

Beispiele:

Wir befinden uns auf der Startseite, die auch gleichzeitig unsere Blog-Startseite ist.

<body class='home blog'>

Wir befinden uns auf einer Kategorie-Archivseite der Kategorie ‘Uncategorized’.

<body class='archive category category-uncategorized'>

Wie befinden uns auf der Seite mit der ID 2.

<body class='page page-id-2'>

Wir befinden uns in der Post-Einzelansicht des Posts mit der ID 11.

<body class='single postid-11'>

Wir befinden uns im Autorenarchiv des Autors ‘Admin’.

<body class='archive author author-admin'>

Eine komplette Liste der möglichen Klassen hat das Team von WP Engineer zusammengestellt:

• rtl
• home
• blog
• archive
• date
• search
• paged
• attachment
• error404
• single postid-(id)
• attachmentid-(id)
• attachment-(mime-type)
• author
• author-(user_nicename)
• category
• category-(slug)
• tag
• tag-(slug)
• page-parent
• page-child parent-pageid-(id)
• page-template page-template-(template file name)
• search-results
• search-no-results
• logged-in
• paged-(page number)
• single-paged-(page number)
• page-paged-(page number)
• category-paged-(page number)
• tag-paged-(page number)
• date-paged-(page number)
• author-paged-(page number)
• search-paged-(page number)

Formatierung der Body-Klassen in CSS

Im HTML-Gerüst einer jeden Website umschließt der Body-Tag immer alle Elemente unseres Layouts. Vor ihm findet keine Ausgabe im Quelltext für das Frontend statt. Das heißt, dass wir mit verschachtelten CSS-Klassen jedes Element auf unserer Website ansprechen und mit den Body-Klassen formatieren können.

Beispiele:

Wir möchten NUR auf der Startseite eine andere Hintergrundfarbe.

body {
        color: #fff;
}
body.home {
        color: #eee;
}

Wir möchten die Überschriften der Kategorie ‘Uncategorized’ nicht in Schwarz sondern in Rot anzeigen.

h2.post-title {
        color: #101010;
}
body.category-uncategorized h2.post-title {
        color: #ff0000;
}

Ich habe hier jetzt relativ einfache Beispiele gewählt. Die Möglichkeiten, die wir mit der body_class-Funktion bekommen, sind jedoch sehr vielfältig. So können wir mit CSS das Layout beeinflussen und bspw. für eine bestimmte Kategorie den Inhaltsbereich größer darstellen und die Sidebar verschwinden lassen. Oder man kann it der Klasse logged-in einem eingeloggten Benutzer eine andere Formatierung anzeigen lassen als nicht eingeloggten. U.v.m.

Ihr seht, mit etwas Kreativität kann man einen sehr umfangreichen Gebrauch dieser Funktion machen.

Fazit

Diese unscheinbare Funktion body_class() hat es also faustdick hinter den Ohren und macht einen weiteren wichtigen Schritt von WordPress in Richtung vollwertiges CMS. WordPress Theme-Entwickler und -Nutzer haben nun auf einfache Weise weitaus mehr Möglichkeiten, verschiedene Bereiche individuell zu formatieren und gestalten.

Relevante Links

• WP Engineer über die body_class()
• Nathan Rice über die body_class()
• WordPress 2.8 – Was gibt’s Neues?
• Neue Funktion the_author_meta() in WordPress 2.8

WordPress 2.8 ist da. Es gibt viele Neuerungen, die für viele spannend sind und auch unter der Haube hat sich einiges getan. Die neue Funktion the_author_meta() bringt endlich Ordnung in den Wust der Autorfunktionen.

Autorinformation

Eine weit verbreitete Praxis bei der Verwendung von WordPress ist das Schreiben mehrerer Autoren an einem Blog. Besonders bei den großen Magazinen, bei denen man – sei es aus Gutherzigkeit oder aus Gründen der Traffic-Maximierung – Gastbeiträge schreiben kann, findet man in jedem Post auch eine kurze Info (Beschreibung, Website etc.) über den Autor.

Diese Autorinformation kann bequem im User-Profil im Backend verwaltet und dann dementsprechend im Theme verwendet werden. Bisher waren dafür viele verschiedene Funktionen verantwortlich, die nun stillgelegt wurden:

the_author_ID, the_author_login, the_author_firstname, the_author_lastname, the_author_nickname, the_author_email, the_author_url, the_author_aim, the_author_yim, the_author_mns, the_author_description (+ alle zugehörigen get_-Funktionen)

Funktion the_author_meta()

Die genannten Funktionen wurden schließlich zu der Funktion the_author_meta() und get_the_author_meta(), bei der man über Parameter die einzelnen Profilfelder ansprechen kann, zusammengefasst.

<p><?php the_author_meta('display_name'); ?>:</p>
<p><?php the_author_meta('description'); ?></p>

Bemerkung:
Dieser Code liefert uns bspw. den Anzeigename gefolgt von der Beschreibung des Autors, die man unter Profil > Persönliche Informationen eingeben und verändern kann.

Mögliche Parameter sind folgende:

• user_login
• user_pass
• user_nicename
• user_email
• user_url
• user_registered
• user_activation_key
• user_status
• display_name
• nickname
• first_name
• last_name
• description
• jabber
• aim
• yim
• user_level
• user_firstname
• user_lastname
• user_description
• rich_editing
• comment_shortcuts
• admin_color
• plugins_per_page
• plugins_last_view
• ID

Informationen eines bestimmten Users

<?php the_author_meta('first_name',23); ?>

Die Funktion the_author_meta() lässt noch einen weiteren Parameter zu. Wir können zusätzlich zum Profilfeld noch eine UserID bestimmen. Der Vorname von User 23 würde wie oben angezeigt angesprochen. Dieser ließe sich in der fortgeschrittenen Theme-Entwicklung natürlich dynamisch ersetzen.

Twitter-Namen ohne Plugin oder Theme-Optionen ausgeben

Für manche Theme-Entwickler ist vielleicht interessant, dass die Anzeige der Profilfelder AIM, Yahoo und Jabber – die ich persönlich noch nie verwendet habe – nun filterbar sind. Wir könnten im User-Profil also statt AIM das Label Twitter anzeigen lassen und so den Twitter-Namen dann mit der Funktion the_author_meta() und dem Parameter für das AIM-Profilfeld im Theme (zweckentfremded) ausgeben.

Die Anzeige (Label) von AIM könnten wir in der functions.php mit einem Filter verändern:

<?php
function aim_twitter() {
    $twitter = 'Twitter Username';
    return $twitter;
}
add_filter('user_aim_label','aim_twitter');
?>

Neben dem Label für AIM können wir noch die Anzeige von Yahoo (user_label_yahoo) und Jabber (user_label_jabber) filtern.

Auf diese Weise können wir im Theme ohne ein Plugin oder Theme-Optionen den Twitter-Namen des Users ausgeben:

<?php the_author_meta('aim'); ?>

Fazit

Die neue Funktion the_author_meta() bringt nicht unbedingt was bahnbrechend neues mit sich, schafft jedoch, meiner Meinung nach, Ordnung und mehr Übersicht.

Relevante Links

• WordPress Codex: Version 2.8
• WordPress Codex: the_author_meta()
• WordPress Codex: User-Profil
• WordPress Trac: Filter für Profilfelder

Zur Ausgabe des Datums eines Posts wird innerhalb des Loops die WordPress-Funktion the_date() aufgerufen. In den Archiv-Seiten (Index, Kategorien, Suche) jedoch wird das Datum nicht richtig angezeigt, wenn Posts am selben Tag veröffentlicht wurden. Es wird dann nur einmal ausgegeben. Es gibt jedoch eine sichere Lösung dieses Problems.

Datumsanzeige mit the_time()

Die Lösung ist das Verwenden der anderen Zeit-Funktion the_time(), bei der man wie bei the_date() auch das Datumsformat mit Parametern bestimmen kann.

<?php the_time('j. F Y'); ?>

Bemerkung:
Mit dieser Angabe wird das Datum in Form von 27. Oktober 2009 ausgegeben. Der Nachteil dieser Lösung ist allerdings, dass das Datumsformat dann fest im Theme steht und das Format, das man in den WordPress-Einstellungen angegeben hat, ignoriert wird. Das ist natürlich besonders bei einem Theme, das mehrsprachig sein soll, gar nicht gut.

Abfrage des Datumsformats

Um das Format des Datums dynamisch ausgeben zu lassen, kann man die Funktion the_time() mit der Abrage des Datumsformats aus den WordPress-Einstellungen kombinieren.

<?php the_time(get_option('date_format')); ?>

Fazit

Mit der gezeigten Lösung wird für jeden Post das richtige Datum angezeigt, auch wenn mehrere Posts dasselbe Datum haben. Das Datumsformat bleibt außerdem über die Einstellungen veränderbar.

Relevante Links

• WordPress-Codex the_date()
• WordPress-Codex the_time()
• WordPress-Codex Formatting Date and Time
• WordPress-Codex get_option()

Inhalte von WordPress-Seiten werden immer komplexer und damit natürlich ihre Navigation. Eine schicke Sache für ein komplexes Navigationsmenü ist ein Dropdown-Menü. Eine Lösung, die ich gern verwende, ist das Superfish jQuery-Plugin von Joel Birch. Die Implementierung in WordPress ist nicht schwer.

Vor drei Wochen habe ich bereits ein Tutorial geschrieben, welches das Einfügen eines Superfish-Dropdown in eine normale Website erklärt. Wer also noch keine Erfahrung mit dem jQuery-Plugin hat, sollte dort mal einen Blick drauf werfen.

Grundlage für dieses Tutorial
Tutorial: jQuery Dropdown Menü mit Superfish

Einbindung des Superfish-Skriptes

Wie in dem vorherigen Tutorial, müssen wir zunächst das Skript des jQuery-Plugins im Head-Bereich der Website einbinden und aufrufen.

In einem WordPress-Theme bearbeiten wir dafür die Datei header.php. Wir setzen weiterhin voraus, dass sowohl die jQuery-Library (jquery-1.2.6.min.js), das Superfish-Skript (superfish.js) und das Superfish-Stylesheet (superfish.css) im Theme-Ordner im Unterordner /sf/ liegen.

<link rel='stylesheet' type='text/css' media='screen' href='<?php bloginfo('template_url'); ?>/sf/superfish.css' />
<script type='text/javascript' src='<?php bloginfo('template_url'); ?>/sf/superfish.js'></script>

Bemerkung:
Hiermit binden wir also sowohl das Stylesheet des Dropdown also auch das Javascript mit den richtigen Pfaden (/wp-content/themes/dein-theme/sf/) in den Head-Bereich ein.

Somit ist das Plugin für uns nun aufruf- und einsetzbar.

<script type='text/javascript'>
    $(document).ready(function() {
        $('ul.sf-menu').superfish();
    });
</script>

Bemerkung:
Mit diesem Aufrunf wird das Superfish-Plugin nun auf alle ungeordneten Listen mit der CSS-Klasse .sf-menu angewendet. Weitere Anpassungen des Plugins entnehmt bitte dem vorherigen Tutorial.

Superfish-Dropdown und wp_list_categories()

Für die Anzeige eines Dropdown-Menüs für Kategorien brauchen wir eine ungeordnete Liste (ul) aller Kategorien. Unterkategorien werden in verschachtelten Listen dargestellt (ul > li > ul etc.). WordPress stellt uns dafür die Funktion wp_list_categories() bereit.

Ein Aufruf könnte also wie folgt aussehen:

<ul id='cat-menu' class='sf-menu'>
    <?php wp_list_categories('title_li='); ?>
</ul>

Dieses Konstrukt würde nun schon ein ansehnliches Dropdown-Menü erzeugen. Um das Ganze zu verfeinern, kann man dem Menü noch einen Link zur Startseite hinzufügen.

<ul id='cat-menu' class='sf-menu'>
    <li class='cat_item<?php if(is_home()) echo ' current-cat'; ?>'><a href='<?php bloginfo('url'); ?>'>Startseite</a></li>
    <?php wp_list_categories('title_li='); ?>
</ul>

Bemerkung:
Wir haben auch hier alle Einflussmöglichkeiten, die uns die Funktion wp_list_categories() bietet.

Superfish-Dropdown und wp_list_pages()

Ein Menü für WordPress-Seiten mit dem Dropdown darzustellen, ist nun relativ einfach. Mit der Funktion wp_list_pages() erhalten wir die erforderliche Listenstruktur für alle Seiten und Unterseiten.

<ul id='page-menu' class='sf-menu'>
    <?php wp_list_pages('title_li='); ?>
</ul>

Bemerkung:
Auch hier können wir natürlich den Startseiten-Menüpunkt einfügen (s.o.) und das Menü mit den Parametern der Funktion wp_list_pages() an unsere Anforderungen anpassen.

Superfish-Dropdown und wp_page_menu()

Mit der Version 2.7 haben uns die WordPress-Entwickler eine neue Funktion zum Aufruf eines Seitenmenüs gegeben – wp_page_menu().

Wie oben erwähnt, ist es für die Darstellung eines Superfish-Menüs nötig, der ungeordneten Liste (ul) des Seitenemenüs die CSS-Klasse .sf-menu zu geben. Die neue Funktion wp_page_menu() bietet uns zwar einige neue Möglichkeiten (z. B. Startseiten-Link einfügen), “verwährt” uns jedoch den direkten Zugriff auf den ul-Tag der Liste.

Der Aufruf sieht bspw. wie folgt aus:

<?php wp_page_menu('show_home=1&include=1,2,4,7&menu_class=page-navi&title_li='); ?>

Bemerkung:
Wir können u.a. eine CSS-Klasse vergeben (menu_class). Jedoch wird diese Klasse auf den um die Liste (ul) erzeugten div-Container angewendet.

Der Output der Funktion würde etwa wie folgt aussehen:

<div class='page-navi'>
	<ul>
		<li class='current_page_item'><a href='#'>Home</a></li>
		<li class='page_item page-item-1'><a href='#' title='Seite1'>Seite1</a></li>
		<li class='page_item page-item-2'><a href='#' title='Seite2'>Seite2</a></li>
		<li class='page_item page-item-3'><a href='#' title='Seite4'>Seite4</a></li>
		<li class='page_item page-item-3'><a href='#' title='Seite7'>Seite7</a></li>
	</ul>
</div>

Bemerkung:
Nun haben wir zwar eine Liste innerhalb eines div-Containers und für CSS-Formatierungen ist diese Verschachtelung natürlich kein Problem. Für unser Dropdown brauchen wir aber auf jeden Fall die Klasse .sf-menu auf dem ul-Tag.

Der Liste in wp_page_menu() eine Klasse zuteilen

Mit einer kleinen Erweiterung in der functions.php unseres WordPress-Themes können wir die Funktion wp_page_menu() durch einen WordPress-Filter schicken. Mit der PHP-Funktion preg_replace suchen wir uns den ersten(!) ul-Tag im Output unseres Seitenmenüs und erweitern diesen um eine ID und eine Klasse. Ian Steward von ThemeShaper hat diese Lösung vorgestellt.

// Add ID and CLASS attributes to the first <ul> occurence in wp_page_menu
function add_menuclass($ulclass) {
return preg_replace('/<ul>/', '<ul id='nav' class='something-classy'>', $ulclass, 1);
}
add_filter('wp_page_menu','add_menuclass');

Bemerkung:
Mit diesem kleinen Code-Schnipsel in der functions.php ist es nun ohne Probleme möglich, auch in der neuen wp_page_menu-Funktion unsere Klasse .sf-menu an die ungeordnete Liste (ul) weiterzugeben.

Fazit

Wir sehen also, es ist nicht weiter schwierig, ein Superfish-Dropdown-Menü in einer WordPress-Navigation zu nutzen, da wir lediglich eine Klasse vergeben müssen. Was etwas mehr Arbeit bereitet, ist die Anpassung des Stylesheets an das Layout der Seite. Aber auch das ist mit Geduld und Spucke ohne Weiteres zu schaffen

Relevante Links

• Superfish – Suckerfish on ‘roids
• Tutorial: jQuery Dropdown Menü mit Superfish
• Funktion wp_page_menu()
• Adding Class To The WordPress Page Menu
• PHP-Funktion preg_replace()
• Superfish jQuery Menu IE z-index Bug (English)

Die Lokalisierung / Übersetzung von WordPress-Themes ist eine von mir bisher sträflich wenig beachtete Funktion von WordPress. Dabei kann man mit einem relativ geringen Mehraufwand einen gehörigen Mehrwert in Sachen Interantionalisierung von Themes schaffen.

Warum lokalisieren?

Die Vorteile, den kleinen Mehraufwand bei der Erstellung eines WordPress-Themes in Kauf zu nehmen und dieses zu lokalisieren, liegen auf der Hand. Mit gesonderten Sprachdateien lässt sich das Theme unabhängig vom Quellcode, den man dafür dann nicht mehr anrühren muss, in beliebig viele Sprachen übersetzen.

Die WordPress-Installation selbst ist in Sachen Intarnationalisierung und Übersetzung schon weit gediehen und es gibt bereits unzählige Übersetzungen für den WordPress-Admin. Dann sollten wir beim Theme nicht aufhören.

WordPress verwendet GetText:

Um WordPress-Themes zu lokalisieren verwendet WordPress eine Übersetzungsanwendung namens GetText. Mit dieser Anwendung ist es relativ einfach, WordPress zusagen, was wo und womit übersetzt werden soll. Mehr dazu im Detail.

HTML-Strings übersetzbar machen:

Nehmen wir an, wir wollen in userem Theme einen Titel der Sidebar übersetzen. Dort steht im Quellcode folgendes:

<h4>Recent Articles</h4>

Um diesen HTML-String nun per GetText übersetzbar zu machen, müssen wir ihn in einen GetText-Call packen, den viele Theme-Designer von Euch sicherlich schon gesehen haben und der wie folgt aussieht:

<h4><?php _e('Recent Articles', my_theme_name); ?></h4>

Bemerkung:
Hiermit rufen wir die GetText-Funktion _e() auf und sagen ihr, was womit übersetzt werden soll und dass die Übersetzung an dieser Stelle ausgegeben werden soll (PHP: echo). Der erste Parameter in der Klammer sagt, was übersetzt werden soll und der zweite (my_theme_name) sagt WordPress, wo die Übersetzung zu finden ist (dazu später mehr),

GetText in WordPress-Funktionen:

Sicherlich sind Euch auch schon WordPress-Funktionen bekannt, in denen verschiedene Strings verarbeitet werden. Ein Beispiel ist der Aufruf der Anzahl der Kommentare:

<?php comments_number(__('No comments',my_theme_name), __('One comment',my_theme_name), __( '% comments',my_theme_name) );?>

Bemerkung:
In der Funktion comments_number() können wir drei Strings für drei mögliche Fälle übergeben (kein, 1 und x Kommentare). Wie ihr vielleicht seht, rufen wir jedoch jetzt die GetText-Funktion __() auf. Auch diese sagt WordPress was womit übersetzt werden soll, doch nun wird die Übersetzung an dieser Stelle nicht ausgegeben (PHP: kein echo), sondern kann als String von PHP weiterverarbeitet werden.

Text-Domains:

Der Name ist ein wenig irreführend. Es geht um den zweiten Parameter in den GetText-Calls (my_theme_name). Dieser ist optional und hilft WordPress die richtige Übersetzung zu finden. Es kann nämlich vorkommen, dass z. B. in einem Plugin, das wir verwenden, der gleiche String übersetzt werden soll. Mit unserer eindeutigen Text-Domain können wir klar bestimmen, welche Übersetzung gewählt werden soll. Die Text-Domain kann der Theme-Name sein, mit dem man auch den Theme-Ordner benannt hat (z. B. ‘decoder’ oder ‘my_theme_name’).

Vorbereiten und Erstellen der Sprachdatei:

Angenommen wir haben jetzt überall in unseren Theme diese zu übersetzenden Strings verteilt. Als nächstes wollen wir diese in einer Liste ausgeben, um sie weiterverarbeiten zu können.

PHP to .po extractor

Diese Liste, mit der wir auch die Übersetzung machen ist eine .po-Datei (Portable Object). Um nun aus den php-Dateien unseres Themes die Liste in der .po-Datei zu erstellen, gibt es PHP to .po extractor, mit denen wir einzelne Dateien aber auch Zip-Archive verarbeiten können. Dieser sucht alle Strings, die in _e() und __() Funktionen gepackt sind und gibt uns die .po-Datei zurück.

Übersetzen aller Strings in der .po-Datei:

Um .po-Dateien verarbeiten zu können, solltet Ihr Euch das Programm Poedit herunterladen. Mit diesem Programm lassen sich die Übersetzungen einfach und übersichtlich anfertigen. Beim Abspeichern unserer .po-Datei wird automatisch eine .mo-Datei erstellt, die letztlich die Sprachdatei ist, die WordPress benötigt. Die .po-Datei ist sozusagen nur die Bearabeitungsdatei.

Sprachdateien bearbeiten mit Poedit

Wichtig beim Erstellen der Sprachdateien sind noch die Sprach- und Ländercodes, mit denen wir die Sprachfiles benennen. Eine Sprachdatei für Deutsch aus Deutschland müsste also de_DE.po / de_DE.mo heißen. Für Schweizer Deutsch dementsprechend de_CH.po / de_CH.mo.

Laden der Text-Domain:

Wenn wir die .po/.mo-Dateien in unserem Theme-Ordner platziert haben, sagen wir WordPress, dass in unserem Theme eine Übersetzung geladen werden soll.

<?php load_theme_textdomain(my_theme_name); ?>

Bemerkung:
Diesen Aufruf platzieren wir am besten in der header.php, da diese bei jedem Seitenaufruf angesprochen wird.

Wenn WordPress nun das Sprachfile für die Sprache findet, die in der wp-config.php angegeben ist, wird das Theme mit allen Übersetzungen richtig angezeigt.

define ('WPLANG', 'de_DE');

// edit:

Alternative per Plugin:

Wenn einem das Installieren von Poedit und das externe Scannen der PHP-Dateien zum umständlich ist, kann man das Ganze auch WordPress-intern lösen. Das WordPress-Plugin Codestyling Localization scheint mir dafür eine starke Alternative zu sein. Ich habe es selbst noch nicht getestet, werde das aber auf jeden Fall nachholen.

Danke an sokai für den Tipp!

// end edit;

Fazit:

Die Lokalisierung von WordPress-Themes sollte für Theme-Autoren zum Standard gehören. Wenn man diese Routine einmal durchlaufen ist, hält sich der Mehraufwand tatsächlich in Grenzen und das Theme wird dem internationalen Charakter von WordPress gerecht.

Relevante Links:

• WordPress Codex Translating WordPress
• WordPress Codex WordPress in You Language
• Poedit zum Verarbeiten von .po-Dateien
• PHP Text-Scanner zum Erstellen der .po-Dateien
• How to localize WordPress themes and plugins with GetText
• WordPress Themes lokalisieren /// ZyBlog

Die Formatierung der Kommentare – ein beliebter Sport unter Theme-Designern. Wer Kommentare in WordPress 2.7 anpassen möchte, findet in der comments.php jedoch lediglich den Aufruf der Funktion wp_list_comments. Was aber, wenn ich einen völlig anderen Aufbau benötige?

Aufruf der Kommentare:

Wer einmal in die comments.php eines Themes für WordPress 2.7 schaut, findet nicht mehr das gesamte Gerüst eines Kommentars, um dieses nach Belieben anzupassen. Die Liste aller Kommentare wird nur noch mit einer einzigen Funktion aufgerufen.

<div class='commentlist'>
    <?php wp_list_comments(); ?>
</div>

Bemerkung:
Über das Stylesheet können wir natürlich mit CSS einen Großteil der Formatierung übernehmen und bekommen dafür auch zahlreiche Klassen an die Hand. Wenn wir jedoch z. B. ein div hinzufügen oder verändern möchten, wird es schon schwierig.

Eigenes Kommentar-Template aufrufen:

Um hier absolute Kontrolle zu bekommen, können wir beim Aufruf dieser Liste ebenfalls angeben, dass ein individuelles Kommentar-Template verwendet werden soll.

<ul class='commentlist'>
    <?php wp_list_comments('callback=mytheme_comment'); ?>
</ul>

Bemerkung:
WordPress prüft nun, ob in der functions.php eine Funktion mit dem Namen ‘mytheme_comment’ vorhanden ist.

Eigenes Kommentar-Template verfassen:

In der functions.php können wir nun diese Callback-Funktion erstellen und den Aufbau der Kommentarliste nach Belieben anpassen.

function mytheme_comment($comment, $args, $depth) {
   $GLOBALS['comment'] = $comment; ?>
   <li <?php comment_class(); ?> id='li-comment-<?php comment_ID() ?>'>
     <div id='comment-<?php comment_ID(); ?>'>
      <div class='comment-author vcard'>
         <?php echo get_avatar($comment,$size='48',$default='<path_to_url>' ); ?>

         <?php printf(__('<cite class='fn'>%s</cite> <span class='says'>says:</span>'), get_comment_author_link()) ?>
      </div>
      <?php if ($comment->comment_approved == '0') : ?>
         <em><?php _e('Your comment is awaiting moderation.') ?></em>
         <br />
      <?php endif; ?>

      <div class='comment-meta commentmetadata'><a href='<?php echo htmlspecialchars( get_comment_link( $comment->comment_ID ) ) ?>'><?php printf(__('%1$s at %2$s'), get_comment_date(),  get_comment_time()) ?></a><?php edit_comment_link(__('(Edit)'),'  ','') ?></div>

      <?php comment_text() ?>

      <div class='reply'>
         <?php comment_reply_link(array_merge( $args, array('depth' => $depth, 'max_depth' => $args['max_depth']))) ?>
      </div>
     </div>
<?php
        }

Fazit:

Wir behalten also auch in WordPress 2.7 die volle Kontrolle über die Ausgabe der Kommentare. Da wird es in Zukunft, wie auch bisher, sicherlich viel Interessantes und Kreatives zu sehen geben.

Relevante Links:

• WordPress-Codex Template Tags/wp_list_comments