Notizen zu WordPress [4]

• 11.09.06, 22:29 | Content Management, Werkstatt

Inbesondere, wenn man WordPress als CMS-Lösung jenseits eines lupenreinen Blogs einsetzt, steht man häufig vor Anforderungen, die sich nicht unbedingt so mir nichts, dir nichts lösen lassen. Für zwei dieser immer wieder anfallenden Probleme, besser gesagt einer Kombination aus beiden wollen wir einen exemplarischen Lösungsweg aufzeigen, nämlich:

Individuelle Formulare unter bestimmten Bedingungen

Hört sich beim ersten Hinhören etwas gespreizt an, ist aber relativ simpel: Auf einer WP-basierten Website sollen u. a. Seminare und Workshops angeboten werden, zu denen sich Interessenten direkt anmelden können. Mit dem WP-eigenen Kommentarwesen ist es nicht getan, das soll es zusätzlich geben, weil man zu den Veranstaltungen im Vorfeld natürlich auch Fragen stellen und sie nach Ablauf kommentieren/bewerten kann. Wenn alle Plätze voll sind oder die Veranstaltung abgelaufen ist, muss folglich auch das Anmeldeformular verschwinden.

Anfangen tun wir mit einem ganz normalen HTML-Formular, das wie gehabt zwischen <form> und </form> alles abgreift, was zur Anmeldung nötig ist. Dem geben wir einen sinnvollen Namen und packen es in das Theme-Verzeichnis zu den anderen Templates. Nun können wir es an jeder beliebigen Stelle mittels PHP-include einbinden (oder auf die WP-eigenen Templatefunktionen zurückgreifen, wobei die hier keinen erkennbaren Vorteil bieten):

<?php include ("anmeldung_baustein.php"); ?>

Jetzt müssen wir nur noch unterscheiden, ob wir uns jeweils in einer Situation befinden, die ein Anmeldeformular nach sich zieht oder nicht. Der vermutlich flexibleste Weg besteht darin, mit benutzerdefinierten Feldern zu arbeiten. Das ist im Prinzip recht einfach: am Ende jedes Artikels können Sie individuelle Kombinationen aus Feldnamen und -wert anlegen, die (nur) für den jeweiligen Artikel gelten, also z. B. ein Feld namens »aktueller Kontostand« mit dem Wert »niedrig«, »moderat« oder was auch immer. Das ist auf Dauer natürlich ein ermüdendes Spiel, also liegt es nahe, Standardfelder einzurichten, die immer zur Verfügung stehen, in unserem Fall eben »Anmeldeformular« mit den Werten »ja« oder »nein«.

Am komfortabelsten geht das mit den beiden Plug-ins Custom Field Gui und Get Custom Field Values. Wie die Namen schon erahnen lassen, können Sie mit dem ersten eine Art umfassende Konfiguration von Individualfeldern definieren, die systemweit bereit gehalten wird (und ebenso aus Textfeldern bestehen kann wie aus Check- bzw. Radioboxen oder Popup-Menüs), während Sie mit dem zweiten die Werte an jeder beliebigen Stelle Ihres Themes abfragen und ausgeben können. Die Konfigurationsliste gerät in unserem Fall recht übersichtlich (und steht im File conf.ini im Plug-in-Paket):

[Anmeldung]
type = checkbox

Als Ergebnis zeigt die Artikelmaske im CMS ab sofort das hier:

Die Unterscheidung anmelden oder nicht wird getroffen, indem das Feld an- bzw. abgekreuzt wird, eine simple Lösung also, die den Vorteil hat, dass sie auch von nicht so technikbegeisterten Kunden locker zu stemmen ist. Jetzt fehlt noch die Abfrage:

<?php 
// Anmeldeformular aktiv geschaltet?
// Falls ja: $anmeldung=="true"
$anmeldung = c2c_get_custom('Anmeldung', '', '', '');
?>

und in Abhängigkeit von der Antwort die Ausgabe:

<?php 
if ($anmeldung == "true") {
    include ("anmeldung_baustein.php");
}
?>

Die gezeigte Konstruktion eignet sich natürlich in erster Linie für die Artikelseite, mit der gleichen Methode ist es aber auch möglich, z. B. auf einer Teaser-Überblicksseite Links direkt zum Anmeldeformular anzubieten, vorausgesetzt es gibt ein solches:

<?php 
if ($anmeldung=="true") {
    // Link zu Anker namens #anmelden auf Artikeltemplate
    <a href="<?php the_permalink() ?>#anmelden">Anmelden</a>
}
?>

Das einzige verbleibende Problem ist (je nach Aufbau) die Verarbeitung der Eingabedaten, sprich Fehlerprüfung und entsprechende Anschlussmaßnahmen (E-Mail verschicken, Datenbankeintrag o. ä.). Wir haben es schon erlebt, dass unter bestimmten Voraussetzungen Schwierigkeiten auftauchen wenn beim Formular method="post" ist (was fast immer wünschenswert sein dürfte) und die Eingabeprüfung im Dateikopf stattfindet. Diese Schwierigkeiten quälten – folgt man den einschlägigen Foren – bis heute offenbar ausschließlich uns, was meint, sowohl Ursache als auch Lösung sind nach wie vor unbekannt. Wir sind irgendwann dazu übergegangen, die Prüfung etc. konsequent auf die root-Ebene auszulagern (also außerhalb des ganzen WP-Gerödels) und nur noch Ergebnisse hin- und herzuschicken, was absolut reibungslos funktioniert und insofern zu empfehlen ist, schon weil ausgeschlossen werden kann, dass man sich mit WP-Elementen ins Gehege kommt.

Ach ja: das Projekt dazu spielt sich bislang noch im Verborgenen ab – sobald es das Licht der Öffentlichkeit erblickt haben wird, reichen wir einen Link nach.