Archiv der Kategorie: Allgemein

Mea culpa: warum dieser Blog alles andere als barrierefrei ist

Barrierefreiheit im Internet ist ein Thema, das mich in letzter Zeit sehr viel beschäftigt hat. Ich bin durch die Initiative „Bayern barrierefrei“ des Freistaats auf das Thema aufmerksam geworden, und halte es für immens wichtig. Auch Menschen mit Handicap haben ein Grundrecht auf Informationsfreiheit! Da ist Umdenken nötig, denn die meisten Webdesigner vergessen vor lauter SEO-Zirkus und Multimedia-Geblinker, daß es auch Benutzer gibt, die z.B. auf einen Screenreader oder eine Braillezeile angeweisen sind.

Mein Pilotprojekt

Ich habe in den letzten Monaten als Pilotprojekt mein Inselfisch-Kochbuch barrierearm gestaltet, und ich kann ihnen sagen: es war eine Heidenarbeit! Wenn ich dabei nicht so tatkräftige Unterstützung von der Stiftung Pfennigparade bekommen hätte, ich hätt’s aufgeben müssen. Dabei ist das mit der Barrierefreiheit, genauer gesagt: mit der Barrierearmut  eigentlich gar nicht so schwer zu realisieren, es gibt einige nicht schwer zu begreifende Grundregeln. Wenn man die von Anfang an beachtet und z.B. seine Beiträge vernünftig durchformatiert und anständig gliedert, und auf aussagekräftige Alt-Texte bei den Bildern achtet, ist schon viel gewonnen. Wenn man das  im Nachhinein korrigieren will, dann artet es in Arbeit aus. Ich habe über 200 Rezepte und -zig Bilder manuell durchgeforstet und überarbeitet. Es gibt  leider keine Plugins, die einem die logische Gliederung von Texten abnehmen könnten, und wird sie wohl auch nie geben, da muß man schon selber ran. Ich versuche mir jetzt anzugewöhnen, von Anfang an strukturiert zu schreiben, weil ich die Ochsentour mit der manuellen Überarbeitung nicht nochmal durchziehen möchte, einmal hat gereicht.

Böse Sünde: Codeschnipsel als Screenshots

Das geht natürlich im Sinne der Barrierefreiheit überhaupt nicht. Screenshots sind ja auch nur Bilder, wenn da was zu Lesen steht, damit kann kein Screenreader etwas anfangen! Ich habe  in diesem Artikel schon mal kurz darüber gemault, daß es einem WordPress so gnadenlos schwer macht, Programmcode vernünftig in einem Artikel darzustellen. Ich habe jetzt die Screenshots als Notlösung genommen, bin aber noch auf der Suche nach einer besseren Lösung. Vielleicht wäre es hilfreich, den relevanten Programmcode zu einem Artikel als Textdatei mit dranzuhängen, das wär schon mal besser als nix. Ich denke da an die vielen IT-Bücher, wo man die Codebeispiele  als CD mitgeliefert bekommt… mhm, könnte gehen, wenn ich es mir recht überlege. Ich werde mal mit meinem Kontakt bei der Stiftung Pfennigparade darüber sprechen, da muß es einen vernünftigen Kompromiss geben, so daß ich ungehindert flüssig schreiben kann und trotzdem eine nach Möglichkeit barrierearme Seite dabei herauskommt.

Nachtrag:  Habe nachgeforscht, leider scheint es wirklich keine andere Möglichkeit zu geben, als den visuellen Editor NICHT zu benutzen. Keine schöne Lösung… na ja, vielleicht finde ich noch ein Plugin, das den Programmcode nicht verhackstückt. Die Hoffnung stirbt zuletzt 😉

Und was hat das alles mit WordPress zu tun?

Mehr als sie denken. Letztendlich ist ja WordPress unser Werkzeug der Wahl zum Erstellen von Webseiten, und dazu gehört ein bißchen mehr als nur schicke Layouts und tolle Animationseffekte. Ausserdem verführt WordPress beim Hochladen von Bildern zur Schlamperei bei der Beschriftung. Von älteren Webdesignern (z.B. der gute alte NVU) wurde man noch gezwungen, beim Bilder einfügen zumindest einen Alt-Text einzugeben. Bei WordPress kann man da locker drüberklicken, die meisten Leute tun es auch weil ihnen nicht klar ist was ein „Alternativtext“ ist und wozu der gut sein soll.

Jetzt noch die gute Nachricht: es ist gar nicht so schwer, mit WordPress barrierearme Webseiten zu gestalten, wenn man es von Anfang an richtig macht. Die meisten modernen Themes sind gut strukturiert und mit <h1>, <h2>, <li> usw. sauber durchgegliedert, und sie sind auch mit der Tastatur bedienbar. Es gibt sogar spezielle Themes, die von Anfang an auf Barrierefreiheit zugeschnitten sind, aber da muß ich noch ein bißchen forschen, dann erzähle ich mehr darüber, ein andermal. Es wird wieder Zeit für ein bißchen Spaß auf der Datenbank!

 

 

 

Kleiner Exkurs über Attachments

Was genau ist ein Attachment?

Wie ich schon mal kurz angesprochen habe, werden in der Tabelle wp_posts nicht nur die Beiträge und Seiten verwaltet, sondern auch noch andere Objekte, zum Beispiel hochgeladene Bilder. Das ist aber noch lange nicht alles, man kann ja auch ZIP-Dateien hochladen, oder PDFs, oder Word-Dokumente oder oder oder…. Alle diese Dateitypen werden unter dem Begriff „Attachments“ zusammengefaßt, zu deutsch „Anhänge“. Eine komplette Liste der gestatteten Dateitypen gibt natürlich der Codex her, das kann man sich hier in diesem Artikel genauer zu Gemüte führen. Die genaue Spezifikation der hochgeladenen Dateien steckt in der wp_posts im Feld post_mime_type. Was ein MIME Type oder auch Internet Media Type genau ist, kann man hier bei Wiki sehr schön nachlesen. Ich sag mal sehr vereinfachend: MIME Types sind die Dateitypen, die im Internet hin und hergeschickt werden können, und von denen ihr Browser und ihr E-Mail-Programm wissen, was sie damit anfangen sollen.

Die gängigsten Bild-Typen

Uns reicht mal fürs erste, die in WordPress gängigsten MIME Types anzuschauen, und das dürften mit großem Abstand vor allen anderen JPEG-Bilder sein, in den allermeisten Fällen Fotos aus der Digicam. Eher seltener kommen noch PNG-Dateien vor, und ganz vereinzelt schwirren auch noch ein paar animierte GIFs durch die Gegend. Im Feld post_mime-type steht bei Bildern immer ein image/xyz, wobei xyz der Bildtyp ist. Bei unseren JPEGs heißt es dann ganz logisch image/jpeg. Wir können also anhand des Post Types „attachment“ und anhand des MIME Types „image/jpeg“ gezielt alle JPEG-Bilder in unserem kleinen PHP Skript herausfischen, und das werden wir jetzt auch machen. Falls sie auch noch andere Bildtypen hochgeladen haben sollten, fischen sie mit „image%“, dann haben sie alle Bilder, nicht nur die JPEGs. Wir können uns natürlich auch alle vorhandenen Bilder in der Mediathek anschauen, aber wo bleibt da der sportliche Ehrgeiz? 🙂 Aber das hat jetzt mit Attachments im Allgemeinen nicht mehr viel zu tun, deswegen gibts dafür einen neuen Beitrag. Aber erst muß ich noch was loswerden, deswegen gibt es jetzt noch einen Exkurs im Exkurs:

Über Bildformate

Ich meine jetzt nicht Dateiformate, sondern physikalische Formate, die man normalerweise in cm x cm mißt. Bei Fotos sind das schlicht Hoch- und Querformate, je nachdem wie herum sie die Kamera beim Knipsen gehalten haben. Bei gemalten Bildern kommt es noch viel entscheidender auf das Format der Leinwand oder des Blocks an, ich kenn mich da aus, ich bin Malerin. Das gewählte Format bestimmt die Bildkomposition, und niemand käme auf die Idee, ein hoch- oder querformatiges Gemälde quadratisch zuzuschneiden, nur damit es in einen quadratischen Rahmen paßt. WordPress ist da nicht so pingelig. Ich hab erst gedacht, das mit den Gallerys wäre eine tolle Sache für die Bildpräsentation auf meinen Malerei-Seiten, aber Pfiffkas! Die Bilder werden gnadenlos zu kleinen Quadraten verstümmelt, mit eher zufälligen Bildausschnitten. Das ist auch in der Mediathek etwas was mich sehr stört. Ich zeig ihnen mal was ich meine. In einer Gallery oder eben in der Mediathek sieht mein kleines Bild vom  Drachenmädchen Nellie mit der Erdbeertorte so aus:

beeren-sahne-torte-150x150

beeren-sahne-torte-150×150

Da fehlt der ganze Witz an der Sache! Hier zum Vergleich das unbeschnittene Bild:

beeren-sahne-torte

beeren-sahne-torte

Verstehen sie jetzt, was ich meine und warum ich ungehalten bin? Logisch lassen sich Quadrate bei einer HTML-Ausgabe viel einfacher anordnen als gemischte hoch- und querformatige Bilder, aber für meine Aquarelle war das echt der optische Tod, dafür sind die Gallerys völlig unbrauchbar. Für Fotos finde ich die Zwangsquadratur auch nicht optimal, da könnte sich mal jemand etwas besseres einfallen lassen. So, das mußte ich mal loswerden. Später gehts weiter mit ein bißchen Spaß auf der Datenbank!

 

 

 

Beitragsbild oder Bild zum Beitrag?

Bilder sind die Seele eines echten Blogs!

Wir lieben Bilder, je mehr je schöner, sie geben unseren Seiten Leben und den persönlichen Touch. Jetzt wärs halt schön, wenn wir zu unserer selbst erstellten Beitragsliste auch Bilder mit drin hätten! Aber da ist Lady WordPress ein bißchen zickig und macht es uns nicht ganz so leicht.

Was genau sind Beitragsbilder?

Es gibt Bilder, die in einen Beitrag ganz normal eingefügt werden, und es gibt sogenannte „Featured Images“, die bei der Erstellung eines neuen Beitrags angegeben werden können. Es herrscht ehrlich gesagt seit der Einführung der Beitragsbilder oder „Featured Images“ oder auch „Thumbnails“ in WordPress eine leicht babylonische Begriffsverwirrung, was denn nun was ist. Geht schon mal damit los, daß es gar nicht gesagt ist daß ihr Theme Beitragsbilder auch unterstützt, ältere Themes tun das nämlich durchaus nicht immer.  Aber da haben sich schon andere Leute Gedanken darüber gemacht, ich schicke sie mal wieder zu den kompetenten Kollegen vom Elbnetz zum Beitrag:
Wie man Beitragsbider in WordPress richtig nutzt

Da steht echt alles drin, was sie wissen müssen. Und wenn sie den Unterschied zwischen Beitragsbildern und „gewöhnlichen“ zu Beiträgen hochgeladenen Bildern halbwegs verstanden haben, gehts weiter.

Damit wir das jetzt auch programmiertechnisch nutzen können, legen sie bitte zu zumindest zu einigen ihrer Blogbeiträge Beitragsbilder an, wenigstens ein Handvoll, damit wir was zum Ausgeben haben. Dieses Feature versteckt sich ein bißchen im Beitragseditor, ganz nach unten scrollen und rechts gucken. Da gibt es die Option „Beitragsbild festlegen“. Bild auswählen, hochladen und gut ists. Das machen sie jetzt ein paar Mal, und im nächsten Beitrag gibt es dann eine Ausgabe mit Bildern, versprochen! 🙂

Anmerkung:

Das in dem Elbnetz-Beitrag erwähnte Plugin „Autoset Featured Image“ ist leider erstens seit 2 Jahren nicht upgedated worden und zieht zweitens leider nur bei der Erstellung neuer Beiträge, kein Autoset für bereits veröffentlichte Beiträge! Also ist Handarbeit angesagt. Wenn jemand eine schlauere Lösung hat, bitte her damit!

HTML Tabelle mit Tablesorter reloaded

Ich gelobte Besserung. Ich schieb hier nochmal nach, wie unsere HTML-Tabelle aussehen muß, nämlich mit thead und tbody Tags, damit sie vom Table Sorter Plugin auch sortiert wird.

alle_posts_mit_perm_und_tablesorter

alle_posts_mit_perm_und_tablesorter

Das ist jetzt mal ein Screenshot aus dem Notepad++, meinem Lieblings-Editor für alle Zwecke. Ich denke, man kanns lesen… und da seh ich prompt schon einen Fehler, bei dem schließenden thead Tag fehlt der / (Schrägstrich). Tablesorter hats trotzdem gesorted, ich lass das jetzt mal so stehen.

Der Knackpunkt ist hier wie gesagt die Zuweisung:

echo „<table id=’meineTabelle‘ class=’tablesorter‘>“;

Damit weiß der Tablesorter, daß jetzt Action angesagt ist, und er auf diese Tabelle losgehen soll. Mehr ist nicht dabei. Wie schon gesagt, der Tablesorter bietet noch wesentlich mehr Möglichkeiten, aber da darf sich jeder selber einlesen, Doku gibts bei Tante Google.

 

 

 

Mehr Codeschnipsel?

Ich bin von meinen wohlmeinenden Erstkritikerin gefragt worden, ob ich nicht mehr Codebeispiele bringen könnte, das wäre für das allgemeine Verständnis förderlich. Da bin ich wohl wieder mal zu hastig gewesen und habe zuviel Grundwissen vorausgesetzt. Ich gelobe Besserung, und werde meine Programmschnipsel in Zukunft ausführlicher gestalten.

Aaaber…Der visuelle Editor von WordPress treibt jeden Programmierer in den schreienden Wahnsinn. Er verhackstückt jeden Code und schiebt gnadenlos Formatierungen und Zeilenumrüche rein wo man sie am wenigsten brauchen kann. Trotz Hilfsmitteln wie dem SyntaxHighlighter ist es ein eher zufälliges Spiel, ob der Code lesbar dargestellt wird oder nicht. Als Abhilfe wird einem allen Ernstes geraten, den visuellen Editor NICHT zu benutzen, und das kanns dann ja auch nicht gewesen sein. Bis mir da eine praktikablere Lösung begegnet, wirds Codeschnipsel in Zukunft als Screenshots geben, punktum. Dann kann man sie halt nicht rauskopieren, aber ich verspreche, meine Codeschnipsel werden auch in Zukunft so überschaubar bleiben, daß man sie auch mal kurz abtippen kann. Kompromiß, OK? 😉

Warum wir jetzt ein Child-Theme brauchen

Weil wir unsere Datenbankausgabe ein wenig moderner stylen möchten und dafür etwas in die style.css eintragen müssen.

Sie können das auf ihrer Testumgebung auf eigene Gefahr in der Original-style.css in ihrem Theme-Verzeichnis machen, aber ich rate ihnen ernsthaft: gewöhnen sie sich das gar nicht erst an. Zu schnell hat man mal Mist gebaut, passieren Copy&Paste Fehler, hat man versehentlich etwas gelöscht und so weiter und so fort – nee, wir lassen die Originaldatei schön da wo sie ist, basteln uns ein Child Theme und können da in unserer eigenen style.css herumfuhrwerken so lange wir lustig sind.

Was ist überhaupt ein Child-Theme?

Darüber könnte man Bände schreiben, und das haben andere Leute (fragen sie Tante Google) auch schon getan, ich machs aber hier mal so kurz wie möglich. Ein Child Theme ist eine Kopie ihres Originalthemes, liegt bei den Themes in einem eigenen Unterverzeichnis und hat mindestens eine eigene style.css und eine eigene functions.php. Wenn jetzt beim Bearbeiten einer dieser Dateien irgendwas schiefgeht, und im Worst Case ihr WordPress nicht mehr richtig funktioniert, können sie jederzeit zurückswitchen zum Parent (Original-) Theme, den Child Theme Ordner plattmachen und neu anlegen. Dann sind schlimmstenfalls ein paar Zeilen Code verloren, aber ihr Blog läuft wieder normal.

Wie legt man ein Child-Theme richtig an?

Fragen sie auch hier Tante Google, da kommen -zig Einträge. Ich finde diesen Artikel von Elmastudio sehr gelungen, aber es gibt noch viele andere, suchen sie sich was raus. Es gibt jetzt schon länger die „Best Practice“-Empfehlung, auf jeden Fall den Weg über die Einbindung in der functions.php mit den Enqueue-Anweisungen zu gehen, aber die müssen sie gar nicht en Detail verstehen (tu ich auch nicht), Copy&Paste reicht. Früher war es üblich, die style.css des Parent Theme einfach mit dem @import-Befehl einzubinden. Diese Methode ist durchaus heute noch gebräuchlich und wird meiner Erfahrung nach sogar noch von einigen Theme-Herstellern empfohlen. Machen sie es wie sie möchten – aber machen sie es. Ohne Child Theme kein Gefuhrwerke in der style.css oder in der functions.php, never, jamais, nie nicht. Und das meine ich ernst.

 

Inhaltsverzeichnis mit Links oder auch: darf ich vorstellen, der Permalink

Wozu ein Inhaltsverzeichnis?

Wieso nicht? Ich möchte schließlich meinen Lesern einen schönen Überblick über meine Beiträge liefern, in Kurzform und so ähnlich übersichtlich wie ich das im Dashboard unter „Alle Beiträge“ vorfinde.

Jaaa dafür gibt es Sitemap-Plugins, die alle Beiträge nach allen möglichen Kriterien auflisten – aber das fand ich dann doch mit Kanonen auf Spatzen geschossen. Ich brauchte für mein Inselfisch-Kochbuch eine simple Liste aller Rezepte, alphabetisch bitteschön, nach Buchstaben geordnet. Und weil ich kein Plugin gefunden habe, das genau meinen Zweck erfüllte, hab ich mir eins selber geschrieben.

Damit ich mein Publikum nicht verwirre: wir haben ja schon eine Liste aller Beiträge! Ja, aber noch nicht mit Link zum Draufklicken, der direkt zum Beitrag führt, und das machen wir jetzt. Das sieht im Inselfisch-Kochbuch life so aus: Inhaltsverzeichnis A-Z

Gestatten: der Permalink

Was ist eigentlich ein Permalink? Darüber haben die Kollegen vom Elbnetz einen hervorragenden Beitrag „Was sind eigentlich Permalinks„verfaßt, den ich ihnen zur ausführlichen Information ans Herz legen möchte. Ganz kurz und knapp gesagt, Permalinks sind aussagekräftige URLs, die sind sie wahrscheinlich von ihrem WordPress sowieso gewohnt. Wenn sie einen Beitrag in ihrem Urlaubsfotoblog anschauen und mal einen Blick in die Titelleiste ihres Browsers werfen, steht da zum Beispiel sowas wie:

meineseite.de/urlaubsbilder/2017/01/25/gardasee/

Das ist ein sogenannter „sprechender“ Permalink. Das läßt sich schön im Klartext lesen, das ist suchmaschinenfreundlich und sogar für Menschen mit Handicap im Sinne der Barrierefreiheit wunderbar zu lesen. Wie ihr WordPress diese Permalinks anlegt ist unter Einstellungen/Permalinks festgelegt, wahrscheinlich ist dort die Option „Tag und Name“ angewählt. Damit erhält jeder Beitrag so einen aussagekräftigen Permalink, und über den können wir ihn auch aufrufen. Dafür brauchen wir:

Die WordPress-Funktion get_permalink(  )

Im einfachsten Fall ruft man diese Funktion nur mit der ID des gewünschten Beitrags auf. Das sieht zum Beispiel so aus:

$perm= get_permalink( $einpost->ID );

Die Variable $perm bekommt damit den Permalink des aktuellen Beitrags, der über die ID ja eindeutig identifiziert ist. Das bauen wir in unsere foreach-Schleife mit ein, und schon haben wir die Permalinks unserer Beiträge mit in der Ausgabe! Das sieht jetzt fein aufgelistet so aus:

tabelle_mit_permalinks

tabelle_mit_permalinks

Links aus Permalinks

Jetzt brauchen wir nur noch einen <a href> um den Permalink herumzubasteln, und wir haben unseren Link zum Beitrag. Sieht im einfachsten Fall so aus:

links_in_aktion

links_in_aktion

Ist noch nicht richtig schön, aber es funktioniert, und es eröffnet jede Menge Spielmöglichkeiten!

Alle alten Programmierer lieben Listen – die erste Datenbankausgabe

Voraussetzungen

Ich gehe mal davon aus, daß sie grundsätzlich wissen wie man in PHP ein SQL Statement zusammenbaut und wie man daraus eine HTML-Ausgabe erzeugt . Ich werde mich nämlich nicht mit Step-by-Step Details aufhalten, schließlich wollen wir ja Ergebnisse sehen. Dafür wäre es sehr nützlich, wenn sie in ihrem Testblog auch richtig schön viele Beiträge hätten, und auch ein paar Seiten und jede Menge Bilder. Notfalls hacken sie halt so fuffzehn, zwanzig Beiträge ein und schieben ein paar Urlaubsfotos dazu, das geht dann schon für den Anfang. Ich greife für Demozwecke immer gern auf meine Kochrezepte im Inselfisch-Kochbuch zurück, das sind über 200 Beiträge mit etlichen Bildern, da kann man schön spielen 🙂

Was wir nicht brauchen

Ein „new pdo“ und den Connect auf die Datenbank. WordPress ist ja schon mit der Datenbank verbunden, da brauchen wir uns nicht weiter um die Verbindungsdetails zu kümmern. Auch eine Fehlerbehandlung für den Fall daß der Connect nicht hinhaut kann ausfallen, denn wenn das der Fall sein sollte wird ihnen WordPress schon melden, daß was faul ist. Dann haben sie nämlich ein größeres Problem, das jetzt mit unserem PHP-Progrämmchen eher weniger zu tun hat.

Aber ich schweife ab, ran an die Buletten, PHP Snippet editieren, jetzt wirds ernst…. ach, ich vergaß. Darf ich zunächst mal vorstellen…

Was wir unbedingt brauchen: das $wpdb-Objekt

Um die WordPress-Datenbankverbindung ohne weiteres nutzen zu können, müssen wir dem System mitteilen, daß wir gedenken jetzt über die WordPress-eigene Schnittstelle mit der Datenbank zu kommunizierren. Das hört sich tricky an, ist aber in der Realität ganz einfach. Dafür genügt ein einziges Statement:

global $wpdb;

Damit wird eine Objektvariable der Klasse wpdb als Globalvariable deklariert, und damit können wir ihre Methoden zum Datenbankzugriff in unserem Codesnippet nutzen.

Ein einfaches Beispiel

 
global $wpdb;
$alleposts = $wpdb->get_results( "SELECT * from wp_posts where post_status = 'publish' and post_type = 'post'");
  • Der SELECT ist ganz simpel, die Syntax in MySQL ist genau so wie wir sie gewohnt sind.
  • $alleposts ist einfach eine PHP-Variable, die als Auffangbehälter für das Ergebnis unseres SQL-Statements dient.
  • $wpdb->get_results ist die Methode, mit der wir unseren SELECT auf die Datenbank loslassen

Und das Ergebnis? PHP-Programmierer werden es erraten, mit einem „echo $alleposts;“ erziehlen wir die lapidare Ausgabe „Array“.

Ja, Kunststück! 🙂 Die Methode get_results liefert das Ergebnis der SQL-Abfrage, und das sind nunmal im Zweifelsfall mehrere Zeilen.  Die stecken in einem Array, und das läßt sich sehr praktisch zeilenweise ausgeben, nämlich z.B.  so:
foreach ( $alleposts as $einpost ) {
echo $einpost->ID;
echo $einpost->post_status;
echo $einpost->post_type;
echo $einpost->post_title;

}

Der foreach durchläuft einfach alle Zeilen des Arrays, das das Ergebnis unserer SQL-Abfrage enthält, und legt den Inhalt der Zeile in die Variable $einpost. Um nun an die einzelnen Datenfelder der aktuellen Zeile heranzukommen, benutzt man schlicht die Feldnamen der Tabelle. Da wir einen Select* verwendet haben könnte man hier natürlich auch noch wesentlich mehr Felder ausgeben, $einpost->post_author etwa, oder auch $einpost->post_content, aber das wird für den Anfang zu unübersichtlich. So, jetzt nochmal im Ganzen, damit der Zusammenhang noch klarer wird:

global $wpdb;
$alleposts = $wpdb->get_results( "SELECT * from wp_posts where post_status = 'publish' and post_type = 'post'");

foreach ( $alleposts as $einpost ) {
 echo $einpost->ID;
 echo $einpost->post_status;
 echo $einpost->post_type;
 echo $einpost->post_title."<br>";
}

Und, wie siehts aus? Nicht schön, ich gebs zu, aber die Sache hat Potential, müssen sie doch zugeben!

alle_beitraege_unformatiert

alle_beitraege_unformatiert

Hör ich da bei den alten Hasen die Zahnrädchen klingeln und rattern?  Liste aller Beiträge, mit ID und Titel, und da könnte man ja noch andere Felder mit dazunehmen und alphabetisch oder sonstwie sortieren… haargenau! Alles was die Liste noch braucht ist ein bißchen HTML-Zuckerguß, aber darum kümmern wir uns morgen. Nehmen sie ruhig mal das $wpdb-Objekt mit in den Feierabend, das wird nämlich unser bester Freund!

Jetzt gehts endlich los: die zentrale WordPress-Tabelle wp_posts

Ein erster Blick mit phpmyadmin

Also, die Testinstallation steht ja jetzt, wir können einen freien Blick mit phpmyadmin auf die WordPress-Tabellen werfen. Das sind nicht uferlos viele, eine jungfräuliche WordPress-Instanz kommmt mit nur 12 Tabellen aus. Das können später je nach installierten Plugins noch viel mehr werden, aber wir konzentrieren uns hier mal auf die Grundlagen.

Anmerkung:

Wer es ganz genau wissen will: im WordPress-Codex sind die verschiedenen Tabellen natürlich genau beschrieben, ein Übersichtsdiagramm gibt es auch. Schaut mal in der Database Description, da kann man alles genauestens nachlesen. Ich mach hier trotzdem mal mit meiner vereinfachenden Erklärung weiter, der Codex ist für WordPress-Beginner doch ein wenig starker Tobak 😉

12_tabellen

12_tabellen

Und wo sind die Beiträge?

Uns interessiert zunächst mal nur eine Tabelle, die nämlich, die unsere Beiträge enthält, denn die sind ja das Leben und die Seele unseres Blogs. Wenn sie bei der Installation kein anderes als das Standard-Datenbankpräfix gewählt haben, heißt diese Tabelle wp_posts, und ich werde sie auch in Zukunft immer so anreden, damit es keine Verwechslung mit nicht-Wordpress-Tabellen gibt. Vielleicht heißt sie bei ihnen auch xyz_posts oder meinedatenbank_posts, das kommt wie gesagt auf ihr Präfix an, das haben sie selber zu verantworten 😉

Inhalt der Tabelle wp_posts

In der wp_posts also stecken alle Ihre Beiträge, und wenn man sich die Tabelle im phpmyadmin mal näher anschaut, fällt zuerst auf, daß es jetzt schon wesentlich mehr Datensätze als Blogbeiträge gibt. In der wp_posts werden nämlich auch noch andere Objekte gespeichert, die von ihnen bereits erstellten Seiten zum Beispiel, und auch alle Bilder, die sie schon hochgeladen haben, aber dazu später mehr. Hörte ich da ein erstes leises Aufjaulen der alten Datenbankhasen – was haben die Beiträge und die Bilder in ein und derselben Tabelle zu suchen, wo bleibt da die Entity-Relationship? Gemach, gemach. Dazu später mehr. Nehmen sie es jetzt einfach so hin, die jungen Kollegen haben sich schon etwas dabei gedacht, so unterschiedliche Objekte in ein und dieselbe MySQL-Tabelle zu stecken. Aber ich schweife ab, zu dem Thema später mehr.

Datenfelder der Tabelle wp_posts

Die wp_posts hat 23 Datenfelder, und die meisten davon haben selbsterklärende Namen, da gibt’s nicht viel zu rätseln.

wp_posts_23_felder

wp_posts_23_felder

Die Felder post_author, post_date, post_content, post_title usw. sind auch für Nicht-Wordpress-Experten recht selbsterklärend, man übersetzt einfach frei heraus (Beitrags-) Author, Datum, Inhalt und Titel, und da haben wir doch schon die Grundlagen zu einigen hübschen Spielereien auf der Datenbank. Auch den post_type und den post_status nehmen wir noch mit, die helfen uns beim aufdröseln, um was für eine Art von Datensatz es sich handelt. Bei einem veröffentlichten Beitrag beispielsweise ist hat der post_type  den Wert „post“ und der post_status den Wert „publish“, das ist ja auch nicht unlogisch. Bei einer statischen Seite hat der post_type den Wert „page“… ooch da gäbs noch viel dazu zu sagen, aber ich will hier jetzt am Anfang noch nicht so viel Verwirrung stiften.

Wir nehmen also unsere paar selbsterklärenden Datenbankfelder und stricken uns eine Abfrage oder zwei. Aber das machen wir nicht im phpmyadmin, das ist ja unsportlich, schließlich gehts hier um WordPress. Und wir möchten unsere tollen Abfrageergebnisse ja auch in unserem Blog veröffentlichen, nicht wahr? Aber dazu gibts einen neuen Beitrag!

Das WordPress-Datenbankmodell – wie kommt man ran?

Wir basteln uns eine Testumgebung

Um an das WordPress-Datenbankmodell überhaupt ranzukommen, sollte man sich mit phpmyadmin ein bißchen auskennen. Dafür ist es allerdings notwendig, sich bei seinem Provider in die Datenbankverwaltung einzuklinken, und davon rate ich für unerfahrenere Benutzer dringend ab. Auch für den erfahreneren Programmierer ist es ein wenig fahrlässig, auf den Echtdaten herumzufuhrwerken. Investieren sie lieber die berühmten fünf Minuten und installieren sie sich erstmal eine WordPress-Instanz rein zum Testen, am besten in einer eigenen Datenbank, die ebenfalls nur zum Testen verwendet wird. Normalerweise können sie bei ihrem Provider mehrere Datenbanken anlegen, das sollte eigentlich kein Problem sein.

Die ideale Test-Lösung: ein lokaler Webserver

Schöner und sicherer ist natürlich eine lokale WordPress-Testumgebung, die gar nicht ins Internet hinausgestellt wird. Ich verwende seit vielen Jahren Xampp mit Apache als lokalen  Web- und MySQL-Server, und hatte noch nie Kompatibilitätsprobleme oder sonstige Schwierigkeiten  damit.

Googlen sie für die Einrichtung mal nach „xampp wordpress“, da ist nicht viel dabei. Damit ist es überhaupt kein Problem, sich auf dem eigenen PC eine lokale Testumgebung mit WordPress einzurichten, die sie im Notfall (zuviel Pfusch auf der Datenbank gebaut ;)) einfach plattmachen und neu aufziehen können.

Suchen sie sich ein Theme aus, schreiben sie ein paar Beiträge, laden sie einige Fotos hoch, legen sie ein paar Seiten an. Und dann kanns losgehen. Rufen sie phpmyadmin auf, und wir werfen mal einen ersten Blick auf die WordPress-Tabellen, im nächsten Artikel.