Archiv des Autors: admin

Alle alten Programmierer lieben Listen – die erste Datenbankausgabe

Voraussetzungen

Ich gehe mal davon aus, daß sie grundsätzlich wissen wie man in PHP ein SQL Statement zusammenbaut und wie man daraus eine HTML-Ausgabe erzeugt . Ich werde mich nämlich nicht mit Step-by-Step Details aufhalten, schließlich wollen wir ja Ergebnisse sehen. Dafür wäre es sehr nützlich, wenn sie in ihrem Testblog auch richtig schön viele Beiträge hätten, und auch ein paar Seiten und jede Menge Bilder. Notfalls hacken sie halt so fuffzehn, zwanzig Beiträge ein und schieben ein paar Urlaubsfotos dazu, das geht dann schon für den Anfang. Ich greife für Demozwecke immer gern auf meine Kochrezepte im Inselfisch-Kochbuch zurück, das sind über 200 Beiträge mit etlichen Bildern, da kann man schön spielen 🙂

Was wir nicht brauchen

Ein „new pdo“ und den Connect auf die Datenbank. WordPress ist ja schon mit der Datenbank verbunden, da brauchen wir uns nicht weiter um die Verbindungsdetails zu kümmern. Auch eine Fehlerbehandlung für den Fall daß der Connect nicht hinhaut kann ausfallen, denn wenn das der Fall sein sollte wird ihnen WordPress schon melden, daß was faul ist. Dann haben sie nämlich ein größeres Problem, das jetzt mit unserem PHP-Progrämmchen eher weniger zu tun hat.

Aber ich schweife ab, ran an die Buletten, PHP Snippet editieren, jetzt wirds ernst…. ach, ich vergaß. Darf ich zunächst mal vorstellen…

Was wir unbedingt brauchen: das $wpdb-Objekt

Um die WordPress-Datenbankverbindung ohne weiteres nutzen zu können, müssen wir dem System mitteilen, daß wir gedenken jetzt über die WordPress-eigene Schnittstelle mit der Datenbank zu kommunizierren. Das hört sich tricky an, ist aber in der Realität ganz einfach. Dafür genügt ein einziges Statement:

global $wpdb;

Damit wird eine Objektvariable der Klasse wpdb als Globalvariable deklariert, und damit können wir ihre Methoden zum Datenbankzugriff in unserem Codesnippet nutzen.

Ein einfaches Beispiel

 
global $wpdb;
$alleposts = $wpdb->get_results( "SELECT * from wp_posts where post_status = 'publish' and post_type = 'post'");
  • Der SELECT ist ganz simpel, die Syntax in MySQL ist genau so wie wir sie gewohnt sind.
  • $alleposts ist einfach eine PHP-Variable, die als Auffangbehälter für das Ergebnis unseres SQL-Statements dient.
  • $wpdb->get_results ist die Methode, mit der wir unseren SELECT auf die Datenbank loslassen

Und das Ergebnis? PHP-Programmierer werden es erraten, mit einem „echo $alleposts;“ erziehlen wir die lapidare Ausgabe „Array“.

Ja, Kunststück! 🙂 Die Methode get_results liefert das Ergebnis der SQL-Abfrage, und das sind nunmal im Zweifelsfall mehrere Zeilen.  Die stecken in einem Array, und das läßt sich sehr praktisch zeilenweise ausgeben, nämlich z.B.  so:
foreach ( $alleposts as $einpost ) {
echo $einpost->ID;
echo $einpost->post_status;
echo $einpost->post_type;
echo $einpost->post_title;

}

Der foreach durchläuft einfach alle Zeilen des Arrays, das das Ergebnis unserer SQL-Abfrage enthält, und legt den Inhalt der Zeile in die Variable $einpost. Um nun an die einzelnen Datenfelder der aktuellen Zeile heranzukommen, benutzt man schlicht die Feldnamen der Tabelle. Da wir einen Select* verwendet haben könnte man hier natürlich auch noch wesentlich mehr Felder ausgeben, $einpost->post_author etwa, oder auch $einpost->post_content, aber das wird für den Anfang zu unübersichtlich. So, jetzt nochmal im Ganzen, damit der Zusammenhang noch klarer wird:

global $wpdb;
$alleposts = $wpdb->get_results( "SELECT * from wp_posts where post_status = 'publish' and post_type = 'post'");

foreach ( $alleposts as $einpost ) {
 echo $einpost->ID;
 echo $einpost->post_status;
 echo $einpost->post_type;
 echo $einpost->post_title."<br>";
}

Und, wie siehts aus? Nicht schön, ich gebs zu, aber die Sache hat Potential, müssen sie doch zugeben!

alle_beitraege_unformatiert

alle_beitraege_unformatiert

Hör ich da bei den alten Hasen die Zahnrädchen klingeln und rattern?  Liste aller Beiträge, mit ID und Titel, und da könnte man ja noch andere Felder mit dazunehmen und alphabetisch oder sonstwie sortieren… haargenau! Alles was die Liste noch braucht ist ein bißchen HTML-Zuckerguß, aber darum kümmern wir uns morgen. Nehmen sie ruhig mal das $wpdb-Objekt mit in den Feierabend, das wird nämlich unser bester Freund!

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

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

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:

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

hallowelt

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

snippet1

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

testseite

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

hallowelt_ausgabe

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

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

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!

Das WordPress-Datenbankmodell – wie kommt man ran?

Wir basteln uns eine Testumgebung

Um an das WordPress-Datenbankmodell überhaupt ranzukommen, sollte man sich mit phpmyadmin ein bißchen auskennen. Dafür ist es allerdings notwendig, sich bei seinem Provider in die Datenbankverwaltung einzuklinken, und davon rate ich für unerfahrenere Benutzer dringend ab. Auch für den erfahreneren Programmierer ist es ein wenig fahrlässig, auf den Echtdaten herumzufuhrwerken. Investieren sie lieber die berühmten fünf Minuten und installieren sie sich erstmal eine WordPress-Instanz rein zum Testen, am besten in einer eigenen Datenbank, die ebenfalls nur zum Testen verwendet wird. Normalerweise können sie bei ihrem Provider mehrere Datenbanken anlegen, das sollte eigentlich kein Problem sein.

Die ideale Test-Lösung: ein lokaler Webserver

Schöner und sicherer ist natürlich eine lokale WordPress-Testumgebung, die gar nicht ins Internet hinausgestellt wird. Ich verwende seit vielen Jahren Xampp mit Apache als lokalen  Web- und MySQL-Server, und hatte noch nie Kompatibilitätsprobleme oder sonstige Schwierigkeiten  damit.

Googlen sie für die Einrichtung mal nach „xampp wordpress“, da ist nicht viel dabei. Damit ist es überhaupt kein Problem, sich auf dem eigenen PC eine lokale Testumgebung mit WordPress einzurichten, die sie im Notfall (zuviel Pfusch auf der Datenbank gebaut ;)) einfach plattmachen und neu aufziehen können.

Suchen sie sich ein Theme aus, schreiben sie ein paar Beiträge, laden sie einige Fotos hoch, legen sie ein paar Seiten an. Und dann kanns losgehen. Rufen sie phpmyadmin auf, und wir werfen mal einen ersten Blick auf die WordPress-Tabellen, im nächsten Artikel.

WordPress – oben hui

Der Ursprung: Blogs für alle

WordPress wurde ursprünglich dafür entwickelt, die Gestaltung eines ansehnlichen und funktionalen persönlichen Blogs auch für Anwender mit wenig oder keinen Programmierkenntnissen zu ermöglichen.  Das sieht man auch heute noch an dem zentralen Fokus auf die Beitragsseiten, da steckt noch viel Historie mit drin. WordPress wird allerdings heutzutage weit über das ursprüngliche Konzept hinaus als CMS verwendet, aber dazu später mehr.

WordPress als Front End Designer- da gibts nicht viel zu meckern

Eins muß man dem mittlerweile auch schon alten Mädchen WordPress lassen: das Front End Design ist dank unzähliger Themes für jeden denkbaren Zweck einfach genial und genial einfach einzurichten. Wenn man die berühmte Fünf-Minuten-Installation geschafft hat, nur noch ein passendes Theme auswählen und loslegen – aussehen tut das Ergebnis immer gut. Seiten und Beiträge lassen sich wirklich anwenderfreundlich verwalten, auch eine ansehnliche Menüstruktur ist kein Problem, der Anwender muß sich wirklich nur um die Inhalte kümmern und sich weder mit PHP-Code noch mit der Datenbank herumschlagen.

Und wenns doch nicht reicht – für jeden Zweck das passende Plugin?

Die Anzahl der WordPress-Plugins muß heutzutage in die Millionen gehen, es gibt Plugins für jeden nur denkbaren Zweck, die meisten davon kostenlos. Ich will hier gar nicht ins Detail gehen, sonst sitze ich nächste Woche noch an diesem Artikel, es seien nur ein paar Stichworte genannt. Ob Onlineshop, Portfolio-Präsentation, Bildergalerie, Buchungssystem, Diskussionsforum, Firmenpräsenz, Tauschbörse, Hobbyseite oder noch vieles, vieles mehr, alle möglichen Arten von Webseiten lassen sich mit Hilfe von freien Plugins oder auch kostenpflichtigen WordPress-Erweiterungen realisieren.  Eins muß man aber mal ganz deutlich sagen: mit der Auswahl eines für seine Zwecke geeigneten Plugins ist der Endanwender fast immer überfordert. Es gibt zwar -zig Seiten zu  Themen wie:
Die 10 besten Plugins für XYZ (setzen sie hier einen beliebigen Zweck ein) mit WordPress
Aber gerade für professionelle und geschäftliche WordPress-Seiten kommt man kaum darum herum, Fachleute zu Rate zu ziehen. Davon lebt eine ganze Branche von WordPress-Agenturen sehr gut, die lassen sich ihre Arbeit natürlich gut bezahlen.

Ist WordPress also doch die eierlegende Wollmilchsau fürs Internet?

Sieht ganz so aus – in den letzten Jahren wurden insbesondere in Richtung CMS gewaltige Fortschritte erzielt. Ich empfehle hier den sehr informativen Artikel von Christian Strang „WordPress als CMS“ auf wordpress.lernenhoch2.de , hier finden sie geballte Informationen zum Thema.

Und wenn sie sich da durchgelesen haben, gehen wir mal daran, WordPress ein bißchen besser kennenzulernen – aus Sicht einer alten Datenbankprogrammiererin. Aber das wird ein neuer Artikel.

SQL – die vergessene Kunst?

Die dolle Olle – Structured Query Language

Meine zweite große Liebe auf dem Computer, ich hab es schon erwähnt, waren relationale Datenbanken und SQL. Die geniale Structured Query Language wurde an den Universitäten sehr gepflegt, schließlich ist sie ja auch von Wissenschaftlern für Wissenschaftler erdacht worden. Der ursprüngliche Zweck von SQL war ja die digitale Auswertung von Massendaten. Soweit ich weiß waren die Verhaltensforscher die ersten, die mit Hilfe von strukturierten Datenbanken wissenschaftlich fundierte Forschungsergebnisse erzielten. Mehr über die Geschichte und die Grundlagen von SQL kann man hier bei Wiki nachlesen, das ist spannend und gilt alles auch heute noch.

Ach so, und was hat das mit WordPress zu tun? Gemach, gemach.  Ohne MySQL kein WordPress. Mehr dazu (viel mehr!) später.

SQL ist SQL geblieben

Ich jedenfalls habe SQL damals an der Uni sozusagen mit der Muttermilch aufgesogen und habe früh erkannt, welcher Power und welche Vielseitigkeit im relationalen Datenbankmodell steckt. So kam es, daß ich als studierte Biologin in der EDV gelandet bin – und dort echt Karriere gemacht habe. SQL hat sich bis heute kaum verändert. Wer die Grundlagen einmal begriffen hat, dem ist es egal ob er es nun mit Oracle, Access oder SQL Server, MySQL oder sonst einem Dialekt zu tun hat. Einen Select, einen Join oder eine Where-Klausel schreibt man heute noch genauso wie vor 40 Jahren, da ist nicht viel passiert – wozu auch. Die alten SQL-Konzepte sind so gut, da ist nie etwas Besseres nachgekommen.

Datennormalisierung – wer kennt das heute noch?

Was allerdings heute in Vergessenheit geraten scheint, ist die grundlegende Strukturierung der Daten. In SQL-Datenbanken landet heutzutage häufig unkontrolliertes Datenmus, es ist eben zu einfach, irrsinnige Mengen an Daten automatisiert abzuschöpfen. Als Programmierer sitzt man dann zu oft vor einer ungenießbaren Datensuppe, aus der man eine strukturelle Logik erst mühsam herausfieseln muß, ehe man zu vernünftigen Abfrageergebnissen kommt. Dabei könnt’s so einfach sein – wenn sich heute noch jemand die Mühe machen würde, die grundlegenden Tabellen zu Normalisieren und eine vernünftige Struktur hineinzubringen.

Gottseidank gibts Datensuppe – und (noch) keine gläsernen Bürger

Ich bin eigentlich ganz froh, daß die heutzutage erhobenen Datenmengen so schlecht strukturiert sind. Wenn da mal jemand vernünftig aufräumen würde, wären wir ganz schnell beim gläsernen Bürger. Überlegen sie nur mal, was herauskäme, wenn all ihre Bank- und Behördendaten, ihre Handy- und Internetprofile, ihre Krankenkassendaten und was weiß ich noch alles sauber durchstrukturiert und per SQL ganz easy abfragbar wären. Dann hätten wir sie, Huxley’s Schöne Neue Welt – und ich bin heilfroh, daß es nicht so ist.

Unfreiwilliger Schutz vor der totalen Überwachung

Die irrsinnigen Mengen an Datenschrott, die heutzutage über jeden von uns in irgendwelchen Computern gespeichert sind, sollen bitte so unübersichtlich und unauswertbar bleiben, wie sie sind, das ist unser bester Schutz vor der totalen Digitalisierung, die mit den heutigen technischen Mitteln theoretisch schon möglich wäre. Praktisch umsetzbar ist sie (noch) nicht, weil bei der Unzahl an unterschiedlichen Systemen und labyrinthischen gewachsenen Strukturen keiner mehr durchblickt, und das soll bitteschön so bleiben. Daten-Müllhalden als Schutz vor der totalen Überwachung?

Besser als nix, wenn sie mich fragen. Lieber ärgere ich mich noch lange Jahre z.B. mit Behörden oder Versicherungen rum, weil die anscheinend keine Daten speichern (oder sie nicht wiederfinden) und man bei jedem kleinen Antrag alles noch mal von vorn ausfüllen muß. Ist für mich als Bürger etwas unbequem, aber ehrlich: wenn die alle auf Knopfdruck meine sämtlichen Daten da hätten, würde mir mulmig. Da sei St.Murphy vor, er bewahre uns bitte das behördliche Datenchaos. Amen! 😉

Über mich – ich komme aus der Computer-Steinzeit

Eine nicht ganz so kurze Vorstellung

Gestatten, daß ich meine digitale Historie  vorstelle? Nachdem ich schon sehr lange im Geschäft bin, geht das nicht in drei Worten, aber ich werde versuchen, mich kurz zu fassen.  Sie müssen auch nicht alles lesen, aber andererseits weiß man doch ganz gern, mit wem man es zu tun hat, daher erzähle ich mal ein bißchen was von meinen „Roots“ und ein wenig Computergeschichte. WordPress kommt hier erstmal gar nicht vor, das gibts ja erst seit 2004. Aber Datenbanken gabs damals schon…

Ich bin Fachinformatikerin für Anwendungsentwicklung und seit Anfang der 80er Jahre im IT-Gewerbe tätig. Ich bin auch Datenbankprogrammiererin der ersten Stunde, das fing so ca. 1980 mit Superbase auf dem Commodore C64 an. Damals habe ich an der Uni jeden greifbaren Kurs und jedes Seminar belegt, das irgendwie mit Computern zu tun hatte, und mit Begeisterung bald die ersten Projekte umgesetzt. Meine allererste Datenbank enthielt meine Kochrezepte, dieses Hobby pflege ich auch heute noch digital, schauen sie mal rein ins Inselfisch-Kochbuch.

Die ersten PCs und dBase

Die zweite Datenbank war dann schon etwas ernsthafter gestrickt, da habe ich ein Verwaltungsprogramm für eine mittelgroße Taxifirma mit dBase auf DOS programmiert. Das waren die Zeiten, als es noch Computer ohne Festplatten gab, und Floppy Disks noch floppten – Disk1 fürs Betriebssystem, Disk2 fürs Anwendungsprogramm, und immer schön aufpassen daß der RAM nicht volläuft…. aber ich schweife ab, das sind Relikte aus der Steinzeit, als IT noch EDV hieß.

Informatik studieren? Gabs damals nur als Nebenfach

Einen Studiengang Informatik gab es damals leider noch nicht (den hätte ich sofort genommen!), es wurden allerdings an sämtlichen naturwissenschaftlichen Fakultäten Computerkurse angeboten. Viel noch am Großrechner, weil Standalone-PCs damals noch unmöglich teuer waren, und die Mainframes eh an den Unis rumstanden. Ich entsinne mich an meinen ersten Programmierkurs „Standard Pascal unter Unix“, da ging die Eingabe noch über Lochkarten, und die Programm-Ausgaben erfolgten an Deckwriter-Terminals. Nix Monitore! Das kann man sich heute gar nicht mehr vorstellen, aber es hat funktioniert.

Grundlagen in strukturierter Programmierung

Vielleicht hat es mich nachhaltig geprägt, daß meine erste Programmiersprache nicht BASIC-Spaghetti war, sondern das streng strukturierte prozedurale Pascal. Was ich damals über Variable und Konstanten, über if..then..else, über do…while, Gültigkeitsbereiche von Variablen, Funktions- und Prozeduraufrufe und all diese klassischen Programmierkonstrukte aufgesaugt habe, hat mich mein ganzes Programmiererleben lang begleitet und ganz ehrlich: so viel hat sich bis heute nicht geändert . Wenn ich meine Sourcecodes von damals noch hätte, ich wette, die würde ich ohne große Änderungen auch unter PHP, Javascript oder VBA zum Laufen kriegen!

Meine zweite große Computerliebe war SQL, aber das, finde ich, verdient einen eigenen Artikel.

Für wen ist dieser Blog gedacht?

Ist ernstgemeint: für alte Programmierer. Das ist jetzt nicht unbedingt für Tattergreise gedacht, sondern für technisch interessierte Leute, die schon ein paar Jahre Erfahrung in der IT auf dem Buckel haben. Dazu zähle ich auch ausdrücklich die alten Hobby-Programmierer, denn von denen gibt es viele sehr gute da draussen, die womöglich ihre erste Datenbank noch anno Dunnerkeil mit dBase geschrieben haben und die sich mit Excel, Word und Access schon unter DOS auskannten.

Also für Dinosaurier?  Ausdrücklich JA! Ich liebe Dinos, vermutlich weil ich selber mittlerweile einer bin 😉

Und mit diesen Dinosauriern möchte ich mich gerne über WordPress unterhalten, die erfolgreichste Blog-Software aller Zeiten. Ich selber nutze Wordpess seit einigen Jahren als Frontend für die Erstellung kleiner und mittlerer Webseiten, und bin eigentlich ein begeisterter Fan,  es ist so schön einfach zu bedienen, es ermöglicht auf einfachste Weise wunderbare Layouts und ist unendlich erweiterbar.

Warum „eigentlich“ ein Fan?

Weil ich nicht alles an WordPress gut finde.  Es gibt auch Sachen, die mich echt nerven, oder wo ich nicht verstehe warum man Dinge unnötig kompliziert macht. Ich möchte hier aber keinesfalls verbiesterte Kritik üben, mir geht es um eine eher lockere, ich würde fast sagen spielerische Herangehensweise, denn WordPress kann auch richtig Spaß machen.

Was ich voraussetze

Einige allgemeine Grundlagen der Programmierung (Sie sollten schon wissen wie man ein if..then..else und sowas konstruiert), solide SQL-Grundkenntnisse und ein allgemeines Verständnis des relationalen Datenbankmodells, dazu noch für den optischen Zuckerguß Erfahrung mit HTML und CSS, und ein bißchen PHP und MySQL kann auch nichts schaden. Und natürlich zumindest erste Erfahrungen mit WordPress, wenigstens ihre Urlaubsfotos sollen sie schonmal damit veröffentlich haben 😉

Was  ich nicht machen werde

Ich werde hier keine Sammlung von fix und fertigen Code Snippets zum Rauskopieren aufstellen, dafür fehlt mir einfach die Geduld. Einige beispielhafte Codeschnipsel hier und da müssen genügen, sie können ja selber tippen, und alte Programmierer lassen sich von verschachtelten Klammerungen und der allgemeinen Gänsefüßchenwut nicht abschrecken. Mir geht es darum, daß sie meine Codebeispiele nach vollziehen können, weil sie sie verstanden haben. Hier wird es also keinen  Copy&Paste-Laden geben, sondern eher eine lockere Plauderei über Konzepte mit eingestreuten Programmierbeispielen, die sie selber ausbauen und aufhübschen können. Sie werden sehen, wir werden jede Menge Spaß damit haben!

Ein wirklich nützliches Plugin: der Tablesorter

Ich kenn das bei den alten Programmierhasen, wenn die eine Tabelle sehen kriegen sie dieses Glitzern in den Augen und wollen sie unbedingt nach den verschiedensten Kriterien sortieren, nach Namen und IDs und Datum und was weiß ich noch alles… gemach, gemach. Nicht gleich mit PHP loslegen, das geht heutzutage auch bequemer. Wir holen uns dafür das Plugin Table Sorter an Bord, das beruht auf dem bekannten jQuery Tablesorter 2.0 von Christian Bach und ist sehr einfach in der Anwendung. Es kann zwar ohne Erweiterung kein deutsches Datumsformat, aber das soll uns erstmal nicht stören, in der wp_posts ist kein „German“ Datum drin.

Erste Voraussetzung: die Tabelle muß sauber mit thead und tbody-Tags strukturiert sein, deswegen meine Vorbemerkung aus dem letzten Beitrag. Wenn dann das Plugin installiert ist, genügt eine einfache Erweiterung im <table>-Tag, das schreibt sich so:

<table id='meineTabelle' class='tablesorter'>

Statt ‚meineTabelle‘ können sie einen beliebigen Tabellennamen angeben, er sollte halt innerhalb einer Seite eindeutig sein. Die Zuweisung der class = ‚tablesorter‘ sorgt dafür, daß sich das Plugin einschaltet. Wenn sie jetzt ihre Testseite mit der Tabellenausgabe neu laden, sollte es etwa so aussehen:

tablesorter

tablesorter

Und wenn sie auf die Pfeilchen in der Kopfzeile der Tabelle klicken, werden die Datensätze hübsch nach dieser Spalte sortiert – schick, nicht wahr? Der Tablesorter kann übrigens noch viel mehr, aber das sprengt hier komplett den Rahmen. Selber nachlesen auf der Plugin-Seite , oder auch direkt bei Christian Bach.

Das Sortieren zieht natürlich erst so richtig, wenn man es mit vielen unterschiedlichen Datensätzen zu tun hat, und wir waren ja bei der Abfrage einer Handvoll veröffentlichter Beiträge stehengeblieben. Lassen sie mal die Where-Klausel weg und schauen sie sich alle Einträge in der wp_posts mit dem Table Sorter an, das ist sehr aufschlußreich und erspart einem das SQL-Tippen im phpmyadmin. Konnte ich das Glitzern in den Augen der alten Tabellenhasen befriedigen? Das Potential des Tablesorter ist enorm, das müssen sie zugeben, der ist ungeheuer vielseitig einsetzbar und erspart einem im Zweifelsfall viele Zeilen PHP-Code.