Archiv der Kategorie: Custom Fields (benutzerdefinierte Felder)

Turnverein die erste Liste: Mitglieder-Adressen

Ausgabe Adressenliste

Alle alten Programmierer lieben Listen, und wir können uns aus unseren schönen Stammdaten schon eine erste Ausgabe bauen: Namen, Adressen und Telefonnummern nämlich, da brauchen wir gar nichts weiter dazu als unser gutes altes Arbeitspferd PHP Code for Posts. Unsere eigene Tabelle mitglieder_stamm kann nämlich vom $wpdb-Objekt genau so angesprochen werden wie die WordPress-eigenen Tabellen, liegt ja in der selben Datenbank.

Tabelle als Konstante definieren

Da wir ja ganz am Ende wieder auf unsere Originaltabelle savecontactform7_1 switchen wollen, lege ich den Namen der aktuellen Tabelle auf eine Konstante und gebe den Tabellennamen im Kopf mit aus, damit wir wissen wo wir arbeiten.

/*****Haupttabelle Name als Konstante definieren*******/
 define("MAINTABLE","mitglieder_stamm");

echo "<h2>Mitglieder Adressenliste</h2>";

echo "Aktuelle Tabelle =&nbsp".MAINTABLE."<br>";

Der Select ist dann ganz simpel:

global $wpdb;
        $alleposts = $wpdb->get_results( "SELECT * from ".MAINTABLE."");

Ausgabe als Tabelle

Wie gewohnt mit einer Foreach-Schleife, das haben wir schon oft genug gemacht, da spare ich mir jetzt nähere Kommentare:

foreach_adressen

Das reicht schon, wir bekommen jetzt alle eingegebenen Testdaten tabellarisch angezeigt.

adressenliste

Das war jetzt zu einfach, nicht wahr? Bitte sehr, wir erweitern unsere Möglichkeiten jetzt gleich kräftig, aber dazu gibts einen neuen Beitrag.

Eigene Tabellen – schließlich heißt es „MeinSQL“

MySQL läßt sich so schön übersetzen

Mir gefällt auch die Semantik: das ist „Mein SQL“, hier kann ich schalten und walten wie ich will, kann Tabellen und Abfragen anlegen und verknüpfen, kann sortieren und inserten und updaten nach Lust und Laune, und Open Source und kostenlos ist es obendrein. MySQL bietet wirklich unbegrenzte Möglichkeiten und ist flexibel ohne Ende. Über den genialen phpMyAdmin steht auch eine professionelle Verwaltungsoberfläche zur Verfügung, die keine Wünsche offenläßt. Also, warum nutzen wir dann dieses Potential nicht zur Erweiterung von WordPress?

Ist es unanständig, eigene Tabellen zu benutzen?

Wenn ich mir viele Plugins und WordPress-Erweiterungen so anschaue, drängt sich mir immer der Gedanke auf: da wäre Vieles mit eigenen Tabellen eleganter gelöst. Da wird die wp_posts hergewürgt um Bilder für eine Slideshow zu verwalten, da klingelt es nur so in der wp_postmeta vor lauter benutzerdefinierten Feldern, da werden wp_terms und Konsorten zur Erzeugung eigener Taxonomien gebeutelt – hallo, das geht auch viel einfacher!

Aber anscheinend gehört es nicht zum guten Ton und ist nicht heilige „Best Practice“, WordPress mit eigenen Tabellen zu erweitern. Dabei ist die existierende Tabellenstruktur uralt und hat definitiv auch einige Design Flaws – ich erinnere nur an die gemischte Verwaltung von Bildern und Beiträgen in der wp_posts, da werden grundverschiedene Entitäten zusammengeschmissen, die eigentlich nichts miteinander zu tun haben. Statt die alte Tabellenstruktur mal zu überarbeiten und aufzufrischen, sind aber heute Legionen von Programmierern damit beschäftigt, neue Logiken in die alte „eiserne Jungfrau“ von einer Architektur zu quetschen, und möglichst bloß nicht ogottogott neue Tabellen anzulegen und einzubinden. Warum das so ist? Keine Ahnung, ich beobachte diese Tendenz nur immer wieder und wundere mich.

Mir ist das Wurst: ich nehme eigene Tabellen wo es praktisch ist

Wie ich vorher schon angesprochen habe: in jedem noch so kleinen Laden gibt es immer Listen, Artikelstammdaten etwa, Kundenadressen mit Kundennummern, Mitgliederverzeichnisse und so weiter und so fort… Ob diese Listen jetzt in Excel, Access oder MySQL geführt werden, ob ein professionelles CRM/ERP System wie Wiso MeinBüro oder Lexware oder anderes eingesetzt wird, die Listen sind da, und wir wollen unsere Stammdaten auch in WordPress nutzen. Statt sie jetzt umständlich in benutzerdefinierte Felder einzuhacken, gibt es auch einen einfacheren Weg.

Der Schlüssel: ja eben!

Der Schlüssel zu dem ganzen Zauber ist: der Schlüssel, auch Kennziffer oder (meistens) ID genannt. Jeder noch so kleine Kaufladen hat Artikelnummern, jeder Verein hat Mitgliedsnummern, jede Kanzlei hat Mandantennummern – der Witz ist, daß jede Entität (jeder Artikel, jeder Kunde, jedes Mitglied) durch eine eindeutige Nummer identifizierbar ist. Wo Datenbanken verwendet werden, ist es üblich einen numerischen Schlüssel durch ein AutoIncrement-Feld automatisch vergeben zu lassen. Es gibt aber auch alphanumerische Schlüssel, z.B. Artikelnummern nach einem Muster wie DE-1234. EN-1234, wo DE bzw. EN dann logischerweise für Deutsch oder Englisch steht. Soweit alles logo?

Ja, dann verwenden wir sie halt auch, die Schlüssel! Wenn wir schon einen eindeutigen Identifikator für unsere Datensätze haben, dann nehmen wir den auch her, um die Verknüpfung zu unserem guten alten WordPress herzustellen. Damit es nicht ganz so trocken wird, nehme ich mal ein anschauliches Beispiel, an dem man gut sehen kann, was sich mit eigenen Tabellen in WordPress so alles leicht realisieren läßt. Aber dazu gibt es einen neuen Beitrag.

Gut gemeint, bedingt brauchbar: Benutzerdefinierte Felder

Einleitung

Als vor ein paar Jahren die benutzerdefinierten Felder (Custom Fields) in WordPress eingeführt wurden, wurde das als großer Schritt in Richtung CMS hochgelobt und gleich mit -zig Anwendungsbeispielen unterfüttert. Benutzerdefinierte Felder sind dafür gedacht, die Beiträge mit weiteren Daten anzureichern, das kann ganz unterschiedliche Anwendungen haben. Man könnte z.B. in einem Bücherblog die ISBN-Nummer des jeweils besprochenen Buches in ein benutzerdefiniertes Feld eintragen, man könnte in einem kleinen Online-Shop zu einzelnen Artikeln die Preise hinterlegen, man könnte in einem Mitgliederverzeichnis für einen Verein verschiedene Daten zu den einzelnen Mitgliedern abspeichern (Geburtsdatum, Telefonnummer, Adresse).

OK, Feld ist gespeichert. Und jetzt?

Wenn man seine benutzerdefinierten Felder in den Beiträgen auch sehen möchte, muß man sie in den Code der entsprechenden PHP-Datei (z.B. single.php) eintragen, das sieht dann etwa so aus:

<?php get_post_meta($post_id, '$key', $single); ?>

Dabei ist die $post_id natürlich die ID des aktuellen Beitrags, das $key ist der Platzhalter für den Namen des benutzerdefinierten Feldes, und $single weist WordPress an, einen einzelnen String auszugeben (alternativ ginge auch ein Array, wenn ein Custom Field mehrere Werte enthält, aber das lassen wir jetzt mal weg).

Ein Beispiel wäre jetzt hier mal der Preis zu einem Beitrag, der $key wäre hier schlicht „Preis“:

benutzerdefiniert_preis

Was passiert hinter den Kulissen auf der Datenbank?

In der Tabelle wp_postmeta landet ein neuer Eintrag mit einer laufenden meta_id:

post_meta_custom_field

Hier wird über die post_id der Name und der Wert des benutzerdefinierten Feldes festgehalten. Der meta_value ist übrigens ein Longtext, also hier können sie jede Menge Text (max. 4.294.967.295 Byte) eingeben!

Sie können allerdings auch jede Menge Unsinn eingeben, statt dem Preis in € das Tagesdatum zum Beispiel, oder auch unsinnige Werte wie „Zwofuffzig“, WordPress ist das egal. Die Nachteile hiervon liegen auf der Hand, und deswegen gibt es auch Plugins, die die Verwaltung von Custom Fields erheblich verbessen.

Das Plugin Custom Field Template

Diese Plugin ermöglicht es, die Eingabebereiche von benutzerdefinierten Feldern einzugrenzen. Mit Hilfe von definierbaren Eingabefeldern, Radio-Buttons, Checkboxes usw. wird es dem Benutzer sehr vereinfacht, sinnvolle Eingaben zu machen. Das ist alles gut und schön und auch sehr professionell gemacht, aber mir gefällt das alles nicht so recht, und ich sage auch gleich, warum.

Wer tippt den ganzen Datenhaufen ein?

Um mal bei dem Anwendungsbeispiel mit dem kleinen Onlineshop zu bleiben: angenommen, man legt für jeden Artikel einen Beitrag an, hübsch mit Bild und kleinem Text. Dann könnte man ein benutzerdefiniertes Feld für den Preis anlegen, vielleicht noch eins für die Artikelnummer, und interessant wäre vielleicht auch der noch Lagerbestand, wieviele Stück noch verfügbar sind. In einem normalen kleinen Laden hat man hierfür zumindest eine Excel-Liste, in der man die ganzen Artikel verwaltet. So, und jetzt kommen die Custom Fields: das soll man alles per Hand einhacken? Nicht in echt, oder?

Oder sehen wir uns mal das Mitgliederverzeichnis eines Vereins an: Miitgliedsnummer, Name, vollständige Adresse, Geburtsdatum, Funktion… da gibt es jede Menge Daten, die hineingehören. Und die soll man alle per Hand erfassen? Ja mir wannsd net gangst, wie man auf bairisch sagt, zu Hochdeutsch: „Das geht ja wohl gar nicht!“

Letztes Beispiel: Bei meiner Modeldatenbank hätte ich zu jedem Model (1 Model=1 Beitrag) sage und schreibe 34 benutzerdefinierte Felder auszufüllen: Körpergröße, Kleidergröße, Schuhgröße, Haarfarbe, Augenfarbe, Oberweite… usw. usf, was halt so alles zu einer Modelsedcard gehört, und das ist eine Menge Holz! Also nee echt nicht, das hacke ich da nicht per Hand rein. Schon gar nicht, weil ich die ganzen Modeldaten eh über ein Contact Form 7-Formular erfasse und sowieso in der Datenbank gespeichert habe.

Und bevor wir jetzt darüber nachdenken, wie man die passenden Einträge zu den benutzerdefinierten Feldern in der wp_postmeta aus unseren Excel-Listen oder MySQL-Tabellen automatisiert erzeiugen könnten – nicht wahr, liebe alte Programmierer, daran habt ihr sofort gedacht! Also, das machen wir NICHT. Wir machen uns das Leben deutlich einfacher.

Wir verwenden eigene Tabellen

Aber dazu gibt es definitiv einen neuen Beitrag, dieser hier ist lang genug geworden.

Zum schwarzen Pinguin

IT nach Feierabend