Auf diesen Artikel über den Facebook-Sharebutton bei schwindt-pr.com wies mich neulich meine Netzwerkkollegin Kerstin Hoffmann hin. Fand ich gut und habe das inzwischen in meinem Blog ausprobiert. Nun wollte ich die Buttons nicht ins Template schreiben und habe daher einen zusätzlichen Widget-Container in der functions.php eintragen. Der erscheint jetzt unter jedem Artikel.

Widget-Container hinzufügen

Dazu bekommt die functions.php zunächst eine neue Sidebar. Moderne Themes haben meist schon Widget-Einträge. Beim neuen Standardtheme Twenty Twelve findet man die Registrierfunktion der Widgets ab Zeile 204. Diese Funktion erhält eine Ergänzung nach gleichem Muster wie die vorhandenen Container. Das sieht dann beispielseweise so aus:

// innerhalb von function nameDesThemes_widgets_init()
register_sidebar( array (
   'name' => __( 'Social', 'nameDesThemes' ),
   'id' => 'social',
   'description' => __( 'eigene Beschreibung', 'nameDesThemes' ),
   'before_widget' => '<div id="share" class="social widget %2$s"> ',         
   'after_widget' => '</div>',
   'before_title' => '<h2>',         
   'after_title' => '</h2>',
) );    	

Damit ist das neue Widget registriert. Neben Namen, ID und Beschreibung sind auch bereits alle HTML-Tags definiert, die gebraucht werden. Eine eigene Klasse ist hilfreich, um dem Container ggf. ein anderes Styling zu verpassen.

Widget in der content-single.php

Exkurs: Seit WP 3.0 und dem Standard-Theme Twenty Ten ist in vielen Themes der eigentliche Loop-Bereich in ein Template_Part ausgelagert. Die Template-Seite ruft den ausgelagerten Inhalt mit dem Befehl get_template_part() auf und inkludiert ihn. Gegenüber der früher üblichen Einbindung per INCLUDEPATH bietet diese Methode mehr Flexibilität und macht die Templates-Parts zudem für Child-Themes verwendbar.

Danach kommt der Einbau des Widgets, das in diesem Fall nicht in der Seitenleiste sondern direkt im Inhalt steht - und zwar am Fuß des Beitrags. Da ich den modularisierten Aufbau der Einzelansichten mit get_template_part nutze, kommt der folgende Code in die content-single.php unter den Artikelinhalt (the_content).

<?php if ( is_active_sidebar( 'social' ) ) : ?>
    <?php dynamic_sidebar( 'social' ); ?>
<?php endif; ?>

Abgefragt wird, ob das Widget "social" aktiv ist, also Inhalt hat und dann wird es eingebaut. Das erspart überflüssige HTML-Tags, falls das Widget leer sein sollte.

PHP-Code in Text-Widget

Fehlt nur noch der Inhalt des Widgets. Die flexiblen Text-Widgets eignen sich gut für individuelle Eingaben. Sie akzeptieren aber nur Text, maximal mit HTML- und CSS-Anweisungen. Um Link und Titel des jeweiligen Beitrags auszulesen, müssen es aber die in WordPress üblichen Anweisungen wie get_permalink() und the_title() sein. Dazu muss die Textbox PHP-Code ausführen können. Plugins gibt es dafür mehrere, ich wollte aber lieber eine Funktion in mein Theme schreiben. Diesen Schnipsel fand ich bei pixelbar.be:

add_filter('widget_text', 'gibmirphp', 99);

function gibmirphp($text) {
 if (strpos($text, '<' . '?') !== false) {
    ob_start();
    eval('?' . '>' . $text);
    $text = ob_get_contents();
    ob_end_clean();
 }
 return $text;
}

Zusammen mit dem Link-Code für die Social Media-Buttons funktioniert das Sharing meiner Artikel jetzt in Facebook, Twitter und Google+. Die Eingabe im Text-Widget sieht bei mir wie folgt aus:

Facebook:

<a title="In Facebook teilen - es öffnet sich ein neues Fenster" href="http://www.facebook.com/sharer.php?u=<?php the_permalink() ?>&t=<?php the_title() ?>" target="_blank" rel="nofollow">teilen</a>

Twitter:

<a title="Auf Twitter weitersagen - es öffnet sich ein neues Fenster" href="http://twitter.com/home?status=<?php the_permalink(); ?>" target="_blank">twittern</a>

Google Plus

<a title="bei Google+ posten - es öffnet sich ein neues Fenster" href="https://plus.google.com/share?url=<?php the_permalink(); ?>" target="_blank">teilen</a>

Die Fenster für die Eingabe öffnen sich in einer normalen neuen Seite. Auf Popups habe ich im Moment verzichtet. Vielleicht ändere ich das aber noch. Was meinen Sie denn dazu?

Wenn die .sql-Datei in das root-Verzeichnis des Servers geladen wurde, wird der gesamte Pfad zur Datei bereits angegeben.

Das wünsche ich natürlich niemand, dass die WordPress-Installation nicht mehr funktioniert. Wenn es passiert ist es gut, wenn man ein Backup gemacht hat. Ich nutze dafür backWPup und muss mir endlich mal aufschreiben, wie die Reihenfolge der Schritte ist:

1. Komplett leeres neues WordPress installieren.
2. Darin nur Plugin backWPup installieren und aktivieren.
3. Backup aus vorhandener Installation zurecht legen. Bei Standardeinstellungen ist es eine ZIP-Datei. Stärker komprimiert kann es aber auch eine .tar.gz-Datei sein.
4. ZIP-Ordner extrahieren. Mit einem ZIP-Programm wie 7-Zip muss die .tar.gz  zweimal entpackt werden.
5. sql-Datei daraus per FTP ins root-Verzeichnis der neuen Installation laden.
6. In backWPup die sql-Datei aufrufen. Meist steht der Pfad schon da. Man kann die Datei auch vom eigenen Rechner hochladen.
7. Ausführen und wie empfohlen die sql-Datei vom Server löschen.
8. Vom extrahierten Ordner den Unterordner “wp-content” ebenfalls per FTP hochladen und bestehende Dateien damit überschreiben. (In der Backup-Version sind auch alle Themes und Plugins enthalten. Die müssen mit auf den Server, sonst wirft die Datenbank Fehlermeldungen aus.)

Das sollte es gewesen sein. Die Dateien aus dem Backup und die Einträge in der Datenbank sind damit wiederhergestellt. Ich kann nur empfehlen, regelmäßig Backups zu machen. Das genannte Tool ist dabei eine große Hilfe.

Update am 29.03.2013:

Leider funktioniert seit Version 3.0 die Wiederherstellung der WordPress-Installation – Dateien und Datenbank – nicht mehr wie beschrieben. Das Plugin wird inzwischen von Inpsyde angeboten. Die Basis-Version ist weiterhin kostenfrei. Ich finde es sehr schade, dass die oben beschriebene, sehr bequeme Import-Funktion im neuen backWPup fehlt. Laut Angabe in der Dokumentation arbeitet die Firma an einer besseren Importfunktion für das WordPress-Backend. Ich bin gespannt.

Wenn das Plugin diese Funktion wiederbekommt – beispielsweise in der Pro-Version, wäre ich auch bereit, dafür zu zahlen. Bis dahin teste ich mögliche Alternativen. Ganz brauchbar erscheint mir Blogvault. Wenn ich eine für mich passende Alternative gefunden habe, könnte es sein, dass ich dabei bleibe. Für mich wäre backWPup dann Geschichte. Sehr schade!

Layouts von Grund auf zu erstellen ist nicht meine Kernkompetenz. Hin und wieder bin ich aber gefragt, meine Inspiration über den Bildschirm fliegen zu lassen und das Design selbst zu entwickeln.

Insbesondere knackige Farbprofile zu erstellen finde ich schwierig. Mir hilft da Kuler, ein Online-Tool von Adobe.

Eigene Farbprofile lassen sich mit Kuler speichern.

Gut finde ich, dass verschiedene Farbharmonien wie monochrom oder komplementär schon vorgegeben sind. So erhält man bereits einen Eindruck der möglichen Farbpaletten. Die meisten Nutzer entscheiden sich aber doch mit “custom” für die individuelle Auswahl.

Es gibt einen Haufen Stellknöpfe fürs Finetuning. Da ist es gut, dass sich das für gut befundene Profil speichern lässt. Fertige Paletten lassen sich zudem als ASE-Datei (Adobe Swatch Exchange File) für die Verwendung im lokalen Photoshop exportieren. Finde ich ausgesprochen praktisch, denn das gilt sogar für ältere Version wie CS2.

Wer will kann seine Profile veröffentlichen und von anderen Nutzern bewerten lassen. Inzwischen gibt es einige Themes, die man durchstöbern kann. Man muss ja nicht alles neu erfinden ;-).

Einige meiner Kunden hätten gern ihre Hausschrift auf der Webseite. Dafür habe ich sogar mal eine Flashseite bauen müssen, nur damit der Lieblingsfont auch zuverlässig angezeigt werden konnte. Das ist ebenso wie das altbekannte Image-Replacement so ganz und gar nicht barrierefrei. Da bis heute die meisten Kunden mit Barrierefreiheit nicht viel am Hut haben (wollen), bemühe ich mich immer um Techniken, die zugänglich sind und ohne großes Rampenlicht im Hintergrund wirken. Jetzt habe ich mal einen genaueren Blick auf @font-face geworfen. Diese Methode beschränkt sich auf die Einbettung per CSS, anders als Cufón und sIFR, die mit Javascript und Flash arbeiten.

Inzwischen können eigentlich alle modernen Browser mit Non-Websafe-Schriften umgehen und wenn der Internet Explorer (IE) sein “Spezialfutter” bekommt, kann der das auch – selbst die älteren Modelle. Als Font-Versionen kommen u.a. TrueType (.ttf ), OpenType (.woff) und der Embedded Open Type (.eot) für den IE infrage. Die Font-Dateien lädt man auf den eigenen Server und kann sie dann mit @font-face in ein Stylesheet einladen. Danach lassen sie sich wie gewohnt per font-family ansprechen. Eine Anleitung mit Code-Beispiel gibt es auf Elmastudio. Dort sind auch einige Quellen erwähnt, wo man freie Schriften bekommt und Tools, mit denen sich die eigene Schrift in die o.g. Formate umwandeln lässt. Unbedingt darauf achten, dass die Schriften für diese Verwendung freigegebenen oder lizenziert sind!

Firefox-Problem

Nachdem ich mein @font-face Kit bei Font Squirrel runtergeladen und den mitgelieferten CSS-Code eingebaut hatte, sah ich meine neue Schrift in allen Browsern, sogar im IE7. Nur der Firefox – Version 3.6 – wollte partout nicht. Irgendwas stimmte mit meiner CSS-Datei nicht, denn die Beispieldatei aus dem Kit lief problemlos. Inzwischen bin ich schlauer: Der @font-face-Code muss nicht nur am Anfang der CSS-Datei stehen, er darf auch unter keinen Umständen innerhalb von @media all oder ähnlichen Anweisungen stehen. Nachdem ich das geschnallt habe, klappt es jetzt auch mit dem @font-face.

Neulich hatte ich mal wieder vergessen, dass Safari und Opera standardmäßig nur Formularfelder anspringen, wenn man die Tab-Taste benutzt. Der Safari muss dafür tatsächlich in den Einstellungen geändert werden. Mit Opera lässt sich per Strg + Auf/Ab-Tasten navigieren, kann man aber auch dauerhaft umstellen. Diese Übersicht zeigt, welche Änderungen in den genannten und einigen weiteren Browsern vorgenommen werden müssen. Ist zwar nur für Mac geschrieben, scheint auch für PC zu funktionieren.

Mich hat schon immer gestört, dass die von WordPress in Bilder umgewandelten Emoticons wie alle Bilder nicht wirklich gut mit dem Fließtext harmonieren. Dort werden sie schließlich am häufigsten eingesetzt. Aber ich wollte auch nicht auf die Icons verzichten, weil sie mehr auffallen als die einfachen Schriftzeichen und halt auch hübscher aussehen.

Jetzt habe ich eine Lösung dafür gefunden: Pure-CSS Emoticons, fügt der Zeichenkette ein span-Tag mit CSS3-Styling hinzu. Das Originalzeichen bleibt bestehen, es wird lediglich ein Schriftschnitt, Textfarbe und Hintergrund gesetzt. Das Plugin enthält bereits einen recht großen Vorrat an Emoticons. Per jQuery ausgelesen werden sie mit dem assozierten Style versehen – standardmäßig gibt es Zeichen mit Hintergrund gelb :-) rosa <3 oder pink >:). Vermutlich lassen sich in der JS-Datei auch eigene Zeichen ergänzen, habe ich aber bisher nicht ausprobiert.

Wozu das gut sein soll?

1. Die CSS-Emoticons skalieren perfekt mit der gewählten Schriftgröße. Ist klar, denn es sind ja normale Schriftzeichen.
2. Ein alt-Tag ist nicht nötig, das Zeichen kann ja direkt gelesen werden.
3. Beim Kopieren von Textpassagen mit Emoticons bleibt das Zeichen erhalten, während ein img-Tag meist ignoriert wird.

Im besten Fall (Webkit- und Mozilla-Browser) sieht man das Icon wie gewohnt. Der Internet Explorer hat erwartungsgemäß Probleme mit der Darstellung. Dafür gibt es ein Fallback. Webkit-Browser können sogar den Rotation-Style anzeigen, den man bei den Einstellungen im Backend auswählen kann.

Fazit: Finde ich Klasse und denke, so ist die Emoticon-Darstellung sogar barrierearm.