Pages als Lieferanten für Widgets

Eher selten wird m. E. die Problematik diskutiert, wie der Webentwickler die Website in einer Weise anlegt, dass sie vom Autor und Redakteur einfach zu bedienen ist. Im allg. wird davon ausgegangen, dass insbesondere der Redakteur schon die Fertigkeiten und Tricks lernen wird und lernen kann, die es ihm ermöglicht, die Website mit entsprechenden Inhalten zu füllen. Für Artikel und Seiten ist das sicher auch ein kleineres Problem, wenn auch kein triviales.

Ich möchte hier kurz die Features auflisten, die dem Redakteur die Arbeit erleichtern oder vielleicht sogar erst ermöglichen:

  • Frontend-Editoren (z. B. Plugins von scribu, …)
  • Posting by E-Mail (hervorragend unterstützt durch das Plugin Postie)
  • Editor Styles (Mit Hilfe von Advanced TinyMce können die Autoren/Redakteure auf eine Auswahl von Stylings festgelegt werden)
  • editor-style.css (durch Anpassung dieser Datei kann man den TinyMce an das Frontend angleichen)
  • Ajax-basierte Seitenbäume im Administrationsbereich (am besten unterstützt durch das Plugin Admin Menu Tree Page View)
  • Anpassung des Administrationsbereichs an die Bedürfnisse des Redakteurs (am besten unterstützt durch das Plugin Adminimize von Frank Bültge)
  • Und zum Schluss mein Thema: die Bedienung der Widgets durch Pages

Ich möchte nun den Blick auf Widgets lenken, die ja nicht nur von ewigen Inhalten (Adressen, Öffnungszeiten, Logos und dergleichen) oder sich selbständig erneuernden Inhalten (Kalender, letzte Artikel usw.) besetzt sind sondern möglicherweise auch Inhalten haben sollen, die vom Redakteur oder gar Autor gepflegt werden müssen, z. B. mit Bildern, Werbebannern, Linklisten, aktuelle Nachrichten usw. Ich denke, es ist kein Versehen, dass den Redakteuren der Zugriff zu den Widgets im WP-Standard verweigert wird. Natürlich kann man durch irgendein Rollen-Plugin diese Vorgabe aufweichen, aber hat man damit auch die Voraussetzung geschaffen, dass der Redakteur mit den Widgets auch fachgerecht umgehen kann?

Mein Ansatz geht dahin, dass ich den Redakteur bei dem Knowhow abholen möchte, dass   er besitzt: nämlich Artikel/Seiten schreiben, sie gestalten, Bilder und sonstige Medien hochladen oder/und einbringen und das ist es. Wenn man sehr einfache Text-Widgets hat, die ab und zu zu aktualisieren sind (Beispiel: Sonderangebote), kann man sich mit dem Frontend-Editor von scribu helfen. Der hat zwar meistens seine Tücken, aber ist für solche Fälle ganz gut geeignet. Hat die Site aber eine reichhaltige Widgetstruktur, die verschiedene Aufgaben zu bewältigen hat, ist das nicht mehr möglich.

Auf solche Fälle stößt man natürlich durch konkrete Vorgaben von Auftraggebern. So waren es die letzten beiden Sites, die ich bearbeitet, die mich in diese Problematik hineingestoßen haben.

Und noch reichhaltiger MICE-Contact:

Aus diesen Gründen versuche ich meine Sites so aufzubauen, dass sie dem Prinzip folgen: Seiten bedienen Widgets oder anders herum: Widgets beziehen ihre Informationen von Seiten.

Diese Seiten bezeichne ich als Hilfsseiten, sie sind Träger der Informationen für die Widgets und tauchen i. Allg. in keinem Frontend-Menü auf. Man kann sie auch als privat deklarieren, dann dürften sie eigentlich hinreichend geschützt sein.

Seiten haben 2 Arten von Informationen: den Inhalt und die Attachments. Beide können von Bedeutung für die Widgets sein. Die puren Attachments (ob eingebettet in der Seite oder nicht) werden von vielen Galerien-Plugins benutzt, um z. B. Slider zu beliefern. Wenn man den Slider nur in der Seite oder Artikel haben möchte, ist das OK, will man ihn jedoch in einem Widget wiedergeben, muss man dafür sorgen, dass das Widget das Slider-Plugin oder was immer für den Effekt verantwortlich ist, vom Widget verstanden wird. Das ist Aufgabe des Webdesigners, der Redakteur muss nur die dem Widget zugeordnete Seite ändern. Das gleiche gilt, wenn ich im Widget den Inhalt der Seite wiedergeben will. Das können wieder Bilder sein, in diesem Fall in die Seite eingebettete Bilder oder eben irgendwie gestaltete Texte. Da Widgets keine einfache Gestaltungsmöglichkeit besitzen, nämlich nur HTML-Code, wäre dies schon eine echte Herausforderung für den Redakteur/Autor, wenn man ihn direkt auf das Widget loslassen würde. Also muss der Administrator nur dafür sorgen, dass das Widget den Inhalt der zugeordneten Seite ausliest.

Die Techniken zur Realisierung sind alle sehr einfach und dürften von den meisten Webentwicklern problemlos beherrscht werden. (Die von mir eingesetzten Programmtechniken werde ich vorstellen.) Mir geht es darum die Entwickler für diese Problematik zu sensibilisieren – wenn sie es noch nicht sind – und sie zu ermutigen, sich diese Techniken bewusst zu machen und ganz systematisch anzuwenden. Damit befähigt er den Redakteur komplexere Aufgaben mit dem Können zu bewältigen, das er naturgemäß für seine Rolle haben muss.

Natürlich muss der Redakteur dafür eine Dokumentation bekommen, die ihm eindeutig sagt, welche Seite mit welchem Widget zu tun hat und wie diese Seiten mit den entsprechenden Informationen zu befüllen sind, damit das zugeordnete Widget auch das gewünschte anzeigt. Wie eine solche Dokumentation aussehen könnte, möchte ich ausschnittsweise am Beispiel der sehr komplexen Site mice-contact.com demonstrieren.

  1. Man nummeriere alle Hilfseiten in der Reihenfolge, wie sie entstanden sind, durch.
  2. Man stelle einen Screenshot der Website her, z. B. mit dem Firefox-Plugin Nimbus Screen Capture.
  3. Man übertrage die Nummer der Hilfsseite in das zugeordnete Widget-Feld. Ein Ausdruck dieses markierten Screenshots reicht i. Allg. völlig als Dokumentation.

Will der Redakteur/Autor nun ein Widget ändern, sucht er die Hilfsseite mit der Widgetnummer und nimmt die Änderungen vor. Sind es Bilder, die aus den Attachments der Seite bezogen werden, kann der Seitentext als zusätzliche Dokumentation verwendet werden, da dieser ja nicht übertragen wird, sondern nur die attached images. Es spielt dabei keine Rolle, ob es Lücken in der Nummerierung gibt oder gewisse Hilfsseiten für ganze andere Zwecke benötigt werden. Für die leichtere Rückverfolgung vom Seitenscreenshot zur Seite im Backend ist es nur wichtig, dass die Seiten im BE fortlaufend nummeriert sind. Auch der umgekehrte Weg vom Widget im Backend zur zugeordneten Seite sollte dokumentiert werden. Wir zeigen gleiche, welche Möglichkeiten es gibt.

Um die Widgets für die Kommunikation mit den Seiten einzurichten, müssen folgende Vorkehrungen getroffen werden:

  1. Text-Widgets müssen php-fähig sein: dafür wird das Plugin PHP Text in Widget eingesetzt.
  2. Text-Widgets müssen shortcodes verstehen: hierzu wird in der functions.php des Themes folgender Filter eingesetzt: add_filter(‚widget_text‘, ‚do_shortcode‘);
  3. Eine Kommunikationsfunktion muss definiert werden: Diese Funktion bezieht schlicht den Content aus der zugeordneten Seite:
    function dk_get_content($post_id, $hilfsseite){
    $my_post = get_post($post_id);
    $content = $my_post->post_content;
    echo $content;}

Der optionale Parameter $hilfsseite dient nur der bequemen Dokumentierung, von welcher Hilfsseite das Widget bedient wird, es hat keine funktionale Bedeutung.

Wir betrachten verschiedene Situationen an Hand der Website mice-contact.com (Bem: diese Site ist zum Zeitpunkt der Veröffentlichung des Artikels in dieser Form noch nicht online).

Slideshow – einer Seite zugeordnet

Die Slideshow lassen wir im Widget mit dem NIVO-Slider ablaufen. Bedeutung haben dabei nur die Attachments. Der Textteil der Seite dient der Dokumentation.

Im Medientteil sieht das so aus.

Den Editorteil kann z. B. folgendermaßen gestalten:

Im zugeordnete Widget steht dann der oben dokumentierte Shortcode: [nivo theme=oik …]. Zusätzlich kann man noch einen HTML-Kommentar schreiben, um auf die Hilfsseite zurückzuverweisen: <!—Zugeordnete Seite: 2- ->.

Text und/oder Bilder für ein Widget

In diesem Fall kommt beim Widget die Kommunikationsfunktion dk_get_content zum Einsatz.

Die Seite wird z. B. folgendermaßen aufgebaut. Der auszulesende Inhalt besteht aus einer Linkliste.

Das zugeordnete Widget sieht dann so aus:

Der 2. Parameter 7 verweist also zurück auf die Hilfsseite 7.

Wenn man z. B. 2 statische Bilder im Widget darstellen möchte, kann man diese in die Hilfsseite einbetten, sie müssen nicht attached sein.

Das zugeordnete Widget hätte dann den Code <?php dk_get_content(10897,11) ?>. Natürlich kann man diesen Code auch noch in HTML einbetten, um ihm z. B. eine Klasse oder einen Identifyer für CSS zuzuweisen.

Weiterer Einsatz von Hilfsseiten und Kommunikationsfunktion

Die Kommunikationsfunktion ist nicht auf den Einsatz in Widgets beschränkt, sie kann ebenso gut an verschiedenen Stellen von Seiten oder Artikeln eingesetzt werden und fungiert dann im Zusammenspiel mit der zugeordneten Seite gewissermaßen als flexibles Contentelement (FCE), ein Konzept , das von TYPO3 bekannt ist.

Das grau unterlegte Feld auf der folgenden Beispielseite wird nur auf ausgewählten Seiten und an verschiedenen Stellen eingeblendet. Um es nur an einer Stelle editieren zu müssen, bietet sich wieder eine Hilfsseite an, die an diese Stellen kommuniziert wird.

Auf der Editorseite sieht das dann so aus:

Warum Pages und nicht Posts

Der Hauptgrund für diese Entscheidung liegt in der Existenz des Plugins Admin Menu Tree Page View. Dies erlaubt einen schnellen Zugriffe auf die Seite, die Seitennummer und die Identifikationssnummer. Das Einsparen von Reloads ist, glaube ich, immer ein gutes Argument.

Aus der Diskussion

  1. Um PHP in Widgets und damit unnötige Syntaxfehler zu vermeiden, wurde vorgeschlagen, einen Shortcode für diese Funktion zu definieren. Dies werde ich demnächst realisieren.
  2. Es wurde vorgeschlagen, Custom Post Types als Informationsträger statt Pages zu verwenden. Die hat seinen Reiz, werde ich aber vermutlich nicht realisieren, weil die Nutzung von Sites aufgrund des zum Schluss erwähnten Plugins einfach effektiver ist.
  3. Ein anderer Vorschlag lief darauf hinaus, diese Text-Widgets ganz rauszuschmeißen und die Kommunikationsfunktion direkt in die entsprechenden Themefunktionen einzusetzen. Dies muss ich strikt ablehnen, da damit die Trennung von Programm und Daten (Seitenidentifikationsnummer im Programm!!) schwer verletzt wird.
  4. Für einen großen Teil der mit der dargestellten Technik gelösten Probleme würden sich auch geeignete Banner-Plugins anbieten. Ich hatte am Anfang danach gesucht, aber wohl nicht die geeigneten gefunden. Ich glaube aber, dass ich mit diesem Verfahren flexibler bin und vor allem vom Plugin-Entwickler unabhängiger.
  5. Es wurde danach gefragt, wie die Nutzer damit zurecht kommen. Da das ganz frisch entwickelt ist, habe ich noch nicht die entsprechenden Nutzererfahrungen, werde sie aber demnächst machen und werde darüber an geeigneter Stelle (Meetup oder FB) berichten.

Hier findet Ihr die Folien des Vortrages zum Download Pages als Lieferanten für Widgets Folien