Archiv der Kategorie: MySQL

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

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..

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.

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

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.

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

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.

Das erste Plugin: PHP Code for Posts

Meine erste Wahl

Ich hab lang überlegt, welches der Zillionen Plugins für WordPress ich als erstes vorstelle, aber irgendwie ist mir die Auswahl am Ende dann nicht besonders schwer gefallen. Als alter Programmierer will man halt auch was programmieren, nicht bloß Plugins zusammenkleistern. Und die einfachste Möglichkeit, WordPress eigenen PHP-Code unterzujubeln geht über dieses (oder ein Ähnliches) Plugin. Ich hätte auch zuerst erklären können, wie man einen Shortcode anlegt oder wie man ein eigenes Plugin schreibt, aber ich geh gern den einfachsten Weg, und PHP Code for Posts ist so schön straight, das wärmt mein altes Programmiererherz richtig. KISS – keep it short and simple, so nannten wir das früher immer.

Installieren

Also, ran an die Plugin-Installation (ich gehe davon aus daß das nichts Unbekanntes ist), suchen nach „PHP Code for Posts“ und das geniale kleine Plugin von Jamie Fraser installieren und gleich aktivieren.

screenshot_phpcodeforposts

Hier kommt noch der Link zur offiziellen Plugin-Seite, der Vollständigkeit halber.

Nach der Installation haben sie am unteren Ende des Admin Menüs einen neuen Eintrag „PHP Code“, das wird jetzt unser Arbeitspferd.

adminmenu_phpcode

Das erste Code-Snippet: Hallo Welt! – was sonst?

Ich erkläre das jetzt dieses eine Mal etwas genauer, schließlich wird PHP Code for Posts jetzt unsere wichtigste Arbeitsgrundlage, das soll schon funktionieren. Eigentlich ist es ja selbsterklärend… aaaber ich will ja auch die Anfänger und Hobbyprogrammierer hier mitziehen, also, los gehts:

Den Menüpunkt PHP Code anwählen, den blauen Button „New Snippet“ anklicken.
Einen Namen für das Code Snippet und eine kurze Beschreibung eingeben
Da wo steht „CODE HERE“ die berühmte Hallo-Welt-Zeile eintragen.

hallowelt

Jetzt noch „Save Code Snippet“ nicht vergessen, und sie kriegen oben den Shortcode für das Snippet angezeigt.

snippet1

Den Shortcode kopieren sie sich, inklusive der eckigen Klammern.

Jetzt brauchen wir noch eine Testseite, also Neu/Seite, und die betiteln wir mal mit einem schönen Namen, z. B. „Testseite“ 🙂 und fügen den Shortcode ein.

testseite

Seite veröffentlichen, angucken und Voila! Unser erstes PHP Snippet für WordPress ist gelungen!

hallowelt_ausgabe

Wie, mehr nicht? Gemach, gemach. Wir haben ja auch nur eine einzige echo-Anweisung programmiert, und genau das macht unser Code Snippet, eine simple Textausgabe. Sie können aber in PHP Code Snippets jeden beliebigen PHP Code eingeben, und der wird treu und brav ausgeführt – alles, aber wirklich alles ! Auch SQL-Statements mit DELETE oder UPDATE auf der Datenbank, dabei ist also ein bißchen Vorsicht geboten. Unser Arbeitspferd steht bereit und aufgezäumt da, jetzt kanns losgehen.

Kleiner Tipp am Rande

Ich mache mir immer zwei Browserfenster auf, in einem lasse ich das PHP Code Editfenster anzeigen, im zweiten mache ich meine Beispielseite auf. Code ändern, Save Code Snippet nicht vergessen, auf die Beispielseite gehen und einmal F5 drücken, und sie sehen sofort was ihr geänderter Code macht. Meistens hab ich noch ein drittes Fenster mit dem phpmyadmin offen, da guckt man mal schnell auf die Datenbank, ob die Abfrageergebnisse auch plausibel sind.

Alles klar? Bereit für ein bißchen PHP auf der Datenbank? Gut, im nächsten Beitrag starten wir durch.

Jetzt gehts endlich los: die zentrale WordPress-Tabelle wp_posts

Ein erster Blick mit phpmyadmin

Also, die Testinstallation steht ja jetzt, wir können einen freien Blick mit phpmyadmin auf die WordPress-Tabellen werfen. Das sind nicht uferlos viele, eine jungfräuliche WordPress-Instanz kommmt mit nur 12 Tabellen aus. Das können später je nach installierten Plugins noch viel mehr werden, aber wir konzentrieren uns hier mal auf die Grundlagen.

Anmerkung:

Wer es ganz genau wissen will: im WordPress-Codex sind die verschiedenen Tabellen natürlich genau beschrieben, ein Übersichtsdiagramm gibt es auch. Schaut mal in der Database Description, da kann man alles genauestens nachlesen. Ich mach hier trotzdem mal mit meiner vereinfachenden Erklärung weiter, der Codex ist für WordPress-Beginner doch ein wenig starker Tobak 😉

12_tabellen

Und wo sind die Beiträge?

Uns interessiert zunächst mal nur eine Tabelle, die nämlich, die unsere Beiträge enthält, denn die sind ja das Leben und die Seele unseres Blogs. Wenn sie bei der Installation kein anderes als das Standard-Datenbankpräfix gewählt haben, heißt diese Tabelle wp_posts, und ich werde sie auch in Zukunft immer so anreden, damit es keine Verwechslung mit nicht-Wordpress-Tabellen gibt. Vielleicht heißt sie bei ihnen auch xyz_posts oder meinedatenbank_posts, das kommt wie gesagt auf ihr Präfix an, das haben sie selber zu verantworten 😉

Inhalt der Tabelle wp_posts

In der wp_posts also stecken alle Ihre Beiträge, und wenn man sich die Tabelle im phpmyadmin mal näher anschaut, fällt zuerst auf, daß es jetzt schon wesentlich mehr Datensätze als Blogbeiträge gibt. In der wp_posts werden nämlich auch noch andere Objekte gespeichert, die von ihnen bereits erstellten Seiten zum Beispiel, und auch alle Bilder, die sie schon hochgeladen haben, aber dazu später mehr. Hörte ich da ein erstes leises Aufjaulen der alten Datenbankhasen – was haben die Beiträge und die Bilder in ein und derselben Tabelle zu suchen, wo bleibt da die Entity-Relationship? Gemach, gemach. Dazu später mehr. Nehmen sie es jetzt einfach so hin, die jungen Kollegen haben sich schon etwas dabei gedacht, so unterschiedliche Objekte in ein und dieselbe MySQL-Tabelle zu stecken. Aber ich schweife ab, zu dem Thema später mehr.

Datenfelder der Tabelle wp_posts

Die wp_posts hat 23 Datenfelder, und die meisten davon haben selbsterklärende Namen, da gibt’s nicht viel zu rätseln.

wp_posts_23_felder

Die Felder post_author, post_date, post_content, post_title usw. sind auch für Nicht-Wordpress-Experten recht selbsterklärend, man übersetzt einfach frei heraus (Beitrags-) Author, Datum, Inhalt und Titel, und da haben wir doch schon die Grundlagen zu einigen hübschen Spielereien auf der Datenbank. Auch den post_type und den post_status nehmen wir noch mit, die helfen uns beim aufdröseln, um was für eine Art von Datensatz es sich handelt. Bei einem veröffentlichten Beitrag beispielsweise ist hat der post_type den Wert „post“ und der post_status den Wert „publish“, das ist ja auch nicht unlogisch. Bei einer statischen Seite hat der post_type den Wert „page“… ooch da gäbs noch viel dazu zu sagen, aber ich will hier jetzt am Anfang noch nicht so viel Verwirrung stiften.

Wir nehmen also unsere paar selbsterklärenden Datenbankfelder und stricken uns eine Abfrage oder zwei. Aber das machen wir nicht im phpmyadmin, das ist ja unsportlich, schließlich gehts hier um WordPress. Und wir möchten unsere tollen Abfrageergebnisse ja auch in unserem Blog veröffentlichen, nicht wahr? Aber dazu gibts einen neuen Beitrag!

Zum schwarzen Pinguin

IT nach Feierabend