Archiv der Kategorie: Bilder

Barrierefreie Farbkontraste 2: der Sourcecode

OK jetzt gilts: man kann eine beliebige RGB-Farbe wählen und sich ausgeben lassen, welche der 140 benannten HTML-Farben einen guten (barrierefreien) Kontrast dazu liefert. Das kann man nicht nur für Schriften verwenden, sondern auch für Logos und Icons, die auf einen farbigen Hintergrund gesetzt werden sollen.

Voraussetzung ist eine Tabelle, in der die 140 Farben mit Color Group (Farbfamilie), Namen und Hex- und RGB-Notation gespeichert sind, ich zeig hier noch mal einen Ausschnitt:

mysql_farbtabelle

Wie die Farben da reinkommen beschreibe ich jetzt hier nicht, das ging über ein Excel-Makro und ist letzendlich völlig wurst für die Funktionalität. Also, wir haben unsere Farbtabelle.

Jetzt brauchen wir eine Datenbankverbindung, die beschreibe ich hier auch nicht mehr extra. Dann muss wieder mal ein Formular her, für die Auswahl der Basisfarbe bietet sich der Input-Type Color an, bei dem man in den meisten modernen Browsern einen schicken Colorpicker angezeigt bekommt. Man könnte auch ein Eingabefeld für den Hex- oder RGB-Wert nehmen, das ist letztlich Geschmackssache. Also, los gehts, mit einer Datei namens farbnamen.php, die sieht zunächst so aus:

<!DOCTYPE html>
<html lang="de">
<style type="text/css">
h1,h2,h3{
    font-family:Arial;
}
</style>
<head>
<title>Colors Arbeitspapier</title>
</head>

<body>
<h1>Beispiel Contrast Colors mit HTML Named Colors</h1>

<form action="farbnamen.php" method="post">

      <h2>Bitte eine Farbe auswählen:</h2>
      <input type="color" name="farbe" value=""><br>
      <h2>Bitte eine Farbfamilie für die Kontrastfarbe wählen:</h2>
    <select name="farbfamilien">
        <option value="BLUE">Blau</option>
        <option value="GREEN">Grün</option>
        <option value="PURPLE">Violett</option>
        <option value="WHITE">Weiß</option>
        <option value="BROWN">Braun</option>
        <option value="YELLOW">Gelb</option>
        <option value="GRAY">Grau</option>
        <option value="RED">Rot</option>
        <option value="PINK">Pink</option>
        <option value="ORANGE">Orange</option>
      </select>
     <br><br>
    <input type="submit" name = "senden">
  
</form>

Das ist erstmal straightes HTML, zuerst kommt der Color Picker, dann das Dropdownfeld für unsere Farbfamilien, und das wars auch schon. Man könnte den Select auch mit einem Distinct aus der Datenbank füttern, das hab ich mir jetzt gespart und die 10 Einträge so reingeschrieben.

Los geht es wie immer wenn auf den Submit-Button geklickt wurde. Der Colorpicker liefert den Hex-Wert der gewählten Farbe, das Dropdownfeld den Namen der Farbfamilie. Den Hex-Wert zerlege ich in die einzelnen Komponenten, die brauche ich später um meine Funktion zur Berechnung der wahrgenommenen relativen Helligkeit damit zu füttern, dazu weiter unten mehr. Das Ganze sieht jetzt erstmal so aus:

startbildschirm

Bei Klick auf das schwarze Farbkästchen poppt der Colorpicker auf, in Chrome beispielsweise sieht der so aus:

chrome_colorpicker

Das Dropdownfeld ist auch keine Überraschung:

dropdown

Aber jetzt wirds gleich interessant, ich habe nämlich für die Zerlegung des Hex-Wertes in seine RGB-Komponenten eine schicke Funktion gefunden, das geht mit sscanf():

<?php
require_once('config.php');

if(isset($_POST['senden'])){
    
    
    echo "Sie haben diese Farbe gewählt:<span style='background-color:".$_POST['farbe']."'>Hexadezimalwert: ".$_POST['farbe']."</span><br>";
    
    $akt_farbe = $_POST['farbe'];
    
    //RGB-Werte aus hex holen
    $hex = $akt_farbe;
    list($r, $g, $b) = sscanf($hex, "#%02x%02x%02x");
        
    echo "<h3>Die relative Helligkeit beträgt: ".Brightness($r,$g,$b)."</h3>";
    echo "<h3>Kontrastfarbe aus der Farbfamilie ".$_POST['farbfamilien']."</h3>";
    echo "<hr>";
    $input_brightness = Brightness($r,$g,$b);

Mit der Funktion Brightness wird wie gesagt die wahrgenommene Helligkeit der gewählten Farbe bestimmt, Input-Parameter sind die drei RGB-Komponenten. Die Funktion selber sieht so aus:

//relative (wahrgenommene) Helligkeit aus RGB berechnen
function Brightness($r, $g, $b)
    {
       return sqrt(
          $r * $r * .241 + 
          $g * $g * .691 + 
          $b * $b * .068);
    }

Jetzt hole ich mir aus der Datenbank alle Farben, die zu der gewählten Farbfamilie gehören. Zuerst setze ich noch einen Flag $gefunden, der bleibt auf False wenn in der gewählten Farbfamilie keine Farbe mit einem ausreichenden Kontrastwert gefunden wurde und dient dann weiter unten zur Info-Ausgabe.

Dann gehe ich mit einem While über alle gefunden Farben und gebe nur diejenigen aus, bei denen eine Differenz > 130 zur relativen Helligkeit der vom Benutzer vorgegebenen Farbe gefunden wird.

//alle passenden Einträge der Farbtabelle ausgeben
        //Flag default  
        $gefunden = false;
        
        //Nur die Einträge der gewählten Farbfamilie auslesen
          $abfrage = mysqli_query($conn,"SELECT * FROM $table 
                    WHERE familie LIKE '".$_POST['farbfamilien']."' "); 
          while($row = mysqli_fetch_array($abfrage,MYSQLI_ASSOC)) 
          { 
            //RGB-Werte aus hex holen
            $hex = $row['hex'];
            list($r, $g, $b) = sscanf($hex, "#%02x%02x%02x");
            //Helligkeit bestimmen
            $row_brightness = Brightness($r,$g,$b);
            
            //Kontrastwert berechnen
            $differenz = abs($row_brightness - $input_brightness);
            
            //Nur Kontrast höher als 130 ausgeben (Wert ggf anpassen)
            if ($differenz > 130){
                //flag setzen wenn mindestens ein Kontrast > 130 gefunden wurde
                $gefunden = true;
            echo ' <span style="color:'.$row['farbname'].'">'.$row['farbname'].'</span>.'.$row['hex'].'rel. Helligkeit: '.$row_brightness.' Differenz: '.$differenz.'<br>'; 
            echo "<h1><span style='color:".$row['farbname']."; background-color:".$akt_farbe."'>".$row['farbname']." ist ein guter Kontrast</span></h1>";
            echo "<hr>";
            }
            
        } // ende von while $row...
if($gefunden==false){echo "Keine passende Kontrastfarbe in der Farbfamilie ".$_POST['farbfamilien']." gefunden";}

} //Ende von isset senden

Für die Ausgabe der passenden Kontrastfarben verwende ich Spans und formatiere sie mit den entsprechenden Farbwerten. Falls keine Farbe mit ausreichendem Kontrast gefunden wurde, gebe ich dies als Info aus. Das war’s!

Hier noch ein Screenshot der Ausgabe, als Besipiel habe ich als Grundfarbe Gelb und für die Kontrastfarbe die Farbfamilie Blau gewählt:

farben_ausgabe

Fertig ist das Werkzeug zur Kontrastfarbenbestimmung. Zugegeben könnte man es noch wesentlich hübscher formatieren, aber die Funktionalität haut hin, das genügt mir jetzt erstmal. Schlanke noch nicht mal 100 Zeilen Code, das ist mal wieder was für mich und meine minimalistischen Freunde – viel Spaß beim Nachbauen!

Nachtrag

Jetzt konnte ich mir es doch nicht verkneifen, die ganze Sache noch ein bißchen ansehnlicher zu gestalten. Der Prototyp sieht jetzt so aus:

aufgehuebscht

Die Farben hole ich mir natürlich aus der Datenbank, wenn ich dazukomme, schreib ich noch einen neuen Artikel darüber. Aber hier ist jetzt mal Schlussende, der Beitrag ist lang genug

Ein dicker, fetter WordPress-Bug: die Sache mit den Alt-Texten

Warum sind Alt-Texte so wichtig?

Wenn man Bilder in seine Webseite einfügt, kann man viel falsch machen. Zum Beispiel (was in WordPress leicht passiert) keinen Alt-Text einfügen, oder nur einen kryptischen Dateinamen wie DSC73635.JPG, so wie es aus der Digicam kommt, verwenden. Dabei ist der Alt-Text immens wichtig, wenn man barrierefreie Webseiten gestalten will, weil er für User von Screenreadern und anderen Hilfsmitteln die einzige Möglichkeit ist, Informationen über Bilder zu erhalten. Und auch für nicht barierrefreie Seiten gilt: der Alt-Text ist nach W3C ein „required“ Attribut, also eine Pflichtangabe.

Bilder einfügen in WordPress: schnell mal drübergeklickt

WordPress bietet zwar beim Hochladen über die Mediathek die Möglichkeit, einen Alternativtext zum Bild einzugeben, aber es meckert auch nichts an wenn man dieses Feld leer läßt und ein Bild ohne Alt-Text hochlädt. Hier gehört eine Prüfung hin, die den Anwender auf den Fehler hinweist!

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 sogar wenn man brav seinen Alt-Text eingibt, hat WordPress so seine Schwierigkeiten mit der Verwaltung. Das hatte ich in einem Beitrag über die Bildausgabe schon einmal erwähnt, aber es ist ein derart kapitaler Bug, daß ich ihn jetzt nochmal ausführlich beschreibe. Ich muß jetzt mal ein bißchen ausholen, um das näher zu erklären.

Wo landet der Alt-Text auf der Datenbank?

Zur Erinnerung: das Bild als solches landet in der wp_posts mit dem Post Type attachement. In der wp_postmeta gibt es dann tatsächlich noch 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.

Das klingt soweit ja noch ganz gut, aber was, wenn man Alt-Texte nachträglich ändern will oder muß?

Dann passiert folgender blühende Unsinn:

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.

Übrigens: wenn sie den Alt-Text im visuellen Editor geändert haben und jetzt eine programmgesteuerte Ausgabe der alt-Texte via get_image_attribute() oder Ähnlichem probieren, kriegen sie natürlich die falschen Alt-Texte angezeigt, nämlich die aus der wp_postmeta, und nicht die aus dem img-src-Tag. Schöner Sch…, nicht wahr?

Konsequenzen dringend nötig

Das ist ein richtiger dicker, fetter Bug, da gibts kein Schönreden. Und es ist besonders ärgerlich, weil eben die Alternativtexte für die Barrierefreiheit so wichtig sind! Da dürfen sich die WordPress-Entwickler in Bälde etwas einfallen lassen, das Thema „Accessibility“, wie die Barrierefreiheit im Englischen heißt, ist auch in USA aktuell und taucht dort immer öfter in den Medien auf. Es gab auch schon spektakuläre Gerichtsurteile gegen Firmen, die ihre Webseiten nicht nach den Regeln der Barrierefreiheit gestaltet haben. Da darf man gespannt sein, wie der Gesetzgeber reagiert! Accessibility oder Zugänglichkeit von Webseiten ist eben ein brandaktuelles Thema, nicht nur bei uns.

Spiel&Spaß mit Shortcodes

Haben sie sich die Bilderausgabe auch schon in einen Shortcode gepackt? Ja fein, dann wirds Zeit für ein bißchen Spielerei am Sonntag Nachmittag

Anzahl der Bilder limitieren und Zufallszahl einbauen

Man will ja vielleicht nicht immer gleich alle Bilder ausgeben, sondern nur eine kleine Auswahl. Das ist ganz simpel, wir ergänzen das SQL-Statement einfach um eine LIMIT-Anweisung. Und damit nicht immer die selben Bilder herauskommen, ergänzen wir die Sache um die Zufallsfunktion RAND(). Das kommt ans Ende des SQL, vor den letzten schließenden Gänsefüßchen:

…ORDER BY RAND() LIMIT 6″ );

Ergebnis:

6_bilder_screenshot

Ab in die Seitenleiste

Und damit man die Bilderausgabe auch mal an anderer Stelle unterbringt, setzen wir den Shortcode ins Text-Widget und ziehen dieses in die rechte Seitenleiste. Sieht auch sauber aus:

6_bilder_seitenleiste

Ich hab auch mal das Inhaltsverzeichnis in die Seitenleiset gepackt, das sieht dann so aus:

ivz_in_der_seitenleiste

Wie und wo die Platzierung des Shortcodes Sinn macht, hängt natürlich vom verwendeten Theme und von der Art der Ausgabe ab, aber ich denke sie haben jetzt die Möglichkeiten ein bißchen gesehen. Nur zu, viel Spaß beim rumprobieren! Es darf naturlich auch noch ein wenig am CSS geschraubt werden, ich rücke hier mal die Bilder näher zusammen (den Margin einfach rausnehmen):

6_bilder _ohne_margin

Also, viel Vergnügen beim Ausprobieren!

Bilder Ausgabe: Link zum Parent

Wir waren dabei stehengeblieben, alle Bilder aus der Mediathek auszugeben, und hatten diese Ausgabe auch hübsch formatiert. Wissen sie noch:

inner_join_ergebnis_style

Zu welchem Beitrag gehört das Bild? Zum Parent!

Jetzt wäre es natürlich noch sehr schick, wenn man von den Bildern direkt zu den zugehörigen Beiträgen und/oder Seiten gelangen könnte, nicht wahr? Auch das ist keine Hexerei, dafür verwenden wir das Feld parent_id aus der Tabelle wp_posts. Das kann 0 (Null) sein, für den Fall daß das Bild nicht zugeordnet ist, aber im Normalfall steht hier bei einem Bild einfach die ID des Datensatzes (Beitrag oder Seite), zu dem das Bild hochgeladen wurde.

Dazu holen wir uns mit get_permalink(parent_id) den Permalink zum entsprechenden Elter, basteln einen Link mit a href daraus, und fertig! Das war jetzt aber echt einfach, oder?

Feinarbeit

Wenn man ganz sauber arbeiten will, erledigt man die „elternlosen“ Bilder mit einer Erweiterung der WHERE-Klausel um ein parent_id > 0. Man könnte auch nur alle Bilder zu Beiträgen ausgeben, nicht die zu den Seiten, das läuft dann wieder mit post type like ‚post‘ und post_status like ‚publish‘ , aber das sei jedem selber überlassen.

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! 🙂

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.