Zuerst gehen wir ins Backend zu Design-> Menü und schalten die CSS Klassen an. Dazu klicken wir auf Optionen einblenden und unter Erweiterte Menüeigenschaften anzeigen setzen wir einen Haken bei CSS Klassen und schließen die Optionen wieder.

Anschließend nutzen wir die Links-Box zum Erzeugen der Menüeinträge für Twitter, RSS und Facebook und fügen sie dem Menü hinzu. Dort ergänzen wir die 3 Menüeinträge mit den CSS Klassen. Das RSS Feed bekommt die Klasse rss, Twitter die Klasse twitter und Facebook facebook. Speichern nicht vergessen.

Ich habe eine Sprite vorbereitet, die ihr mit Rechtsklick->Grafik speichern unter… herunterladen könnt. Diese Sprite kommt in das Verzeichnis twentyeleven/images/.

Anschließend öffnen wir die Datei TwentyEleven style.css mit einem Texteditor und suchen die Zeile #access a. Darunter fügen wir unser zusätzliches CSS ein. Viel haben wir nicht zu ergänzen. Wir lassen unsere 3 Listenelemente nach rechts floaten, schieben den Text aus dem sichtbaren Bereich und positionieren die Grafik. Einzig für die hover-, focus- und active states müssen wir eine etwas umständlichere Regel definieren, um die background-gradients von TwentyEleven zu umgehen.

#access .twitter, #access .rss, #access .facebook {
	float: right;
}
#access .twitter a, #access .rss a, #access .facebook a {
	background: transparent url(images/social-sprite.png) 0 0 no-repeat;
	padding: 0;
	text-indent: -9999px;
	width: 70px;
}
#access .rss a { background-position: 0 0; }
#access .facebook a { background-position: 0 -96px; }
#access .twitter a { background-position: 0 -48px; }
#access .rss a:hover, #access .rss a:focus, #access .rss a:active {
	background: transparent url(images/social-sprite.png) 0 -144px no-repeat;
}
#access .twitter a:hover, #access .twitter a:focus, #access .twitter a:active {
	background: transparent url(images/social-sprite.png) 0 -192px no-repeat;
}
#access .facebook a:hover, #access .facebook a:focus, #access .facebook a:active {
	background: transparent url(images/social-sprite.png) 0 -240px no-repeat;
}

• Twitter-Icons, Xtreme, jQuery Bug
• WordPress: private Seite in der Navigation
• User Contact Info in WordPress 2.9 erweitern
• 5 Gründe für WordPress
• Aptana mit CSSDoc erweitern

Erweitert ein Plugin oder Theme die Klasse WP_Media_List_Table für eigene Zwecke, gibt es nach dem Update auf 3.2 einen Fatal Error. Eine mögliche Lösung für dieses Problem, die wir in Xtreme One drin haben:

class Xtreme_Media_Slider_List_Table extends WP_Media_List_Table {
	function Xtreme_Media_Slider_List_Table() {
		if(in_array("__construct", get_class_methods("WP_Media_List_Table"))) {
			parent::__construct(); //WP 3.2
		}else{
			parent::WP_Media_List_Table(); //WP < 3.2
                 }
                 $this->detached = true;
	}
        // ...
}

• WordPress Seiten mit etwas anderen Passwörtern

In der functions.php des Themes schreiben wir:

add_filter( 'widget_text', array( $wp_embed, 'run_shortcode' ), 8 );
add_filter( 'widget_text', array( $wp_embed, 'autoembed'), 8 );

Danach braucht man im Textwidget nur die URL des Videos hineinkopieren und schon wird es angezeigt.

• Adobe CS3 Gratis Video Training
• Screencasts und Videos im Blog darstellen
• Zend One Video Channel
• Warten auf das Video
• Stress mit dem Video

Jedes Childtheme verwaltet jetzt seine eigenen Optionen inclusive der Widgeteinstellungen. Das bedeutet für den Nutzer, daß er zwischen verschiedenen Childthemes wechseln kann, ohne jedesmal die Layouteinstellungen und Widgets bzw. deren Inhalte neu anzupassen.

Das 2. Highlight ist das neue Backup-Modul. Das Backup-Modul bietet die Möglichkeit, eine bestehende Konfiguration als XML-Datei zu speichern und auch wieder einzulesen. Damit ist es beispielsweise möglich, ein Projekt lokal zu entwickeln und mittels der Backup-Datei online einzuspielen. Selbstverständlich mit allen Widgets und deren Einstellungen bzw. Inhalten. Eine enorme Zeitersparnis.

Damit sind wir unserem Ziel, dem Anwender ein einzigartiges Tool in die Hand zu geben, wieder ein Stück näher gekommen. Unendlich viele verschiedene Layouts, dank YAML mit einem zukunftsweisenden CSS Framework, optionale HTML5-Ausgabe, kinderleichte Konfiguration im Backend -> Xtreme One ist das einzige WordPress Framework, bei dem Zukunft kein Fremdwort ist.

• Xtreme One Version 1.0.1 und internationaler Launch
• Xtreme One Betatester gesucht!
• Xtreme One – es geht weiter
• Xtreme One WordPress Framework veröffentlicht!
• WordPress 2.3 Release Date

Eleganter gelöst ist das im Theme Toolbox, ebenfalls aus der WordPress-Schmiede. Die Ellen hat sehr schön beschrieben, wie es funktioniert. Leider ist die Variante auch nicht perfekt. Machen wir mal eine einfache Sache, die ich sehr häufig benötige:

<?php
/* Start the Loop */
$i = 0; ?>
<?php while ( have_posts() ) : the_post();
 $i++; ?>
 
        <?php get_template_part( 'content', get_post_format() ); ?>
 
<?php endwhile; ?>

Ich habe einen einfachen Zähler integriert. Jetzt geben wir den Wert des Zählers in dem Template content.php aus:

<header class="entry-header">
<?php echo '$i = ' . $i ?>
</header>

$i hat keinen Wert. Taugt also auch nur bedingt.
Es ist zwar schön, mit kleinen, leicht editierbaren Dateien zu arbeiten. Muß oder möchte man die Funktionalität erweitern, hat man nur die Möglichkeit, die entsprechenden Variablen global zu definieren oder man ist am A….

• Warum ein WordPress Theme niemals Daten speichern sollte
• Sticky Post Dilemma in WordPress
• WordPress Sticky Posts – Teil 3
• WordPress 2.9 add_theme_support und has_post_image
• WordPress post_class – Fluch oder Segen?

Somit konnte man im Theme mit the_time( get_option( ‘date_format’ ) ) das gespeicherte Datumsformat holen und es wurde korrekt ausgegeben. Ab WordPress 3.0 gibt es jetzt eine Funktion, die alles von selbst erledigt: get_the_date(). Wichtig ist, zu beachten, daß diese Funktion nur den String des Datums zurückgibt und nicht automatisch eine Ausgabe erzeugt.

<span class="postdate published"><?php echo get_the_date()  ?></span>

Zusätzlich kann man über die PHP-Datumsparameter diese Funktion beieinflussen. Möchte man beispielsweise HTML5 ausgeben, sieht das dann so aus:

<time datetime="<?php echo get_the_date('c') ?> pubdate"><?php echo get_the_date() ?></time>
 
// Ausgabe:
<time datetime="2011-01-18T17:50:52+00:00 pubdate">January 18, 2011</time>

Auf Anregung von Markus hier noch die Ergänzung mit the_date():

/*
* Parameter 1 - PHP Date Format
* Parameter 2 - String before
* Parameter 3 - String after
* Parameter 4 - echo true oder false
*/
<?php the_date( '', '<span class="postdate published">', '</span>', true ); ?>

• Topartikel besser präsentieren
• WordPress RSS Widget Kuriositäten
• XSS Artikel bei bueltge.de
• Copyright Jahr im Footer
• WordPress Plugin Tutorial

function my_post_class( $classes ) {
    $classes[] = 'meine_eigene_klasse';
    return $classes;
 }
add_filter( 'post_class', 'my_post_class' );

Dieser Filter wirkt natürlich global. Überall, wo die Funktion post_class() aufgrufen wird, knallt der Filter ‘meine_eigene_klasse’ rein. Soll er ja auch.

Jetzt habe ich ein Tabberwidget, bei dem ich zusätzlich eine spezielle Klasse brauche. Aber eben nur bei dem Tabberwidget. Die Sache mit dem Filter hilft mir da nicht weiter. Hier habe ich Folgendes gemacht:

<div class="<?php echo join(' ', get_post_class( 'tab-content' ) ) ?>">

Auf diese Weise wird die Klasse tab-content post_class hinzugefügt, aber nur in diesem Fall und nicht überall, wie bei dem Filter.

• WordPress body_class und YAML
• User Contact Info in WordPress 2.9 erweitern
• WordPress post_class – Fluch oder Segen?
• WordPress 2.8 body_class, automatic_feed_links
• 5 Gründe für WordPress

Bei diesen Überlegungen stellt sich für mich auch die Frage, warum ein Theme entscheiden soll, was für Daten gespeichert werden? WordPress geht seit einiger Zeit den Weg von add_theme_support( ‘post_thumbnails’ ) oder auch jetzt wieder bei den Post Formats add_theme_support( ‘post-formats’, array( ‘aside’, ‘gallery’ ) ). Das bedeutet, wenn ein Theme über diese beiden Snippets nicht verfügt, den Nutzer keine “Artikelbilder” bzw. keine Postformate zur Verfügung stehen.

Was bedeutet in diesem Falle nicht zur Verfügung stehen? Das bedeutet, ihm wird WordPress Core Funktionalität entzogen, da er das Artikelbild oder das Postformat nicht speichern kann, weil es das Theme nicht unterstützt. Und damit komme ich auf den Punkt, auf den ich hinaus will.

Man sollte die Speicherung und die Ausgabe von Daten strikt trennen. Ein Theme ist nur eine formatierte, gestylete Sicht auf die Daten. Ein Theme wird öfter mal gewechselt, also darf es nicht sein, das durch den Wechsel des Themes möglicherweise der Nutzer in der Eingabe seiner Daten beschnitten wird. Dass er mit einem Theme, welches nicht alle Core-Funktionen unterstützt, manche Daten nicht anzeigen kann, ist weniger tragisch. Er kann die Funktionalität nachrüsten oder sich ein anderes Theme suchen. Aber er hat die Kontrolle über seine Daten.

Was gewinnt man, wenn das Theme keine Postthumbnails supported? Man spart einen Eintrag pro Post in der Datenbank. Ebenso bei den Post Formats.

Die WordPress Entwickler gehen den Weg, den User nicht mit Funktionen zu verwirren, die ein Theme nicht unterstützt. Deshalb die Funktionen add_theme_support. Dann werden die Metaboxen Artikelbild oder Post Formats nicht erst im Backend angezeigt. Ich glaube, das ist der falsche Weg. Wie soll ein Blogger, der heute anfangen will zu schreiben und noch keine großartigen Kenntnisse von WordPress, Themes etc. hat, auf diese eigentlich existierenden Features aufmerksam werden, nur weil das Theme, was er sich ohne Vorkenntnisse nur nach Geschmack ausgesucht hat, es nicht unterstützt?

Für mich ist dieser Weg genau so falsch wie das Integrieren von SEO Funktionen durch ein Theme oder Framework, welches ebenfalls die Daten in benutzerdefinierten Feldern speichert (ganz groß in Mode bei einigen Themeschmieden). Gefällt mir das Theme nicht mehr, sind die Daten weg. So etwas gehört in ein Plugin.

Versteht mich bitte nicht falsch, ich möchte nicht mit diesem Beitrag die WordPress Entwickler kritisieren (er kommt auch noch bei wpengineer.com), aber vielleicht bringt er eine interessante Diskussion hervor, die unterm Strich das eine oder andere in einer späteren Version bewegt.

• Lustige Suchanfragen Teil 1
• Impressum
• Theme Uninstaller
• 5 Gründe für WordPress
• Was soll ein WordPress Theme alles können?

Im Adminbereich von Xtreme One gibt es eine Checkbox “use HTML5 output” und wenn die an ist, wird HTML5 ausgegeben. Sehr angenehm war die Tatsache, das ich am CSS für das Layout nichts ändern mußte, da YAML seit der Version 3.3 HTML5 unterstützt. Insgesamt halten sich die Änderungen in Grenzen. Ich habe die WordPress Gallery Funktion etwas umgeschrieben, die ist in HTML5 keine Definitionsliste mehr, sondern eine ungeordnete Liste mit figure und figcaption Elementen. Die Widgets sind in HTML5 mit section gewrappt. Ärgerlich nur, das man bei zB. dem Seitenwidget, welches ja eigentlich eine Navigation ist, kein nav Element verwenden kann.

Bei den Kommentaren bin ich mir noch nicht sicher, was ich da mache. Bei einer linearen Anzeige der Kommentare könnte man auf die Liste verzichten und die Kommentare als article untereinander schreiben. Hat der Nutzer aber verschachtelte Kommentare eingestellt, funktioniert das nicht mehr ohne Liste.

Ein paar Sachen muß ich noch umbauen und testen. Die Xtreme One Beitragswidgets müssen natürlich auch articles ausgeben statt dem Div.post. Insgesamt bin ich aber mit dem Resultat sehr zufrieden und ich denke, dem Nutzer die Wahl zu geben, XHTML oder HTML5 zu benutzen, hat schon was. Vor allem, wenn man dafür nur einen Haken im Backend setzen muß.

• Nächste Woche Xtreme One 1.2
• Xtreme One Version 1.0.1 und internationaler Launch
• Xtreme One Betatester gesucht!
• Xtreme One – es geht weiter
• Xtreme One WordPress Framework veröffentlicht!

Xtreme-theme.com ist eine WordPress Multisite Installation und das Supportforum ist ein vBulletin 4.0 Forum, welches sich in einem eigenen Verzeichnis befindet und unter der Subdomain support.xtreme-theme.com zu erreichen ist. Zur Zeit haben wir 6 Blogs plus die Childtheme-Demoblogs:

• xtreme-theme.com – Hauptseiten in englischer Sprache
• de.xtreme-theme.com – deutsche Xtreme-Theme Seiten
• dokumentation.xtreme-theme.com – deutsche Xtreme One Dokumentation
• documentation.xtreme-theme.com – englische Xtreme One Dokumentation
• knowledgebase.xtreme-theme.com – Knowledge Base in englischer Sprache
• wissen.xtreme-theme.com – deutsche Knowledge Base

Alle Blogs werden mit Xtreme One angetrieben (was sonst?) und 3 Childthemes. Die Childthemes haben eigene Textdomains, um sie 2-sprachig verwenden zu können. Dort sind die Strings enthalten, die im Framework nicht vorkommen. Sprachplugins verwenden wir keine. Wir schreiben in englisch und parallel in deutsch.

Die Themes, Showcases und Testimonials sind Custom Post Types  mit ein paar zusätzlichen benutzerdefinierten Feldern, wie dem Buy-Link, den Preis etc. Für die Ausgabe der Testimonials habe ich ein Widget gebaut, bei dem ich deutsch oder englisch anzeigen kann. Da wir ein paar der Xtreme One Widgets, wie zum Beispiel den Slider für die Childthemes, auf unterschiedlichen Subdomains verwenden, habe ich die Widgets etwas modifiziert, so dass sie Multisite Queries ausführen können. Über eine Selectbox kann ich auswählen, welcher Blog abgefragt werden soll.

Jeder Childtheme-Demoblog läuft auf einer eigenen Subdomain.  Wir haben dazu ein kleines Plugin geschrieben, welches den Theme-Switcher erzeugt. Das Plugin fügt im Network Admin bei der Seiten-Übersicht eine zusätzliche Checkbox ein, mit der die Demoblogs ausgewählt werden. Die Daten für den Preis und den Kauf-Link werden dann von xtreme-theme.com abgefragt und der Switcher erzeugt. Lege ich ein neues Demoblog an, Haken setzten und fertig.

Wir wollten für die Hauptseiten, die Dokumentation und die Knowledgebase ein unterschiedliches Aussehen. Das haben wir durch 3 Childthemes realisiert, wobei bis auf ein paar kleinen Änderungen an den Templates nur CSS geändert und andere Gafiken verwendet wurden. Der komplette Header mit den beiden Navigationen ist auf allen Domains in Höhe und Anordnung gleich, da es sonst zum nervigen Wandern der Navigationen beim Umschalten geführt hätte. Wir verwenden ausschließlich die WP Menüs, die ich mittlerweile nicht mehr missen möchte.  Für die Flaggen in der Navigation wurden nur die CSS Klassen de und en eingetragen und entsprechend gestyled. So etwas war vorher nicht so einfach möglich.

Die vielen unterschiedlichen Layouts und Sidebars einzubinden war mit dem Layoutmanager von Xtreme One nur eine Sache von Minuten. Gewünschte Container auswählen, Breiten einstellen, Sidebars auswählen und speichern. Also alles Bordmittel von Xtreme One. Einzig für die Einbindung von Analytics und ein paar Kleinigkeiten, die auf allen Subdomanis vorkommen, habe ich noch ein Plugin geschrieben, um nicht diese Sachen mehrfach tun zu müssen.

Es war und ist ein spannendes Projekt, mit dem wir noch viel vorhaben.

• Xtreme One Version 1.0.1 und internationaler Launch
• Xtreme One WordPress Framework veröffentlicht!
• Nächste Woche Xtreme One 1.2
• Xtreme One – es geht weiter
• Xtreme One Betatester gesucht!