Stefan.Waidele.info

If all you have is a hammer, everything starts to look like a nail

Manche Werkzeuge können andere ersetzen. Manchmal ganz gut, manchmal weniger gut.

So ist das auch mit dem Web-Werkzeug “Content Management System” (“System zur Verwaltung von Inhalten/Webseiten”, kurz CMS), das vor einigen Jahren in zwei Spezialwerkzeuge aufgespalten wurde: Blogs und Wikis. Neben den spezialisierten Varianten, die zusammen das Web 2.0 ausmachen, gibt es weiterhin den klassischen Zweig, der sich für allgemeine Webseiten, meist nach Ausprägung des “Web 1.0″ anbietet.

Substitution, Runde Ia – Blog als Homepage, Wiki als Homepage

Schon recht früh im Web 2.0 (bevor der Begriff überhaupt aufkam?) gab es Projekte, die mit Blogs und Wikis in den Bereich der klassischen CMS vordrangen. Dies geschieht hauptsächlich durch Layouts, die die eigentlichen Merkmale der Web2.0-Werkzeuge vor dem Besucher der Website verstecken, und diese Stärken nur im Backend, also für den Verwalter bzw. für die Autoren ausspielt. Ich habe den Webauftritt des Hotel Krone sowohl als Wiki, als auch als Blog realisiert. (Natürlich nicht gleichzeitig )

Substitution, Runde Ib – CMS als Blog, CMS als Wiki

Auch die Hersteller von CMS haben sich nicht lumpen lassen: Es gibt kaum mehr ein System, dass innerhalb seiner Strukturen nicht auch das Bloggen unterstützt bzw. das Erstellen von Wikis ermöglicht. Ob diese Funktionen im Basissystem oder als Plugin realisiert werden ist unwichtig, wer ein Blog oder ein Wiki will, braucht deshalb nicht mehr von seinem gewohnten CMS umsteigen.

Substitution, Runde IIa – Wikis als Blog

Für mein Lieblings-Wiki “DokuWiki” gibt es ein Plugin, mit dem man bloggen kann. (Sogar mehrere) Wohl prominentestes Beispiel für dessen Anwendung ist der Hauptentwickler von DokuWiki Andreas Gohr. Wer sein Projekt hauptsächlich als Wiki realisiert und sich im DokuWiki-Backend wohl fühlt, der hat keinen Grund, sich reines Blogsystem zu installieren.

Substitution, Runde IIb – Blogs als Wiki

Der umgekehrte Weg ist noch nicht so gut vorbereitet, weshalb ich ihn hier etwas ausführlicher skizzieren will: Wie kann man eine WordPress-Installation zumindest Teilweise als Wiki ge- oder missbrauchen?

Was braucht WordPress, um ein Wiki zu sein?

Nicht viel, die meisten technischen Vorraussetzungen sind schon vorhanden. Der Rest ist Finetuning beim Theme und bei der Rechtevergabe. Hier die typischen Merkmale von Wikis, zusammen mit der möglichen Umsetzung in WordPress. Hierbei treffe ich noch keine Aussage, ob die Wiki-Seiten in WordPress als “Blogartikel” oder als “Pages” (oder gar gemischt) angelegt werden sollten.

• Schnell
  In den meisten modernen WP-Themes ist jedem Artikel ein Edit-Link beigefügt. Ist ein Nutzer mit entsprechenden Rechten angemeldet, so kann der Artikel oder die Seite schnell bearbeitet werden
• Einfaches Markup
  Einfaches Markup ist für Wikis wichtig. Realisiert wird dies in der Regel mit Auszeichnungssprachen wie Markdown oder systemspezifischen Regeln. Dies war sicher lange Zeit angebracht. Jedoch wird mit diesen “einfachen” Auszeichnungen auch eine weitere Zwischenschicht mit ihren eigenen Problemen geschaffen. Daher bietet sich eigentlich HTML als universelle Auszeichnungssprache an. Sie ist weit verbreitet und gut dokumentiert. Außerdem bieten sich Systemen, die HTML nutzen inzwischen gute WYSIWYG-Editoren an.
  Von daher ist die “Einfachheit” im WP-Backend gegeben. Wer nicht meiner Meinung ist, kann sich auch ein entsprechendes Plugin installieren.
• Sicher (durch Versionsverwaltung)
  Jedes Wiki-System bietet eine Versionsverwaltung. Man kann die Bearbeitungsschritte von jedem Artikel nachverfolgen, miteinander Vergleichen und im Fehlerfall bzw. bei Vandalismus auch alte Versionen wieder herstellen. Dieses Feature hat inzwischen auch in WordPress Einzug gehalten, jedoch besteht hier noch Aufholbedarf. Die Revisionen der Artikel oder Seiten sollte auch für Leser sichtbar sein (Vielleicht ist dies schon gegeben – über Lösungsvorschläge wäre ich dankbar)
  Das Plugin “Display Revisions” könnte hier gute Dienste leisten. (Oder die Funktion wp_list_post_revisions() – aber darüber habe ich keine Dokumentation gefunden) – Auch the_modified_author() (ab WP2.8, via WPengineer.com) wird hier von Nutzen sein.
• Offen – “Wiki as a Lifestyle”
  Dies ist keine technische Vorgabe für Wikis, sondern eine Entscheidung des Managements. Man kann auch WordPress so konfigurieren, dass sich jeder registrieren und danach drauflosschreiben kann. Die Tatsache, dass dies (meist sogar ohne Registrierung) bei Wikis meist die Voreinstellung ist und bei Blogsystemen meist gar nicht in Erwägung gezogen wird, ist für die technische Betrachtung nicht relevant. Es gibt sehr restriktiv geführte Wikis. Warum soll es keine offen geführten Blogs geben?
• Einfaches Erstellen von Seiten
  In Wikis erstellt man eine neue Seite, indem man diese verlinkt. Beim ersten Klick auf den Link existiert die Seite noch nicht, aber das System bietet an, diese zu erstellen. A new page is born.
  Bei WordPress müsste man die Fehlerseite (“404.php”) so gestalten, dass ebenfalls die Option geboten wird, die noch nicht vorhandene Seite zu erstellen. Ich habe in meine 404.php folgenden Code eingefügt: <?php echo $_SERVER['REQUEST_URI'] ?> und bekomme nun die aufgerufene Seite angezeigt. Mit dieser Information und der Funktion wp_insert_post() müsste sich doch auch die Seite erstellen lassen. Die anwesenden WP-Cracks und PHP-Puzzler dürfen sich gerne zu Wort melden
• Index – Alle Seiten im Überblick
  Wo man schnell Seiten erstellen kann, kann es auch vorkommen, dass man den Überblick verliert. Bei Wiki-Systemen gibt es dann die Index-Funktion, die alle Seiten im Wiki anzeigt. Dies ist bei WordPress auch vorhanden – einfach das entsprechende Widget in die Sidebar und es ist egal, ob man einen Artikel oder eine Seite sucht. Über die Funktion wp_list_pages() müsste auch eine Umfangreichere Anzeige möglich sein.
• Recent Changes
  Gibt es eine Möglichkeit, die Änderungen der Artikel oder Seiten als RSS zu abonnieren? Je größer die Zahl der Mitarbeiter im Wiki wird, desto wichtiger ist es, dass man sich schnell darüber informieren kann, wann und wo die letzten Änderungen vorgenommen wurden.
• Backlinks
  Mithilfe von “Backlinks” kann man feststellen, welche andere Wikiseiten auf die soeben betrachtete verweisen. Diese Funktionalität wird in Wikisystemen durch eine sehr “teure” (d.h. in großen Wikis sehr aufwändige) Volltextsuche zur Verfügung gestellt. Auf diese Weise könnte man wohl auch ein Blog durchsuchen. Aufgrund der schon vorhandenen Trackbacks besteht jedoch meist schon eine “dokumentierte Beziehung” zwischen verlinkten Seiten, die “Backlinks” weitgehend ersetzen kann.
• Namespaces
  Viele moderne Wikis bieten mit Namensräumen eine Möglichkeit, die Inhalte zu gruppieren und zu strukturieren. Bei WordPress-Seiten ist dies mithilfe von Seiten und Unterseiten möglich. Bei Blogartikeln ist die Gliederung nach Kategorien/Unterkategorien oder Tags möglich. Durch URL-Einstellungen lassen sich auch bei Blogartikeln URLs der Form …/kategorie/unterkategorie/artikel realisieren.

Diese Überlegungen sind noch nicht abgeschlossen, und auch die technischen Lösungen sind oft nur angedacht und noch nicht ausgearbeitet. Jedoch finde ich es spannend, wie sich die verschiedenen, spezialisierten CMS-Typen wieder aufeinander zubewegen.

Gerne lese ich Eure Ideen, Gedanken und Kritikpunkte zum Thema “Wikis in WordPress” hier in den Kommentaren oder auch per Mail.

Don’t force it…get a bigger hammer!