Die Sache mit der Suchmaschinenoptimierung

Die Nutzung von SEO-Plugins ist für viele (semi-)­professionelle Bloggerinnen und Blogger ein absolutes Muss. Doch was tun, wenn man zu einem Wechsel des Plugins gezwungen ist?

Wenn man mich in den vergangenen Jahren gefragt hat, welches SEO-Plugin ich für WordPress empfehlen könne, war meine Antwort immer klar: „wpSEO“. Im Vergleich zu vielen Mitbewerbern verfügte wpSEO über ein sauberes und klar strukturiertes Interface, eine nerd-kompatible Dokumentation und den besten (deutschsprachigen) Support, den ich mir überhaupt vorstellen konnte.

Seit Sergej im Juni 2015 seinen Rückzug aus der WordPress-Community angekündigt hat, habe ich das Schicksal von wpSEO stets als ungewiss wahrgenommen. Zunächst fand sich kein geeigneter Käufer für das Projekt, dann kam doch der Verkauf, gefolgt vom Launch eines wpSEO-Blogs und seit November ’15 einer Reihe von Updates, die für meinen Geschmack in die falsche Richtung gehen.

Feed-Tracking mit FeedPress

Ähnlich wie der inzwischen von Google aufgekaufte Dienst Feedburner ermöglicht FeedPress das Tracken von Zugriffen und Klicks auf Beiträge in einem RSS-Feed.

Als wir mit dem PressWerk Podcast im letzten Jahr in den DEWP Planet-Feed gekommen sind, war ich besonders neugierig, wie sich das auf unsere Besucherzahlen auswirken würde. Als alter Daten-Nerd war mir ein Vorher-/Nachher-Unterschied der Zugriffe nicht genug. Ich habe mich auf die Suche nach einer Tracking-Lösung gemacht.

Das Problem mit Feedburner

Der 2004 gegründete Feed-Analyse und -Tracking Dienst Feedburner stirbt seit dem Kauf durch Google 2007 einen langsamen aber sicheren Tod. Google hat im Laufe der Zeit APIs abgeschaltet und Funktionen eingestellt.

Ein weiteres Schloss an der Tür

Mit 2-Faktor-Authentifizierung werden dieser Tage viele online Services abgesichert. Selbstverständlich gibt es auch für WordPress Lösungen in den verschiedensten Geschmacksrichtungen.

Die Idee, bei Anmeldung neben einem Passwort noch eine zweite Bestätigung in Form eines Codes zu verlangen, ist nicht neu. Weil dann für einen Angriff nicht nur ein Passwort erraten, sondern auch etwas physisches (TAN-Liste, Code-Generator, Mobiltelefon) in Besitz gebracht werden muss, erhöht eine richtig implementierte 2-Faktor-Authentifizierung den Schutz – zum Beispiel – des WordPress-Backends erheblich.

Die Qual der Wahl

Seit 2013 fasziniert mich die Idee, meine WordPress-Instanzen mit einem zweiten Faktor zusätzlich zu schützen. Anfänglich war das Angebot an Plugins auf WordPress.org überschaubar (und wenig berauschend).

Mit dem Auftauchen kommerzieller Anbieter wie Duo oder Clef kam etwas Bewegung in die Szene. Für mich persönlich war es aber keine Option, meinen WordPress-Login an einen Drittanbieter zu koppeln, von dessen Infrastruktur am Ende im Zweifelsfall abhängt, ob meine Nutzer sich anmelden können oder nicht.

Fehlermeldung bei Datenbankfehlern anpassen

Wenn eine WordPress-Installation ein Problem in der Kommunikation mit der Datenbank feststellt, wird eine Fehlerseite angezeigt. Diese Fehlerseite kann angepasst und erweitert werden.

Die Fehlerseite, die WordPress bei Problemen mit der Datenbank ausgibt, gewinnt beim besten Willen keinen Schönheitswettbewerb. Doch seit WordPress 2.3 (2007) lässt sich diese einfache Fehlermeldung mit einer anderen, angepassten oder hübscheren eigenen Version überschreiben. Dafür muss lediglich eine db-error.php-Datei im Verzeichnis /wp-content/ abgelegt werden.

Browserfenster mit Text: Error establishing a database connection
Out of the box wird bei einem Datenbankproblem einfach ein wenig Text auf weißem Grund ausgegeben.

Glänzende Aussichten

Manchmal sind es die Kleinigkeiten, die uns Freude bereiten. Dinge, die einfach funktionieren. Manche Details können schon einfach schön sein, weil sie nicht stören. Vielleicht ist dies das ganze Geheimnis hinter guter User Experience: Stör mich nicht.

Wie viel im WordPress Backend schon erreicht wurde, fällt erst dann auf, wenn man einmal ein paar Versionen zurückblättert und sich durch das Backend klickt.

screenshot-1

Do you speak WordPress?

Am 24. April 2016 fand der erste Global WordPress Translation Day statt. Der Tag war ein großer Erfolg, aber nicht jeder konnte dabei sein. Daher hier nochmal ein kleiner Überblick, wie die WP Übersetzung eigentlich funktioniert.

Ham ist Schinken und Jam ist Marmelade. Unsere Tochter besucht die vierte Klasse der hiesigen Grundschule und lernt gerade ihre ersten Englisch-Vokabeln. Für die Frühstücksbestellung im Hotel wird es demnächst sicher reichen, aber Begriffe wie posts und pages, comments, custom fields, terms, navigation menus, und custom posts types sind dann doch eher technisches Vokabular, das es gerade Einsteigern zusätzlich erschwert, eine Webanwendung wie WordPress kennen zu lernen. Manche Plugins erschließen sich selbst dann nicht auf Anhieb, wenn sie bereits übersetzt sind. Ohne Übersetzung? Da ist die Sprachbarriere für viele Benutzer garantiert zu hoch.

Das Child-Theme Dilemma

Child-Themes sollen das Aktualisieren des Eltern-Themes möglichst einfach machen. Doch was, wenn Template-Dateien im Eltern-Theme so großen Änderungen unterworfen sind, dass davon ein Child-Theme betroffen ist? Mit einem einfachen Versionsheader kann man dies zumindest kenntlich machen.

Immer wieder wird darauf hingewiesen, dass man, wenn man ein Theme abändern möchte, ein Child-Theme erstellen soll. So wichtig dieser Hinweis ist, wird doch meistens unterschlagen, dass die Child-Theme Technik auf der einen Seite zwar ein Problem löst, auf der anderen dafür aber ein ganz neues aufwirft. Wozu verwenden wir Child-Themes?

Nehmen wir Änderungen direkt an einem Theme vor und wird das Theme vom ursprünglichen Themenautoren aktualisiert, so werden unsere Änderungen mit dem Update des Themes überschrieben und gehen verloren. Erstellen wir hingegen ein Child-Theme, so können wir in diesem unsere Änderungen vornehmen, ohne ihren Verlust durch ein Update fürchten zu müssen. Das Konzept ist dabei sehr schlank und elegant umgesetzt. Mit nur zwei kleinen Dateien ist das Child-Theme bereit. Man kopiert sich schlicht die zu ändernden Template-Dateien vom Parent-Theme in das Child-Theme und kann diese dort gefahrlos abändern. Gefahrlos? Nicht ganz. Was passiert zum Beispiel, wenn das Update des Eltern-Themes dergestalt ist, dass es gewisse Abhängigkeiten, in denen das Child-Theme steht, zerstören? Über dieses Child-Theme Dilemma wird eher selten gesprochen.