Archiv für den Monat: Februar 2017

Bilder: jetzt tragen wir mal alle Informationen zusammen

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

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

Bildinformationen in der Tabelle post_meta

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

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

Bildinformationen in der Tabelle WP Posts

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

mediathek_felder

Wo findet man was in den Tabellen wieder?

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

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

Noch ’ne Runde über Attachments, speziell Bilder

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

Nur mal so zur Erinnerung: Bildattribute in HTML

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

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

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

Bildattribute in WordPress

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

Warum gibt es keine eigene Tabelle für Attachments?

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

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

Und wenn ich jetzt einfach alle alt-Texte korrigiere?

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

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

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

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

SELECT * from wp_posts

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

Was ist ein Datenbankpräfix?

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

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

SELECT * from $wpdb->prefix.posts

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

Fußnote

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

Mea culpa: warum dieser Blog alles andere als barrierefrei ist

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

Mein Pilotprojekt

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

Böse Sünde: Codeschnipsel als Screenshots

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

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

Und was hat das alles mit WordPress zu tun?

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

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

Kleiner Exkurs über Attachments

Was genau ist ein Attachment?

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

Die gängigsten Bild-Typen

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

Über Bildformate

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

beeren-sahne-torte-150×150

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

beeren-sahne-torte

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

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 😉

Beitragsbild in unserer Tabelle mit ausgeben

Nachdem wir jetzt ja erschöpfend geklärt haben, was ein Beitragsbild eigentlich ist, gehts jetzt an die spaßige Seite, nämlich die Ausgabe der Beitragsbilder in unserer eigenen Datenbankabfrage. Wir haben immer noch den selben alten Select:

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

Und wir haben immer noch die selbe foreach-Schleife mit der Formatierung als HTML-Tabelle. Jetzt geht es ein bißchen von hinten durch die Brust ins Auge weiter.

2 WordPress-Funktionen für Beitragsbilder

Wir holen uns zuerst über die ID des aktuellen Beitrags die ID des Beitragsbilds=Thumbnails, das geht mit der WordPress-eigenen Funktion get_post_thumbnail_id(), und zwar machen wir das so:

get_post_thumbnail_id($einpost->ID)

(Kleine Erinnerung: genauere Details zu den WordPress-Funktionen im Codex nachschauen!)
Mit der Thumbnail-ID holen wir uns mit der Funktion wp_get_attachment_url() die URL des Beitragsbildes:

wp_get_attachment_url(get_post_thumbnail_id($einpost->ID))

Ich liebe diese sprechenden Funktionsnamen! 🙂
Das Ganze legen wir dann noch auf eine Variable, und dann sieht die neue Zeile in unserer foreach-Schleife so aus:

$artikelbild_url = wp_get_attachment_url(get_post_thumbnail_id($einpost->ID));

Sie können sich ja spaßeshalber erstmal die Variable $artikelbild_url so wie sie ist mit echo ausgeben, oder wir packen das Ergebnis der ganzen Prozedur gleich in einen img-Tag. Ich hab versprochen, mehr Codeschnipsel, also bitte, nochmal die komplette foreach-Schleife:

thumbnail_url_holen

Und? Rumms, da kommen doch die Bilder gleich in voller Größe auf den Bildschirm gerauscht, das ist jetzt genauso häßlich wie im Theme Twenty Fourteen. Abhilfe schafft eine width-Angabe im img-Tag:

echo „<td><img src ='“.$artikelbild_url.“‚width = ‚100px‘></td>“;

Statt 100px können sie natürlich einen beliebigen Wert eingeben, aber ich wollte ungefähr Paßfotogröße, das sieht bei mir jetzt so aus:

passfotos

Schon deutlich hübscher, nicht wahr? Und jetzt wollen wir mal die ganzen inzwischen überflüssigen Felder wie ID usw. ausblenden und der Sache per CSS ein pfiffigeres Styling verpassen, aber dazu gibt es einen neuen Beitrag.

Beitragsbilder Ausgabe Beispiel

Na, haben sie ein paar Beitragsbilder eingefügt? Ja? Und was sehen sie jetzt? Gar nichts?

Tscha, das kommt auf ihr Theme an. Meistens werden die Beitragsbilder auf der Beitragsseite in der Übersicht ausgegeben, und selbst das nicht immer schön. Beim Twenty Fourteen zum Beispiel sieht das schrecklich aus:

beitragsbild_twenty_fourteen

Das Bild ist viel zu groß, blöd zentriert so daß es gegen den Beitragstitel verschoben aussieht, und die schraffierten Flächen links und rechts sind auch nicht gerade schön. Die kommen übrigens daher, daß meine Beitragsbilder in diesem Beispiel sehr klein sind, da wird einfach der Rest der Seitenbreite ausgefüllt. Bei einem größerformatigen Foto siehts auch nicht viel besser aus, das nimmt halt dann die ganze Breite ein:

beitragsbild_twenty_fourteen_gross

Das dient jetzt nicht wirklich der Übersicht und ist auch nicht richtig schön, finde ich. Ja, was nun? Wir holen jetzt erstmal die Beitragsbilder in unseren Codeschnipsel, aber dafür gibts einen neuen Beitrag.

Beitragsbild oder Bild zum Beitrag?

Bilder sind die Seele eines echten Blogs!

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

Was genau sind Beitragsbilder?

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

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

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

Anmerkung:

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

Zum schwarzen Pinguin

IT nach Feierabend