Dazu müssen in der Konfigurationsdatei nginx.conf – zu lokalisieren unter /etc/nginx/ – alle Zeilen beginnend mit gzip_ einkommentiert werden. Einkommentiert bedeutet, dass das Doppelkreuz am Anfang der jeweiligen Zeilen eliminiert gehört. Und zwar:

Die Standard-Einstellung

# gzip_vary on;
# gzip_proxied any;
# gzip_comp_level 6;
# gzip_buffers 16 8k;
# gzip_http_version 1.1;
# gzip_types text/plain text/css application/json ...

verwandelt sich in:

gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_types text/plain text/css application/json ...

Änderungen speichern, Nginx neu starten:

/etc/init.d/nginx restart

Die letzte einkommentierte Zeile listet Dateiformate auf, die Nginx Gzip-komprimiert an den Client schickt. Diese kann auf Wunsch ausgedehnt oder reduziert werden.

Caching- und Gzip-Header gesendet von Nginx

Steuerungszentrale
Im vorherigen Artikel wurde gezeigt, wie eine Konfigurationsdatei pro Server erstellt und im Nginx-Verzeichnis sites-available abgelegt wird. In unserem Beispiel heißt die Datei helpdesk.wpseo.de – diese wurde mit minimalen Eigenschaften bereits versehen. Nun ist es an der Zeit, die empfohlene Konfiguration in voller Länge zu präsentieren. Die Devise bleibt nach wie vor: Nginx optimiert für WordPress.

Server-Konfigurationsdatei

server {
	## INIT
	listen 80 default_server;
	server_name helpdesk.wpseo.de;


	## ROOT
	root /var/www/helpdesk.wpseo.de;


	## LOGS
	error_log /var/log/nginx/helpdesk.error.log;


	# DEFAULT INDEX
	index index.php;


	## SECURITY
	if ( $request_method !~ ^(GET|HEAD|POST)$ ) {
		return 444;
	}
	location ~ /(\.|wp-config.php|liesmich.html|readme.html) {
		return 444;
	}


	## REWRITES
	location ~ ^/(\d+)/$ {
		return 301 /?p=$1;
	}


	## RESSOURCES
	location ~ \.(?:ico|png|jpe?g|css|js)$ {
		expires 31d;

		add_header Pragma "public";
		add_header Cache-Control "public, must-revalidate, proxy-revalidate";

		#location ~ \.(?!ico).+$ {
		#	valid_referers none blocked server_names ~(wpseo.|google.|yahoo.|bing.|facebook.|fbcdn.|pinterest.);
		#	if ( $invalid_referer ) {
		#		return 444;
		#	}
		#}
	}


	## REDIRECT INDEX
	location / { 
		try_files $uri $uri/ /index.php;
	}


	## PHP FILES
	location ~ \.php$ {
		include fastcgi_params;

		fastcgi_index index.php;
		fastcgi_pass 127.0.0.1:9000;
		fastcgi_split_path_info ^(.+\.php)(/.+)$;
	}


	## AUTH ADMIN
	location = /wp-login.php {
		#auth_basic            "Restricted";
		#auth_basic_user_file  /etc/nginx/htpasswd;

		include fastcgi_params;

		fastcgi_index index.php;
		fastcgi_pass 127.0.0.1:9000;
		fastcgi_split_path_info ^(.+\.php)(/.+)$;
	}
}

Erläuterungen
Die meisten Zeilen der Konfiguration kommen bekannt vor, da vorhin besprochen. Weiter geht’s mit dem Abschnitt SECURITY. An dieser Stelle werden unerlaubte Request-Methoden abgewehrt. Auch der Zugriff auf unsichtbare System- und WordPress-interne Dateien, welche möglicherweise die Nummer der eingesetzten Blogsoftware-Version verraten, wird sofort beendet. Unter REWRITES befindet sich eine Regel, die einen im Browser aufgerufenen Permalink im Format /%post_id%/ auf /?p=%post_id% per 301 Redirect umleitet.

Der Bereich RESSOURCES vereint in sich die Behandlung aller Grafik-, CSS- und JavaScript-Ressourcen. Hier wird Nginx aufgefordert, korrekte Cache-Header zu senden. Die Gültigkeit des Caching beläuft sich auf 31 Tage.

In der gleichen Abfrage für Ressourcen sind sechs Zeilen Code auskommentiert – dabei handelt es sich um einen Hotlinking-Schutz. Sind die Zeilen nachträglich einkommentiert (wie? siehe oben), so unterbindet Nginx die Einbettung eigener Ressourcen auf fremden Webseiten. So schützt man sich gegen Diebstahl von Medien. Favicons sind von der Sperre ausgeschlossen. Die Liste mit Domains ist eine Whitelist – dort sind Domains eingetragen, wo die Einbindung erlaubt ist. Wichtig: Auch die eigene Domain gehört in die Auflistung mit rein (wpseo. = exemplarisch).

Schutz des Administrationsbereichs
Aus Sicherheitsgründen wird es empfohlen, den Admin-Bereich mit einem zusätzlichen Zugang auszustatten. Genauer gesagt die Eingangstür dahin: die Datei wp-login.php (dazu passend: Mehr Sicherheit für WordPress durch den “Admin”-Schutz). Für diesen Zweck sind folgende Schritte erforderlich:

1. Z.B. unter /etc/nginx/ eine neue Datei namens htpasswd anlegen (die Datei beinhaltet keine Punkte).
2. Der Dateiinhalt sind die Zugangsdaten des Nutzers. Das Format wäre Nutzer:Passwort. Diese können mit dem Online-Generator erzeugt werden. Wichtig: Unter Algorithmus bitte Crypt auswählen.
3. Passwortdatei speichern.
4. In der Server-Konfigurationsdatei die Zeilen mit auth_basic und auth_basic_user_file einkommentieren.
5. Nginx restarten.

Tipp zur Spam-Bekämpfung
Handelt es sich um eine CMS-Website, also um Inhalte mit abgestellten Kommentar- und XML-RPC-Funktionen, so würde es Sinn machen, die Dateien wp-comments-post.php und xmlrpc.php auf die interne Blackliste zu setzen und jede Anfrage dahin mit dem Code 444 unverzüglich zu beenden. Die betroffene Zeile aus dem Snippet oben müsste in diesem Fall wie folgt aussehen:

location ~ /(\.|wp-config.php|liesmich.html|readme.html|xmlrpc.php|wp-comments-post.php) {
  return 444;
}

Nginx optimiert: 100 Page Speed Punkte beim Twentyeleven Theme

Load Test
Die durchgeführten Optimierungen (samt Cachify) können sich sehen lassen: WordPress kann locker mit 10 Millionen Hits pro Tag umgehen.

Outro
An dieser Stelle endet die Tutorial-Serie. Der WordPress-Blog läuft performant unter Nginx und PHP5-FPM. APC beschleunigt zusätzlich die Ausführung der Skripte. Durch die Erweiterung der Server-Konfigurationsdatei ist WordPress gegen böswillige Angriffe und unerwünschte Einbettungen der Medien geschützt. Ressourcen sind mit korrekten Caching-Mechanismen ausgestattet. Jetzt ist der Blogger mit hochwertigen Inhalten dran ;)

Tutorials der Serie

• Teil 1: Nginx + PHP5-FPM + APC + MySQL für WordPress installieren
• Teil 2: Nginx Webserver und MySQL für WordPress konfigurieren
• Teil 3: WordPress auf Nginx: Performance und Sicherheit optimieren

MySQL-Datenbank
Zunächst loggt sich der Administrator mit den Root-Zugangsdaten für MySQL ein (dafür erst per SSH auf dem Server anmelden):

mysql -uroot -p

Neue Datenbank kreieren:

CREATE DATABASE helpdesk;

Einen separaten Nutzer definieren:

CREATE USER 'helpdesk_user'@'localhost' IDENTIFIED BY 'MEIN-PASSWORT';

Alle MySQL-Tabellen der Datenbank an den neuen Nutzer binden:

GRANT ALL ON helpdesk.* TO helpdesk_user@localhost;

Mit exit auf der Konsole verlässt man MySQL.

Der MySQL-Zugang wird später in der WordPress-Konfigurationsdatei wp-config.php hinterlegt und baut sich wie folgt zusammen:

define('DB_NAME', 'helpdesk');
define('DB_USER', 'helpdesk_user');
define('DB_PASSWORD', 'MEIN-PASSWORT');
define('DB_HOST', 'localhost');

Soweit steht die Datenbank und kann ab sofort mit Inhalten gefüllt werden.

Nginx Konfiguration

Die nächsten Schritte beschreiben eine minimale, grundliegende Justierung des Nginx-Webservers für einen WordPress-Blog. In einem der kommenden Tutorials der Serie wird eine erweiterte Kalibrierung vorgestellt, die auf Performance und Sicherheit ausgelegt ist.

Als Erstes legt man das Root-Verzeichnis für die WordPress-Instanz an:

mkdir -p /var/www/helpdesk.wpseo.de
chown -R www-data:www-data /var/www

Der Verzeichnisname gehört selbstverständlich angepasst: Ordner = Domain ist eine gute Regel für mehr Übersicht auf der Serverebene. Alternativ würde auch der Projektname genügen. An diesen Speicherort (also unter /var/www/helpdesk.wpseo.de) können WordPress-Dateien via SFTP übertragen werden.

Jeder Blog bzw. jede (Sub)Domain bekommt nicht nur ein eigenes Document-Root, sondern auch eine eigene Nginx-Konfigurationsdatei. Ist keine Pflicht, doch die Trennung nach Projekten erlaubt eine maximale Flexibilität bei abweichenden Einstellungen. Aus diesem Grund erstellt der Administrator unter /etc/nginx/sites-available/ eine für das Projekt zuständige Datei mit notwendigen Webserver-Regeln. In unserem Fall trägt die Datei den Namen helpdesk.wpseo.de

Verfügbare Nginx-Konfigurationsdatei im Ordner sites-available

Innerhalb der Konfigurationsdatei werden alle Einstellungen, Weiterleitungen und andere Steuerungsmechanismen notiert. Auch kleinere Anpassungen rund um den Webserver finden dort ihr Zuhause, da Nginx keine – doch so schnell erreichbare und bequeme – Datei .htaccess unterstützt. Im Klartext: Aus der SEO-Sicht notwendige Redirects müssen ebenfalls dort behandelt werden.

Das wäre der simple Inhalt der Datei zum Copy&Paste:

server {
  listen 80 default_server;
  server_name helpdesk.wpseo.de;

  root /var/www/helpdesk.wpseo.de;
  index index.php;

  location / {
    try_files $uri $uri/ /index.php;
  }

  location ~ \.php$ {
    fastcgi_split_path_info ^(.+\.php)(/.+)$;
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_index index.php;
    include fastcgi_params;
  }
}

Erläuterung
Keine Hexerei: Sieht nach wenig aus, ist es auch.

• default_server: Der virtuelle Server wird als Standard-Server festgelegt und kann im Browser direkt über die IP erreicht werden (bei einer DNS-Weiterleitung dann auch über die Domain).
• server_name: Als Servername ist die zukünftige (Sub)Domain definiert (erst bei DNS-Weiterleitungen relevant, kann auch localhost sein).
• root: Das im vorherigen Schritt zugewiesene Root-Verzeichnis der Website.

Speichern. Per Terminal als “erreichbar” markieren:

ln -s /etc/nginx/sites-available/helpdesk.wpseo.de /etc/nginx/sites-enabled/

Nginx neu starten:

/etc/init.d/nginx restart

Falls noch nicht geschehen, WordPress-Files ins Stammverzeichnis per SFTP übertragen und wp-config.php mit Anmeldedaten der MySQL-Datenbank versehen.

Beim Aufruf der Server-IP im Browser erscheint der WordPress-Installationsassistent. Das deutet auf einen fehlerfreien Betrieb des Webservers in Zusammenspiel mit WordPress hin.

Outro
Der WordPress-Blog steht ebenfalls, ist erreichbar und kann wie sonst üblich eingerichtet werden. Ein Tipp am Rande: Für SEO-freundliche Permalinks empfiehlt sich das dafür programmierte Toolbox-Modul – nach der Aktivierung können Permalinks in den WordPress-Einstellungen im Format /%postname%/ ausgewählt und genutzt werden.

Toolbox-Modul speziell für Nginx-Webserver

Hinweise

• Befinden sich WordPress-Dateien in einem Unterordner (z.B. wordpress), müsste die Nginx-Konfiguration nachträglich angepasst werden.
• Plugins, die für ihre korrekte Funktionsweise die Datei .htaccess beansprucht hatten, dürfen unter Nginx nicht länger zum Einsatz kommen und gehören abgestimmt oder abgestellt.

Tutorials der Serie

• Teil 1: Nginx + PHP5-FPM + APC + MySQL für WordPress installieren
• Teil 2: Nginx Webserver und MySQL für WordPress konfigurieren
• Teil 3: WordPress auf Nginx: Performance und Sicherheit optimieren

Installation
Nach einem erfolgreichen SSH-Login via Konsole aktualisieren folgende Befehle die interne Liste mit Download-Quellen auf dem Server.

echo "deb http://packages.dotdeb.org squeeze all" > /etc/apt/sources.list.d/squeeze-dotdeb.list
gpg --keyserver keys.gnupg.net --recv-key 89DF5277
gpg -a --export 89DF5277 | apt-key add -
aptitude update

Im Anschluss startet die eigentliche Installation der Komponenten: Nginx Webserver, PHP5-FPM samt Module, MySQL-Server.

aptitude install nginx
aptitude install php5-fpm php5-mysql php5-gd php5-curl php5-apc
aptitude install mysql-server

Anmerkungen

1. Während der Installation des MySQL-Servers erscheint plötzlich eine in Blau hinterlegte Abfrage für das MySQL-Passwort des root-Nutzers. Bitte dran denken, die Eingabe aufzubewahren.
2. PHP-Module können jederzeit nachinstalliert werden, falls sich Anforderungen im Laufe des Blog-Betriebs ändern sollten. Das installierte Zusatzmodul APC (php5-apc) beschleunigt zusätzlich die Ausführung der PHP-Skripte, da diese im schnelleren Shared-Memory der Server-Instanz abgelegt werden. Das WordPress Caching-Plugin Cachify setzt ebenfalls auf APC.

Passwort-Abfrage für den MySQL-Server

Start
Nach einer erfolgreichen Installation können die einzelnen Dienste gestartet (und später mit gleichen Befehlen rebootet) werden:

/etc/init.d/mysql restart
/etc/init.d/php5-fpm restart
/etc/init.d/nginx restart

Ab diesem Zeitpunkt ist Nginx als Webserver in Betrieb und liefert statische Inhalte an Clients aus. Das sollte der Aufruf der Server-IP in der Adressleiste des Browsers bestätigen: Welcome to nginx!

PHP-Aktivierung
Nginx ist von Haus aus tatsächlich so konfiguriert, dass ausschliesslich statische Dateien (HTML, Bilder, etc.) verarbeitetet und zurückgegeben werden. PHP ist zwar jetzt auf dem Server installiert und gestartet, doch das muss Nginx erst kommuniziert werden. Zur Veranschaulichung reicht vorerst das simple Einkommentieren der bereits vorbereiteten Zeilen in der Nginx-Konfigurationsdatei. Diese Default-Datei befindet sich unter /etc/nginx/sites-available/, kann via Transmit erreicht und im Editor geöffnet werden. Dort nachfolgende Zeilen finden und Sternchen vor den Befehlen entfernen.

location ~ \.php$ {
  fastcgi_split_path_info ^(.+\.php)(/.+)$;
  fastcgi_pass 127.0.0.1:9000;
  fastcgi_index index.php;
  include fastcgi_params;
}

Ein Neustart quittiert jede Änderung der Konfiguration:

/etc/init.d/nginx restart

Standardeinstellungen des Nginx-Webservers in der Datei "default"

Ab sofort interpretiert Nginx jede Datei mit der Endung .php als ein PHP-File und startet entsprechend den PHP-Interpreter. Zum Ausprobieren der korrekten Funktionsweise kann eine Datei namens phpinfo.php mit nachfolgendem Inhalt unter /usr/share/nginx/www erstellt, abgelegt und im Browser via http://meine.ip/phpinfo.php aufgerufen werden:

<?php phpinfo() ?>

Outro
Erscheint die erwartete Übersicht an PHP-Informationen, hat alles wunderbar funktioniert. Nginx und PHP5-FPM arbeiten perfekt.

Tutorials der Serie

• Teil 1: Nginx + PHP5-FPM + APC + MySQL für WordPress installieren
• Teil 2: Nginx Webserver und MySQL für WordPress konfigurieren
• Teil 3: WordPress auf Nginx: Performance und Sicherheit optimieren

1. Bucket als Website definieren
Durch den Klick auf das betroffene Bucket in der linken Spalte öffnet sich rechts die entsprechende Datenstruktur. Die Schaltfläche Properties verbirgt im unteren Fensterbereich weitere Registerkarten mit zusätzlichen Eigenschaften des gewählten Bucket. Relevant an dieser Stelle ist der Tab Website mit seinen Einstellungen für den Betrieb einer Website auf Amazon S3.

Der Tab Website glänzt nicht wirklich durch eine Vielfalt an möglichen Optionen. Umso einfacher und verständlicher ist die Einschaltung der Möglichkeit, statische Webseiten auf Amazon S3 zu hosten. Checkbox aktivieren und als Index-Dokument index.html eintragen (weicht der Dateiname ab, so ist dieser anzupassen). Speichern. In der gleichen Ansicht präsentiert Amazon S3 die Zieladresse der aktuellen Website – unter der kryptischen URL ist die Startseite des Projekts aufzurufen.

Wichtig zu beachten: Amazon S3 gibt lediglich statische HTML-Dateien an den Browser aus. Webseiten mit angeblich dynamischen Inhalten (auf Basis von PHP, ASP, etc.) werden nicht geparst (da der Interpretor fehlt) und stets mit dem Original-Quelltext ausgegeben.

Einstellungen für das Hosting einer Website auf Amazon S3

2. Bucket einer Domain zuweisen
Erlaubt der Hoster bzw. Domain-Verwalter eine DNS-Umleitung der Domain, so kann die gewünschte, deutlich kürzere (Sub)Domain auf die genannte URL des Amazon S3-Buckets (Endpoint) “gezeigt” werden. Beispiel: Für das Bucket xmas.wpseo.de lautet die CNAME-Zieladresse wie folgt (Punkt am Ende wichtig):

xmas.wpseo.de.s3-website-eu-west-1.amazonaws.com.

Der Artikel Amazon CloudFront mit Amazon S3 verknüpfen beschreibt den sinnvollen Weg, Amazon CloudFront als eine mögliche CDN-Lösung zu nutzen.

Outro
Der wesentliche Vorteil des Hosting einer (statischen) Website auf Amazon S3 ist sicherlich die tadellose Verfügbarkeit der Seiten – auch bei Last (ja, auch statische Ressourcen können unter Last stehen bzw. Last bekommen). In ersten 12 Monaten sogar kostenlos (5 GB Speicher und andere Begrenzungen beachten).

wpSEO bei Google mit einem Produkt-Snippet

Der Artikel beschreibt im Groben die Methode, eine Produktseite im HTML-Code mit den von Google und Yahoo festgelegten schema.org-Markierungen auszustatten und damit für das Produkt-Snippet innerhalb der Google-Suchergebnisse vorzubereiten. Wie im Screenshot abgebildet, konzentriert man sich hier ausschließlich auf Kundenbewertungen und Preisangaben. Google stellt dagegen deutlich mehr Merkmale für Hervorhebungen von Produkteigenschaften (dazu zählen u.a. Marke, Bild, Verfügbarkeit) zur Verfügung.

Je nach Webseite indexiert Google die eingeführten Kennzeichnungen innerhalb eines Werktages. Als Beispiel für den nachfolgenden Code liegt die für wpSEO, das WordPress SEO Plugin vorgenommene Umsetzung zugrunde.

1. Deklarierung als Produkt
Zunächst sollte Google davon in Kenntnis gesetzt werden, dass es sich beim Seitenaufruf um eine Produktseite handelt. Das geschieht wahlweise im betroffenen DIV-Container oder direkt beim Einstieg in den Quelltext im <html>-Tag. Die Injektion ins HTML-Tag ist dann vorzuziehen, wenn Produkteigenschaften teilweise in die Metatags als Microdata ausgelagert sind. Dazu zählt beispielsweise ein abweichendes Vorschaubild, welches ein Produkt repräsentiert, auf der Detailseite zwecks notwendiger Markierung jedoch nicht vorkommt.

Anbei die beiden Varianten:

<div itemscope itemtype="http://schema.org/Product">

<html itemscope itemtype="http://schema.org/Product">

2. Auszeichnung der Kundenbewertungen
Idealerweise verfügt jedes Produkt im Shop über Bewertungen. Bestenfalls über eine ausreichende Anzahl an Bewertungen. Diese werden letztendlich im Google Produkt-Snippet abgebildet. Wichtig zu beachten ist die ernstgemeinte Regel, dort keine Shop-Bewertungen, vielmehr Produkt-abweichende Stimmen und Meinungen zu integrieren. Der Code-Auszug ist exemplarisch, dürfte allerdings in jedem E-Commerce- und Templating-System ähnlich aufgebaut sein.

<p itemprop="aggregateRating" itemscope itemtype="http://schema.org/AggregateRating">
  <em itemprop="ratingValue">4.99</em> Sterne bei
  <em itemprop="reviewCount">804</em> Bewertungen.
</p>

Die Daten sind vom System dynamisch gefüllt. Aus den beiden Kennzahlen generiert Google eine entsprechende Ausgabe im Produkt-Snippet. Die Eigenschaften im Einzelnen:

• ratingValue steht für die aktuelle Durchschnittsmenge an Bewertungssternen. Per Default geht Google von einer Obergrenze mit 5 Sternen aus, dies kann ebenfalls nachjustiert werden.
• reviewCount signalisiert die Gesamtzahl an Bewertungen, die lieber nicht manipuliert werden sollte.

Tipp am Rande: Findet die Ausgabe der vergebenen Sterne auf der Produktseite als schicke Grafik statt, kann auf Textmarkierungen via <em> und <span> verzichtet werden und auf der Meta-Ebene erfolgen. Der obige Code würde entsprechend wie folgt aussehen:

<p itemprop="aggregateRating" itemscope itemtype="http://schema.org/AggregateRating">
  <meta itemprop="ratingValue" content="4.99" />
  <meta itemprop="reviewCount" content="804" />
</p>

Auch sieht Google es vor, Kundenmeinungen im Shop als einzelne Reviews markieren zu können.

3. Preisangaben zum Produkt
Dito beim Produktpreis: Hat ein Produkt einen festen Verkaufspreis, so wird dieser mit wenig Code an Suchmaschinen kommuniziert:

<p itemprop="offers" itemscope itemtype="http://schema.org/Offer">
  <em itemprop="price">€ 19.99</em>
</p>

Variiert der VK dagegen je nach Größe, Farbe, Art, Händler oder Menge, können hierfür zusammengehörige Kommunikationsglieder eingefügt werden. In Einfach: Den kleinsten und den höchsten Preis zeichnet der Entwickler im Produkttext oder analog zu Bewertungen als Metatags aus.

<p itemprop="offers" itemscope itemtype="http://schema.org/AggregateOffer">
  <em itemprop="lowPrice">€ 19,99</em> bis <em itemprop="highPrice">€ 99,99</em>
</p>

Fazit
Noch ist die Zahl der Shop-Betreiber, die auf Auszeichnungen der Artikeleigenschaften im Quelletxt setzen, sehr gering. Das sollte als Chance genutzt werden, um in den SERPs aufzufallen. Und zugleich einen Mehrwert durch (Mehr)Information bieten. SEO mit Köpfchen.

Rich Snippets Testung Tool steht wie immer helfend zur Seite.

Hervorhebungen im Quelltext
Beim Eintragen einer Webadresse in das dafür vorgesehene Feld (alternativ bei direkter Eingabe im Mitteilungstext) sendet Google+ unverzüglich eine Anfrage an die hinterlassene Webseite. Dabei versucht Google Metainformationen für das +Snippet zu extrahieren. Dazu gehören: Ein Titel, eine Kurzbeschreibung und ein Vorschaubild.

Damit notwendige Daten schnell und zuverlässig erkannt und als Snippet verfügbar sind, empfiehlt Google eine Auszeichnung der einzelnen Werte direkt im Quelltext der Webseiten. Hierfür stehen zwei Möglichkeiten parat:

• Im <head> einer Blogseite als Metatag. Betroffen ist das WordPress-Template header.php
• Im <body> bzw. direkt bei der Ausgabe des Artikelinhalts im WordPress-Loop. Betroffen ist single.php

Die zweite Methode ist klar zu bevorzugen, da die Auszeichnungen im Template nur platziert, jedoch nicht befüllt werden müssen. Zu beachten ist ebenfalls die Obergrenze von 200 Zeichen für eine Kurzbeschreibung, da Google diese im Snippet sonst kürzt.

SEO-Metadaten als Referenz
WordPress SEO Plugin Nutzer können sich die Mühe mit der Platzierung der Markierungen im Code sparen, denn Google wertet auch die Standard-Metadaten wie den Seitentitel (title-Tag) und die Seitenbeschreibung (Meta-Tag description) einer Blogseite aus. Die beiden Werte generiert das Plugin eh für Suchmaschinen, Google+ bedient sich lediglich an der Quelle.

Die empfohlene Länge der manuellen Metabeschreibungen im SEO-Plugin von 140 Zeichen zeigt hier ihre wahre Stärke: die von Google übernommene Kurzbeschreibung passt ausgezeichnet ins Snippet-Design. Dazu ein Screenshot:

Perfekt abgestimmter Google+ Snippet für ein Blogpost

Thumbnail im Snippet
Für eine vollendete Optik eines gelungenen Google+ Snippet fehlt eine Bildvorschau für den verknüpften Blog-Artikel. Auch für diesen Zweck hält Google eine entsprechende Auszeichnung nach dem gleichen Muster parat: Als Meta oder im Loop können Bilder im Artikel zur Nutzung im Snippet gekennzeichnet werden.

Für Vorschaubilder im Snippet benötigt Google+ ausschliesslich Bilder mit einer Mindesthöhe von 120 Pixel. Ist das festgelegte Artikelbild kleiner, wird es nicht verwendet und Google+ sucht sich eine passendere Grafik innerhalb der Webseite raus. Ist das Bild dagegen zu groß, skaliert Google automatisch auf die vorgegebene Höhe.

Wer Theme-interne Templates nicht anfassen mag oder kann, nutzt einfach das nachfolgende Toolbox-Modul, welches Artikelbilder im Open Graph Protocol als Metatag og:image ausgibt und Google+ (bei richtigen html-Attributen auch für Facebook) somit ein brauchbares Vorschaubild zur Verfügung stellt. Bitte Hinweise am Seitenende beachten.

Toolbox-Modul für Artikelbilder als Metatag

<?php
/*
Module Name: Ausgabe der Artikelbilder als Metatag
Module URI: http://playground.ebiene.de/wordpress-google-plus/
Description: Fügt dem Head-Bereich ein og:image-Metatag mit aktuellem Artikelbild zu. [Frontend]
Author: Sergej Müller
Author URI: http://ebiene.de
*/


/* Sicherheitsabfrage */
if ( !class_exists('Toolbox') ) {
	die();
}


/* Ab hier kann's los gehen */
function sm_meta_thumb() {
	/* Nur mit ID */
	if ( empty($GLOBALS['post']) or !is_object($GLOBALS['post']) or (!$id = $GLOBALS['post']->ID) ) {
		return;
	}

	/* Keine Feeds und X-Backs */
	if ( is_feed() or is_trackback() ) {
		return;
	}

	/* Beiträge mit Thumbs */
	if ( is_singular() && has_post_thumbnail($id) ) {
		$image = wp_get_attachment_image_src(
			get_post_thumbnail_id($id)
		);

		$thumb = $image[0];

	/* Default Thumb */
	} else {
		$thumb = 'http://cdn.wpseo.de/website/v3/img/logo/120x120.png';
	}

	/* Ausgabe */
	echo sprintf(
		'%s<meta property="og:image" content="%s" />',
		"\n",
		esc_attr($thumb)
	);
}

/* Fire */
add_action(
	'wp_head',
	'sm_meta_thumb'
);

Hinweise

• Die Ausgabe erfolgt ausschließlich auf Seiten mit Artikelbildern. Auf restlichen Seiten im Blog (Startseite, Archiv, etc.) gibt das Modul ein Standard-Thumbnail aus, welches im Modul-Schnipsel als Pfad angepasst werden sollte.
• Aufruf der WordPress-Funktion wp_head() muss in header.php stattfinden.

Testing
Das Ergebnis lässt sich wahlweise direkt in Google+ durch die Eingabe einer URL (ohne abzusenden) testen. Oder mithilfe des Google Snippet Tools.

Absicherung gegen Updates
Mitgelieferte Sugars speichert Espresso in sich selbst – zu finden unter Programme > Espresso > Paketinhalt zeigen. Der Vollständigkeit wegen, sei der komplette Pfad zu den verborgenen “Zuckerstückchen” genannt: /Applications/Espresso.app/Contents/SharedSupport/Sugars/. Dort bewahrt das Programm alle Module auf, die allerdings an der Stelle nicht bearbeitet werden dürfen. Das nächste Update würde die Sugars ersetzen, alle Änderungen seitens Nutzer gehen verloren.

Sobald man weiß, welche Sugar-Datei (die nach Formaten gegliedert sind) bearbeitet werden soll, gehört diese in die Zwischenablage kopiert. In unserem Fall ist es die CSS.sugar, weil dort eine Korrektur an der Autovervollständigung der CSS-Attribute vorgenommen werden soll. Die kopierte Datei landet vorerst auf dem Schreibtisch.

Einträge für die Autovervollständigung in Espresso XML

XML als Funktionsquelle
Nach einem Doppelklick würde Espresso das File vom aktuellen Ort (Schreibtisch) in den Benutzerordner /Library/Application Support/Espresso/Sugars/ befördern. Bleiben wir also bei unserem Vorhaben, diverse Einträge aus der Liste der Autovervollständigung für CSS-Dateien zu entfernen (widows, ja widows als erster Auto-Vorschlag beim Tippen von width nervt auf Dauer).

Hierfür wird das Sugar via Rechtsklick > Paketinhalt zeigen temporär “entpackt”. Dort navigiert man zum Ordner CodeSenseLibraries und weiter zu CSS.xml. Genau diese XML-Datei beinhaltet alle Vorschläge für CSS-Attribute im Editor. Jetzt nach Wunsch und Laune modifizieren, speichern. Doppelklick auf Sugar, Datei verschwindet vom Desktop. Espresso neu starten.

CSS.sugar im Finder extrahieren

LESS-Support
Für alle Nutzer von LESS kann das LESS.sugar ans Herz gelegt werden. Alternativ zu LESS.sugar kann im CSS.sugar die Datei Languages.xml im Knotenpunk detectors um den Eintrag <extension>less</extension>> erweitert werden.

Outro
Der besprochene Weg zeigt die Möglichkeit, Espresso nach eigenen Bedürfnissen anzupassen. Wahlweise mithilfe von Installationen zusätzlicher Sugars oder unkomplizierter Bearbeitung der Sugars im Benutzerordner. Überflüssige, veraltete Werte in der Autovervollständigung sind so prompt eliminiert und stören nicht länger. Ein angelegtes Backup dient immer als Versicherung.

[gist id=xxxxx]

Zuständige Gist-ID für den Shortcode

Integration der Stylesheets
Das Modul kümmert sich nicht nur ums Auslesen, Caching und die Darstellung der Code-Auszüge. Die für die Syntax-Hervorhebung zuständige CSS-Datei wird auf Beiträgen mit der Gist-Einbindung ebenfalls eingebunden und nachgeladen. Sind eigene Stylesheets für die Code-Formatierung im Einsatz, so kann auf die CSS-Registrierung im Modul verzichtet werden.

Toolbox-Modul für die Gist-Einbindung

<?php
/*
Module Name: Einbindung der Gist-Snippets
Module URI: http://playground.ebiene.de/gist-toolbox-modul/
Description: Abfrage und Darstellung der Gist-Snippets via [gist id=xxxx] Shortcode. [Frontend]
Author: Sergej Müller
Author URI: http://ebiene.de
*/


/* Sicherheitsabfrage */
if ( !class_exists('Toolbox') ) {
	die();
}


/* Gist */
class Gist
{


	/**
	* Initiator der Klasse
	*/

	public static function init()
	{
		add_action(
			'wp_enqueue_scripts',
			array(
				__CLASS__,
				'register_style'
			)
		);

		add_shortcode(
			'gist',
			array(
				__CLASS__,
				'handle_shortcode'
			)
		);
	}


	/**
	* Registrierung des CSS
	*/

	public static function register_style()
	{
		wp_register_style(
			'gist_css',
			'https://gist.github.com/stylesheets/gist/embed.css'
		);
	}


	/**
	* Verarbeitung des Shortcodes
	*
	* @param   array   $atts    Array mit Attributen
	* @param   string  $txt     Text zwischen den Tags [optional]
	* @return  string  $output  Ermittelter Gist-Quelltext
	*/

	public static function handle_shortcode($atts, $txt = null)
	{
		/* Leer? */
		if ( empty($atts['id']) ) {
			return 'No Gist ID.';
		}

		/* Init */
		$id = (int) $atts['id'];
		$transient = 'sm_gist_' .$id;

		/* Einbinden */
		wp_enqueue_style('gist_css');

		/* Im Cache */
		if ( $gist = get_transient($transient) ) {
			return $gist;
		}

		/* Abrufen */
		$response = wp_remote_get(
			'https://gist.github.com/' .$id. '.json',
			array('sslverify' => false)
		);

		/* Fehler? */
		if ( is_wp_error($response) ) {
			return $response->get_error_message();
		}

		/* Holen und parsen */
		$json = json_decode(
			wp_remote_retrieve_body($response)
		);

		/* Leer? */
		if ( empty($json->div) ) {
			return 'Empty Data.';
		}

		/* Zuweisen */
		$output = (string) $json->div;

		/* Cachen */
		set_transient(
			$transient,
			$output,
			60 * 60 * 24
		);

		return $output;
	}
}


/* Fire */
add_action(
	'init',
	array(
		'Gist',
		'init'
	)
);

Hinweise

• Für eine fehlerfreie Funktionsweise des Toolbox-Moduls werden PHP 5.2.0 sowie ein Server mit ausgehenden Verbindungen vorausgesetzt.
• Die Lösung behandelt einfache Gist-Snippets mit nur einem File. Bei komplexeren Ansätzen mit mehreren Dateien pro Gist empfiehlt sich die umfangreichere Methode von Dominik Schilling.

Related Posts im WordPress-Blog

Arbeitsweise der Lösung
Nach der Aktivierung des Moduls (Frontend als Bereich) und der Einbindung des Hooks (siehe weiter unten) prüft die Funktion zunächst, ob der Artikel mindestens einer Kategorie zugeordnet ist. Ist das der Fall, startet eine WordPress-Query die Suche nach ähnlichen Artikeln, wobei die Kategorie-ID als gemeinsamer Nenner gilt. Die Anzahl der gefundenen Treffer beschränkt sich auf zwei, eine Erhöhung der Zahl im Code ist jederzeit möglich.

Verfügen erstellte Beiträge über Artikelbilder, so werden diese im Modul berücksichtigt und zusätzlich zum Artikeltitel auf der Blogseite ausgegeben. Andernfalls kommt lediglich der alleinstehende Titel als klickbare Fläche zum Vorschein.

Verknüpfung mit Themes
Die Einbettung der Treffer an der gewünschten Stelle im WordPress-Theme erfolgt durch ein speziell dafür angelegtes Hook namens related_posts. Der sparsame Aufruf lautet:

<?php do_action('related_posts'); ?>

Toolbox-Modul für Related Posts

<?php
/*
Module Name: Ausgabe Kategorie-verwandter Artikel
Module URI: http://playground.ebiene.de/related-posts-wordpress-nativ/
Description: &lt;?php do_action('related_posts'); ?&gt; für die Ausgabe der Treffer im Theme. [Frontend]
Author: Sergej Müller
Author URI: http://ebiene.de
*/


/* Sicherheitsabfrage */
if ( !class_exists('Toolbox') ) {
	die();
}


/* Ab hier kann's los gehen */
function sm_related_posts() {
	/* Keine Kategorien */
	if ( ! $cat = get_the_category() ) {
		return;
	}

	/* IDs */
	$ids = implode(
		',',
		array_reduce(
			$cat,
			function($v, $w) {
				$v[] = $w->term_id;
				return $v;
			}
		)
	);

	/* Query starten */
	$query = new WP_Query(
		array(
			'cat' => $ids,
			'orderby' => 'rand',
			'post__not_in' => array(get_the_ID()),
			'posts_per_page' => 2
		)
	);

	/* Keine Ergebnisse */
	if ( ! $query->have_posts() ) {
		return;
	}

	/* Ausgabe */
	echo '<ul id="related">';

	while ( $query->have_posts() ) {
		$query->the_post();

		echo sprintf(
			'<li class="item"><a href="%s">%s%s</a></li>',
			get_permalink(),
			( function_exists('has_post_thumbnail') && has_post_thumbnail() ? get_the_post_thumbnail() : '' ),
			get_the_title()
		);
	}

	/* Reset */
	wp_reset_postdata();

	echo '</ul>';
}

/* Funktionsaufruf */
add_action(
	'related_posts',
	'sm_related_posts'
);

Optische Anpassungen
Die CSS-Formatierung der Ausgabe kann analog zu der im Artikel Thematisch ähnliche Beiträge samt Vorschaubilder in WordPress beschriebenen Methode erfolgen. IDs und Klassen innerhalb der Tags können modifiziert werden.

Toolbox hat die Aufgabe, functions.php zu revolutionieren

Klarheit beim Funktionsaufbau
Welchen Vorteil hat die Modularisierung der Snippets? In erster Linie ist es die Übersichtlichkeit. Durch die Aufteilung und eine sinnvolle Benennung der Code-Schnipsel, erfolgt eine schnellere Zuordnung der Funktionen – man erfährt prompt und ohne ein komplexes Kommentarsystem zu besitzen, welches Modul (und somit auch welcher Code) für welche Funktionsweise im Blog zuständig ist. Mehr Struktur und Ordnung kommen rein. Der Gedanke ähnelt sehr der Verwaltung von Plugins innerhalb von WordPress: Zielsetzungen kapseln.

Zudem ist es ein weiterer Schritt in Richtung Trennung zwischen Funktion und Layout, denn die globalen Codeanweisungen gehören nicht unbedingt ins Theme.

Zuweisung der Lade-Bereiche und Abschaltung
Toolbox-Module sind nichts anderes als gruppierte Funktions- und Hooks-Aufrufe. Doch die Module lassen sich auf Wunsch einzeln deaktivieren. Oder auch genau festlegen, wo diese geladen und ausgeführt werden. Dazu stehen Segmente Nur im Frontend, Nur im Backend und Im Back- und Frontend zur Auswahl bereit.

Verfügbare Toolbox-Module mit Beschreibung aufgelistet

Aufbau der Toolbox-Module
Ein Toolbox-Modul ist eine PHP-Datei im Plugin-Verzeichnis modules, bestehend aus optionalen Metadaten, einer Sicherheitsabfrage und benutzerdefinierten Code-Fragmenten. Wie auch bei WordPress-Plugins besitzen Meta-Informationen der Toolbox-Module über ein festgelegtes Muster. Der Module Name, die Description und Module URI werden ausgewertet und in der Auflistung der Module innerhalb der Plugin-Einstellungen angezeigt.

Als Linktipp eignen sich an dieser Stelle wpsnipp.com und wp-snippets.com mit ihren zahlreichen WordPress-Snippets.

Skelett eines Toolbox-Moduls

<?php
/*
Module Name: Name des Moduls
Description: Beschreibung des Moduls [Backend|Frontend]
Author: Sergej Müller
Author URI: http://ebiene.de
*/

/* Sicherheitsabfrage */
if ( !class_exists('Toolbox') ) {
  die();
}

/* Ab hier kann's los gehen */
echo 'Hier mein Snippet';

Ratschläge zum Modulaufbau

• Für die korrekte Darstellung der Sonderzeichen, sollte das Modul im UTF-8 Format gespeichert werden.
• Abschließendes ?> am Ende des Moduls ist nicht notwendig.

Potential bei Themes, Multisite und Performance

• Toolbox stellt die Funktionalität der aktiven Module Themes-übergreifend bereit, d.h. bei einem Layout-Wechsel sind die hinterlegten Funktionen sofort einsatzbereit. Dito bei Multisite-Blogs.
• Im Vergleich zu WordPress Plugins, erfolgt bei den Modulen keine Prüfung auf vorhandene Updates. Das verringert wiederum die Ladezeiten.
• Schon gewusst, das WordPress die functions.php aus aktuellem Theme sowohl im Blog-Frontend wie auch Backend lädt? Durch eine genaue Zuweisung der Lade-Bereiche (Frontend, Backend, FE und BE), lässt sich die Performance des Blogs steigern und die Fehlerquote senken, da Funktionen nur dort geladen und ausgeführt werden, wofür diese tatsächlich programmiert wurden.

Module im Lieferumfang
Dem Plugin liegen vorgefertigte Module bei.

Neue oder weiterentwickelte Module

• Kompatibilität für nginx Webserver
• Artikelbilder als Metatag
• Einbindung von Gist-Snippets
• Modifizierung der Admin Bar
• Bildoptimierung beim Upload
• Ausgabe thematischer Artikel
• Aktivierung der Vorschaubilder

Hinweise

• Mindestvoraussetzungen: WordPress 3.3 und PHP 5 (5.3 empfohlen)
• Plugin-interne Hilfe oben rechts beachten

Outro
Will der aktuelle Blog um eine Funktion erweitert werden, wo der PHP-Code eigentlich in die functions.php gehören sollte? Stop! Ein weiteres Toolbox-Modul anlegen, Metadaten anpassen, den Schnipsel einfügen, für einen Bereich aktivieren. Arbeiten lassen.

Flattr
Unterstützung via Flattr ist jederzeit willkommen. Danke.

Download
› Toolbox – WordPress Snippets als Module ↓