Archiv der Kategorie: Plauderei

WordPress als führendes System für die Mitgliederverwaltung? Ein Fazit

Ich habe mich jetzt in etlichen Beiträgen mit dem CSV-Import eigener Daten für eine Mitgliederverwaltung in WordPress herumgeschlagen, da wird es Zeit, ein Resumee zu ziehen.

Ist die Lösung mit dem CSV-Import praxistauglich?

Zur Erinnerung: ich habe mich dafür entschieden, immer die komplette CSV-Datei zu importieren, und einen Select vorzuschalten, der bereits vorhandene Datensätze (kenntlich an der eindeutigen ID/Mitgliedsnummer) unberührt stehenläßt.

Das kann man wirklich so machen, da im WordPress-Beitragseditor vorgenommene Änderungen an Mitgliederdaten so erhalten bleiben. Man muß halt nur konsequent sein, und eventuelle Änderungen von Adress- oder sonstigen Daten wirklich in WordPress einpflegen und nicht in der Excel-Liste, die ja nach wie vor weitergeführt wird.

Was nicht so schön ist: die Vergabe einer neuen Mitgliedsnummer muß in der Excel-Liste manuell erfolgen. Man könnte zwar auf die Idee kommen, die beim Anlegen eines Beitrags erzeugte WordPress-ID aus der Tabelle wp_posts als Mitgliedsnummer zu verwenden. Aber das ist ziemlich unbefriedigend, weil WordPress ja allen möglichen Ruß in der wp_posts speichert, Bilder und andere Attachments und Seiten und und und….

In der Praxis wird man hier früher oder später von der Excel-Liste auf eine separate Datenbanktabelle umstellen, sei es nun MySQL oder Access oder was auch immer. Hier hat man die Möglichkeit, die neue ID für ein neues Vereinsmitglied per AutoIncrement automatisch erzeugen zu lassen, das schließt Fehler bei der Vergabe einer neuen ID effektiv aus, und man kann seinen Nummernkreis selbst bestimmen.

Ja aber – wenn wirs schon in einer Datenbanktabelle haben…

Genau! Meine Rede! Wir entscheiden uns für eine MySQL-Lösung, und dann gehen wir weit, weit zurück und erinnern uns, was ich in etlichen Beiträgen vor langer Zeit über die Einbindung eigener Tabellen in WordPress erzählt habe. Es ist relativ einfach zu realisieren, die Datenpflege kann über unseren selbstgeschriebenen Datenbankeditor sehr komfortabel erfolgen, es kann in der eigenen Tabelle sehr gezielt nach den unterschiedlichsten Kriterien gesucht werden, um nur einige Pluspunkte zu nennen. Das bringt mich auf was, das ich beinahe vergessen hätte:

Benutzerdefinierte Felder sind importiert, und nun?

Wir können sie auch relativ problemlos anzeigen, aber was ist, wenn ich mal eine gezielte Suchauswertung über mehrere Custom Fields fahren will? Zum Beispiel alle Mitglieder herausfinden, die in München wohnen, männlich sind und an Fußball interessiert.

Da hakts nämlich kräftig. WordPress bietet so ad hoc keine Möglichkeit dafür. Ja ich hörs schon, es gibt Plugins die einem da behilflich sind und eine gezielte Suche nach benutzerdefinierten Feldern ermöglichen, aber wie sieht das Ergebnis aus? Krieg ich halt die Ergebnisse meiner Suche auf einer WordPress-Seite als HTML angezeigt.Na prima.

Und was ist wenn ich das weiterverarbeiten will, z.B. für eine gezielte Mailing-Aktion an alle meine Münchner Fußballmänner? Da muss ich schon auf die Datenbank.

Nochmal langsam zum Nachvollziehen: für jedes Custom Field ein Join

Zur Erinnerung, meine benutzerdefinierten Felder stecken in der wp_postmeta und sind dort über die post_id den Datensätzen in der wp_posts zugeordnet. Das Feld für den Ort hat den meta_key „ort“ und als meta_value den entsprechenden Eintrag, z.B. München. Um jetzt alle Datensätze herauszufischen, die in der wp_postmeta beim meta_key einen Ort haben, muß ich die Tabellen über die post_id joinen, das sieht dann in etwa so aus:

SELECT wp_postmeta.meta_id, wp_postmeta.post_id, wp_postmeta.meta_key, wp_postmeta.meta_value, wp_posts.post_title, wp_posts.post_content, wp_posts.post_status
FROM wp_posts INNER JOIN wp_postmeta ON wp_posts.ID = wp_postmeta.post_id
WHERE (((wp_postmeta.meta_key) Like „ort“) AND ((wp_posts.post_status) Like „publish“));

Ganz schön viel Holz für ein einzelnes Feld, nicht wahr? Wenn ich jetzt zusätzlich noch ein zweites Feld, z.B. die Postleitzahl, mit dazuhaben möchte, muß ich tatsächlich die Tabellen ein zweites Mal  joinen und die where-Klausel nochmal stellen mit wp_postmeta.meta_key) Like „plz“, das sieht dann schon so aus:

SELECT wp_postmeta.meta_id, wp_postmeta.post_id, wp_postmeta.meta_key, wp_postmeta.meta_value, wp_posts.post_title, wp_posts.post_content, wp_posts.post_status, wp_postmeta_1.meta_key, wp_postmeta_1.meta_value
FROM wp_postmeta AS wp_postmeta_1 INNER JOIN (wp_posts INNER JOIN wp_postmeta ON wp_posts.ID = wp_postmeta.post_id) ON wp_postmeta_1.post_id = wp_posts.ID
WHERE (((wp_postmeta.meta_key) Like „ort“) AND ((wp_posts.post_status) Like „publish“) AND ((wp_postmeta_1.meta_key) Like „plz“));

Das, liebe Freunde, gefällt mir überhaupt nicht. Auf meiner eigenen Datenbanktabelle würde der Select nämlich ungefähr so aussehen:

Select ID, vorname, nachname, ort, plz from meine_tabelle

Fertig. Ist irgendwie hübscher, nicht wahr?

Mein Fazit

Mir ist für so etwas die simple MySQL-Abfrage auf der eigenen Datenbanktabelle -zigfach sympathischer als der mühsame mehrfache Join von wp_posts und wp_postmeta. Das ist meine persönliche Präferenz als alte Datenbankerin.

Und mein Fazit lautet: Ich würde meinem Kunden auf jeden Fall die Lösung mit der eigenen Datenbanktabelle als die wesentlich flexiblere und übersichtlichere Methode nahelegen. Aber wie gesagt, ich bin da vorbelastet, ich lieeebe Datenbanklösungen und spiele gern mit MySQL. Am Ende muß jeder selber entscheiden, was ihm bzw. seinem Kunden besser taugt.

Ich lass es jetzt mal gut sein und überlege mir ein neues Thema für etwas praktischen Spaß auf der Datenbank. Stay tuned!

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!

 

 

 

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.