Bilder ausgeben: nochmal mit sauberem Code und Präfix

Nachbesserung, zähneknirschend 😉

Meine wohlmeinenden Erstkritiker waren hartnäckig, jetzt muß ich noch mal nachbessern. Ich geb ja zu, es war nicht ganz fein von mir, den SQL für die Ausgabe aller Bilder mit absolut doofen Tabellennamen (iii_wpposts, iii_wppostmeta) in den Beitrag zu setzen. Und auch das nur als Screenshot, so daß man sich das Ding noch nicht mal kopieren konnte. Also gut, ich lege nach. Aber bevor ich mich hier wieder mit dem visuellen Editor anlege, gibts den aktuellsten Code als Zip-Datei.

Gezipptes PHP-Skript

Hier klicken für den Zip-Download: join_posts_und_postmeta_mit_wpdbprefix

Was hat sich geändert?

Jetzt aber trotzdem nochmal ein Screenshot, damit man auf einen Blick sehen kann, was sich geändert hat.

prefix_auf_variable

Ich habe zwei Variable für die Tabellennnamen angelegt, und diese sauber mit

$wpdb->prefix."tabellenname"

befüllt. Jetzt muß man nur noch im Select die hart codierten Tabellennamen gegen die Variablen austauschen, d.h. überall wo vorher stand iii_wpposts steht jetzt „.$meine_posts.“, und statt iii_wppostmeta steht jetzt „.$meine_postmeta.“. Das wars schon, ansonsten hat sich an dem Select rein gar nichts geändert!

Das ist mit den vielen Gänsefüßchen und Punkten zwar nicht mehr besonders gut zu lesen, aber letztendlich kommt es auch der Funktionalität zugute, das Skript sollte jetzt eigentlich auf jeder halbwegs normalen WordPress-Installation laufen. Ich habs auf drei verschiedenen Testinstanzen getestet, bei mir tut es genau das was es soll, nämlich alle Bilder als Übersicht im Thumbnail-Format ausgeben. Und das mit ca. 20 Zeilen Code 😉

Nicht vergessen: der Eintrag in der style.css

Da muß man je nach installiertem Theme vielleicht noch ein bißchen Feintuning machen, aber der Eintrag in der style.css des Child Themes für die div ist auch der gleiche geblieben, der sieht immer noch so aus:

.evisdiv{
    
    float: left;
    height: auto;
    width: 20%;
    overflow: hidden;
    border: 1px solid blue;
    margin: 10px;
    padding: 10px;
    box-shadow: 5px 5px 3px #888
  
}

Den overflow könnte man rausschmeissen, weil ja jetzt die quadratierten kleinen Thumbnails verwendet werden, und den Rest kann sich jeder nach persönlicher Vorliebe stylen – have fun mit CSS! 🙂

Barrierefreiheit für den Hausgebrauch: Strukturierung

Ich stehe beim großen Thema Barrierefreiheit zugegeben erst am Anfang, da gibt es noch viel zu lernen. Aber ich hatte tatkräftige Hilfe von der Stiftung Pfennigparade, die erfahrenen Programmierer dort haben mir viele wertvolle Tipps gegeben, so daß ich mein Inselfisch-Kochbuch zumindest barrierearm und auch für Menschen mit Handicap gut zugänglich gestalten konnte. Das war für mich ein großer persönlicher Erfolg, und ich freue mich über stetig wachsende Besucherzahlen. Es war aber auch ein Haufen Arbeit, und ich möchte hier einige Tipps geben, die es anderen WordPress-Entwicklern und auch privaten Anwendern vielleicht leichter machen, barrierearme Webseiten zu erstellen.

Von Anfang an gut strukturieren: HTML Bascis

Die allermeiste Heidenarbeit war es, die Beiträge in meinem Kochbuch im nachhinein durchzustrukturieren und sinnvoll zu formatieren. Ich habe über 200 Rezepte manuell anfassen müssen, weil ich sie im Lauf der Jahre einfach so als Fließtexte erfasst hatte und keine vernünftige Dokumentstruktur drin hatte. Dabei ist es eigentlich ganz einfach: längere Textpassagen sind mit Zwischenüberschriften zu untergliedern, und diese sind in HTML ganz schlicht als h1, h2, h3… h6 auszuzeichnen. Wobei ich mehr als h3 noch nie gebraucht habe, für die meisten Zwecke reichen zwei Überschriften-Ebenen vollkommen aus. Der Fließtext dazwischen wird sinnvollerweise als Absatz (<p>) formatiert. Für Aufzählungen nimmt man ein <ul>, für nummerierte Listen ein <ol>. Reinstes HTML-Basic! All diese Strukturierungselemente stehen im visuellen Editor einwandfrei zur Verfügung, nur benutzen muß man sie auch!

Anwendungsbeispiel Kochrezept

Ich zeige zuerst einmal, wie man es nicht macht. Dieser Rezepttext wurde einfach so heruntergeschrieben und mag jedem einigermassen erfahrenen Hobbykoch etwas sagen, aber er ist grottenschlecht im Sinne der Barrierefreiheit weil gar nicht strukturiert. Das geht schon damit los, daß die eigentliche Überschrift mit im Fließtext klemmt und nur fett hervorgehoben wurde. Auch der Rest des Rezepts ist schlicht gar nicht strukturiert, das wird einfach so heruntergeplaudert und man kann schlecht erkennen, wo es jetzt um die Zutaten und wo es um die Zubereitung geht, und was da sonst noch stehen mag.

Das unstrukturierte Rezept

Curry-Bananen-Dip zum Fondue, oder auch zu Gegrilltem. Man braucht dafür eine richtig reife Banane, am Besten schon ein paar Tage vorher kaufen und reifen lassen, bis sie schön weich ist und cremig wird. Banane mit Limettensaft mit einer Gabel fein zermusen, Salz und soviel Currypulver darangeben daß es deutlich scharf, aber noch angenehm schmeckt. Sofort servieren, oder den Dip mit zusätzlich etwas Limettensaft beträufeln, er verfärbt sich sonst braun. Nach einem guten, würzigen aber nicht penetranten Currypulver muß man ein wenig suchen, die aus dem Supermarkt sind meistens nicht so überragend. Wenn man kein anderes kriegt, eher weniger Currypulver verwenden und die nötige Schärfe mit ein paar Tropfen Tabasco oder etwas Sambal Oelek herbeizaubern.

Da muß Struktur rein! Ein Kochrezept besteht ja bei mir meistens aus 4 Komponenten:

einer Einleitung, in der ich ein paar nette Worte über Herkunft und Besonderheiten des Rezeptes erzähle,
einer Zutatenliste,
der eigentlichen Zubereitung
und dann noch ein oder mehrere Tipps zum Rezept.

Ja dunnerlittchen, da sind mir vielleicht die Schuppen aus den Haaren gefallen, als mir der nette Herr Programmierer von der Pfennigparade erklärte, daß das als Strukturierung vollständig ausreichte, ich müßte es nur auch in HTML umsetzen!

Und das geht so: Zwischenüberschriften rein und mit Überschrift 2 formatieren, Überschrift 1 ist schon vergeben, die hat in WordPress der Beitragstitel. Zutaten und Zubereitung klar trennen, die Tipps einzeln ans Ende setzen. Das sieht dann so aus:

Das gut strukturierte Rezept:

Curry-Bananen-Dip

Einleitung

Zum Fondue, oder auch zu Gegrilltem. Man braucht dafür eine richtig reife Banane, am Besten schon ein paar Tage vorher kaufen und reifen lassen, bis sie schön weich ist und cremig wird.

Zutaten

1 reife Banane, Saft 1 Limette, wenig Salz, 1-2 Teel. gutes Currypulver.

Zubereitung

Banane mit dem Limettensaft mit einer Gabel fein zermusen, Salz und soviel Currypulver darangeben daß es deutlich scharf, aber noch angenehm schmeckt. Sofort servieren, oder den Dip mit zusätzlich etwas Limettensaft beträufeln, er verfärbt sich sonst braun.

Tipp:

Nach einem guten, würzigen aber nicht penetranten Currypulver muß man ein wenig suchen, die aus dem Supermarkt sind meistens nicht so überragend. Wenn man kein anderes kriegt, eher weniger Currypulver verwenden und die nötige Schärfe mit ein paar Tropfen Tabasco oder etwas Sambal Oelek herbeizaubern.

Fazit

Da staunste, was? Die Strukturierung im Sinne der Barrierefreieheit hat das Rezept wesentlich übersichtlicher gemacht und auch für „normale“ Besucher besser zu lesen. Das ist übrigens ein angenehmer Nebeneffekt bei der Gestaltung im Sinne der Accessibility, wie das auf neudeutsch heißt: es tut der Lesbarkeit und der Verständlichkeit der meisten Texte gut, wenn man auf eine saubere Strukturierung achtet.

Aber trotzdem, 200 Rezepte nachträglich strukturieren, das mach ich nicht nochmal, das war eine Mordsarbeit. Jetzt schau ich halt, daß ich die Rezepte gleich von Anfang an richtig strukturiere und formatiere, und gut ists.

Bildausgabe: noch ein paar Spielereien

Das selbe nochmal mit Vorschaubildern

Also gut, meine Bildausgabe sah zugegeben nicht besonders ordentlich aus, weil die Bildformate im Inselfisch-Kochbuch so höllisch unterschiedlich sind. Dann nehmen wir halt in Gottes Namen mal die quadratischen Vorschaubilder. Und die Beschriftungen und Beschreibungen lassen wir ganz weg, weil da eh nichts Gescheits drinsteht. So besser?

join_mit_thumbnails

Was hab ich gemacht? Mir das quadratische Vorschaubild mit der Funktion wp_get_attachment_thumb_url($att_id)
geholt. Davor muß man allerdings den Select erweitern und sich noch die ID des Bild-Datensatzes für die Funktion mit dazunehmen, ich hab das mal so gemacht:

SELECT wp_posts.ID as ‚BildID‘,…

Der Rest des Select bleibt absolut gleich. Die foreach-Schleife sieht jetzt so aus:

bild_ausgabe_thumb

Die echos für die jetzt überflüssigen Felder sind rausgeflogen, und in den img src-Tag kommt jetzt eben die URL des Thumbnails und nicht die des Originalbildes. Ausserdem habe ich die width-Angabe rausgenommen, weil die Thumbnails in meinem Theme eh bloß 150x150px groß sind.

Jetzt noch ein paar Anpassungen in der style.css, die height für evisdiv auf auto gesetzt, das Orange im Background rausgenommen und den border radius rausgeschmissen. Jetzt kann echt keiner mehr meckern:

inner_join_ergebnis_style

Es sieht jetzt wirklich auf den ersten Blick ordentlicher aus, aber die abgeschnittenen Bilder finde ich nach wie vor nicht schön. Na ja, wer’s mag…

Alle Bilder: jetzt gehts an die Ausgabe

Jetzt kommt die Schlamperei auf

Wenn alles geklappt hat, dürfte der phpmyadmin jetzt nur noch die fünf mit dem „as“ benamsten Felder ausgeben. Und wenns euch genauso geht wie mir und ihr beim Bilder hochladen geschlampert habt, steht im alt-Text und im Titel genau das gleiche drin, und die Beschreibung ist in vielen Fällen leer, einfach weil man beim Hochladen nichts angegeben hat. Ich war sogar noch etwas mehr gschlampert: bei mir haben die Felder Bildtitel, Bildbeschreibung und Bild_alttext den selben Wert, weil ich hier einfach mit Copy&Paste gearbeitet habe.

Wo bleibt da die Barrierefreiheit?

Ganz einfach, ich komme damit durch, weil es sich bei meinen Beiträgen um schlichte Kochrezepte handelt. Wenn da als alt-Text „lasagne“ oder „huhn-mit-prosecco“ steht, ist das voll OK weil sich im Kontext „Online-Kochbuch“ jeder etwas darunter vorstellen kann.

Das PHP-Skript

Ich hab da erstmal eine tabellarische Ausgabe gemacht:

join_posts_und_postmeta

Das Wichtigste ist eigentlich, daß in der foreach-Schleife die Felder aus dem Join jetzt mit dem Alias angesprochen werden, den wir jeweils mit dem „as“ angelegt haben. Sonst ist der Aufbau analog zu dem, was wir schon mit den Beiträgen und den Beitragsbildern gemacht haben, erinnern sie sich?

Ich geh mal jetzt ein bißchen in den Schnelldurchgang, das haben wir ja schließlich alles schon mal gehabt. Tabellentags raus, img src rein, div um die foreach-Schleife gelegt, ein wenig CSS Styling.

Die neue foreach-Schleife

Die sieht jetzt so aus:

join_post_und_postmeta_ausgabe

Wenn man jetzt beim Hochladen der Bilder aussagekräftige Inhalte für Bildbeschreibung, -beschriftung -titel und alt-Text eingegeben hätte, bekäme man auch was Ordentliches zu sehen. Probieren sie es aus, laden sie mal ein paar neue Bilder hoch und machen sie sich die Mühe, alle Felder vernünftig auszufüllen. Dazu hätte ich noch einige Anmerkungen, aber jetzt schauen wir uns erstmal unsere Ausgabe aller Bilder an. Bei mir sieht man gleich, daß ich geschummelt habe und in der Bildbeschreibung das selbe drinsteht wie in der Bildbeschriftung, und daß meine Bildchen sehr unterschiedliche Formate haben:

neu_join_screenshot

Wenn man übrigens mit der Maus über eines der Bilder fährt, poppt der title-Text auf – hübscher Effekt, finde ich 🙂

WordPress macht das allerdings von selber nicht, im img src-Tag im post_content wird der Bildtitel nicht mit eingetragen, der entschwindet irgendwo im Nirvana 🙁

Das Problem mit den Hoch- und Querformaten

Tscha, da haben wir es wieder. Natürlich kommen die Querformate hier wieder zu klein raus, weil die Breite ja mit der width-Anweisung im img src Tag festgelegt ist. Aber ich hab lieber das GANZE Bild in der Anzeige, als ein zugeschnittenes Quadratchen mit x-beliebigem Bildausschnitt. Meine persönliche Meinung.

Was fehlt noch?

Jetzt wäre es natürlich schick, wenn man zu jedem Bild auch einen Link auf den zugehörigen Beitrag oder die zugehörige Seite hätte. Was hab ich da wispern gehört – parent_id? Genau! Aber dafür gibts einen neuen Beitrag.

Bilder: Join aus der wp_posts und der wp_postmeta

Also, mal das Ziel nicht aus den Augen verlieren: wir wollten Bilder ausgeben, und zwar für den Anfang mal alle, mit den relevanten Bildinformationen alt-Text, Titel, Beschriftung und Beschreibung. Wie kriegen wir die jetzt aus den beiden Tabellen wp_posts und wp_postmeta raus? Ich seh schon das Glitzern in den Augen der alten Datenbankhasen: mit einem Join über die ID, ganz klar. Damit man den Überblick nicht verliert, selektieren wir jetzt gezielt nicht mehr alle, sondern nur noch einige Felder aus der wp_posts und holen uns aus der wp_post_meta nur den meta_value. Im ersten Ansatz sieht das so aus:

Der angepaßte Select

Ich mußte hier auf eine andere Test-Installation zurückgreifen, weil ich viele Bilder brauchte. Die hat das Datenbank-Präfix „iii_wp“ – muß man halt auf das eigene Präfix anpassen, tut mir leid wegen der Umstände.

SELECT iii_wpposts.post_title as „Bildtitel“, iii_wpposts.post_content as „Bildbeschreibung“,
iii_wpposts.post_excerpt as „Bildbeschriftung“, iii_wpposts.guid as „Bild_url“, iii_wppostmeta.meta_value as „Bild_alt_text“ FROM iii_wpposts
INNER JOIN iii_wppostmeta ON iii_wpposts.ID = iii_wppostmeta.post_id
WHERE (((iii_wpposts.post_type) Like „attachment“) AND ((iii_wpposts.post_mime_type) Like „image/jpeg“) AND ((iii_wppostmeta.meta_key) Like „_wp_attachment_image_alt“)))

Wahrscheinlich könnte man in der WHERE-Klausel auf den post_type Like „attachment“ verzichten, wir selektieren ja dann noch auf den post_mime_type Like „image/jpeg“, aber schaden kanns auch nicht, das lasse ich mal so stehen.

Statt iii_wp müssen sie sich halt jetzt ihr eigenes Präfix denken, aber so funktioniert es prinzipiell. So geht der Inner Join der Tabellen über die Post ID, letztendlich sollte das Statement im phpmyadmin jetzt genauso viele Datensätze ausgeben, wie wir Bilder in der Mediathek haben.

inner_join_ergebnis

Warum stehen im Select die ganzen „as“-Klauseln? Weil wir die Alias-Namen der Felder nachher für die PHP-Ausgabe brauchen.

Paßt alles? Fein, dann machen mir mal weiter mit:

Arme Waisenkinder: Bilder ohne Eltern

Die alten Füchse haben sicher schon mit der parent_id geliebäugelt, die riecht ja förmlich nach einem Join zum Beitrag, aber wir machen mal einen Schritt nach dem anderen. Wenn man sich die Datensätze aus dem Abfrageergebnis mal genauer anschaut, kann es sein daß bei einigen Datensätzen im Feld parent_id eine Null steht. Das sind die Datensätze, die man sich in der Mediathek unter „Nicht verknüpft“ anschauen kann, also Bilder, die zwar hochgeladen, aber noch nicht mit einem Beitrag oder einer Seite verknüpft worden sind, oder die aus einem Beitrag oder einer Seite gelöscht wurden, aber nicht aus der Mediathek.

Ob wir die jetzt mitnehmen oder nicht ist Geschmackssache, aber man sollte zumindest wissen, daß die auch da sind, wenn man ALLE Bilder ausgibt. Und das machen wir im nächsten Beitrag. Morgen. Ich muß mich jetzt erstmal von dem ganzen Felderwirrwarr erholen – ich will eine vernünftige Attachment-Tabelle für mein WordPress! 😉

Bilder: jetzt tragen wir mal alle Informationen zusammen

… oder wir versuchen es wenigstens. Das Gezeter mit dem nachträglich geänderten alt-Text lassen wir jetzt mal hinter uns, und gehen davon aus daß beim Bilder-hochladen die relevanten Informationen richtig eingegeben wurden, sonst wird das hier nix.

Wie ich im letzten Artikel schon angerissen habe, steckt ein Teil der Informationen zu in WordPress hochgeladenen Bildern in der Tabelle wp_posts, ein anderer Teil in der Tabelle wp_post_meta. Verknüpft werden die beiden Tabellen über die ID des Bild-Datensatzes aus der wp_posts, aber bevor ich darauf näher eingehe, noch ein kurzer Blick auf:

Bildinformationen in der Tabelle post_meta

In dieser Tabelle werden zu jedem hochgeladenen Bild drei (mindestens, es gibt Sonderfälle aber die lassen wir hier mal weg) Datensätze angelegt, die sich durch den jeweiligen meta_key identifizieren lassen. Hinter dem Metakey _wp_attached_file steckt der relative Pfad zur Bilddatei – relativ zum Pfad des Images-Verzeichnis der jeweilige WordPress-Installation. Unter _wp_attachment_image_alt findet man wie gesagt den Alternativtext, und dann gibt es noch _wp_attachment_metadata, da blicke ich ehrlich gesagt noch nicht so ganz durch was was bedeutet. Man erkennt jedenfalls die Informationen aus der JPEG-Datei (aperture, credit, camera, orientation etc.), und dann gibt es da noch Größenangaben für Thumbnails und Medium-Bilder, die müßten eigentlich dem entsprechen, was im Dashboard unter Einstellungen/Medien zu finden ist.

Aber das führt jetzt ein bißchen zu weit, wir nehmen nur den alt-Text mit und gehen zurück in die Tabelle wp_posts.

Bildinformationen in der Tabelle WP Posts

Jetzt gehen wir erst nochmal in die Mediathek zurück und schauen uns da an, was man zu einem neu hochgeladenen Bild alles eingeben kann. (Die Anhang-Seite ignorieren wir erstmal)

mediathek_felder

Wo findet man was in den Tabellen wieder?

URL, die sollte man tunlichst in Ruhe lassen – im Feld guid
Titel, der müßte eigentlich dem HTML-title entsprechen und wird mit dem Dateinamen (ohne Endung) des Bildes vorbelegt – im Feld post_title
Beschriftung, das sollte die sein, die im Artikel unter dem Bild auftaucht – im Feld post_excerpt
Alternativtext – ja gottseidank, den erkennen wir wenigstens wieder! Der steckt in der wp_postmeta im Feld meta_value
Beschreibung, die wird, glaube ich irgendwo gelesen zu haben, abhängig vom Theme angezeigt oder auch nicht. Könnte etwas mit der caption beim figure-element zu tun haben, aber wie gesagt, das weiß ich nicht so genau. Jedenfalls im Feld post_content zu finden.

Ich hoffe, ich hab alles, denn jetzt gehts ans SQL, im nächsten Beitrag.

Noch ’ne Runde über Attachments, speziell Bilder

Ich hab ja eigentlich wieder ein bißchen Spaß auf der Datenbank versprochen, aber ich fürchte, jetzt wirds erstmal eher weniger lustig. Wir waren ja bei unseren Attachments vom Typ image/jpeg stehengeblieben, und haben schon gesehen, daß die in der wp_posts gespeichert werden. Jetzt gehts aber mal ein bißchen ans Eingemachte: welche Informationen zum Bild stehen wo und in welcher Tabelle?

Nur mal so zur Erinnerung: Bildattribute in HTML

Das absolute Minimum, was zum Einfügen eines Bildes gebraucht wird, sieht so aus:

<img src="bild01.jpg" alt = "Erstes Bild">

bild01.jpg ist die URL, die angibt auf welchem Pfad das Bild tatsächlich liegt, und alt ist der Alternativtext, der so wichtig für die Screenreader ist und auch angezeigt wird, wenn das Bild noch nicht vollständig geladen ist. Es gibt auch noch mehr Bildattribute, den Titel und Größenangaben usw., aber wir lassens hier mal gut sein, kann ja auch jeder selber googlen, hier bei Wiki zum Beispiel

Bildattribute in WordPress

Wenn man sich so einen Datensatz von einem JPEG-Attachment in der wp_posts im phpmyadmin mal näher anschaut, kommt man zuerst mal durcheinander. Da steht etwas(oder auch nichts) in post_title, etwas in post_content, und guxtu: bei post_excerpt und post_name kann auch noch was drinstehen. Was ist hier was? Wenigstens kann man klar und deutlich sehen, daß in guid die URL des Bildes drinsteht, das ist doch immerhin schon was. Aber ansonsten gibts hier Kraut und Rüben, und falls sie den Alternativtext vermissen sollten (so sie einen eingegeben haben), der ist hier nicht zu finden. Der steckt nämlich in einer anderen Tabelle, in der wp_postmeta hat er sich verschämt versteckt! Da gibt es doch tatsächlich einen Datensatz mit einem Fremdschlüssel, der die ID unseres Bild-Datensatzes aus der wp_posts enthält. Da wo im Feld meta_key das Schlüsselwort _wp_attachment_image_alt steht, da steckt daneben im Feld meta_value der alt-Text. Gut, nicht?

Warum gibt es keine eigene Tabelle für Attachments?

Ja, Dunnerlittchen! Wieso hat man denn nicht für die Attachments eine eigene Tabelle angelegt, mit anständigen Feldnamen für alt-Text, Titel usw., mit einer einzigen sauberen Verknüpfung über die ID des Beitrags, zu dem die Bilder gehören? Stattdessen werden hier die eigentlich für Posts gedachten Felder post_title, post_content und post_excerpt hergewürgt, und das alt-Attribut ganz woanders versteckt. Da soll doch der …. Blitz dreinschlagen, um es mal ganz gemäßigt auszudrücken. Das kommt davon, wenn man Äpfel und Birnen (Posts und Attachments) in ein und dieselbe Tabelle stopft, obwohl es doch krass unterschiedliche Entitäten sind.

Wenn sie übrigens beim Bilder hochladen vergessen haben, alt-Texte anzugeben, wird der jeweilige Dateiname dafür verwendet. Das ist gängige Praxis, aber nicht schön, weil der Screenreader dann eben -zig mal DSC01648 oder sowas vorliest, und das bringt natürlich überhaupt nichts.

Und wenn ich jetzt einfach alle alt-Texte korrigiere?

Gemach, gemach, so einfach ist das nicht. Wenn sie jetzt im visuellen Editor hingehen und das jeweilige Bild bearbeiten, können sie zwar einen neuen, besseren alt-Text eingeben, aber der wird mitnichten in der Datenbank im Feld meta_value gespeichert! Der landet nur im img-src-Tag im post_content, und die Datenbank kriegt nichts mit davon. Wenn sie das Pferd jetzt andersherum aufzäumen und in der Mediathek das richtige Bild raussuchen, hier auf Bearbeiten gehen und da einen neuen alt-Text eingeben, landet der zwar in der Tabelle wp_postmeta (beim Metakey _wp_attachment_image_alt) aber nicht im Beitrag. Man müßte erst das betreffende Bild aus dem Beitrag löschen und aus der Mediathek wieder neu hereinnehmen, dann dürfte wieder das Datenbankfeld für den alt-Text herangezogen werden.

Hab ich sie jetzt komplett durcheinandergebracht? Jetzt wissen sie warum ich mir für WordPress eine „saubere“ separate Attachment-Tabelle wünsche!

Hab ich doch glatt vergessen: Tach auch, ich bin dein Präfix!

Ich bin von wohlmeinenden Kritikern darauf hingewiesen worden, daß ein Statement wie :

SELECT * from wp_posts

ein bißchen nach Schlamperei riecht. Schließlich kann man bei der WordPress-Installation ein x-beliebiges Datenbankpräfix angeben, und dann heißt die Tabelle eben nicht wp_posts, sondern womöglich 783287xyzposts, und mein SQL fällt auf die Nase.

Was ist ein Datenbankpräfix?

Das stammt noch aus den Zeiten, als MySQL Datenbanken beim Provider rar und teuer waren, und man notgedrungen mehrere WordPress-Installationen in eine einzige MySQL-Datenbank stecken mußte. Das Datenbankpräfix muß innerhalb einer Datenbank eindeutig sein, denn es dient dazu dem System mitzuteilen, welche Tabellen zu welchem Blog gehören. Das hat früher oft ganz schön Verwirrung gestiftet und machte auch das Datenbank-Backup eines Blogs nicht gerade übersichtlicher. Aber ich denke, heutzutage wo bei jedem Webspace zwanzig und mehr MySQL-Datenbanken dabei sind, ist das kein Thema mehr. Ich bevorzuge es, für jeden Blog eine eigene Datenbank zu nehmen (Pscht, das mit dem Multisite-Blog habe ich jetzt nicht gehört!) und als Präfix den Default wp_ zu belassen.

Wenn man jetzt Code schreiben möchte, der auf jeder normalen WordPress-Installation läuft, muß man natürlich den richtigen und kompletten Tabellennamen, der sich immer aus dem Prefix und dem WordPress-Basistabellenamen zusammensetzt, angeben. Dafür gibt es die Systemvariable prefix. Im Code sieht das dann korrekt so aus:

SELECT * from $wpdb->prefix.posts

Ich bleibe aber trotzdem bei meiner vereinfachten Schreibweise mit dem wp_posts, weil ich finde daß es leichter zu lesen ist, und für mich weniger Arbeit zum Tippen 😉

Fußnote

Ich habe schon oft gelesen, daß es aus Sicherheitsgründen dringend anzuraten ist, ein möglichst kryptisches Datenbankpräfix zu wählen, von wegen Hackerangriffe und so. Weiß ich nicht was ich davon halten soll, schließlich kann der böse Hacker den Dreh mit dem $wpdb->prefix auch kennen, und damit ist es nix mit dem Schutz. Aber das nur mal so als Nachgedanke..

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-150×150

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

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!