Archiv der Kategorie: WordPress

Plugins – auf Teufel komm raus?

Das Open Source Prinzip

Also, normal bin ich ja schon eine grosse Freundin von Open-Source-Software. Die Idee, Programmcode offenzulegen und für jeden Interessenten zugänglich zu machen, hat unbestreitbar viele Vorteile für den Otto-Normalanwender. Auf diesem Weg kommt man kostenlos an echt professionelle Software für fast alle Zwecke, vom alternativen Betriebssystem Linux über Open Office als echte Konkurrenz für Microsoft Office und noch vieles mehr bis eben hin zu unserem WordPress, dem Fex unter den Webdesignern für das kleine Budget. Durch die Offenlegung der Sourcen kann auch jeder Programmierer, der sich dazu berufen fühlt, eigene Erweiterungen schreiben und ebenfalls als Open Source zur Verfügung stellen. Es gibt heute 48,995 Plugins im wordpress.org Plugin Directory, und das sind nur die kostenlos erhältlichen. Von den gegen Honorar programmierten oder fertig käuflichen muß es noch viel mehr geben, jede kleine Softwareschmiede programmiert heutzutage Plugins für alle Zwecke für ihre Kunden.

Für jeden Zweck ein Helferlein

Ob sie jetzt einen Onlineshop oder ein Hobbyforum betreiben wollen oder nur ein paar Kontaktformulare erstellen, ob sie einen Spamschutz brauchen oder ein komplettes SEO-Paket, ob es um Designanpassungen geht oder um Multimediaspielereien, es gibt für Tausend unterschiedliche Zwecke Plugins. Die Installation ist einfach, jeder Hobby-Wordpress-Admin hat schon -zig Plugins installiert, da sind ganz schnell mal so zwanzig, dreißig Installationen zusammen, und man hat eigentlich noch gar nicht viel gemacht.

Ein schwarzes Schaf dabei?

Ja, bis es dann passiert: ein Plugin zuviel installiert, und WordPress ist plötzlich beleidigt. Das muß nicht gleich der berüchtigte White Screen of Death sein, da können auch ganz andere Fehlfunktionen auftreten, die man vielleicht nicht gleich bemerkt. Da funktioniert plötzlich der Customizer nicht mehr, oder es verhaut das Seitenlayout, oder was auch immer da alles schiefgehen kann. Da wird dann immer wohlmeinend geraten, erst einmal alle Plugins zu deaktivieren und dann eins nach dem anderen wieder zu aktivieren, damit man herausfindet welches Helferlein denn nun den Ärger verursacht hat. Na prima. Und wenn man an sein WordPress gar nicht mehr rankommt? Kann man ihm immer noch das ganze Plugin-Verzeichnis unter dem Hintern wegziehen und schauen obs dann wieder normal läuft. Auch ’ne Lösung.

Denn sie wissen nicht, wer was tut

Jedem altgedienten Softwareentwickler da draussen sträuben sich hier natürlich alle Haare, das hat ja mit Datensicherheit überhaupt nichts mehr zu tun, aber bitte bürsten sie sich wieder flach, meine lieben Anwendungsprogrammierer und gelernten Informatiker, es kommt noch besser. WordPress lädt den Endanwender ja auch noch ein, den Plugin-Code zu verändern, man muß nur Im Plugin-Verzeichnis auf das Knöpferl „Bearbeiten“ klicken und landet mittenmang im Source-Editor und kann hier nach belieben Code verändern, löschen, herumkopieren und was weiß ich noch. Da muß noch nicht mal Absicht dahinterstecken, wie schnell hat man sich mal mit der Maus verklickt – und wenn man dann (vielleicht sogar nur aus Unwissenheit) die Änderungen speichert, ist das Malheur passiert.

Der Pferdefuß bei Open Source

Ja, echt wahr, sie können jetzt lang den Kopf schütteln, meine Damen und Herren gelernten ITler, aber so ist es nunmal. Jeder Endanwender kann nach Belieben den Sourcecode von Plugins bearbeiten, nix mit kompiliert, nix mit Kapselung, und schon gar nix mit Schutz von Gewährleistungsvoraussetzungen. Gewährleistung gibts nämlich bei Open Source nicht, weil die Grundlage dafür fehlt, nämlich der Schutz des Programmcodes vor unbefugten Änderungen. Das haben sie und ich noch als strengste Auflage bei allen ernsthaften Programmierprojekten gelernt, aber vor lauter Open Source-Begeisterung ist dieser so wichtige Aspekt der Datensicherheit komplett ins Hintertreffen geraten. Da kann jetzt jeder selber seine Schlüsse ziehen, ob eine derart leicht zerhackbare Software für den professionellen Einsatz wirklich geeignet ist, oder nicht. Das mal so als Gedanke zum Feierabend.

Wer schreibt schon Kommentare? Die Spam-Bots!

Das mit den Kommentaren in WordPress ist so eine Sache. Da haben sich die WordPress-Entwickler echt Mühe gegeben und so richtig rangeklotzt, das sieht man an den fein einstellbaren Optionen unter Einstellungen/Kommentare. Ja und wozu? Jetzt will sie keiner!

Meine E-Mail soll ich angeben? Nein Danke!

Erstens schreibt kein Schwein einen Kommentar, wenn er seine E-Mail-Adresse hinterlassen soll. Das kann man zwar ausschalten, aber es ist per Default aktiviert, und schreckt erfahrungsgemäß ganz viele Besucher ab. Niemand möchte sich ungefragte Werbemails und Newsletter einfangen, und eine E-Mail-Adresse ist schließlich eine sehr persönliche Information, die man nicht so ohne weiteres auf einer fremden Seite eingibt. Ausserdem gibt es wohl eine sehr hohe Hemmschwelle, auf fremden Seiten überhaupt Spuren zu hinterlassen. Die überwiegende Mehrzahl der Besucher bleibt lieber in der passiven Betrachter-Rolle und kommentiert auch dann nicht, wenn die E-Mail-Addi nicht abgefragt wird. Anders sieht das in den unzähligen gutbesuchten Hobby- und Freizeitforen aus, da ist die Hemmschwelle derartig niedrig, daß die Leute in den Forenbeiträgen über alles, aber wirklich alles plaudern. Scheinbar ohne sich dessen bewußt zu sein, daß JEDER ihre Beiträge lesen kann. Schauen sie mal bei chefkoch.de in die Plauderecke, dann wissen sie was ich meine…
Aber das ist jetzt ein bißchen sehr Off Topic, zurück zu unserer durchschnittlichen WordPress-Webseite.

Kommentare zu geschäftlichen Seiten – macht das überhaupt Sinn?

WordPress ist ja das ideale Frontend für überschaubare Webauftritte von kleinen Unternehmen und Selbständigen, für den Metzger und die Gaststätte um die Ecke, für das Lebensmittelgeschäft, die Autowerkstatt, für Ärzte, Anwälte, Steuerberater – was diese Kundschaft benötigt, ist einfach eine Visitenkarte im Internet, in der sich die Firma darstellt, und in der die relevanten Firmeninformationen (Geschäftsfeld, Angebote, Spezialitäten, Öffnungszeiten, Anfahrtskizze etc pp.) zu finden sind. Meistens ist noch ein einfaches Kontaktformular gefragt, und mehr nicht. Das geht sogar noch weiter: die Blog-Funktionalität von WordPress wird größtenteils kaum genutzt, ganz selten gibt es mal die Anforderung nach einer Seite mit aktuellen Informationen wie z.B. die Wochenkarte eines Restaurants oder das monatliche Mandantenrundschreiben eines Steuerberaters. In der Regel aber sind die WordPress-Seiten für kleinere Unternehmen statisch, erfordern keinerlei Interaktivität und möchten auch bittesehr keine Kommentare haben, die werden fast immer ganz deaktiviert, punktum.

Und wie ist das mit dem Spam?

Das hält sich dank Akismet, Antispam Bee und Konsorten in sehr überschaubaren Grenzen. Ein Spamschutz-Plugin ist ein Muß für jede WordPress-Webseite, die irgendeine Art von Kontaktformular anbietet. Aber die bekannten Spamwächter funktionieren absolut zuverlässig und sind völlig problemlos sowohl in der Installation als auch im laufenden Betrieb.

Und was ist mit Captcha als Schutz?

Mit Kanonen auf Spatzen geschossen. Ausserdem sind Captcha und reCaptcha und wie sie alle heissen unüberwindliche Hindernisse im Sinne der Accessibility/Barrierefreiheit. Einen sehr informativen Artikel hierzu finden sie hier bei bitv-lotse.de, und den empfehle ich jetzt als Abendlektüre.

Barrierefreiheit für den Hausgebrauch: ein Inhaltsverzeichnis V.01

Wozu ein Inhaltsverzeichnis?

Aber ich darf doch mal bitten, ein ordentliches Kochbuch braucht ein Inhaltsverzeichnis, in dem alle Rezepte alphabetisch aufgelistet zu finden sind! Wo man fix etwas nachschlagen kann wenn man ein bestimmtes Rezept sucht, wie zum Beispiel Lasagne unter Buchstabe L. Oder wo man auch mehrere Rezepte unter einem Begriff wie K wie Kartoffel… -suppe, -knödel, usw.findet.

Das brauchte ich auch für mein Inselfisch-Kochbuch, und hab logo schnell mal was programmiert. Meine Rezepte sind natürlich als Beiträge abgelegt, also ein beherzter Griff in die Tabelle wp_posts, und alle mit dem post_type „post“ und davon natürlich nur die veröffentlichten Beiträge, also post_status „publish“ rausgeholt. Alphabetisch sortiert nach Titel, von A wie Apfelkücherl bis Z wie Zwetschgenknödel, das war jetzt echt nicht weiter schwierig.

Das SQL-Statement

Das war wie gesagt ganz simpel:

SELECT * from wp_posts where post_status = ‚publish‘ and post_type = ‚post‘ order by post_title

Schon alles, mehr brauchen wir nicht.

Die foreach-Schleife

Die Ausgabe geht dann wieder mit einer foreach-Schleife, die sah am Anfang einfach so aus:

foreach ( $alleposts as $einpost ) 
{ 
 
  $url = get_permalink($einpost->ID);
  echo "<a href='".$url."'>", $einpost->post_title, '</a></br>';
}

Das mit dem get_permalink hatten wir schon, das holt uns die komplette URL zur ID des aktuellen Datensatzes. Daraus hab ich mit dem <a href…> und dem Beitragstitel flugs den Link zum Rezept gebastelt, und fertig war mein alphabetisches Inhaltsverzeichnis! Ich benamste es in IVZ kompakt, machte ein Plugin draus und fand es ganz toll.

ivz_B

Tscha, und dann kamen die netten Herren von der Pfennigparade und fanden das IVZkompakt prinzipiell eine gute Idee, aber sie hatten einige Verbesserungsvorschläge. Stellen sie sich einfach vor, sie müßten sich eine unstrukturierte (wenn auch alphabetische) Liste von über 200 Rezepten am Stück vorlesen lassen, dann können sie sich denken daß das nicht im Sinne der Barrierefreiheit ist. Also mußte eine Untergliederung nach Buchstaben her, und entsprechend Zwischenüberschriften. Als „nice to have“ wurde noch gewünscht, zu jedem Buchstaben auch die Anzahl der vorhandenen Rezepte sehen zu können, damit man selbst entscheiden konnte ob man da jetzt durch alle durchgehen oder lieber zum nächsten Buchstaben springen wollte.

Der Wunsch der netten Jungs war mir Befehl, ich habe das IVZ komplett umgestrickt, aber dafür gibts einen neuen Beitrag.

Kommt auf den Wunschzettel: eine eigene Bildertabelle für WordPress

Der Attachment-Kuddelmuddel in der wp_posts

Wie wir gesehen haben, war es ein ganz schöner Aufwand, alle relevanten Informationen für die Ausgabe aller Bilder zusammenzutragen. Ich habe an anderer Stelle schon angemeckert, daß es aus aus Sicht eines alten Datenbankers nicht OK ist, so unterschiedliche Entitäten wie Posts und Attachments in der selben Tabelle, nämlich der wp_posts, zu verwalten. Ich laß jetzt mal die anderen Attachment-Typen (ZIP, Wav, Doc…) weg und werfe nur einen gezielten Blick auf die Bilder. Das ist auch semantisch sinnvoll, weil Bilder eine ganz spezielle Art von MIME-Types darstellen. Korrekterweise muß man sagen, daß wir hier von Inline-Bildern sprechen, die vom Browser im Dokument innerhalb des Textflusses direkt dargestellt werden. Externe Bilder wären dann die, die erst geladen werden wenn man auf einen Link oder ein Vorschaubild klickt, aber ich schweife ein bißchen ab. Wer mehr wissen will: ein interessanter Artikel zu dem Thema ist hier bei der Uni Passau zu finden.

Begnügen wir uns mit den ganz normalen Bildern auf Seiten und in Beiträgen, und ich geh mal lieber direkt ran an meine Wunschtabelle.

Die neue Bilder-Tabelle: ein Vorschlag

Wie könnte das jetzt aussehen, wenn man die Bilder aus der wp_posts auslagert und eine eigene Tabelle für sie anlegt? Ganz einfach so:

neue_bildertabelle

Feldliste der neuen Tabelle

Ich geh mal die Felder der Reihe nach durch:

bild_id: AutoIncrement, die eindeutige Identifikationsnummer des Datensatzes.
beitrag_ix: der Fremdschlüssel für die ID des zugehörigen Beitrags, das „ix“ steht für „id extern“
bild_url: der vollständige Pfad zur Bilddatei
bild_titel: selbsterklärend
bild_beschriftung: selbsterklärend
bild_alt_text: selbsterklärend
bild_beschreibung: selbsterklärend

Wo sind denn all die anderen Felder geblieben?

Brauchen wir nicht mehr.

Der post_type attachment ist überflüssig, weil wir hier in der neuen Tabelle nur noch Attachments verwalten.
Der post_mime_type image/ ist überflüssig, weil wir nur noch Bilder verwalten.
Es ist sogar überflüssig, nach MIME-Type jpeg oder andere Bildformate zu unterscheiden, weil im img src-Tag auch png, gif, ico usw, zulässig sind, genaueres zu den zulässigen Bildtypen steht im Codex.
Der post_status ist überflüssig, aber der hat uns ohnehin für die Bildausgabe nicht die Bohne interessiert.
die Verknüpfung auf die wp_postmeta ist überflüssig, weil wir hier für den alt-Text das eigene Feld bild_alt_text haben

Alles klar soweit?

Das neue SQL Statement

Wie lautet also das neue SQL für die Ausgabe aller Bilder? Gehen wir mal davon aus, daß die Tabelle schlicht wp_bilder heissen soll. Dann schreibt sich das so:

Select * from wp_bilder;

Das wars.

Und das möchte ich jetzt erstmal etwas einwirken und sacken lassen.

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.