sheepworld.de – Ein schafiges Projekt mit WordPress-MU und Buddypress

In diesem Artikel geht es mal zur Abwechslung nicht um ein juristisches Thema. Es geht um das Projekt sheepworld.de, das ich in den letzten Monaten geleitet habe und welches gerade online gegangen ist. Um weil ich solche Erfahrungsberichte selbst gerne lese, möchte ich auch meine Erfahrungen teilen.

Und falls sich jemand wundert, warum ein Rechtsanwalt über Onlineprojekte schreibt: Ich war neben meinem Studium als Webdesigner tätig und betreue heute neben meiner juristischen Tätigkeit die Onlineaktivitäten der sheepworld AG. So kann ich auch als Rechtsanwalt am Ball bleiben und verliere nicht den Bezug zur Materie, in der ich berate. Und Spaß macht es auch noch. 😉

1. Über die Auftraggeberin

Die sheepworld AG ist bekannt für schafige Postkarten und Geschenkartikel. Sie wurde 1997 gegründet und hat sich von einem „Garagen-Start-Up“ (tatsächlich war es ein Keller) zu einem weltweit tätigen Unternehmen mit rund 60 Mitarbeitern entwickelt.

Die Zielgruppe ist sehr breit und reicht im Kern von 12 bis 29 Jahren. Was zur Folge hatte, dass es weder eine reine Kinderseite noch eine Erwachsenenseite werden durfte. Sie musste alle ansprechen.

2. Vorgeschichte von sheepworld.de

Die alte Seite von sheepworld habe ich 1999 mit Design auf Tabellenbasis und (geschätzt) Frontpage erstellt. Später kam ein Forum dazu, das sich zu einer Community entwickelte, die auf Basis des phpBB2.0-Forum-Software verwaltet wurde.

Später kamen ein Shop (Oxid Professional Edition 3.0), die Unternehmensseite (typo 3) ein Blog (WordPress) und diverse kleinere Satellitenprojekte (E-Cards, Vermissdichweide, Glitterschafe, etc.) nach und nach dazu. Dieses organische Wachstum ergab also ein großes Kuddelmuddel an unterschiedlichen Plattformen, Domains und grafischen Aufmachungen. Das Problem lag darin, dass man unterschiedliche Systeme warten musste und auch aus Nutzersicht war es schwer alles zu überblicken. So gab es gegen Ende eine Splashpage, die auf die einzelnen Angebote verlinkte.

Auch der Service war umständlich, weil die Emails aus dem Kontaktformular per Email verschickt wurden und ganz oft im Unternehmen hin und her an die zuständigen Bearbeiter geleitet werden mussten. Zuletzt ächzte auch das selbst geschriebene Newslettersystem, das auf ein paar Tausend aber nicht auf sechsstellige Abonnentenzahlen ausgelegt war.

2. Die Ziele

Mit der Vorgeschichte waren die Ziele klar. Alles sollte unter ein Dach, für die Mitarbeiter von sheepworld einfach zu verwalten und einfach zu aktualisieren sein. Natürlich in einem einheitlichen Design, das zur Marke passt und deren Produkte zielgruppengerecht zur Geltung bringt. Es galt also folgende Komponenten zu vereinigen:

• Blog
• E-Cards-Versand mit Archivierung
• Shop
• Community
• Produktvorstellung
• Goodies für die Produktfans
• Unternehmensseite
• Ein Ticketingsystem im Servicebereich zur zentralen Verwaltung von Anfragen
• Ein stabiles Newslettersystem
• Möglichkeit weitere Seiten innerhalb desselben Systems anzulegen und zu verwalten (z.B. eine englische sheepworld-Version)
• Einfach zu verstehendes Redaktionssystem

3. Die Auswahl der Software – Teil 1, die Basis

Eine schwierige Frage war, welche  Software das Ganze bewältigen sollte. Jetzt wurde der Mischmasch unterschiedlicher Systeme zum Vorteil, weil wir auf die bisherigen Erfahrungen zurück blicken konnten. Ich stelle jetzt nicht alle in Erwägung gezogenen System en Detail vor, weil die Liste zu lange wäre. Statt dessen empfehle ich für Vergleiche opensourceCMS.

• typo3 – Typo3 ist aus meiner Sicht weniger geeignet, um es in Projekten mittlerer Größe einzusetzen oder um mal eben schnell eine Erweiterung zu schreiben. Zum einen ist die Verwaltung von Inhalten per typoscript aufwändig und zum anderen gibt es nicht viele Communityerweiterungen. Ich kann mir vorstellen, wenn sich jemand den ganzen Tag lang mit typo3 beschäftig, viele Seiten und Redakteure mit unterschiedlichsten Rechten unter einen Hut bringen will und keine ausgefallenen Wünsche erfüllen muss, dann ist typo3 richtig. Vor allem wenn dieselben Seiten in mehreren Sprachen vorliegen müssen.
• Joomla! – Joomla hat zwar viele Community-Funktionen und Extensions, aber es ist nicht geeignet um damit mehrere Seiten unter verschiedenen Domains einfach zu verwalten. Zudem fand ich die Backendverwaltung von Inhalten nicht intuitiv.
• Drupal – Ich habe Drupal über einen längeren Zeitraum getestet und war gemischter Meinung. Zum einem ist die Art Inhaltseinheiten in gleichartigen „Nodes“ zu verwalten großartig. Aber die Verwaltung von Templates empfand ich als umständlich, wenn man es z.B. mit WordPress vergleicht, wo es ein einfaches ist für jede Seite ein eigenes Template anzulegen. Dennoch war die Entscheidung gegen Drupal nicht einfach und beruhte darauf, dass wir mit WordPress mehr Erfahrungen hatten.
• Expression Engine – bietet einfach nicht genug Community Module, trotzdem ist es ein formidables CMS, das sich jeder anschauen sollte.
• WordPress-MU – WordPress hat mich schon als Blogsystem begeistert, weil es einfach zu Handhaben ist. Es bietet unzählige Erweiterungen und Tutorials. Zudem sieht das Backend der Redakteure nicht nach furchteinflössender Technik aus. 😉 Heute ist WordPress eigentlich schon kein reines Blogsystem mehr, sondern ein CMS. Zudem unterstützt WordPress-MU die Verwaltung mehrerer unabhängiger Seiten unter einem Dach. Auch die simple Updatefunktion für das System und die Plugins wissen zu begeistern. Ferner erschien kurz bevor wir mit den Planungen anfingen Buddypress (deutsche Community). Buddypress ist ein zusammenhängendes Bündel an Communityplugins, wie Nutzerverwaltung, Aktivitätsaufzeichnung, Gruppenverwaltung, Foren, Bilderalben (kommt) und ist einfach zu erweitern. Natürlich bestand ein Risiko, weil man bei so einer jungen Software die Entwicklung kaum absehen kann. Da buddypress jedoch offiziell von  Automattic, der Firma hinter WordPress, entwickelt wird, hat es unser Vertrauen gefunden. Also fiel die Wahl auf WordPress-MU mit buddypress.

Mit der Entscheidung für WordPress-MU und Buddypress waren wir aber noch nicht fertig. Der Shop, das Ticket-System, Newslettersystem und ein Shop mussten her.

3. Die Auswahl der Software – Teil 2, der Newsletter

Als Newslettersystem hatte ich mir schon länger PHPlist ausgeguckt. Es erlaubt mehrere Abonnentenlisten zu verwalten (z.B. Endkunden und Fachhändler), sowie einen Versand per Cronjob. Klar, es gibt mittlerweile viele kostenpflichtige Angebote, die auch andere Features wie rechtliche Hilfen bieten. Doch die lohnten sich bei unseren Empfängerzahlen nicht, da sie mit bis über Tausend Euro pro Newsletter zu Buche schlagen würden. Und rechtliche Hilfe ist ja vor Ort.

Nur die Statistikfunktionen von PHPlist sind etwas mau und schreiten nach manueller Anpassung, die jedoch Modular per PHP zu bewerkstelligen ist. Auch die Anbindung an WordPress könnte besser sein. Zwar gibt es Plugins, aber sie wollten nicht richtig funktionieren, so dass ich es per Hand umgesetzt habe. Eine Modul für den Oxidshop fehlt völlig und auch hier musste die Anbindung per Hand gelöst werden. Das funktioniert jetzt so, dass die Newsletteranmeldungen im Shop vorgenommen werden können (z.B. bei der Bestellung), die Verwaltung oder Abmeldung über die Newsletterseite gehen.

4. Die Auswahl der Software – Teil 3, das Ticketsystem

Als Ticketsystem nutzen wir OS-Ticket. Ein Ticketsystem empfängt zentral die Anfragen vom Kontaktformular und ermöglicht deren zentrale Bearbeitung, ohne dass Emails an die Bearbeiter verschickt werden müssen. Erneute antworten der Nutzer werden durch das System der ersten Anfrage automatisch zugeordnet.

OS-Ticket erlaubt es Mitarbeiter anzulegen sowie sie in Gruppen und Abteilungen mit verschiedenen Rechten einzuordnen. Ferner können die Tickets (Ticket = Anfrage über das Kontaktformular) geschlossen oder anderen Bearbeitern zugewiesen werden. Auch ist es möglich vorgefertigte Antworten anzulegen.

Die Einrichtung war ebenfalls einfach, ebenso wie die Einbindung in WordPress. Zwar gibt es auch hier Module, aber ich habe es mir einfacher gemacht. Ich habe den WordPress-Header, die WordPress-Sidebar und den WordPress-Footer per include-Funktion in das Eingabeformular von OS-Ticket eingebunden. Wer im Hauptmenü das Kontaktformular wählt, landet damit zwar bei OS-Ticket, merkt es aber nicht.

5. Die Auswahl der Software – Teil 4, der Shop

Beim Shop blieben wir bei Oxid PE, jetzt in Version 4.0, weil die Portierung von 3.0 relativ einfach war, wir das System schon kannten und mit ihm überwiegend zufrieden waren. Oxid gibt es als Open-Source Variante, aber auch als kostenpflichtige Version mit Support, für die wir uns entschieden haben.

Das Problem mit Shops ist, dass es weder ein CMS-System gibt, das einen potenten Shop mit allen Funktionen anbietet, noch ein Shopsystem existiert, dass ein vernünftiges CMS für die restliche Seite an Bord hat. Daher sind die meisten Seiten optisch vom Shop getrennt.

Wir wollten jedoch den Shop in die übrige Onlinepräsenz integrieren und nicht als Extraseite öffnen. Doch zwei Probleme gab es:

• Trennung der Communityanmeldungen von Shopanmeldungen
  Nicht jeder, der in einem Shop einkauft will gleichzeitig Mitglied der Community werden und z.B. Freundschaftsanfragen, etc. bekommen. Umgekehrt will nicht jedes Communitymitglied für den Shop registriert werden.
• Unterschiedliche Nutzerverwaltung
  Die Verwaltung der Shopanmeldungen bietet keine Schnittstelle für wordpress. Daher müsste man entweder die Daten ständig abgleichen oder ein zentrales Anmeldemodul bauen. Dagegen spricht, dass dieses Modul überwacht und aktualisiert werden muss, sowie wegen der sensiblen Daten keine Sicherheitslücken haben darf.

Wir haben uns daher entschieden den Shop optisch in die Seite zu integrieren, aber die Shopnutzer von den Communitynutzern getrennt zu halten. Leider klappte es auch nicht den WordPress-Header/Footer in die Shoptemplates einzubinden, weil es andauernd zu Programmfehlern kann. Daher liest der Shop jetzt den WordPressheader/footer aus, speichert sie aber zwischen und bindet eine statische Kopie in den Shop ein. Vielleicht kommt noch eine bessere Lösung.

Im Übrigen funktioniert die Verbindung. So greift WordPress per Plugin auf die Shop-Datenbank zu und generiert z.B. automatisch Banner aus den Shop angeboten. Auch können die Communitymitglieder ihre Shopdaten eingeben und z.B. den anderen Mitgliedern zeigen, welche Artikel von sheepworld sie schon haben und welche sie sich wünschen.

6. Die Auswahl der Software – Teil 5, die E-Cards

Die E-Cards haben wir als ein wordpress-Plugin Marke Eiggenbau umgesetzt. Es gibt zwar einige E-Cards-Plugins, aber sie an unsere Wünsche anzupassen hätte genauso lange gedauert.

Das E-Cards-Plugin erlaubt es

• Karten zu verschicken (wer hätte das gedacht)
• Karten ein Jahr lang vor zu terminieren
• bis zu 10 Empfänger anzugeben
• Karten zu archivieren (für Communitymitglieder)
• Noch nicht verschickte Karten zu bearbeiten(für Communitymitglieder)
• Werbung in E-Cards einzublenden
• E-Cards im Backend zu verwalten und statistisch auszuwerten

Es ist stark mit Buddypress verzahnt und musste zudem die Karten unseres alten Systems verarbeiten können. Insgesamt gilt es einen ständigen Bestand von weit über einee Million E-Cards zu verwalten (wobei alte Karten nach 8 Wochen gelöscht werden).

Die E-Card-Selbst ist übrigens eine „normale“ WordPressseite, die ein eigenes Template zugewiesen bekommen hat.

7. Design & Inhalte – Teil 1, die Struktur

Beim Design hatte ich den Vorteil, dass sheepworld mir einen Grafiker gestellt hat, der meine Ideen und Entwürfe in den sheepworld-Style umgesetzt hat. An dieser Stelle vielen Dank an Jörn, der großartige Arbeit geleistet hat und jeden falsch sitzenden Pixel zurecht geschoben hat ;).

Zuerst musste ich ihm jedoch eröffnen, dass ein Design je nach Browser unterschiedlich aussehen kann, Inhalte sich nicht immer an einem Raster ausrichten können und Schriften auch noch skalierbar sind. Das ist für jemanden, der gewohnt ist seine Grafik bis zum Druck fest in der Hand zu haben, natürlich ein Schock. 😉

Von der Struktur her hat die Seite 5 horizontale Bereiche. Dadurch soll Ordnung gewahrt werden und die Nutzer sollen sich nach diesem Muster auf jeder Seite sofort orientieren können.

• Die Admin-Leiste ganz oben erlaubt es den Nutzern sich überall einzuloggen.
• Der Header enthält eine kleine sheepworld-Erlebniswelt, die sich je nach Jahreszeit verändert (ja, wir sind diesmal mit Weihnachten spät dran ;)).
• Der Inhaltsbereich sieht je nach Rubrik unterschiedlich aus. Der Blog und die Seiten haben eine Sidebar, der Shop und die Community dagegen nicht. Das ist leider etwas inkonsistent, aber sonst hätte die Seite noch breiter als 980px sein müssen. Daher ist die Lösung die Sidebar an manchen Stellen weg zu lassen ein Kompromiss. Ansonsten ist der Inhalt in ein Raster von je 200px Breite und 30px Seitenabstand unterteilt.
• Unter dem Inhaltsbereich ist eine Info-Leiste, die all die kleinen Infos für Besucher zusammen fastst. Z.B. wer in der Community beliebt ist, welche E-Cards neu sind, Shopangebote, etc.
• Der Footer soll eine Anlaufstelle sein, wenn man sich verirrt und ferner klassisch Informationen über die Seite bieten. Daher sind dort das Impressum, die Datenschutzerklärung, eine zweite Suche, RSS und Newsletterlink vorhanden. Ferner eine umfangreiche Sitemap, die alle Seiten aufführt.

8. Das Design – Teil 2, die Features

Keine Sorge, ich werde jetzt nicht alle Features aufführen, sondern nur die aus meiner Sicht interessantesten.

• Slider/ Carousels – Ich setze an vielen Stellen so genannte Slider oder Carousels ein, die es per Pfeilklick erlauben Elemente weiter zu blättern. Ein prominentes Beispiel ist die Startseite, die alle wesentlichen Informationen in einem solchen Slider bietet. So muss der Nutzer weder scrollen noch Blättern, um das zu erfahren, was sheepworld ihm mitteilen möchten.
• Overlaybanner – Statt PopUp-Fenster zu verwenden, setze ich Overlay-Ebenen ein, also Ebenen, die über die Seite gelegt werden. Das ist bequemer, sicherer weil viele PopUpFenster blocken und es ist einfach nervig, wenn überall neuen Fenster aufgehen. Ich gestehe jedoch ein, dass auch die Overlayebenen dann nerven können, wenn man doch lieber ein Fenster hätte. Ein Beispiel für Overlays sieht man, wenn man auf eine E-Card klickt.
• Header einklappen – Beim Header war das Problem, dass die Seite sowohl Gelegenheitsbesucher wie auch Stammkunden ansprechen muss. Und wo der Gelegenheitsbesucher sich über den bunten und animierten Header freut, kann er einem Communitymitglied auf den Nerv gehen (oder dem Webdesigner, der ihn täglich sieht 😉 ). Daher ist es möglich den Header einfach wegzuklappen. (Ganz oben, auf den Pfeil neben der Suche klicken)
  
• Facebook/ Twitter – Auf jeder Seiter prangt in der Sidebar oder im Footer ein Link, mit dem man die Seite  zu Facebook und Twitter. Ich hätte auch gerne StudiVZ und andere deutsche Konsorten aufgenommen, da die sheepworld-Zielgruppe dort eher unterwegs ist. Aber mangels einer Schnittstelle ging das nicht. Ich hoffe da kommt noch was.
• Gästebuch – Was? Gästebuch als Feature? Ist das nicht sehr web 1.0? Der Beliebtheit nach anscheinend nicht. Obwohl ich auch selbst sehr erstaunt bin, wie häufig es genutzt wird. Wohl weil jeder weiß was es ist und es somit der kleinste gemeinsame Nenner für eine Meinungsäußerung ist. Die Einträge aus dem Gästebuch werden im Übrigen an anderen Stellen der Website als „Referenzen“ angezeigt. Wenn man schon so viele Komplimente bekommt. 😉
• Glitterbilder – Relativ einfach mit dem GIFEncoder zu erstellen und ein Spaß für alle. Die Zielgruppe mag sie sehr! Vom Gefühl kann ich nur bestätigen, dass alle Interaktiven Angebote besser ankommen als die üblichen Downloads von Bannern, Hintergrundbildern und Co (die wir aber auch anbieten).
  
• Draw Comments – Rund um dieses Plugin habe ich eine Möglichkeit für Nutzer gestrickt Blogkommentare oder Communitybeiträge mit eigenen Zeichnungen anzureichern. Und bin begeistert, was die für tolle Bilder zeichnen. Auf jeden Fall was anderes als nur Text.
• Produktwelt – Obwohl wir alle Produkte im Shop haben, machten mir die Zuschriften der Nutzer klar, dass es wichtig ist eine Stelle haben, wo Fans und Kunden sich einen Überblick über die Produktpalette verschaffen können.
• Send-a-Song ist der Knaller schlecht hin. Gesungene Postkarten mit individuellem Text erstellen und verschicken zu können kommt fantastsich an. Dieses Projekt haben wir mit handycomedy.de realisiert, die die Technik stellten.

9. Die Server und der Cache

Die Seite wird auf von sheepworld auf eigenem Server gehostet. Doch trotz der technischen Leistung wäre die Seite ohne zusätzliches Tweaking zu langsam. Denn wo die Möglichkeit WordPress per Plugins einfach aufzubohren die Arbeit erleichtert, ist deren Schattenseite ein starker Performanceeinbruch. Zum einem muss der Server viel arbeiten und viele Plugins binden je eine CSS-Datei und eine Javascript-Datei ein, was die Anzahl der HTTP-Zugriffe in die Höhe schnellen lässt.

Wer viele WordPress-Plugins einsetzt, der wird das kennen. Und die sheepworld-Seite hat insgesamt rund 60 Plugins laufen (ich führe sie am Ende alle auf). Ferner hat die Seite viele Grafiken, die ebenfalls den Zugriff verlangsamen.

Um die Seite trotzdem schnell zu halten, habe ich auf folgende Abhilfen gesetzt:

• CSS-Sprites – also Grafiken, die zu einer großen Grafik verbunden werden und so HTTP-Zugriff sparen.
• Expire Daten für CSS, Javascripts und Grafiken – In der .htaccess-Datei wird den Browsern mitgeteilt, dass sie z.B. Grafiken für 2 Wochen in ihrem Cache behalten dürfen.
• GZip-Komprimierung für CSS und Javascript – Die Dateien werden gepackt an die Browser ausgeliefert und senken so die Zugriffszeit. Die Komprimierung übernimmt W3 Total Cache, auf welches ich gleich eingehe.
• Verlagerung von Javascriptdateien an das Ende des BODY der Seite – Der Nutzer empfindet eine Seite als schneller, wenn er die Inhalte „kommen sieht“. Werden die Scripte im Header vor dem Inhalt geladen, dann muss der Nutzer auf die Inhalte warten. Bei vielen WordPress-Plugins ist das leider nicht umsetzbar, weil sie von den Plugins im Header verortet werden und man sie per Hand runter setzen müsste, was nicht immer funktioniert (dann wenn Inhalte ein vorher geladenes Javascript voraus setzen) und ggf. nach den Plugin-Updates jedes Mal getestet werden müsste.
• Content Delivery Network – Die CSS-Dateien und die CSS-Hintergrundgrafiken werden auf einen anderen Server ausgelagert. Dadurch werden Flaschenhälse vermieden, allerdings ist die Beschleunigung nach bisherigen Messungen marginal. Das liegt jedoch daran, dass CDN vor allem dann Sinn bringt, wenn die Server an unterschiedlichen Orten der Erde stehen.
• Caching – Zum Einsatz kommt das „W3 Total Cache„, das ganz frisch auf dem Markt ist. Es unterstützt „Page Caching“, also das Zwischenspeichern von Seiten als HTML-Dateien, so dass sie nicht jedes Mal neu erstellt werden müssten. Jedoch geht das nur für die nichtangemeldeten Nutzer, weil die angemeldeten immer frische Seiten bekommen müssen, um zum Beispiel private Nachrichten zu sehen. Hier erhoffe ich mir noch bessere Caching-Methoden für Buddypress. Mit „Database Caching“ werden Datenbankabfragen zwischengespeichert.
• eAccelerator – Mit dieser Serversoftware wird compilierter PHP-Code zwischen gespeichert und so wird Zeit und Severlast gespart.

Insgesamt brachten die Maßnahmen bis zu 100% Zugriffszeitersparnis, wovon der größte Verdienst dem Caching zufällt. In jeden Fall sollte man ein bisschen Zeit für die Beobachtung und Anpassung einrechnen, um das beste Ergebnis zu erzielen. An dieser Stelle vielen Dank an Thomas der sich bei sheepworld um den Server kümmert und ihn ständig weiter optimiert.

Als Tool für den Performance-Check kann ich YSlow empfehlen.

10. Der rechtliche Teil

Dass eine Seite von einem Juristen erstellt worden ist, erkennt man wohl daran, dass die Nutzungsbedingungen wohl die Seite mit dem meisten Inhalt ist. 😉 Dieser Inhalt ist jedoch notwendig und erleichtert die tägliche Arbeit, in dem er auch als Nachschlagewerk für die Communitybetreuer und die Nutzer fungiert. Daher war es aus meiner Sicht notwendig die Nutzungsbedingungen gut zu strukturieren und den Lesern mit Ankerpunkten eine nutzerfreundliche Navigation zu bieten. Ferner gab ich mir Mühe die Nutzungsbedingungen in „menschlicher“ Sprache zu formulieren. An manchen Stellen (z.B. Haftung) war das kaum möglich, aber ich hoffe bis zum nächsten AGB-Update auch diese Hürden zu umschiffen.

Mehr zum Thema „AGB für Communities“ könnt Ihr in meinem Slidecast erfahren.

Ferner war es uns wichtig, den Nutzern die Möglichkeit zu geben, sich gegen ungewollte Emails abzusichern. Es kommt z.B. schon mal vor, dass ein E-Card-Verfasser permanent eine falsche Emailadresse verwendet und den Inhaber sich so belästigt fühlen kann. Daher habe ich eine Möglichkeit eingerichtet Emailadressen zu bannen. So hat z.B. jede E-Card-Email einen Link, mit dem man die eigene Emailadresse einem Klick sperren kann. Um dem Datenschutz zu genügen, werden diese Emailadressen verschlüsselt gespeichert, so dass wir sie zwar (per hashtag) vergleichen aber nicht entziffern können.

Ebenso enthält das Backend vielfältige Funktionen, um Inhalte (Gästebuchbeiträge, Forumseinträge, Bilder) schnell sperren oder löschen zu können, um den Ansprüchen des Telemediengesetzes zu genügen.

Weiter erhalten die Redakteure eine Media-Richtlinie, die ihnen bei Entscheidungen zum Urheberrecht oder wettbewerbsrechtlichen Fragen hilft.

Für die bisherigen Mitglieder habe ich im Übrigen eine extra Seite eingerichtet, auf der Sie ihre alten Daten selbst übertragen konnten. Auf diese Weise erhielten wir eine rechtlich zulässige Bestätigung der neuen Nutzungsbedingungen und bereinigten zugleich die „Karteileichen“.

Ich bremse mich hier ein bisschen, bevor das hier doch ein Rechtsbeitrag wird. 🙂

11. Going Live

Ende November wurde das Projekt veröffentlicht und läuft seit dem rund. Die größten Schwierigkeiten bereiteten die Einstellungen des Caches. Seit dem wir jedoch von Wp-Cache auf „W3 Total Cache“ gewechselt sind, haben sich diese erledigt.

Erstaunlicherweise war die Anzahl der „Früher war alles besser“-Nutzer viel geringer als ich dachte. Es ist verständlich, dass Nutzer es nicht mögen, wenn sich gewohntes ändert. In unserem Fall war es wohl richtig viele Rubriken zu übernehmen und den Nutzern den Einstieg mit vielen Erklärungen und umfangreichen FAQ möglichst einfach zu machen.

Abgeschlossen ist die Entwicklung noch nicht, es gibt noch genug Features die noch implementiert werden und Optimierungen, die vorzunehmen sind. Aber ein Onlineprojekt sollte sowieso nie als „fertig, jetzt fassen wir es nie mehr an“ betrachtet werden. Irgendwas ist immer und wer weiß, welche Trends und Erkenntnisse um die nächste Ecke warten.

Ende und Daten

Ich hatte mit der Projektplanung und -ausführung eine Menge Freude und hoffe Euch hier einen kleinen Einblick geboten zu haben.

Hier noch die wichtigsten Daten zum Projekt zusammen gefasst (es werden jeweils die aktuellen Versionen eingesetzt). Daneben haben wir noch viele Eigenentwicklungen, die z.B. Schnittstellen zum Shop bieten oder Features wie sheepworld Glitter.

• Basis – Wordpress-MU
• Shop – Oxid Professional Edition
• Ticket/Service – OS Ticket
• Newsletter – PHPlist
• Javascript
  • jQuery
  • Thickbox 3 (für Overlays)
  • jQuery Innerfade für Überblendungen auf der Startseite
  • jCarousel für den Slider auf der Hauptseite
  • jQuery carousel lite für die Carousels mit Inhalten
  • jquery UI (inkl Datepicker) für die ECards-Extras
• WordPress-Plugins
  • Buddypress für die Communityfunktionen
  • Akismet gegen Spam
  • Custom Login Page – um das Backendlogin schöner zu gestalten
  • Draw Comments – erlaubt es den Nutzern die Kommentare oder Gästebucheinträge mit Zeichnungen zu bereichern.
  • Google XML Sitemaps für die Suchmaschinen
  • Lightbox2 für die Bildvergrößerungen
  • Login With Ajax – um eine schöne Loginseite für die Nutzer zu haben
  • o42-clean-Umlauts – Sorgt dafür, dass Umlaute ordentlich behandelt und nicht z.B. in Permalinks in „o“ statt in „oe“ umgewandelt werden.
  • Page Links To – Erlaubt Menüpunkte anzulegen, die wie direkte Links funktionieren. Um z.B. auf eingebundene Bestandteile zu verlinken, die kein Teil von WordPress sind (s. oben Nr. 4).
  • pageMash – erlaubt es Seiten per Drag und Drop zu sortieren oder zu verstecken.
  • PixoPoint Menu Plugin – generiert das Hauptmenü und bietet vielfältige Einstellungen
  • Redirection – Falls man Umleitungen einbauen will
  • SI Captcha Anti Spam – ist für Logins, Registrierungsformulare, etc. Ist kompatibel mit Buddypress
  • W3 Total Cache – der Performaceschub
  • WP-Polls für Umfragen