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

div_ohne_class

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

div_ohne_class_ausgabe

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

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

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

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

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

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

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!

HTML Tabelle mit Tablesorter reloaded

Ich gelobte Besserung. Ich schieb hier nochmal nach, wie unsere HTML-Tabelle aussehen muß, nämlich mit thead und tbody Tags, damit sie vom Table Sorter Plugin auch sortiert wird.

alle_posts_mit_perm_und_tablesorter

alle_posts_mit_perm_und_tablesorter

Das ist jetzt mal ein Screenshot aus dem Notepad++, meinem Lieblings-Editor für alle Zwecke. Ich denke, man kanns lesen… und da seh ich prompt schon einen Fehler, bei dem schließenden thead Tag fehlt der / (Schrägstrich). Tablesorter hats trotzdem gesorted, ich lass das jetzt mal so stehen.

Der Knackpunkt ist hier wie gesagt die Zuweisung:

echo „<table id=’meineTabelle‘ class=’tablesorter‘>“;

Damit weiß der Tablesorter, daß jetzt Action angesagt ist, und er auf diese Tabelle losgehen soll. Mehr ist nicht dabei. Wie schon gesagt, der Tablesorter bietet noch wesentlich mehr Möglichkeiten, aber da darf sich jeder selber einlesen, Doku gibts bei Tante Google.

 

 

 

Mehr Codeschnipsel?

Ich bin von meinen wohlmeinenden Erstkritikerin gefragt worden, ob ich nicht mehr Codebeispiele bringen könnte, das wäre für das allgemeine Verständnis förderlich. Da bin ich wohl wieder mal zu hastig gewesen und habe zuviel Grundwissen vorausgesetzt. Ich gelobe Besserung, und werde meine Programmschnipsel in Zukunft ausführlicher gestalten.

Aaaber…Der visuelle Editor von WordPress treibt jeden Programmierer in den schreienden Wahnsinn. Er verhackstückt jeden Code und schiebt gnadenlos Formatierungen und Zeilenumrüche rein wo man sie am wenigsten brauchen kann. Trotz Hilfsmitteln wie dem SyntaxHighlighter ist es ein eher zufälliges Spiel, ob der Code lesbar dargestellt wird oder nicht. Als Abhilfe wird einem allen Ernstes geraten, den visuellen Editor NICHT zu benutzen, und das kanns dann ja auch nicht gewesen sein. Bis mir da eine praktikablere Lösung begegnet, wirds Codeschnipsel in Zukunft als Screenshots geben, punktum. Dann kann man sie halt nicht rauskopieren, aber ich verspreche, meine Codeschnipsel werden auch in Zukunft so überschaubar bleiben, daß man sie auch mal kurz abtippen kann. Kompromiß, OK? 😉

Warum wir jetzt ein Child-Theme brauchen

Weil wir unsere Datenbankausgabe ein wenig moderner stylen möchten und dafür etwas in die style.css eintragen müssen.

Sie können das auf ihrer Testumgebung auf eigene Gefahr in der Original-style.css in ihrem Theme-Verzeichnis machen, aber ich rate ihnen ernsthaft: gewöhnen sie sich das gar nicht erst an. Zu schnell hat man mal Mist gebaut, passieren Copy&Paste Fehler, hat man versehentlich etwas gelöscht und so weiter und so fort – nee, wir lassen die Originaldatei schön da wo sie ist, basteln uns ein Child Theme und können da in unserer eigenen style.css herumfuhrwerken so lange wir lustig sind.

Was ist überhaupt ein Child-Theme?

Darüber könnte man Bände schreiben, und das haben andere Leute (fragen sie Tante Google) auch schon getan, ich machs aber hier mal so kurz wie möglich. Ein Child Theme ist eine Kopie ihres Originalthemes, liegt bei den Themes in einem eigenen Unterverzeichnis und hat mindestens eine eigene style.css und eine eigene functions.php. Wenn jetzt beim Bearbeiten einer dieser Dateien irgendwas schiefgeht, und im Worst Case ihr WordPress nicht mehr richtig funktioniert, können sie jederzeit zurückswitchen zum Parent (Original-) Theme, den Child Theme Ordner plattmachen und neu anlegen. Dann sind schlimmstenfalls ein paar Zeilen Code verloren, aber ihr Blog läuft wieder normal.

Wie legt man ein Child-Theme richtig an?

Fragen sie auch hier Tante Google, da kommen -zig Einträge. Ich finde diesen Artikel von Elmastudio sehr gelungen, aber es gibt noch viele andere, suchen sie sich was raus. Es gibt jetzt schon länger die „Best Practice“-Empfehlung, auf jeden Fall den Weg über die Einbindung in der functions.php mit den Enqueue-Anweisungen zu gehen, aber die müssen sie gar nicht en Detail verstehen (tu ich auch nicht), Copy&Paste reicht. Früher war es üblich, die style.css des Parent Theme einfach mit dem @import-Befehl einzubinden. Diese Methode ist durchaus heute noch gebräuchlich und wird meiner Erfahrung nach sogar noch von einigen Theme-Herstellern empfohlen. Machen sie es wie sie möchten – aber machen sie es. Ohne Child Theme kein Gefuhrwerke in der style.css oder in der functions.php, never, jamais, nie nicht. Und das meine ich ernst.

 

Inhaltsverzeichnis mit Links oder auch: darf ich vorstellen, der Permalink

Wozu ein Inhaltsverzeichnis?

Wieso nicht? Ich möchte schließlich meinen Lesern einen schönen Überblick über meine Beiträge liefern, in Kurzform und so ähnlich übersichtlich wie ich das im Dashboard unter „Alle Beiträge“ vorfinde.

Jaaa dafür gibt es Sitemap-Plugins, die alle Beiträge nach allen möglichen Kriterien auflisten – aber das fand ich dann doch mit Kanonen auf Spatzen geschossen. Ich brauchte für mein Inselfisch-Kochbuch eine simple Liste aller Rezepte, alphabetisch bitteschön, nach Buchstaben geordnet. Und weil ich kein Plugin gefunden habe, das genau meinen Zweck erfüllte, hab ich mir eins selber geschrieben.

Damit ich mein Publikum nicht verwirre: wir haben ja schon eine Liste aller Beiträge! Ja, aber noch nicht mit Link zum Draufklicken, der direkt zum Beitrag führt, und das machen wir jetzt. Das sieht im Inselfisch-Kochbuch life so aus: Inhaltsverzeichnis A-Z

Gestatten: der Permalink

Was ist eigentlich ein Permalink? Darüber haben die Kollegen vom Elbnetz einen hervorragenden Beitrag „Was sind eigentlich Permalinks„verfaßt, den ich ihnen zur ausführlichen Information ans Herz legen möchte. Ganz kurz und knapp gesagt, Permalinks sind aussagekräftige URLs, die sind sie wahrscheinlich von ihrem WordPress sowieso gewohnt. Wenn sie einen Beitrag in ihrem Urlaubsfotoblog anschauen und mal einen Blick in die Titelleiste ihres Browsers werfen, steht da zum Beispiel sowas wie:

meineseite.de/urlaubsbilder/2017/01/25/gardasee/

Das ist ein sogenannter „sprechender“ Permalink. Das läßt sich schön im Klartext lesen, das ist suchmaschinenfreundlich und sogar für Menschen mit Handicap im Sinne der Barrierefreiheit wunderbar zu lesen. Wie ihr WordPress diese Permalinks anlegt ist unter Einstellungen/Permalinks festgelegt, wahrscheinlich ist dort die Option „Tag und Name“ angewählt. Damit erhält jeder Beitrag so einen aussagekräftigen Permalink, und über den können wir ihn auch aufrufen. Dafür brauchen wir:

Die WordPress-Funktion get_permalink(  )

Im einfachsten Fall ruft man diese Funktion nur mit der ID des gewünschten Beitrags auf. Das sieht zum Beispiel so aus:

$perm= get_permalink( $einpost->ID );

Die Variable $perm bekommt damit den Permalink des aktuellen Beitrags, der über die ID ja eindeutig identifiziert ist. Das bauen wir in unsere foreach-Schleife mit ein, und schon haben wir die Permalinks unserer Beiträge mit in der Ausgabe! Das sieht jetzt fein aufgelistet so aus:

tabelle_mit_permalinks

tabelle_mit_permalinks

Links aus Permalinks

Jetzt brauchen wir nur noch einen <a href> um den Permalink herumzubasteln, und wir haben unseren Link zum Beitrag. Sieht im einfachsten Fall so aus:

links_in_aktion

links_in_aktion

Ist noch nicht richtig schön, aber es funktioniert, und es eröffnet jede Menge Spielmöglichkeiten!

HTML Tabellenausgabe als Beispiel

Wir waren gestern bei der Ausgabe eines Select* auf die wp_posts stehengeblieben. Wie man so etwas mit ein wenig HTML hübscher formatiert sollte eigentlich bekannt sein, aber ich zeigs hier mal als grundlegendes Beispiel ohne grosse Erklärungen.

echo "<table>";    
    
    // Titelzeile ausgeben
    echo "<tr><td>ID<td/><td>post_status</td><td>post type</td></tr>";
    
    //Eine Zeile pro Datensatz ausgeben
    foreach ( $alleposts as $einpost ) {     
        
        echo "<tr><td>".$einpost->ID."<td/>";
        echo "<td>".$einpost->post_status."</td>";
        echo "<td>".$einpost->post_type."</td>";
        echo "</tr>";
    }
echo "</table>";

Die thead und tbody Tags sind hier nicht dabei, aber die brauchen wir später noch, ich hab sie mal vorauseilend mit dazu erwähnt.
Das Ergebnis sollte jetzt in etwa so aussehen:

html_tabelle

html_tabelle

Wie die Tabelle letztendlich genau gestylt wird, hängt von ihrem Theme ab, aber wir lassen es jetzt mal bei der schlichten Darstellung, OK?

Sie können mit unserem SQL-Statement ruhig ein bißchen rumschussern, ein „ORDER BY post_title“ sortiert die Ausgabe natürlich alphabetisch nach Titel, ein „ORDER BY post_date “ nach Datum und so weiter. Es ist auch gestattet noch mehr Felder hinzuzunehmen, das geht in unserem Beispiel immer mit $einpost->’feldname‘, spielen sie hier ruhig auch ein bißchen rum. Für den besseren Überblick empfehle ich, die Titelzeile der HTML-Tabelle ebenfalls immer entsprechend anzupassen.

Und wenn sie mit ihrer Ausgabe zufrieden sind, spendiere ich ein hübsches Plugin, aber erst im nächsten Artikel.