BLOGBEITRAG
Wordpress, Multi-Widgets und die neue Flexibilität
Themengebiet Allgemein
Wordpress bringt aktuell eine unglaublich spannende Neuerung mit, die im Hinblick auf die Flexibilität eines Blogs bzw. einer Seite sehr individuelle Setups erlaubt die in dieser Form bisher nur mit der Anpassung von Template-Dateien und entsprechenden Vorkenntnissen möglich war. Die Rede ist von so genannten Multi-Widgets, die es erlauben, ein Widget mehrfach zu verwenden. Was zunächst nicht sonderlich spektakulär klingt bietet, sofern Theme-seitig entsprechend unterstützt vollkommen offene Gestaltungsmöglichkeiten einer Website auf Wordpress-Basis. Das grundlegende Konzept soll hier genauer vorgestellt werden.
Zum besseren Verständnis sei hier zunächst noch einmal die Logik der Struktur eines Wordpress-Blogs vorgestellt. Wordpress unterscheidet zum einen zwischen Beiträgen und statischen Seiten, zum anderen zwischen verschiedenen Blogansichten, welche die Inhalte eines Blogs anhand bestimmter Kriterien anzeigen.
1. Die Beitragsübersicht: Auf der Startseite des Blogs werden üblicherweise alle Beiträge in chronologischer Reihenfolge aufgelistet, die Form der Darstellung wird durch die index.php des Themes geregelt.
2. Die Einzelbeitragsansicht: Die Auswahl eines Beitrags auf der Startseite des Blogs öffnet den Artikel in der Beitragsansicht, wo dieser Beitrag für sich steht und meist auch weitere Details zum Artikel anführt. Die Darstellung wird hier durch die single.php geregelt.
3. Das Archiv: Auch hier ist der Begriff „Archiv-Ansicht“ besser geeignet, da es sich im Grunde nicht um eine autarke eigenständige Seite handelt sondern um einen temporären Abruf von Beiträgen aus der Datenbank anhand bestimmter Kriterien. So werden bei einem Klick auf eine Kategorie, ein Tag einen Autornamen oder ein Datum die entsprechenden Beiträge aufgelistet. Die Archiv-Ansicht wird durch die archiv.php definiert, kann aber auch in weitere Ansichten aufgesplittet werden. So ist es möglich, eine tag.php anzulegen, die dann eine individuelle Ansicht von Beiträgen anhand der Tags ermöglicht. Die Klassische Aufteilung von Wordpress fasst jedoch zunächst alles in der Archiv-Ansicht zusammen.
4. Die Blogsuche oder Suchansicht: Diese entspricht im Grunde genommen einem Archiv, das jedoch nicht anhand eines Tags oder einer Kategorie Beiträge auflistet, sondern anhand eines speziellen Suchbegriffs den der Nutzer selbst eingibt. Das Default-Theme und der klassische Aufbau sehen dafür aber eine eigene Ansicht vor, die durch die search.php geregelt wird.
5. statische Seiten: Statische Seiten nehmen eine gewisse Sonderrolle ein, da hier keine Beiträge anhand verschiedener Kriterien angezeigt werden. Vielmehr handelt es sich hierbei um eigenständige Seiten mit jeweils eigenständigen Inhalten für die auch das klassische Element einer Seitennavigation bereit steht.
Widgets, widget-ready und widgetized Themes
Die fünf genannten Ansichten bilden also die die recht typische Struktur einer Wordpress-Seite, weiter geht es zunächst mit der Thematik Widgets, dem Handling und widget-ready-Themes. Ein Template, das Widgets unterstützt, hält in einem oder mehreren Bereichen des Blogs Bereiche vor, die durch den Nutzer im Backend von Wordpress mit eigenen Inhalten (Widgets) bestückt werden können. Technisch gesehen muss der Autor diese Bereiche im Theme definieren, aber sinnvoller Weise auch mit Default-Inhalten versehen die angezeigt werden, wenn vom Nutzer keine Widgets genutzt werden.
Das wohl typischste Beispiel ist hier die Sidebar eines Blogs. Der Theme-Autor legt dafür eine sidebar.php an, und definiert diese als Widget-Bereich. Gleichzeitig legt er bereits Inhalte fest, die dargestellt werden wenn kein Widget eingebunden wird. Sofern der Nutzer nun ein Widget im Backend in die Sidebar zieht, werden die vom Autor vorgesehenen Standardinhalte durch das oder die Widgets überschrieben.
Zum Verständnis ein kleines Beispiel:
<div id="sidebar"><!-- the sidebar --> <ul> <?php if ( !function_exists('dynamic_sidebar') ... ?> <?php wp_list_pages(); ?> <?php wp_list_categories(); ?> <?php wp_list_bookmarks(); ?> <?php endif; ?> </ul> </div><!-- end sidebar -->
Die dritte Zeile definiert den Anfang des Widget-Bereichs, die drittletzte Zeile das Ende. Die drei Zeilen dazwischen sind die vom Autor vordefinierten Inhalte (hier die Anzeige der statischen Seiten, der Kategorien und der Blogrolle), welche in dem Moment überschrieben werden, wenn der Nutzer via Backend ein Widget in die Sidebar zieht. Der Grund für diese Herangehensweise ist recht einfach. Dem Autor wäre es möglich, Inhalte außerhalb des Widgetbereichs anzulegen, die dann nicht überschrieben werden.
<div id="sidebar"><!-- the sidebar --> <ul> <?php wp_list_pages(); ?> <?php if ( !function_exists('dynamic_sidebar') ... ?> <?php wp_list_categories(); ?> <?php wp_list_bookmarks(); ?> <?php endif; ?> </ul> </div><!-- end sidebar -->
Im Beispiel sieht man, das die Anzeige der statischen Seite mit wp_list_pages außerhalb des definierten Widget-Bereichs angelegt ist und hier davor liegt. Zieht der Nutzer ein Widget in die Sidebar, bleibt die Anzeige der Seiten an erster Stelle im Blog erhalten, und die Anzeige der selbst gewählten Widgets erfolgt erst danach. Da dies die Flexibilität für den Nutzer einschränkt, wird es also normalerweise so gehandhabt, dass ein Widget die Default-Inhalte eines Themes komplett überschreibt, um größtmögliche Freiheit bei der Gestaltung zu gewährleisten. Dies bedeutet aber auch, dass bei Verwendung nur eines einzigen Widgets, die Sidebar durch den Nutzer komplett selbst definiert werden muss.
Die bisherige Situation
Bisher war es nun so, dass jedes Widget nur genau einmal zur Verfügung stand, um es im Blog zu verwenden. Dies war insofern auch unproblematisch, als das die Sidebar bzw. deren Inhalte auf jeder der oben genannten Blogseiten bzw. Blogansichten stets gleich war. Die Sidebar war auf der Startseite des Blogs weitestgehend die gleiche wie in der Beitragsansicht oder im Archiv, mit Ausnahme der durch die Autoren angelegten Inhalte, die in einigen Fällen mit conditional-Tags nur auf bestimmten Seiten angezeigt wurden. Dies funktionierte aber auch nur solange, wie man kein Widget verwendete. In diesem Falle war eine individuelle Gestaltung der Sidebar für die einzelnen Blogseiten im Grunde nicht möglich, bzw. nur mit entsprechenden Kenntnissen, die dazu befähigen, die Template-Dateien selbst anzupassen, sprich im Quelltext/Quellcode Hand anzulegen.
Dafür standen im Wesentlichen zwei Möglichkeiten zur Auswahl. Einerseits konnte für jede unserer fünf Blogansichten eine separate Sidebar angelegt werde, also sidebar_01.php, sidebar_02.php usw. Diese füllte man dann einfach mit unterschiedlichen Inhalten und rief die entsprechende Sidebar im Template für die jeweilige Blogansicht auf, was dann ungefähr so aussieht:
Sidebar für die Startseite in der index.php einbinden:
<?php include(TEMPLATEPATH . '/sidebar_01.php'); ?>
Sidebar für das Archiv in der archive.php einbinden:
<?php include(TEMPLATEPATH . '/sidebar_02.php'); ?>
Möglichkeit zwei bestand darin, eine einzige Sidebar anzulegen, in der via conditional-Tags die Inhalte für die einzelnen Blogansichten definiert wurden, was ungefähr so aussah:
<div id="sidebar"><!-- the sidebar --> <ul> <?php if ( !function_exists('dynamic_sidebar') ... ?> <?php if ( is_home() || is_single() ) { ?> <?php wp_list_pages(); ?> <?php wp_list_categories(); ?> <?php wp_list_bookmarks(); ?> <?php } ?> <?php if ( is_page() || is_archive() ) { ?> <?php get_calendar(); ?> <?php wp_tag_cloud(); ?> <?php } ?> <?php endif; ?> </ul> </div><!-- end sidebar -->
Grob übersetzt bedeutet das: Wenn Du die Startseite bist oder die Beitragsseite, zeige bitte die statischen Seiten, die Kategorien und die Blogrolle. Wenn Du eine statische Seite bist oder das Archiv, dann zeige bitte den Kalender und die Tagwolke. So eine Sidebar-Datei kann dann eine recht komplexe Struktur annehmen, wenn für jede Blogansicht individuelle Inhalte der Sidebar angelegt werden sollen.
Die neue Multiwidgets-Funktion
Nun bietet Wordpress die neue Multiwidget-Funktionalität, die es erlaubt, ein Widget beliebig oft in die Sidebar zu legen, es kann also mehrfach verwendet werden. Dies allein ist schon recht nützlich, hat aber sein sinnvolles Potenzial dort bereits ausgespielt, wo wie üblich nur einmal der Inhalt der Sidebar für alle Blogseiten definiert werden kann, also auf allen Blogansichten wie bisher auch alles mehr oder weniger gleich aussah. Die Aufgabe im Iowa-Theme bestand nun darin, es dem Nutzer zu ermöglichen, für jede Seite seines Blogs bzw. für jede der oben genannten fünf Blogansichten individuelle Inhalte für die Sidebar auszuwählen. Während der Entwicklung ergaben sich dabei zwei grundverschiedene Herangehensweisen. Nach Murphys Gesetz musste es natürlich so kommen, dass ich mich zunächst für die Lösung entschied, die letztlich nicht genommen wurde. Der Grund für die nun verwendete Lösung sei nachfolgend erläutert.
Lösungsansätze im Iowa Theme
Die erste Variante die mir in den Sinn kam, und zunächst auch nach einer einfachen und gut handhabbaren Lösung aussah war die, genau eine einzige Sidebar zu definieren, und jedem Widget die Option mitzugeben, per Checkbox auswählen zu können, auf welcher Blogansicht bzw. Seite genau dieses Widget angezeigt werden soll. Das ganze sah dann so aus:
» Optionen in den ursprünglichen Iowa-Widgets «
Das funktionierte auch richtig gut, machte Spaß und erschien sinnvoll. Nutzer der aktuellen Iowa Version werden jetzt aufspringen und sagen: „Stopp, her damit, klingt doch prima!“
Die Ernüchterung folgte aber, als ich das ganze einem kleinen Praxistest unterzog. Innerhalb weniger Minuten landeten „alle Widgets“ in dieser einen und „einzigen Sidebar“, und bereits nach den ersten Zehn Widgets war nicht mehr nachvollziehbar, wo ein spezielles Widget im Blog letztendlich auftaucht. Noch schlimmer wurde es, als ich für die eine Seite ein Widget einbinden wollte, dass nur konkrete Unterseiten zu einer Hauptseite anzeigt. Auf einer anderen Hauptseite sollten dann entsprechend nur die anderen Unterseiten angezeigt werden, die zu dieser Hauptseite gehören. Man stelle sich jetzt dieses nette Widget-Chaos vor, dass sich dem Nutzer offenbart, wenn alle Widgets in dieser einen Sidebar im Backend hängen, und jedesmal nachgeschaut werden muss, welches Widget denn nun was macht und wo auftaucht. Das Ende vom Lied war also die Suche nach einer anderen Lösung. Der erste Blick in den Widget-Bereich des Iowa-Themes mag dabei zunächst etwas komplexer anmuten, was angesichts der erklärten Problematik der erste Lösung aber eine doch recht elegante Variante, und aktuell auch die einzige Alternative darstellt, die gleichzeitig aber auch hochgradig flexibel ist.
Anstatt einer Sidebar werden im Backend genau fünf Sidebars angeboten. Wir erinnern uns, für jede der fünf Blogansichten genau eine individuelle Sidebar. Hier können die Widgets beliebig per Drag and Drop eingebunden werden, mit dem Wesentlichen Unterschied, dass sofort beim Aufklappen einer Sidebar erkennbar ist, welches Widget sich darin befindet und wo es dementsprechend auch im Blog auftauchen wird. Da alle Sidebars entsprechend der Blogansichten benannt sind, ist die Orientierung wesentlich besser gelöst als in Variante A. Ein weiterer Nachteil der ersten Lösung bestand weiterhin darin, dass in dem Moment, wo auch nur ein einziges Widget genutzt wurde, logischerweise alle Inhalte jeder einzelnen Blogansicht überschrieben wurden, da ja nur die eine Sidebar definiert wurde. In diesem Moment war es dann notwendig, die Bestückung konsequent für jede Ansicht zu definieren, damit auf jeder Blogseite auch Inhalte vorhanden sind. Bei der zweiten Lösung ist dies nicht erforderlich. Hier kann man in aller Ruhe zunächst die Sidebar der Startseite anpassen, und später bei Bedarf auch alle anderen Seiten. Diese bleiben bis dahin ordentlich mit den vordefinierten Standard-Inhalten bestückt, so dass das Blog zu jedem Zeitpunkt nicht nach Baustelle aussieht sondern stets mit sinnvollen Default-Bereichen aufwartet.
» Verschiedene Widget-Bereiche im Backend «
Um die Flexibilität der Widgets und der Gestaltung der Blogseiten nun noch auf die Spitze zu treiben, kann für Widgets, die in das Archiv oder eine statische Seite gezogen werden explizit bestimmt werden, auf welcher konkreten Seite, bzw. auf welchen speziellen Kategorie-Seiten es erscheint. Mit dieser Funktion ist es nunmehr ein leichtes, ein wirklich CMS-likes Handling mit einer Wordpress-Installation zu realisieren, da nun problemlos kontextabhängige Seitenmenüs einfach im Backend angelegt werden können, ohne auch nur eine einzige Zeile Quelltext anlegen oder ändern zu müssen.
» Optionen in den neuen Widgets «
Die Erklärung, warum aus den fünf Sidebars im Iowa-Theme letztlich noch einige mehr geworden sind hängt damit zusammen, dass neben der Sidebar auch der Footer mit widgetfähigen und unabhängigen Spalten angelegt wurde. Zur genauen Herangehensweise und der sinnvollen Verwendung der Iowa-Widgets folgen hier nach und nach einige Tutorials, die dann Schritt für Schritt erklären, wie man seine Seite mit wenigen Einstellungen sehr flexibel einrichten kann, was dann ähnlich komfortabel ist wie bei einem größeren CMS-System. Fragen zur hier beschriebenen Thematik wie immer via Kommentar.
Beitragsdetails
3 Feedbacks zum Beitrag
-
06 | 08 2009
um 12:50 via Website
hi markus, schaffst du es heute mir das Bild für politopolis zuzuschicken? werbung auf jenapolis ist jetzt gestartet und werde ich auch so in politopolis einbauen. ich würde dabei auch gerne den leuten das gestern besprochene angebot mit dem wordpress anbieten.
gruß arne
-
06 | 08 2009
um 15:20 » Autor-Kommentar «
auch ein kommunikationsweg ;-) hab gestern noch ne Kundenanfrage reinbekommen und bis nachts halb 3 gesessen, bin jetzt damit durch und in zwei Stunden schick ich Dir das Headerbild rüber …
05 | 08 2009
hype.yeebase.com
um 22:04 via Trackback
Wordpress, Multi-Widgets und die neue Flexibilität…
Wordpress bietet mittlerweile eine sehr nützliche Funktion, die im Hinblick auf die Flexibilität eines Blogs bzw. einer Seite sehr individuelle Setups erlaubt die in dieser Form bisher nur mit der Anpassung von Template-Dateien und entsprechenden Vorke…