Archiv der Kategorie: CSS

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

Barrierefreie Farbkontraste – ich hab da so ne Idee

Also, wie man ausrechnet ob auf einem farbigen Hintergrund eine schwarze oder weiße Schriftfarbe besser lesbar ist, das hatten wir ja gerade eben schon mal. Jetzt ist der Kunde aber König, und man kommt auch mal in die Verlegenheit, eine farbige Schrift auf farbigem Grund darstellen zu sollen. Die Anforderung könnte also heissen: es soll eine grüne Schrift auf rotem Grund ausgegeben werden, und die soll möglichst gut lesbar sein. Da kann man einen Colorpicker nehmen und so ungefähr schauen was besser lesbar ist, aber das ist ja doch bloß Trial&Error. Es gibt auch Formeln, mit denen man so etwas berechnen kann, fündig wird man z.B. beim W3C, oder auf dieser Seite von nbtech. Nach deren Algorithmus kann man die „perceived brightness“, also die wahrgenommene Helligkeit einer Farbe als Wert zwischen 0=schwarz und 255=weiß berechnen. Das ist nicht trivial, weil z.B. grüne Töne vom menschlichen Auge als heller wahrgenommen werden als rote Schattierungen. Darum berechnet man die jeweilige wahrgenommene Helligkeit, und vergleicht die Farben dahingehend. Ein Unterschied von ca. 120 zwischen den zwei Farben wird nach W3C als ausreichender Kontrast angesehen. Die Formel lautet wie folgt:

brightness = sqrt( .241 R² + .691 G² + .068 B² )

sqrt ist die Quadratwurzel, R, G, B sind unsere guten alten Bekannten Rot- Grün- und Blauanteil aus dem RGB-Farbraum, wie wir sie in HTML so gerne verwenden (ausführliche Infos hierzu z.B. hier bei W3Schools)

Gar nicht so einfach: was ist Rot, was ist Grün?

Auch das ist nicht trivial, weil von der Meinung des Betrachters abhängig. Ein dunkles Rotbraun mag für einen noch als Rot durchgehen, der nächste ordnet es schon den braunen Tönen zu. Ein sonniges Gelb kann auch als Orange gelten, und ein blaustichiges Grün als Blauton herhalten. Sowas kann man nicht berechnen, da kann man sich nur eine Krücke suchen und daran festhalten. Bei den 16,7 Mio vorhandenen RGB-Farben ist es auch ein Ding der Unmöglichkeit, überall die korrekte Farbfamilie zu bestimmen. Wir nehmen ein paar Farben weniger, das tuts als Arbeitshypothese auch.

Eine Untermenge: die benannten HTML-Farben

Ich habe da eine interessante Zusammenstellung der benannten HTML-Farben im Web gefunden. Bei https://htmlcolorcodes.com/color-names/ gibt es eine Tabelle der von allen modernen Browsern unterstützten benamsten Farben, die nach Farbfamilien (Color Groups) gruppiert ist. Auch bei w3schools gibt es eine gut gestaltete Seite über die Color Groups, nur sind sie da ein bißchen anders zusammengefaßt.

Die Seite von htmlcolorcodes.com habe ich mir mal als Arbeitsgrundlage geklemmt und in eine Datenbanktabelle gejagt. Es sollten eigentlich 140 Farben sein, auf der Seite sind aber 143 Farben aufgeführt. Die Tabelle enthält Duplikate, da werden Farben unter zwei verschiedenen Farbfamilien genannt. Ist jetzt aber nicht so schlimm, letztendlich ist die Information wertvoll, welche Farbtöne als Rot, Blau, Gelb usw. empfunden werden. Es gibt eine Liste von 10 Farbfamilien. Ich werde bei den englischen Bezeichnungen bleiben, schliesslich sind auch die HTML-Farbnamen in Englisch.

Hier mal die Liste der Farbfamilien, mit der jeweiligen Anzahl der zugeordneten Farben:

YELLOW   11
WHITE   17
RED   9
PURPLE   19
PINK   6
ORANGE   6
GREEN   23
GRAY   10
BROWN   17
BLUE   25

Wie gesagt, die Summe ist hier 143, nicht 140, aber das vernachlässigen wir jetzt mal. Dass Blue die meisten Farbtöne zugeordnet hat verwundert auch nicht weiter, da Blau nunmal eine sehr beliebte Farbe bei Webdesignern und Grafikern ist und im Web sehr häufig verwendet wird.

Wer sagt, dass das Rot ist?

Unter der Farbfamilie „Red“ sind 9 benannte Farben zu finden:

family_red

Da sieht man schon, daß die Zuordnung der einzelnen Farbtöne zu denen Farbfamilien ausgesprochen subjektiv und diskutabel ist, Lightcoral würde ich eher unter Pink einordnen. Wenn man sich die RGB-Werte dieser Farben anschaut, wird man auch nicht schlauer.

red_family_rgb

Es ist mitnichten so, dass diese Farben alle einen besonders hohen R-Anteil haben, Darkred ist zum Beispiel so ein Ausreisser mit 139 als R-Wert, dafür sind die G-und B-Werte Null. Ich hab lange rumgesucht, aber bisher keine praktikable Berechnungsmethode gefunden, mit der man x-beliebige Farbtöne einer der obengenannten Farbfamilien zuordnen kann. Deswegen verwende ich die Zuordnungen von htmlcolocodes.com, da hat man zumindest mal einen Anhaltspunkt.

Und wozu das Ganze?

Ganz einfach: mir schwebt sowas wie ein spezialisierter Colorpicker vor, in dem man eine frei wählbare Farbe vorgibt. Dann wählt man aus, aus welcher Farbfamilie die Kontrastfarbe kommen soll, und erhält einen oder mehrere Vorschläge, welche Farbtöne einen guten Kontrast bieten würden. Das als Arbeitshypothese. Mal sehen, wie weit ich damit komme.

Die Voraussetzung: eine MySQL-Tabelle mit allen 140 benannten Farben

Diese enthält die Farbfamilie, den Farbnamen, den Hex-Wert und den RGB-Wert. Die habe ich natürlich nicht per Hand eingehackt, da habe ich einen kleinen Umweg über ein Excel-Makro genommen, mehr wird nicht verraten. Die Tabelle sieht so aus, die Feldnamen sind selbsterklärend:

mysql_farbtabelle

Das wird meine Ausgangsbasis. Und ich komme mit unter 100 Zeilen Code aus. Den Source gibt es dann im nächsten Beitrag.

Joomla-Template 3: das Styling

Wir arbeiten jetzt mit unserer formate.css, die steckt im durch die erfolgreiche Template-Installation neu angelegten Verzeichnis [joomlainstallation]->templates->evis2014 im Unterverzeichnis css.

Damit das Ganze jetzt dem Vorbild TwentyFourteeen etwas ähnlicher sieht, habe ich zunächst einmal die Schriftarten angepasst und die Überschriften h1 bis h3 auf Kapitälchen gesetzt:

body {
  margin: 0;
  padding: 0;
  font-family: Helvetica;
  font-size: 14px;    
  font-weight: normal;
  line-height: 24px;
  color: #43473b;
}

h1, h2, h3, h4, h5, h6 {
  font-family: Times;
  font-weight: normal;
  color: #43473b;;
}

h1 { font-size: 45px; font-variant:small-caps;}
h2 { font-size: 30px; font-variant:small-caps;}
h3 { font-size: 22px; font-variant:small-caps;}


a { color: #43473b; }
a:hover { color: #fc737b;     }

Da ist weiter nichts dabei, das kann sich jeder selber einrichten wie er es gern hätte. Jetzt kommen unsere Inhalts-Divs dran, damit die auch schön nach unserem dreispaltigen Raster ausgerichtet werden:

#wrap {
width: 1260px;
}
    
#sidebarLeft {
padding: 20px;
float: left;
width: 200px;
}

#content {
float:left;
width:600px;
padding:20px;
}

#sidebarRight {

float: left;
width: 200px;
padding: 20px;
}

Das float: left richtet sidebarLeft, content und sidebarRight innerhalb der wrap nebeneinander aus.

Als nächstes nehme ich mir den Seitenkopf vor, da hätte ich gern unmittelbar unter dem Headerbild den Namen meiner Seite angezeigt. Das sieht in der index.php so aus:

<div id="kopf">
        <div id = "seitentitel" name ="titel">
        <?php $config = JFactory::getConfig();
        echo '<h1>'.$config->get( 'sitename' ).'</h1>';?>
        </div>

        <div id = "oben">
        <jdoc:include type="modules" name="oben" style="xhtml" />
        </div>
</div>

Ich habe das Ganze in eine eigene div namens kopf gepackt, weil es so einfacher war den farbigen Hintergrund ohne Lücken zu stylen. In der div seitentitel steckt eine Joomla-Variable, die uns den Seitentitel als h1 formatiert ausgibt, das mache ich mit der Anweisung:

<?php $config = JFactory::getConfig();
        echo '<h1>'.$config->get( 'sitename' ).'</h1>';?>

Gestylt wird die Ausgabe des Titels einfach so:

#seitentitel{
    display: inline-block;
    width: 1260px;
    height: auto;    
    }

In der div oben hatte ich im Modulmanager mein Main Menu positioniert. Damit es jetzt nicht mehr als Liste untereinander, sondern als horizontales Menü erscheint, musste ich etwas tüfteln. Ich habs schließlich so hingekriegt:

#oben ul li{
    display:inline;
    white-space: normal;
    }

Das klebte jetzt erstmal zusammen und war auch noch nicht schön formatiert, aber immerhin schon mal horizontal:

nebeneinander

Das liess sich aber schön nachbessern, mit diesen Anweisungen:

#oben ul li a
{
font-family: Times;
font-style: normal;
font-variant:small-caps;
font-size: 24px;
text-decoration: none;
padding: .2em 1em;
color: #fff;
background-color: #89a7cb;
line-height: 2
}

kam Abstand (padding) zwischen die einzelnen Menüeinträge, und die Schrift wurde schöner formatiert.

Jetzt fehlte nur noch ein einheitlicher Hintergrund:

hintergrund_unschoen

Deswegen hatte ich ja die umhüllende div kopf:

#kopf{background-color: #89a7cb}

Bingo! Fertig ist das horizontale Menü.

horizontales_menu

Und auch unsere dreiteilige Seite sieht gut aus:

fertig_gestylt

Den Footer hab ich jetzt unterschlagen, aber den brauche ich auch nicht wirklich. Ich hab noch ein bisschen an den Feineinstellunggen geschraubt, die Autor-Info aus den Beiträgen rausgenommen und die Print- und Email-Icons verborgen, aber das wars dann auch schon. Das cleane Layout sieht dem Vorbild TwentyFourteen für meine Zwecke ähnlich genug, ich lass es jetzt mal gut sein. Besonders dank des hervorragenden Tutorials von http://joomla-templates-erstellen.de war das jetzt lang nicht so schwierig, wie es sich anfangs anliess, und hat richtig Spaß gemacht.

Nachtrag zum Footer

Der hat in der index.php eine eigene div gekriegt, nach den anderen Elementen und vor dem schliessenden Tag der div wrap:

    <div id="footer">
    Ich bin dein Footer.
    <jdoc:include type="modules" name="footer" style="xhtml" />
    <!-- end #footer --></div>

<!-- end #wrap --></div>

Damit er jetzt wirklich unten erscheint und nicht auf der Seite klebt, ergänzen wir die formate.css um folgenden Eintrag:

#footer {
padding: 10px 0;
clear: both; 
background-color:#89a7cb;

}

Das clear: both macht den Unterschied! Damit werden die floatenden Elemente beendet, es erscheint der Footer dann auch wirklich erst unterhalb der anderen Inhalts-divs. Eine anschauliche Erklärung dazu findet man bei mediaevent.de.

Was wir mit Bildern können, können wir mit Posts schon lange!

Alle veröffentlichten Beiträge

Es wird wieder Zeit für ein bißchen Spaß auf der Datenbank! Wir gehen wieder zurück zu unserer zentralen Tabelle wp_posts und picken uns diesmal alle veröffentlichten Beiträge heraus. Das haben wir schonmal gemacht, bei der Ausgabe der Beitragsbilder ganz am Anfang, wissen sie noch? Der Select ist supersimpel:

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

Die könnten wir jetzt einfach mal alle ausgeben so wie sie daherkommen, nämlich einfach nacheinander aufsteigend Datum. Das sähe dann aber der Beitragsseite (nur mit umgekehrter Sortierung) verdammt ähnlich und hätte weiter keinen Närwert, deshalb geben wir die Beiträge jetzt erst mal gekürzt und in Divs gepackt als Übersicht aus. Unser foreach für diesen Zweck ist auch denkbar einfach, ich gebe fürs erste nur den Titel und den Inhalt aus:

foreach ( $alleposts as $einpost ) 
            { 
            echo "<div class = 'post_ausgabe'>";
                echo "<h1>".$einpost->post_title."</h1>";
                echo $einpost->post_content."</br>";
            echo "</div>";    
            }

Ich habe mir eine neue Klasse von Div, die post_ausgabe definiert, weil ich die Formatierung etwas anders als bei der Bilderausgabe gestalten möchte. Der CSS-Eintrag sieht so aus:

.post_ausgabe{
    
    float:left;
    height: 300px;
    width: 30%;
    overflow: hidden;
    border: 1px solid blue;
    margin: 2px;
    padding:2px;    
    
}

Wichtig ist der overflow: hidden; damit die Sache leserlich bleibt. Und die Ausgabe? Ich nehme mal wieder das Inselfisch-Kochbuch, da sind richtig schön viele Beiträge drin, und das sieht jetzt erstmal so aus:

post_ausgabe

Zugegeben, das könnte hübscher sein, aber darum kümmern wir uns später. Falls sie sich wundern, daß hier überrall „Einleitung“ als Untertitel steht: das ist völlig korrekt so, weil bei mir (fast) jedes Rezept mit einer Einleitung beginnt. Erinnern sie sich? Da war was mit der Textstrukturierung wegen der Barrierefreiheit. Deswegen kommt als erster Text im post_content das Wörtchen „Einleitung“, als h2-Überschrift formatiert. Die Ausgabe ist also völlig richtig.

Link auf den Beitrag

Jetzt fehlt natürlich der Link auf den Beitrag, den holen wir uns wieder mal mit get_permalink(ID) und machen einen a href auf die Überschrift daraus. Der foreach folgt sogleich:

foreach ( $alleposts as $einpost ) 
            { 
            $akt_link = get_permalink($einpost->ID);
            
            echo "<div class = 'post_ausgabe'>";
                echo "<a href = '".$akt_link."'><h1>".$einpost->post_title."</h1></a>";
                echo $einpost->post_content."</br>";
            echo "</div>";    
            
            }

Jetzt sitzen die Links auf den Überschriften, wo sie hingehören.

alle_posts_mit_links

Wieder das Spiel mit dem Limit und der Zufallszahl

Man kann natürlich auch hier die Anzahl der auszugebenden Beiträge limitieren, und mit Rand() eine zufällige Auswahl der Beiträge erzeugen, und man kann den ganzen Shortcode natürlich auch wieder ins Text-Widget packen und z.B. in die Seitenleiste verschieben, da kann jeder selber damit spielen.

Was noch nicht schön ist

Der abgeschnittene Text stört mich, und der -zigfache Text Einleitung. Da letzteres aber sozusagen mein Privatvergnügen ist, gibts dafür einen neuen Beitrag.

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.

Jetzt aber wirklich: CSS für die Datenbankausgabe

Die erste Div, noch ganz spartanisch

Wo waren wir stehengeblieben? Die für den Besucher uninteressanten Datenbankfelder fliegen raus, haben wir gesagt. Wir behalten nur den Beitragstitel, den Link zum Beitrag und das Beitragsbild, und packen diese in eine Div, und das sieht dann erstmal ganz spartanisch so aus:

div_ohne_class

Entsprechend spartanisch ist auch das Ergebnis, das sieht noch gar nichts gleich:

div_ohne_class_ausgabe

Das geht aber auch hübscher!

„des hamma glei“, das haben wir gleich, wie das auf bairisch heißt. Wir ordnen der Div eine CSS-Klasse zu, im öffnenden div-Tag, mit einem schönen sprechenden Namen:

echo „<div class=’div_sparta‘>“;

Mit der neuen Klasse div_sparta begeben wir uns jetzt in die style.css unseres Child Themes und tragen hier erstmal folgendes ein:

.div_sparta {
   float:left;
   heigth: 300px;
   width: 25%;
   }

Das sieht doch schon wesentlich besser aus:

div_sparta_ausgabe

Hier sieht man übrigens gleich, wo jemand geschlampert hat und das Beitragsbild fehlt! Das sind die leeren weißen Stellen.

Was haben wir gemacht?

Der wichtigste Punkt ist float: left, der teilt unserer Div mit, daß sie sich im Dokumentenfluß nach links begeben soll, damit neben ihr auch noch jemand Platz hat. Die
height kann man nach Geschmack wählen, aber die width ist noch wichtig, die hab ich mal auf 1/4 der Seitenbreite gestellt, das sind die 25%. So haben 4 Divs nebeneinander Platz. Man kann für 3 Divs nebeneinander 33,333% einstellen, für 5 Divs nebeneinander 20%, usw., da kann jeder selber rumprobieren.

Anmerkung: aus dem PHP-Code kann jetzt die width-Anwesung aus dem img src Tag raus, das Bild wird automatisch in die Div eingepaßt.

Noch mehr CSS: ich übertreibs mal ein bißchen

Ich hab jetzt mit Absicht mal ein bißchen zuviel rumgestylt, damit man mal eine Vorstellung von den Möglichkeiten bekommt. Ich habe der Div eine neue Klasse evisdiv verpaßt, die sieht so aus:

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

}

Und hier das Ergebnis:

evisdiv_ausgabe

Soll ich jetzt echt im Einzelnen erklären, was ich gemacht habe? Na schön, dies eine Mal, meine Anmerkungen in fett:

.evisdiv{
   background-color: #fc6; Hintergrundfarbe orange
   float: left; Linksbündig
   height: 330px; absolute Höhe in Pixel
   width: 20%; relative Breite in Prozent
   overflow: hidden; Zu große Bilder werden auf die Div-Umrandung zugeschnitten
   border: 1px solid blue; Rahmen blau
   border-radius: 20px; Rahmenecken abgerundet
   margin: 10px; Äusserer Abstand vom Rahmen 10 PIxel
   padding: 10px; Innerer Abstand vom Rahmen 10 Pixel
   box-shadow: 5px 5px 3px #888 Schatten

}

Falls sie sich wundern, daß bei einer width von 20 % jetzt doch nur 4 Bilder nebeneinander Platz haben: das liegt an dem margin (äusseren Abstand) den ich eingestellt habe damit die Divs nicht zusammenkleben, der wird zur Div-Größe dazugerechnet.
Ausserdem habe ich unserem post_title im PHP-Code noch ein <h1>-Tag verpaßt, damit er schön groß rauskommt wie es einem Beitragstitel gebührt, der echo sieht jetzt so aus:

echo "<h1>".$einpost->post_title."</h1>";

Das wars jetzt aber, genug geschafft für diesmal… jetzt darf jeder selber spielen. Hab ich schon gesagt, daß CSS echt Laune macht? 🙂

Frisches Styling für unsere olle Datenbankausgabe: ein wenig CSS

Kleiner Exkurs über WordPress und CSS

CSS ist für WordPress das, was ein volles Beauty&Wellnessprogramm für reifere Schönheiten bedeutet, nämlich eine Generalüberholung der angejahrten Basis, ein komplettes Facelifting, eine neue Frisur und auch noch die passenden Designerklamotten, so daß alles wieder jugendfrisch erstrahlt. Das Beste daran ist, daß man das Schönheitsprogramm noch nicht mal selbst codieren muß, dafür gibts Zillionen von großartigen Themes, man sucht sich einfach eins raus das einem zusagt, und das ganze Stylingpaket wird schon fertig mitgeliefert.

Ich halte gar nichts davon, selber groß in der style.css rumzupfuschen, man macht die Layouts damit meist nicht besser. Schließlich haben sich die Theme Designer grosse Mühe gegeben, Schriften, Farben und Seitenlayouts aufeinander abzustimmen, und wenn jetzt eine einfache Programmiererin da im Design rumpfuscht, das wird nix, das lassen wir lieber. Dann sucht man sich lieber gleich ein anderes Theme, das mehr dem eigenen Geschmack entspricht. Es spricht nichts dagegen, mal ein paar Farben anzupassen und kleine „Glitches“ (Fehlerchen) zu korrigieren. Zum Beispiel ist es mir schon in vielen Themes begegnet, daß die Umrandungen von Formularfeldern so gut wie unsichtbar sind. Da hilft dann tatsächlich nur ein mikrochirurgischer Eingriff in der style.css – aber bitte in der unseres Child Themes, nicht in der Originaldatei. Aber dabei sollte man es dann auch belassen, von Laien selbstgestylte Seiten sehen in den meisten Fällen eher peinlich und stümperhaft aus. Neenee, wir lassen der Lady WordPress ihre Designerklamotten, und konzentrieren uns auf andere Aufgaben. Zum Beispiel:

Das neue Styling unserer Datenbankausgabe

Alle alten Programmierer lieben Tabellenausgaben, aber wir verabschieden und jetzt mal von den vielen <tr><td> Tags und setzen auf eine schlichte <div>. Nur so als Erinnerung: eine div oder Division ist ein HTML-Container, der eine Reihe von Eigenschaften hat, auf der Seite positioniert werden kann und Inhalte (Text, Links, Bilder…) umschließt. Divs können beliebig geschachtelt werden, aber da sollte man ein bißchen vorsichtig sein, sonst kommt es zur berüchtigten Div-Suppe, und das Seitenlayout läuft komplett aus dem Ruder 🙂

Jetzt wird erstmal geputzt

Alle für den Programmierer so immens wichtigen Datenbankfelder wie ID, post_type, post_status und so weiter interessieren den Besucher unserer Webseiten null die Bohne und stiften nur Verwirrung, die fliegen jetzt raus. Wir behalten nur den Beitragstitel, den Link zum Beitrag und das Beitragsbild, und packen diese in eine Div, die wir nachher beliebig stylen können. Unser Select bleibt gleich, die Ausgaben in der foreach-Schleife werden deutlich verschlankt. Die Div bekommt noch eine Klasse zugewiesen, der wir einen Namen geben, an dem wir erkennen, daß die von uns selber stammt, mit der gehen wir dann in die style.css. Jetzt aber erstmal unsere geliftete Datenbankausgabe… holà, heute nicht mehr! Zeit zum Abendessen. Mehr dazu morgen, und dann gibts auch wieder Codeschnipsel, versprochen 😉