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.

Keine Panik

In der britischen Sitcom The IT Crowd beantwortet der erfahrene Servicemitarbeiter Roy alle (wirklich alle) Anfragen zu IT-Problemen mit der Gegenfrage „Have you tried turning it off and on again?“ („hast du versucht, es aus- und wieder einzuschalten?“). Bei Fragen zu WordPress kommt man damit alleine zwar selten weiter, aber tatsächlich lassen sich die meisten Probleme schon mit wenigen Handgriffen beheben.

Schnappatmung: Der White Screen of Death

Häufiger berichten Anwender, dass ihre Website nur noch eine völlig leere, weiße Seite anzeigt – und zwar sowohl im Front- als auch Back End! Dieser Umstand wird auch gerne scherzhaft als „Weißer Bildschirm des Todes“ bezeichnet, weil schließlich gar nichts mehr funktioniert. Was für Anwender nach einer mittleren Katastrophe aussieht („sind jetzt etwa meine ganzen Daten weg?“), ist in den meisten Fällen aber recht einfach zu reparieren.

Neu hier? Wir auch!

Seit Januar 2016 haben wir hier im Verborgenen an Konzepten gefeilt, Designs zurecht gebogen und inhaltliche Feinheiten ausgebügelt. Das Ergebnis: KrautPress - ein deutschsprachiges WordPress Magazin aus und für die Community.

 

Auf KrautPress.de steht eines ganz klar im Zentrum: Themen. Das schlägt sich zum einen in diesem wunderbar schnörkellosen Design nieder, in dem keine nervige Sidebar, keine sinnlosen Stock-Images und keine Inline-Werbung Aufmerksamkeit vom Inhalt ziehen. Zum Anderen sind alle Inhalte stark AutorInnen  getrieben. Jede Autorin und jeder Autor bringt eine ganz eigene Expertise und Sichtweise ein und trägt zu einem möglichst diversen Abbild der gesamten Szene bei.

Mit dem Anspruch inhaltlich hochwertige Beiträge zu veröffentlichen und dabei nicht nur alte Community-Hasen anzusprechen steht KrautPress in Tradition von WP LETTER und PressWerk. Daher haben wir in den letzten Wochen insgeheim gearbeitet um heute mit einigen ersten Artikeln an den Start gehen zu können.

In den nächsten Tagen werden wir auch von einigen neuen Köpfen Beiträge aus den verschiedensten Facetten des WordPress-Universums lesen dürfen. Neben fortgeschrittenen Tutorials,  WordPress Grundlagen und WordCamp-Berichterstattung soll aber auch der gelegentliche Blick über den Tellerrand nicht ausbleiben.

Im Namen aller vor und hinter den Kulissen Beteiligten wünsche ich nun viel Spaß beim Stöbern, Lesen und Weitersagen.

Aufbruch

Vom ersten WordCamp Europe in Holland über das erste offizielle deutsche WordCamp bis hin zum ersten WordCamp in Italien – jedes WordCamp war ein wichtiger Meilenstein und hat neue Horizonte eröffnet.

Leiden, Oktober 2013

Mein erstes, richtiges WordCamp? Das war das WordCamp Europe im Oktober 2013 in Leiden, Niederlande. Alle waren sie da – die ganz Großen der WordPress Community: Matt Mullenweg, Samuel „Otto“ Wood, Joost de Valk (Yoast), Andrew Nacin, Brad Williams, … Vor allem aber standen sie nicht unnahbar auf großer Bühne, sondern beantworteten in persönlichen Gesprächen bereitwillig selbst Einsteigern wie mir alle möglichen und unmöglichen Fragen.

Hier traf ich auch zum ersten Mal Caspar Hübinger, Co-Initiator des WordPress Meetup Potsdam, Organisator des deutschen WP Camp (einer zumindest an WordCamps angelehnten Veranstaltung) und nun Co-Organisator des WordCamp Europe.

Sechs Monate später, unmittelbar vor dem ersten offiziellen WordCamp in Deutschland, stellte Caspar der deutschen WordPress-Community in einem Brandbrief berechtigte Fragen.

Bist du irgendwo? Gibt es dich? Noch, oder wieder? Wer bist du, und wenn ja, wie viele? Caspar Hübinger, Juni 2014

Die deutsche WordPress-Community? Nicht existent. Weder auf Google, noch in Form internationaler Beteiligung am gemeinsamen Projekt WordPress. Nicht auf dem WordCamp Europe und auch nicht in den Köpfen der Anwender, die WordPress täglich benutzten.