Im Moment bin ich etwas unzufrieden.
Unzufrieden mit der Software die ich bei meiner Tätigkeit verwende. Als Angestellter habe ich lediglich einen eingeschränkten Einfluss, als Entwickler oder mit einem Blog sieht das anders aus.
Es geht hier nur um meine persönliche Meinung und nicht um eine Wertung oder Empfehlung, das ginge auch nicht wirklich, da ich nicht keinen kompletten Marktüberblick haben kann und ich nehme auch nicht für mich in Anspruch die Weisheit gepachtet zu haben.
… aber nun zum Thema
Blog, CMS, Wiki,Trac oder was denn nun
Ich habe einige Blogs privat gestartet, einige meiner Tätigkeiten drehen sich um ein CMS, ich verwende z.B. für das Niederlegen von Abarbeitungshinweisen ein Wiki. Früher wurde ein Tracsystem für den Austausch von Hinweisen und Quellcode bei der Programmierung genutzt. Dazwischen war ich auch mit und an einigen Shops am werkeln. Neuerdings habe ich mit einer Software Namens BCSW zu tun, die im Grunde die Aufgabe hat nutzergruppenbezogen Dokumente auszutauschen.
In allen Ansätzen steckt ohne Zweifel Sinn, aber mag es an der Bequemlichkeit vlt. auch am Alter liegen, irgendwie finde ich an allen Dingen irgendwas störend.
Den Artikel schreibe ich, weil ich mich durch Reflektion dieser Punkte einem Bedarf möglichst stark nähern möchte. Ich hatte das im letzten Jahr bereits mal auf Papier versucht und bekam dabei heraus, dass ich eigentlich irgendeine Art von Kombination aus allem suche.
Also fasse ich mal zusammen was ich gern hätte und da ich unmöglich den gesamten Markt im Blick haben kann, bin ich immer dankbar für Hinweise auf Fehleinschätzungen oder Ergänzungen.
Blog, CMS, Wiki,Trac oder was denn nun
Beginnen wir mal bei dem Wiki…
Toll, wir kennen alle Wikipedia.
Blöd nur, wenn eine Version verwendet wird, die keinen Datenbankexport anbietet.
Die neue Version verarbeitet den Dump der alten natürlich nicht.
Export ist daher nur über jeden einzelnen Artikel möglich. Das ist einerseits ein indiskutabler Aufwand, andererseits möchte man auch ungern 1000 Seiten einfach wegschmeissen.
Btw. Ein Problem ist auch die fehlende Aktualität – es erfolgt keine Kontrolle, ob die Artikel überhaupt noch „uptodate“ sind.
Es gibt ja ein paar weitere Ansätze das Dokuwiki kommt z.b ohne DB aus. Ein klarer Pluspunkt.
Tracserver:
Vielzu aufgeblasen … beinhaltet unter anderem ein Wiki, ein Forum … ist aber trotzdem unübersichtlich.
CMS:
Das muss man von Fall zu Fall unterscheiden. Typo3 kann alles, aber bedarf einer größeren Einarbeitungszeit.
WordPress:
Ich war lange skeptisch, habe mich überzeugen lassen. Gut für eine normale Website ist ein CMS wie Typo einfach mal ein Tick zu viel.
Nachteil: Die Geschwindigkeit nimmt mit Einbeziehung diverser Plugins stark ab. Nicht alle sind miteinander kompatibel.
Was mich bei einem Wiki und auch WordPress stört ist das Einbinden von Bildern ist einfach nicht mehr zeitgemäß. Ich muss umständlich das Bild hochladen und den Artikel den ich schreibe verlassen, um das Bild dann wieder einzubinden, so bin ich aus dem Schreibfluss raus, das kostet mir zu viel Zeit.
Blog, CMS, Wiki,Trac oder was denn nun
Da gibt es noch einen weiteren Punkt.
Die Artikel werden entworfen… ich habe mir das so angewöhnt, – nichtzuletzt weil ich keinen Redaktionsplan o.ä. verwende, dass ich bei einer Idee einfach eine Artikelüberschrift mit der Idee bezeichne und den eigentlichen Artikel später dann auszuformulieren gedenke.
Das klappte anfänglich recht gut… bei 2,3 oder mehr Blogs verliert man die Übersicht.
Ich glaube denoch nicht, dass es sinnvoll ist, alles in einen Blog zu packen. Es sollte schon eine gewisse thematische Differenzierung stattfinden.
Kurzum es wäre eine Anwendung schön, mit der man die Artikel diverser Blogs verwalten könnte.
Es gibt Blogdesk für WP … leider lief das bei mir nicht…
Wenn bekannt ist, welche Tabellen betroffen sind, sollte der Insert/Update aber keine allzugroße Hürde sein, um das selbst nachzubauen.
Da bin ich aber noch immer nicht bei dem weiteren wichtigen Thema: Der Geschwindigkeit!
Bei uns werden die Seiten aus dem CMS gerendert und die erzeugten statischen Seiten in das entsprechende Verzeichnis des Webservers übertragen. Was ich anfänglich für überzogen ansah, erweist sich aus diversen Gründen als durchaus richtiger Ansatz.
1. Sicherheit – es ist keine Datenbank beteiligt / es gibt bei den öffentlichen Seiten keinen Loginbereich / dynamische Bereiche beschränken sich auf das Minimalste. (Kontaktformular)
2. Der eignetliche Server braucht weniger Leistung, wenn die Seiten nicht erst umständlich beim Aufruf erstellt werden.
… ja und wenn ich die Seiten cache, dann kann konsequenterweise auch komplett auf statische Seiten setzen.
3. Klar, Geschwindigkeit – konzentrieren wir uns mal weniger auf umständlich dynamisch generierte Seitenstrukturen, übergroße Bilder, und setzen auf Inhalt, dann reduzieren wir die Ladezeit erheblich.
Kürzere Ladezeiten sind nicht nur für den Nutzer angenehmer auch der Bot/Crawler/Spider der großen Suchmaschinen hat kein großes Interesse an einem riesen Haufen HTML Gedöns. Je kürzer desto besser…
Jetzt könnte man über die sogenannten Static Site Generatoren wie z.B. Jekyll nachdenken. 2 Versuche das Teil zu installieren, bringen doch eine gewisse Ernüchterung.
Wenn man tatsächlich Artikel direkt auf statischen Seiten veröffentlichen wollte, wäre die Frage wie sich ein mögliches Menü verändern sollte. Es würde bedeuten, dass jede bereits statisch erstellte Seite nochmals angefasst werden müsste.
oder man setzt auf den aktuell zu erstellenden Artikel immer auch einen Link auf den vorhergehenden. Damit der jeweils neueste angezeigt wird, könnte man die in der .htaccess auf diesen verlinken.
Das wäre eine Möglichkeit, aber so wirklich elegant ist das auch nicht.
Websitesuche
Eine weiterer Punkt wäre das Thema Websitesuche… d.h. wenn ich eine Website durchsuchen möchte, sollte eine entsprechende Funktion vorhanden sein.
Wordpress hat das, mediawiki, Typo.. das haben die meisten integriert.
Eine Datenbankabfrage ist auch schnell erstellt, aber sie dauert.
Besser ist es eine Software wie z.B. Xapian dafür zu nutzen. Das habe ich bei unserer Website – das sind insgesamt um die 20.000 Einzelseiten + ca. 15.000 pdf Dokumente eingebaut, ohne die im CMS integrierte Variante zu benutzen. Es handelt sich dabei um eine Umsetzung in C, jede Form irgendwelcher Javaumsetzungen lehne ich aus naheliegenden Gründen ab.
Xapian arbeitet hervorragend, einmal eingerichtet führt es einmal am Tag einen Scan über die gesamten Seiten aus und die Ergebnisse werden m.E. in Dokumenten abgelegt… (es könnte auch SQL Lite sein. Ich habe es nicht mehr genau in Erinnerung)
Das wäre eine Möglichkeit… einen ähnlichen Ansatz könnte man für eine Art Sitemap nutzen, aus der dann ein Menü automatisiert erstellt wird.
Das Endziel ist und bleibt, dass dem Benutzer ausschliesslich statische Seiten zum Aufruf zur Verfügung stehen.
Shops:
Ich bin sicher es gi