• Mailingliste: ccc-tf@lists.chaos-inkl.de
• Zeitplanung:

• Termine
  • Erstes Treffen: Samstag, den 27.7. ab 11 Uhr im Raum. Zielsetzung:
    • Zuordnung Aufgaben zu Personen finden
    • CMS-Systeme evaluieren (können Links erhalten werden, Fühl für Autoren, etc - Katalog erarbeiten!) - dafür bitte schon funktionierende Kopien erstellen
    • Anpassung der Inhaltsstruktur erarbeiten, ggf. direkt an CMS-System anpassen
    • Out of scope: Grafische Gestaltung
  • Pads
    • Orga: http://pad.ccc-mannheim.de/p/ccc-tf
    • How to migrate content: https://pad.ccc-mannheim.de/p/cccde-howto
    • URL-Liste: https://pad.ccc-mannheim.de/p/httrack

Das gegenwärtige System (https://github.com/hukl/cccms) besteht aus einer RoR-Applikation, welche das Editieren des Contents im Backend erlaubt, und einer Webfarm basierend auf varnish und nginx. Die RoR-Applikation hat eine rollenbasierte Rechteregelung - es gibt Admins und Autoren. Neuer Content wird geschrieben, indem ein neuer Node in einem Textinterface angelegt wird. Eventuelle Assets wie Bilder etc. müssen über ein separates Interface hochgeladen werden. Insbesondere das Ändern eines existierenden Eintrags wird von den Autoren gehasst - man muss die richtige Node-ID mehr oder minder raten.

Das neue System muss ähnlich performant sein und gleichzeitig sicher. Darüber hinaus soll die neue Infrastruktur besser bedienbar sein, d.h. die Autoren sollen in einem bekannten Interface mit entsprechendem Komfort arbeiten können. Es geht hierbei nicht um die technisch schickste Lösung, sondern um die von der Useability her tollste Sache.

Zusätzlich muss der Content von www.ccc.de (und auch das „alte“ http://dasalte.ccc.de) auf der neuen Webseite verfügbar sein. Die bisherigen Links müssen erhalten bleiben. Diese haben z.B. die Form „http://ccc.de/de/updates/2013/vds-eugh“. Neben den Updates (die auch über RSS syndiziert werden) sind auch einfache Seiten wie „Themen“ oder „CCC Regional“ etc. vorhanden. Der Navigationspunkt „Veranstaltungen“ enthält eine Liste von Einträgen, ähnlich den Updates - ggf. sind diese Hinweise einfach speziell getagged.

WICHTIG: Das ist nicht der erste Anlauf, das perfekte www.ccc.de zu erfinden. Die Dokumentation des ersten Rewrite ist im Dokuwiki zu finden:

• https://doku.ccc.de/intern/Www.ccc.de
• https://doku.ccc.de/intern/Website-Taskforce

Note: Dieser muss evaluiert werden und ist nicht in Stein gemeisselt.

1. Die bisherige Hostinginfrastruktur soll erhalten bleiben, d.h. die bewährte Kombination aus nginx und varnish sollte nicht angefasst grundlos verändert werden. Auch aus Sicherheitsaspekten heraus soll der Content z.B. via wget -m gemirrored werden und wird dann statisch ausgeliefert.
2. Zum Erstellen des Contents wird $CMS verwendet. Wordpress ist eine Möglichkeit, da es hinreichend vielen Autoren bekannt und ziemlich nutzerfreundlich ist. Auf dem Regiotreffen wurde mehrfach auch Plone vorgeschlagen. Das CMS ist nicht direkt aus dem Internetz erreichbar, sondern wird via http basicauth bzw. einen anderen Zugriffsschutz gesichert. Durch das statische Ausliefern ist es nicht möglich, Kommentare etc. zu nutzen - das ist auf ccc.de aber auch nicht sinnvoll.
3. Die Struktur der bisherigen Seite wird nachgebaut, ggf. durch weitere Untermenüs besser navigierbar gemacht. Dabei werden die Inhalte auf CCC.de manuell als neue Einträge in das Wordpress eingepflegt. Dabei muss unbedingt auf den Erhalt der URLs geachtet werden. Eine Versionierung der Webseite durch ein „v3“ in der URL wäre cool
4. Das Theme sollte chaosorientiert sein, gerne aber etwas aufgefrischt und im Hinblick auf mobile Datenempfangsgeräte responsiv gestaltet werden. Ein entsprechend einfach zu modifizierendes Theme muss noch gesucht werden - gerne auch von Leuten, die Erfahrung mit dem Customizing der Themes haben.
5. Wichtig: Für Dokumentationszwecke (ggf. auch juristische Auseinandersetzungen) sollen die einzelnen Webseitenversionen archiviert sein. Beim Mirrorn der statischen Webseite wird einfach bei einer Änderung ein Git-commit gemacht, der die komplette Version in ein Repository sichert. Da dabei nur die geänderten Seiten gespeichert werden, ist auch kein Speicherplatzproblem zu erwarten.

1. Aufbau eines (oder mehrerer) Testsystems, um den Lösungsvorschlag und unterschiedliche CMS evaluieren zu können. Dabei Content-Migrationsplan und statisches Ausliefern unbedingt testen. Ggf. Problemanalyse. Als Basis für die Experimente kann things.chaos-inkl.de dienen - da läuft zur Zeit nur blindenmodelle.de drauf.
   1. Es gibt nun zwei Testinstallationen von Wordpress - http://things.chaos-inkl.de/cccde1 und http://things.chaos-inkl.de/cccde2. Sowohl Content-Team als auch HTML-Team können parallel daran arbyten.
2. Aufteilung in Teams:
   1. Content-Migration: Ein paar Leute kopieren den Content von ccc.de und dasalte.ccc.de in das Testsystem; manuell. Dabei müssen die URLs erhalten bleiben, die Tags etc. auch.
   2. HTML&CSS-Magic: Ein neues Gesicht für ccc.de. Grafiknerd fehlt gerade.
3. Betatest. Hier wird das Testsystem einem größeren Personenkreis zugänglich gemacht, ggf. auftretende Fuckups müssen diskutiert werden.
4. Rollout - ggf. auf der bereits bestehenden Infrastruktur.
5. Maintenance - hier können wir auch aktiv bleiben.

Howto: migration

Als Suchmaschine bietet sich Apache Solr (Engine) mit Nutch (Crawler) an, wobei die Skalierung auch bei extremen Größenordnungen noch gegeben ist. Dynamischer Content wird auch indiziert, wobei es wie auch bei Google gewisse Einschränkungen gibt. robotx.txt Files werden beachtet. Ein Prototyp ensteht unter https://search.c3events.de (ist aktuell nur zweitweise online) wobei Crawler, Engine und Frontend auf der gleichen Maschine laufen. Indiziert wird derzeit nur der Content von https://www.cccmz.de um zu sehen, was z.B. bei Wordpress heraus kommt. Das Frontend für die User wird in PHP erstellt, weil es einfach sein soll. Solr wird vom PHP in Form eines Webservices angesprochen, wobei Solr die Suchresultate in JSON oder XML liefern kann. Die Suche erlaubt die ANgabe von Parametern.

Zugangsdaten search.c3event.de

Username: ccc

Passwort: ncc1701

Erkenntnisse

• Je nach Anwendung kann der Crawler auch lokal auf dem Zielserver laufen, was je nach Anwendung sinnvoll sein kann.
• Es können mehrere Crawler laufen, die an eine oder mehrere Solr Instanzen berichten
• Die Suche kann auch von verschiedenen Erfas genutzt werden, so könnten die Webangebote der verschienen Erfas zentral indiziert werden
• Der Crawler ist nicht nur auf http(s) beschränkt
• Nutzung von Cloudflare bei stakren Lastsitualtionen? (z.B. XXC3)
• Je nach Umfang des Webauftritts sehr hohe Speicheranforderungen (Apache Hadoop lässt grüßen)
• Die Qualität der Suche kann sich sehen lassen, bleibt noch abzuwarten, was der mit PDF oder OpenOffice Files macht. Microsoft Office mag er offenbar nicht → Wird nicht indiziert.
• Der Crawler benötigt noch einiges Tuning (Speicherlast vs. Speed)

Userinterface

KISS (Keep It Stupid and Simple) erlaubt nicht nur eine einfache Integration, sondern Sicherheitsprobleme werden auch offensichtlicher und lassen sich leichter finden/beheben. Die Wahl ist dafür auf PHP gefallen, weil sich das dann leichter in Wordpress oder andere Tools einbauen lässt. Also nicht wundern, wenn das aussieht wie ein Webauftritt aus den 1990er Jahren.

Wordpress

Da gibt es auch ein Plugin für Apache Solr: http://wordpress.org/plugins/advanced-search-by-my-solr-server/

Hier bitte konzeptionelle Probleme auflisten, die bei der Evaluation/Konzeption der CMS auftreten.

• Die Suchfunktionialität des aktuellen ccc.de wird auf Serverseite erzeugt - das aktuelle CCC.de ist also nicht komplett statisch. Allerdings scheint der Rest statisch ausgeliefert zu werden. Entsprechende Weiterleitungen im NGINX?
• Multilanguage-Support
• … siehe Etherpad (vorerst)