Standardmäßig wird im Kopfbereich eines jeden Themes der Meta-Tag generator mit der Versionsnummer von WordPress ausgegeben. Nun kann es vorkommen, dass Theme-Designer diesen aus Sicherheits- oder anderen Gründen anpassen möchten. Im Folgenden zeige ich, wie man den Tag entfernen, verändern oder erweitern kann.

Kopfbereich

Sobald ein WordPress-Theme die Funktion wp_head() einsetzt (sollte zwingender Standard sein), wird im Kopfbereich head ein Meta-Tag mit Angabe der WordPress-Versionsnummer ausgegeben.

<meta name="generator" content="WordPress 3.0.1" />

Entfernen

In der Vergangenheit gab es immer wieder Aufrufe, diese Versionsnummer als Sicherheitsmaßnahme gegen gezielte Hackerangriffe auf WordPress zu entfernen. Alles Humbug sagen WordPress-Entwickler.

Wer diesen Meta-Tag dennoch loswerden möchte, kann folgenden Code in die functions.php des Themes kopieren:

remove_action('wp_head', 'wp_generator');

Verändern

Wenn man den Meta-Tag nicht komplett entfernen möchte, kann man ihm mit dem Filter the_generator verändern. So ließe sich z. B. nur die Versionsnummer entfernen:

function wdm_generator($generator) {
        return str_replace(' '.get_bloginfo('version'), '', $generator);
}
add_filter('the_generator', 'wdm_generator');

Erweitern

Machmal kann es nützlich sein, diese Angaben im Kopf des WordPress-Themes noch zu erweitern. Mit dem schon angesprochenen Filter the_generator lässt sich das einfach umsetzen. Um bspw. die Versionsnummer des Themes hinzuzufügen, kann man folgenden Code in die functions.php kopieren:

function wdm_generator($generator) {
    $generator .= "\r\n" . '<meta name="generator" content="Mein Theme 2.0" />';
    return $generator;
}
add_filter('the_generator', 'wdm_generator');

* "\r\n" dient lediglich dazu einen Zeilenumbruch im Quelltext zu erzwingen und ist optional.

WordPress ist schon von Haus aus gut dafür eingestellt, von Suchmaschinen gefunden zu werden. Das Standard Theme sowie die meisten kostenlosen Templates, besteht aus sauberen, gut für Maschinen lesbaren Code. Durch wenige Handgriffe im Theme, kannst Du Deinen Blog optimal für Suchmaschinen einrichten.

Den Title-Tag optimieren

Der Title-Tag, in der header.php, ist für die Suchmaschinenoptimierung einer der wichtigsten Faktoren. Es ist der Name des Dokuments und das erste was die Suchmaschine von deiner Seite lernt, hier sollten die Wörter stehen für die Du gefunden werden willst. Der Title im WordPress Default Theme war eine lange Zeit nicht wirklich optimal eingestellt, was jetzt aber behoben wurde und auch insbesondere im neuen Standard Theme Twenty Ten sehr schön gelöst ist.

Der Name deines Artikels sollte im Title-Tag vor dem Namen deines Blogs stehen, da Suchmaschinen den ersten Worte des Titels mehr Bedeutung schenken und es so auch für den Suchenden leichter zu erkennen ist, worum es auf deiner Seite geht. Sollte das in Eurem Theme noch nicht so sein, schlage ich vor es wie im derzeitigen Default Theme zu machen.

<title><?php wp_title('&laquo;', true, 'right'); ?> <?php bloginfo('name'); ?></title>

Wer möchte kann sich seinen Title-Tag aber auch noch differenzierter gestalten, je nach dem in welchem Bereich Deiner Webseite der Besucher sich gerade befindet. Startseite, Kategorien, Archive und beispielsweise die Suchresultate können verschieden angepasste Title-Tags besitzen:

<title><?php
if(is_single() || is_page()) {
  single_post_title(); echo ' | '; bloginfo( 'name' );
} else {

if(is_category() || is_archive()) {
  wp_title(''); echo ' auf '; bloginfo( 'name' );
} else {

if(is_front_page() || is_home()) {
  bloginfo('name'); echo ' | '; bloginfo( 'description' );
} else {

  wp_title(''); echo ' | by creative! ';

} } } ?></title>

Meta-Tags: Keywords & Description

Ebenfalls im Kopf eines HTML Dokuments befinden sich die Meta-Keywords und die Meta-Description. Diese waren früher sehr gut dafür geeignet, bessere Positionen bei den Suchmaschinen zu erlangen. Nachdem diese Methode allerdings, vor über 10 Jahren schon, ausgenutzt wurde, haben beide im Grunde überhaupt keinen Einfluss mehr auf Eure Rankings.

Dennoch sucht Google beispielsweise in eurer Meta-Description, um eine kleine Beschreibung für die Suchresultate zu generieren, findet Google dort nichts, wird meist eine relevante Stelle aus dem normalen Text gewählt. Wollt Ihr diese Elemente ohne Plugins direkt kontrollieren, könnt Ihr die WordPress Tags und das Feld Auszug (Excerpt) benutzen um diese Daten für jede Unterseite einzutragen und im Quellcode wieder auszugeben:

<?php if(is_home()) : ?>
 <meta name="description" content=" <?php bloginfo( 'description' ); ?> ">
<?php else : ?>
 <meta name="description" content=" <?php the_excerpt_rss(); ?> ">
<?php endif; ?>

<meta name="keywords" content="<?php
$posttags = get_the_tags();
if ($posttags) {
foreach($posttags as $tag) {
echo $tag->name . ' ';
}
}
?>">

Das ist eine der simpelste Möglichkeit, Tags und Description dynamisch im Template auszugeben. Auf der Frontpage wird die Blog Description verwendet und auf den Unterseiten die spezifische Beschreibung aus dem Excerpt-Feld. Dieser Eintrag muss, wie der Title in die header.php in den Head Bereich des Dokuments. Die kurze Beschreibung sollte nicht mehr als etwa 160 Zeichen haben, da sie sonst nichts in das kleine Feld unter den Suchresultaten bei Google passt.

URL-Struktur umschreiben

Die von WordPress erzeugten URLs haben normalerweise diese Form: domain.com/?p=126, können aber mittels mod_rewrite beliebig verändert werden. Dazu geht Ihr, im Admin Menü, auf den Bereich Einstellungen, auf die Seite Permalinks und wählt dort die gewünschte URL-Struktur aus. Ich persönlich wähle meist die möglichst einfachste Form aus, in dem ich im Feld Benutzerdefinierte Struktur nur /%postname%/ eingebe, was eine URLs in dieser Form erzeugt: domain.com/artikelname/.

Damit die Änderungen wirksam werden brauchst du die sogenannte .htaccess Datei, die man in der Regel selbst erstellen und hochladen muss. Du nimmst einen einfachen Text bzw. HTML Editor und erstellst eine leere Datei mit dem Namen .htaccess ohne Dateiendung. Auf der Permalink Seite schlägt WordPress Dir den Code für diese Datei vor, den du einfach in deine leere Datei kopierst, abspeicherst und ins WordPress Hauptverzeichnis hochlädst. Hast du das gemacht, kannst du die Änderungen aus dem Permalink Menü übernehmen und gleich schon betrachten. Links auf alte URLs werden von WordPress automatisch weitergeleitet, es gehen keine Besucher oder Google Pagerank verloren.

Semantisch korrekte Überschriften

Suchmaschinen mögen es wenn die HTML Überschriften sinngemäß verwendet werden. In einer vernünftigen Struktur würde die H1 als Überschrift, ganz oben, für den Blog Namen verwendet werden. Die H2 Als Artikel Überschrift, bei gleichbleibender H1 und die H3-H6 als Unterüberschriften, unter der H2 im Text. Google scheint insbesondere H2 und H3 Überschriften zu verwenden, um den Sinn einer Seite zu verstehen.

Viele Theme Designer benutzen beispielsweise aber auch H3 Überschriften in der Sidebar, in denen dann bloß so etwas wie ‘Kategorien’ oder ‘Die neusten Artikel’ steht, anstatt zum Text relevante Wörter. Daher empfehle ich Überschriften nur im Content zu verwenden. Mit CSS können die Titel in der Sidebar auch ohne HTML H1-H6 Überschriften auf die gleiche Größe gebracht werden:

Kategorien

Auch andere, für den Inhalt des Textes, unrelevante HTML Überschriften, wie beispielsweise ‘Einen Kommantar schreiben’ in der comment.php, sollten mit dieser Methode angepasst werden.

Duplicate Content vermeiden

Duplicate Content bedeutet, das ein Inhalt auf einer Webseite unter verschiedenen URLs erreichbar ist. Wenn man auf der Frontpage beispielsweise, ganze Artikel anzeigt, ohne sie durch den more-tag zu kürzen, ist der Inhalt schon doppelt erreichbar, nämlich auf der Artikel URL selbst und auf der Frontpage. Gleichzeitig aber wahrscheinlich auch in allen angegebenen Kategorien, Tags und entsprechenden Unterseiten.

Wenn Google jetzt Deinen Inhalt, zu einer passenden Suchphrase, anzeigen möchte, muss es sich zwischen einer dieser Unterseiten entscheiden. Oft landet der Google Sucher dann auf einer Tag oder Kategorien Seite, wo der passende Beitrag zwischen 10 oder 20 anderen irgendwo versteckt ist, anstatt auf dem Artikel selbst.

Es hilft seine Blogartikel mit dem more-tag beim schreiben sinngemäß zu kürzen, noch effektiver ist es allerdings den Suchmaschinen gleich zu verbieten Kategorien und Tags überhaupt in den Index mit aufzunehmen. So steht der einzelne Artikel nicht mehr in Konkurrenz zu seinen eigenen Duplikaten. Mittels spezieller Anweisungen für die Suchmaschinen Roboter lässt sich das sehr einfach in ein WordPress Theme integrieren:

<?php if(is_category() || is_search() || is_archive() || is_tag()) : ?>
<meta name="robots" content="noindex, follow">
<?php else : ?>
<meta name="robots" content="index, follow">
<?php endif; ?>

Auch dieser Code wird in den Head Bereich eingetragen. Wenn es sich um eine Kategorie, Suchergebnis, Archiv oder Tag-Seite handelt wird noindex, follow ausgegeben. Das bedeutet diese Seite soll nicht in den Suchmaschinenindex gelangen, dennoch aber angesehen, alle Links verfolgt und Linkstärke weitergegeben werden. Alles andere wird wir immer behandelt index, follow ist quasi die Grundeinstellung.

Onpage und Offpage SEO

Mit diesen simplen Veränderungen ist im Grunde jedes WordPress Theme gut ausgestattet und grundlegend konfiguriert um von Suchmaschinen gut gefunden, verstanden und bewertet zu werden. Komplexere Probleme mit Suchmaschinen tauchen erst auf wenn Webseiten es mit hunderten und tausenden verschiedener Inhalten zu tun haben. Für den normalen WordPress Blog reicht das alles hier aus, um mit jeder anderen Seite in den Google Suchergebnissen konkurrieren zu können.

Alles was man auf der eigenen Seite erledigen kann, wird Onpage SEO genannt. Hat Google es bei einer Suchanfrage mit zwei Seiten zu tun, die im Onpage Bereich gleich gut optimiert worden sind und deren Inhalte vielversprechend ausschauen, gewinnt allerdings die Seite, der Google bereits mehr vertraut, was von der Vernetzung im Web abhängig ist. Diese externen Faktoren zu beeinflussen wir Offpage SEO genannt, ist nicht CMS spezifisch und sprengt hier leider den Rahmen. Grundlegend kann man aber sagen, das Du qualitativ hochwertige Links zu deiner Webseite brauchst, um von den Suchmaschinen ernst genommen zu werden. Und der Schlüssel zu guten Links, ist gute Inhalte zu schreiben.

Normalerweise gibt WordPress für Kategoriearchive automatisch URLs nach dem Muster www.domain.com/category/allgemein aus. Das Wort category ist dabei die sogenannte Kategoriebasis und die will man unter Umständen anders bezeichnen.

Ändern der Kategoriebasis

Das Ändern dieser Kategoriebasis geht ganz einfach mit WordPress Bordmitteln. Dazu geht man in der WordPress Administration einfach unter WP-Admin > Einstellungen > Permalinks und schreibt seine bevorzugte Kategoriebasis in das vorgesehene Feld unterhalb der Permalink-Einstellungen. Schreibt man dort z.B. artikel rein, würden die URLs ab sofort so aussehen: www.domain.com/artikel/allgemein. Natürlich kann man hier jede Bezeichnung verwenden, die einem sinnvoll erscheint.

Gleiches Spiel mit der Tag-Basis

Das Gleiche gilt auch für die Tag-Basis, die normalerweise z.B. so aussieht: www.domain.com/tag/wordpress. Auch das kann beispielsweise in www.domain.com/schlagwort/wordpress geändert werden und ist zumindest bei einer deutsch-sprachigen Seite ggf. sinnvoller.

Vollständiges Entfernen der Kategoriebasis

Leider ist ein vollständiges Entfernen der Kategoriebasis noch nicht möglich. Zwar werden Plugins angeboten, die diesen Job erledigen sollen, aber wirklich problemlos funktioniert das noch nicht. Aus dem Grund stelle ich hier auch keine entsprechenden Plugins vor. Es bleibt zu hoffen, das eine solche Möglichkeit irgend wann mal in WordPress integriert wird.

Relevante Links

• WordPress Codex: Category/Tag Base
• WordPress Codex: Einstellungen > Permalinks

Der Umzug einer kompletten Installation ist dank der Export/Import-Funktion von WordPress und ein paar gezielten Tricks eine Sache von 3 Schritten in wenigen Minuten.

Sprungmarken

• Bestehende Daten exportieren
• Bestehende Daten importieren
• Alte Pfade korrigieren

1. Bestehende Daten exportieren

Um den kompletten Inhalt (Artikel, Seiten, Kommentare, benutzerdefinierte Felder, Kategorien und Schlagwörter) einer bestehenden WordPress-Installation auf einer alten Domain oder einem alten Server zu exportieren, gehen wir im Admin-Bereich im Hauptmenü links zu Werkzeuge > Daten exportieren.

WordPress bietet uns nach dem Klick auf Export-Datei herunterladen eine XML-Datei bspw. mit dem Namen wordpress.2010-04-26.xml zum Download an. Wir speichern diese auf unserem Computer.

2. Bestehende Daten importieren

Im Folgenden gehe ich davon aus, dass eine frische WordPress-Installation auf dem Ziel-Server unter einer neuen Domain verfügbar ist.

WordPress bietet neben der Exportfunktion sinnvollerweise auch eine Importfunktion. Diese macht es denkbar einfach, Artikel aus anderen Blogsystemen oder RSS-Feeds zu importieren. Von WordPress zu WordPress ist selbstredend ebenfalls möglich.

Wir wählen also die Option WordPress und im folgenden Schritt die von unserer alten Installation exportierten XML-Datei auf unserer Festplatte.

Nach dem Klick auf Datei aktualisieren und importieren werden wir auf eine weitere Seite geleitet, auf der wir entscheiden können, ob ein oder mehrere neue User (basierend auf den Benutzern der alten Installation) angelegt oder ob alle Artikel einem oder mehreren Benutzern der neuen Installation zugewiesen werden sollen.

Da es sich in meinem Beispiel um nur einen und denselben Autor handelt, ist es egal, was ich hier auswähle. Ich weise alle Beiträge dem admin der neuen Installation zu.

Ein weiterer und weitaus wichtigerer Punkt ist der Haken bei Dateianhänge herunterladen und importieren. Standardmäßig ist der Haken nicht gesetzt. Er muss für unseren Import in jedem Fall gesetzt werden, damit alle Bilder der alten Installation übernommen werden.

Mit dem Klick auf Senden wird der eigentliche Importvorgang gestartet. Dieser kann je nach Umfang der Daten ein paar Momente dauern.

Nach Beendigung dieses Vorgangs bekommen wir die Erfolgsmeldung Alles fertig!

3. Alte Pfade korrigieren

So gaaaanz fertig sind wir noch nicht. Es müssen noch einige Pfade mit der alten Domain, die in den Artikelinhalten oder benutzerdefinierten Feldern vorkommen, angepasst werden.

Alle Dateien in der Mediathek (Bilder etc.) haben jetzt eine neue Adresse/Pfad. Artikelbilder (WP 2.9 Post-Thumbnail-Funktion) werden automatisch angepasst. Bildern oder Links im Artikel- oder Seiteninhalt (Post-Editor), die in der Datenbank gespeichert sind, müssen jedoch manuell von uns aktualisiert werden.

Um jetzt nicht jeden Artikel einzeln zu öffnen und ihn nach Bildern oder Links im Text durchsuchen zu müssen, bedienen wir uns dem äußerst nützlichen Plugin Search and Replace von Frank Bültge.

Mit diesem Plugin lässt sich eine bestimmte Zeichenfolge in der WordPress-Datenbank durch eine andere ersetzen. In unserem konkreten Fall heißt das, wir ersetzen in allen Datenbanktabellen jedes Vorkommen von http://alte-domain.de mit der Zeichenfolge http://neue-domain.de.

Nun sind alle Inhalte samt Bildern übernommen, Pfade und interne Links in Artikeln und Seiten korregiert. Fertig!

Fazit

Wenn man in diesem Vorgang ein wenig Übung hat, kann man eine komplette Installation in wenigen Minuten von einem Server oder einer Domain auf einen anderen Server oder eine anderen Domain schieben. Einfach!

In der WordPress-Installation verwendete Plugins sollten deaktiviert und ggfs. auf dem neuen Server oder der neuen Domain nochmals installiert werden.

Relevante Links

• WordPress Codex: Export Content
• WordPress Codex: Import Content
• Plugin: Search and Replace von Frank Bültge
• WordPress-Buch: Mit WordPress umziehen

Post Revisions – also die automatische Speicherung mehrerer Versionen eines Beitrags, oder einer Seite – ist eigentlich eine großartige Sache. Leider wird dadurch die Datenbank schnell zugemüllt.

Post Revisions deaktivieren

Wenn man auf Speicherplatz achten muss oder wenn man einfach seine Datenbank entschlacken will, kann man diese Post-Revisions (auf Deutsch übrigens Artikel- oder Seitenüberarbeitungen) sehr einfach deaktivieren. Dazu öffnet man die Konfigurationsdatei von WordPress wp-config.php und fügt folgende Codezeilen ein:

define('WP_POST_REVISIONS', false );
define('AUTOSAVE_INTERVAL', 300 ); // seconds

Dadurch werden alle künftigen Post-Revisions vermieden. Zusätzlich wird das automatische Speichern von 60 Sekunden auf 300 Sekunden verlängert. WordPress speichert nun also nicht mehr jede Minute, sondern nur alle 5 Minuten. Natürlich kann man letzteres auch weglassen.

Datenbank säubern

Nun haben wir die künftigen Post-Revisions deaktiviert, aber diejenigen, die bereits in der Datenbank drin sind, haben wir noch nicht gelöscht. Das machen wir nun als nächstes.

Hierzu müssen wir direkt auf die Datenbank gehen. Am einfachsten geht das mit PHPMyAdmin, einer Benutzeroberfläche, die die meisten Hoster zur Verfügung stellen.

Nun führen wir also folgenden SQL Befehl auf der Datenbank aus:

DELETE FROM wp_posts WHERE post_type = "revision";

Fertig. Nun sind die bereits vorhandenen Post Revisions aus der Datenbank gelöscht und neue werden gar nicht erst angelegt.

Fazit

Post Revisions sind grundsätzlich keine schlechte Sache. Sie können sehr hilfreich sein, wenn mehrere Autoren an einer Seite arbeiten und plötzlich etwas gelöscht wurde, was eigentlich noch gebraucht worden wäre. Aber sie produzieren auch Datenmüll und belasten dadurch die Datenbank. Letztlich muss jeder selbst entscheiden, ob er sie benötigt oder nicht.

Relevante Links

• WordPress Codex: Post-Revisions

Das WordPress-Plugin WP-PageNavi von Lester ‘GaMerZ’ Chan sollte in keinem inhaltsreichen Blog fehlen. Standardmäßig fügt das Plugin einem Theme ein Stylesheet hinzu, dass ich persönlich relativ mau finde. Hier ein paar Tipps dieses abzuschalten und zu verschönern.

Der Standard

Auf vielen Blogs ist es zu bewundern, das Standard-Stylesheet des WP-PageNavi-Plugins in vollendetem Blau-Schwarz, das für viele vielleicht nicht so optimal zum Theme passt. Meine Themes auf ThemeShift.com sind allesamt mit diesem Plugin kompatibel, d. h. das Standard-Stylesheet wird mit einer an das Theme angepassten Formatierung ersetzt.

Aussehen mit Standard-Stylesheet

1. Standard-Stylesheet deaktivieren

Zunächst müssen wir also das Standard-Stylesheet loswerden, dass beim Aktivieren des Plugins dem Head-Bereich des Themes hinzugefügt wird. Wenn im Theme-Ordner kein Stylesheet namens pagenavi-css.css vorhanden ist, wird das gleichnamige Stylesheet aus dem Plugin-Ordner verwendet.

Um dem User nun die Arbeit abzunehmen und später eigene Styles zu verwenden, deaktiviere ich zunächst den Stylesheet-Aufruf von WP-PageNavi, indem ich folgende Zeilen in die functions.php des Themes schreibe:

<?php
    // remove default css for wp-pagenavi
    remove_action('wp_head', 'pagenavi_css');
    remove_action('wp_print_styles', 'pagenavi_stylesheets');
?>

Bemerkung:
Ich verwende hierzu zwei verschiedene Anweisungen, da das Plugin in der Version 2.4 die WordPress-Action add_action('wp_head', 'pagenavi_css') und in der aktuellen Version 2.5 add_action('wp_print_styles', 'pagenavi_stylesheets') verwendet. Um sicher zu gehen, kann ich mit remove_action beide Möglichkeiten deaktivieren.

2. Eigene Styles anlegen

Um das Aussehen der Plugin-Ausgabe dem Theme anzupassen, kann man beispielsweise folgende Styles verwenden:

.wp-pagenavi {
    /* hier die Styles für den Container-div */
}

.wp-pagenavi .pages {
    float: right;
}

.wp-pagenavi a {
    margin: 0 5px 0 0;
    padding: 4px 5px;
    color: #505050;
    text-align: center;
}

.wp-pagenavi .current {
    margin: 0 5px 0 0;
    padding: 4px 8px;
    background: #505050;
    color: #fff;
    text-align: center;
}

Bemerkung:
Das Ergebnis würde in etwa so aussehen, wie die Seitennavigation dieses Blogs – zu sehen auf der Startseite unten oder im Artikelbild dieses Beitrags.

3. Aufruf der Seitennavigation

Standardmäßig ist das Plugin in einem Theme noch nicht installiert. Daher muss zunächst abgefragt werden, ob das Plugin aktiviert ist. Wenn das nicht der Fall ist, wird die Standardnavigation von WordPress (z. B. ältere Posts – neuere Posts) angezeigt.

<?php if(function_exists('wp_pagenavi')) : wp_pagenavi(); else: ?>

    <p style="float:left">
    <?php next_posts_link(__('&amp;laquo; Previous entries','mytheme')); ?>
    </p>
    <p style="float:right">
    <?php previous_posts_link(__('Next entries &amp;raquo;','mytheme')); ?>
    </p>

<?php endif; ?>

4. Anlegen von paging.php

Um die Seitennavigation, die eh in allen Archiv-Templates (index.php, archive.php, author.php & search.php) gleich ist, zentral zu verwalten, empfehle ich im Theme-Ordner eine neue Theme-Datei bspw. mit dem Namen paging.php anzulegen und den Aufruf der Seitennavigation in dieser vorzunehmen.

Diese paging.php kann dann aus jeder Theme-Datei mit folgendem Aufruf angesprochen werden:

<?php include( TEMPLATEPATH . '/paging.php'); ?>

Bemerkung:
Falls die Datei in einem Unterordner des Theme-Ordners angelegt wird, muss der Pfad entsprechend angepasst werden.

5. Container um Seitennavigation

Manchmal ist es notwendig einen weiteren Container um die Seitennavigation zu erstellen, um das HTML-Gerüst weiter zu verschachteln.

Die Navigation (next_posts_link() oder eben wp_pagenavi()) produziert, wenn nur eine Seite vorhanden ist, keinen Output. Ein weiterer Container um die gesamte Navigation würde jedoch im Code enthalten sein.

Um sozusagen zu Fuß vorher abzufragen, ob eine Seitennavigation überhaupt benötigt wird, kann vorher abgefragt werden, ob der aktuelle WordPress-Loop mehr als eine Seite produziert.

<?php global $wp_query; if($wp_query->max_num_pages > 1) : ?>

    <!-- Hier das Paging -->

<?php endif; ?>

Gesamter Code

Der gesamte Code der paging.php mit den Abfragen, ob Navigation nötig und ob das Plugin aktiviert ist, könnte wie folgt aussehen:

<?php global $wp_query; if($wp_query->max_num_pages > 1) : ?>

    <?php if(function_exists('wp_pagenavi')) : wp_pagenavi(); else: ?>

    <p style="float:left">
    <?php next_posts_link(__('&amp;laquo; Previous entries','mytheme')); ?>
    </p>
    <p style="float:right">
    <?php previous_posts_link(__('Next entries &amp;raquo;','mytheme')); ?>
    </p>

    <?php endif; ?>

<?php endif; ?>

Fazit

Diese etwas komplexere Einbindung einer Seitennavigation bietet mir gerade beim Erstellen von WordPress-Themes ein gesundes Maß an Flexibilität, was den Aufbau und die Einbindung in das Theme angeht. Wenn ein Theme-Benutzer nun das Plugin verwenden sollte, braucht er es nur zu installieren und zu aktivieren. Die übrige Arbeit ist bereits getan – ein weiterer kleiner Gewinn an Nutzerfreundlichkeit also.

Relevante Links

• WordPress-Plugin: WP-PageNavi
• WordPress-Codex: add_action()
• WordPress-Codex: remove_action()

Ein neunes hochinteressantes Plugin hat sich vor einiger Zeit aufgetan – Antispam Bee: Das WordPress-Plugin für den Schutz gegen Spam. Den Angaben des Plugin-Autors Sergej Müller zufolge kommt es mit sehr wenig Code aus, ist jedoch, das kann ich bestätigen, sehr wirksam im Schutz gegen Spam.

Einsatz von Askimet in Deutschland problematisch

Vor gut ein, zwei Wochen gab es zahlreiche Hinweise, dass die Nutzung des mit WordPress ausgelieferten Antispam-Plugin Askimet in Deutschland rechtlich problematisch ist. Außerdem ist es zumindest bei mir ab und zu vorgekommen, dass auch Kommentare, die absolut in Ordnung waren, von Askimet als Spam markiert wurden. Und Lust und Zeit, täglich 5 Seiten Spam durchzuchecken, habe ich keine.

Die Alternative Antispam Bee

Ein absolut empfehlenswerte Alternative ist das Antispam-Plugin Antispam Bee von Sergej Müller. Großer Vorteil dieses Plugins ist, dass Antispam Bee keine Daten zu irgendwelchen Servern sendet, sondern unabhängig arbeitet.

Antispam Bee kann Spam markieren oder gleich löschen

Fazit:

Ich selbst habe das Plugin jetzt seit gut 2 Wochen im Einsatz. Es ist tatsächlich sehr zuverlässig und markierte bisher keinen Kommentar fälschlicherweise als Spam.

Anderherum kamen noch einige Spam-Kommentare in die Moderationsschleife. Das beschränkt sich jedoch auf 4 – 5 Kommentare in den 2 Wochen. Das ist mir wesentlich lieber als Kommentare meiner User zu verlieren. Ich bin mit dem Plugin sehr zufrieden!

edit:
Dass zum Teil noch Kommentare in der Warteschleife landen, “liegt daran, dass WordPress-interne Regeln zuvor greifen” (s. Kommentar).

Relevante Links:

• Release-Post Antispam Bee
• Plugin-Autor Sergej Müller
• Weblog Sergej Müller

Suchmaschinenoptimierung (SEO) sollte für jeden, der seinen WordPress-Blog der breiten Öffentlichkeit vorstellen möchte, ein zentrales Thema sein. Mit dem WordPress-Plugin wpSEO kann man ohne jegliche Fachkenntnisse hervorragende Ergebnisse bei Google & Co. erzielen.

Vernünftige Suchmaschinenoptmierung einer Website sollte immer aus einem Mix an Maßnahmen bestehen. So ist z. B. die Generierung der Meta-Tags und des Titels einer jeden Seite eine sehr wichtige dieser Maßnahmen.

Die leichteste und, meiner Meinung nach, lückenloseste Methode, einen WordPress-Blog zu optmieren, ist wpSEO von Sergej Müller. Dieses Plugin erledigt zuverlässig jene Maßnahmen, die dynamisch (maschinell) durchgeführt werden können:

• Seitentitel formatieren
• Meta-Description anpassen
• Meta-Keywords generieren
• Duplicate Content vermeiden
• AdSense-Markierung
• u.v.m.

einfach zu bedienende wpSEO Optionen

Eine große Stärke dieses Plugins ist die Einfachheit, mit der es zu bedienen ist. D. h. bei wpSEO aber nicht, dass es dadurch weniger komplex ist. Laien, die von der Programmierung für Suchmaschinen wenig Kenntnisse haben, können somit ihren Blog absolut professionell optimieren. Die Ergebnisse in den Suchmaschinen werden dies zeigen.

XML-Datei mit empfohlenen Optionen

Um den starken Service, den uns Sergej Müller mit diesem Plugin bereitstellt, zu komplettieren, kann man sich die empfohlenen Einstellungen der Optionen, mit denen man auf jeden Fall auf der sicheren SEO-Seite ist, in Form einer XML-Datei hochladen.

Fazit:

Bin wahrhaftig begeistert! Einfacher und lückenloser kann man einen Blog nicht optmieren.

Relevante Links:

• WordPress-Plugin wpSEO
• Plugin-Autor Sergej Müller
• Weblog Sergej Müller

Je mehr WordPress in den Focus der weltweiten Blog-Gemeinde rückt und im Einsatz ist, desto mehr wird es natürlich auch Angriffziel für Hacker. Eine mögliche Schwachstelle ist das Directory-Listing, das einem Hacker über den Browser Einblick in Dateien einer WordPress-Installation geben kann. Das zu unterbinden ist einfach.

Ist Directory Listing bei Dir möglich?

Bei vielen Internet-Providern ist das Directory-Listing bereits unterbunden, jedoch beileibe nicht bei allen. Um zu testen, ob es bei Dir möglich ist, gib beispielsweise folgendes in die Adresszeile des Browsers ein.

http://deine-url.de/wp-content/plugins

Ansicht Directory-Listing

Solltest Du dann eine Auflistung Deiner verwendeten Plugins sehen, würde ich weiterlesen.

Wo ist die Gefahr?

Wenn sich wie in der Abbildung oben auf so einfache Weise einen genauen Überblick über Dateien und in diesem Fall Plugins verschaffen kann, sind gezielte Angriffe auf mögliche Sicherheitslücken in Plugins möglich.

Und davon mal abgesehen hast Du vielleicht auch Dateien auf Deinem Server, die nicht die ganze Welt etwas angehen. Mit dem Directory-Listing kann man mit dem Browser gemütlich durch Deine Dateien stöbern. Schon gewusst?

Wie kann ich das unterbinden?

Die Auflistung von Dateien durch den Browser kann man ganz einfach mit ein paar Zeilen in der .htaccess unterbinden. Öffne dazu die .htaccess in Deinem Root-Verzeichnis und füge folgende Zeilen hinzu:

# Prevents directory listing
Options -Indexes

Unser aller Freund – der Hacker – bekommt dann folgendes Bild geboten.

Directory-Listing unterbunden

Fazit:

Du siehst, mit ein paar einfachen Schritten ist eine große mögliche Sicherheitslücke einer WordPress-Installation geschlossen. Es bedarf keiner fortgeschrittenen Kenntnisse, seine WordPress-Installation Schritt für Schritt sicherer zu machen.

Relevante Links:

• WordPress Security-Tipps

Weil ich für ein Kundenprojekt ein Kontaktformular brauchte und auch auf webdemar.com eines einbinden möchte, habe ich mich seit langem mal wieder auf die Suche nach einem guten Plugin dafür begeben. Mit dem Contact Form 7 bin ich fündig geworden und möchte es Euch hiermit empfehlen.

Bisher habe ich für Kontaktformulare in WordPress-Installationen immer den Dagon Design Form Mailer verwendet. Irgendwie hatte ich aber mal Lust, was Neues auszuprobieren und wollte auch eine Ajax-Lösung, die das Formular ohne Neuladen der Seite verschickt und eine Versandbestätigung oder eben eine Fehlermeldung ausgibt.

Das WordPress Plugin Contact Form 7 ist dafür die ideale Lösung. Es erfüllt alle oben genannten Anforderungen und macht insgesamt einen sehr robusten Eindruck.

Ein weiterer Grund, warum ich mich für dieses Plugin entschieden habe, ist die super-einfache Bedienung, die jedoch der Flexibilität und umfangreichen Möglichkeiten der Anpassung keinen Abbruch tut.

HTML-Editor Contact Form 7

Durch einen eigenen HTML-Editor kann man die Konfiguration ganz einfach mithilfe eines Tag-Generators für die verschiedenen Arten der Form-Elemente vornehmen. Folgende Elemente mit den entsprechenden Attributen kann man sich mit dem Generator erstellen und in den Editor kopieren:

• Text-Feld
• E-Mail-Feld
• Textarea
• Dropdown
• Checkboxes
• Radiobuttons
• Acceptance (z. B. für AGB)
• CAPTCHA
• File-Upload
• Submit-Button

Verwaltung der Bestätigungen und Fehlermeldungen

Auch die Bestätigungsnachrichten und Fehlermeldungen kann man bequem auf dieser Seite verwalten und anpassen.

Fazit:

Alles in Allem hat mich dieses Plugin wirklich in seiner wirklich einfach zu bedienenden Komplexität stark beeindruckt und kann es nur jedem empfehlen. Contact Form 7 wurde außerdem in zahlreiche Sprachen (u.a. Deutsch) übersetzt und benötigt kaum arbeitsaufwenige Anpassungen. Lediglich die CSS-Styles sollte man dem eigenen WordPress Theme anpassen.

Relevante Links:

• Plugin Directory Contact Form 7