Schon seit einigen Tagen steht das WebSoziCMS3 als Beta-Version zum (Vorab)-Test zur Verfügung. Umgeschaltet wird wie gehabt über den Link “Beta-Test beginnen” im Admin-Block nach dem einloggen.

Die Bezeichnugn Beta-test ist übrigens in diesem Fall eigentlich falsch, denn diese Version ist noch nicht Feature-Complete, wie der Programmierer sagt (es sind also noch nicht alle geplanten neuen Funktionen implementiert). Wegen der aktuellen Wahlkämpfe war es uns aber wichtig, euch schon fertige neue Funktionen so schnell wie möglich zur Verfügung stellen. Zur Zeit sind dies:

- ein komfortabler HTML-Editor in vielen Eingabefeldern (also sehr viel weniger manuelles HTML als bisher)

- eine Social-Media-Share-Leiste (Facebook, Twitter und Google+) unter Artikelnnach Heise-Vorbild (d.h. um Datenschutzrechtliche Bedenken zu minimieren sind 2 Klicks für eine Interaktion mit den genannten Diensten erforderlich, so dass nicht von vornherein Daten an diese Dienste übertragen werden)

- als kleinere Neuigkeit wird der Metatag “Content” bei Artikeln jetzt aus dem Artikel selber gespeist, nicht mehr aus den Systemeinstellungen. Das hat den Hintergrund, dass beim Teilen von Artikeln auf Sozialen Netzwerken (wie Facebook z.B.) dann auch der Inhalt des Artikels mit in das Sozciale Netzwerk übernommen wird.

Soweit die derzeit schon implementierten neuen Features. Weitere geplante Neuigkeiten betreffen vor allem eine noch tiefere Integration mit Sozialen Netzwerken.

Die Nutzung der Vorabversion (Beta-Test ist es hier streng genommen wie gesagt eigentlich nicht) erfolgt wie immer auf eigenes Risiko, es können sich noch Funktionen verändern oder auch wegfallen bzw. noch nicht vollständig sein (das betrifft momentan z.B. teils schon vorhandene Optionen zu sozialen Netzwerken)

Gegeben sei z.B. die Aufgabe, auf einen bestimmten Termin im Begrüßungstext der Homepage hinzuweisen. Herkömmlich wird man das vermutlich so lösen, dass man den Termin in den Kalender einträgt und den Text im Begrüßungstext in der einen oder anderen Form nochmal wiederholt. Wenn sich was ändern muss man dann die Änderung allerdings an beiden Stellen nachvollziehen (und eine vergisst man garantiert).

Man kann sich aber auch den Kalendereintrag in den Startseitentext importieren – mit folgendem Code:

<wsc:modul>
<wsc:param name="mod" value="kalender" />
<wsc:param name="op" value="show" />
<wsc:param name="id" value="4401" />
<wsc:template name="title">
<h1>Mein Termin</h1>
</wsc:template>
</wsc:modul>

Die ID eines Kalendereintrages erfahrt ihr im Zweifelsfall beim editieren des Eintrages, er ist dann in der URL-Leiste sichtbar. Mit diesem Code wird ein Auszug des Kalenders mit der Überschrift “Mein Termin” (das kann natürlich selber gesetzt werden, wenn man den Text zwischen <h1> und </h1> verändert) an die gewünschte Stelle geladen. Verändert sich der Kalendereintrag (weil sich z.B: die Uhrzeit verändert), verändert sich automatisch auch der “fremd” angezeigte Kalendereintrag.

Cool, nicht? Und das funktioniert im Prinzip mit jedem Modul im WebSoziCMS, die jeweils erforderlichen Paramenter sind leicht herauszufinden, wenn man sich die URL-Leiste bei Ansicht des gewünschten Eintrages mal näher anschaut.

Bereits seit längerem konnte man ja Version 2.9 als Beta-Version alternativ zur bisherigen Version 2.8. des WebSoziCMS über das Admin-Menü auswählen.

Heute nun haben wir die Version 2.8 deaktiviert und die Version 2.9 als stabile Version bereitgestellt (also den Beta-Test dafür beendet), Hauptaugenmerk der neuen Version liegt auf Fehlerbereinigung, neue Funktionen gibt es im Bereich der Seiten, wo jetzt ein Seitentyp speziell für Personenauflistungen (z.B. Vorstandslisten) zur Verfügung steht. Ausserdem wurde der HTML-Parser (die Funktion, die Eingaben auf Gültigkeit überprüft) etwas entschärft, so dass externe Einbindungen (z.B. Facebook, Flickr) nun in der Regel ohne Fehlermeldungen möglich sind.

Übrigens ist es nicht so, dass in der langen Zeit, die die Version 2.9 als Beta-Version nun existiert hat nichts am System passiert ist. Es wurden vielerlei Dinge im Hintergrund geändert, sichtbar waren allerdings in aller Regel nur neue Themes.

Wir bleiben übrigens bei Versions-Nummern, auch wenn mir jemand auf Facebook den Release-Namen “Wulf-Ex” vorgeschlagen hat.

Nach dem Release ist vor dem Release. Bis zum Sommer wollen wir Version 3 des WebSoziCMSes bereit stellen. Der Focus liegt hierbei auf Social-Media )(also Facebook, Twitter & Co.) , auch wenn die allermeisten Dienste heute schon problemlos einbindbar sind so fehlt es doch an vielen Stellen noch ein wenig an Komfort oder wo möglich an Automatismen. Mit dem nächsten Release werden also auch wieder sichtbarere Änderungen erfolgen.

Langfristiger ist die Version 4 in Planung – hier soll der komplette Unterbau erneuert werden, um auch das Look&Feel zu modernisieren

Entgegen langläufiger Meinung steigen die Kosten für Webhosting und Domains schon länger wieder an. Bei den Servern machen sich z.B. gestiegene Stromkosten bemerkbar, bei den Domains haben viele Registries (also die Stellen, wo die jeweiligen Endungen verwaltet werden) in der letzten Zeit Ihre Preise erhöht, zudem machen sich gerade in dem Bereich auch ungünstigere Wechselkurse immer stärker bemerkbar.

Bislang konnten wir diese Preiserhöhungen immer abfangen, so dass unsere Preise teilweise schon jahrelang stabil sind und wir die gestiegenen Kosten selber getragen haben. Im Bereich der Server waren uns in der Vergangenheit teilweise enorme Verbesserungen möglich, die wir ohne Preiserhöhungen an unsere Kunden weitergegeben haben (wie z.b. die kürzlich Erhöhung des zur Verfügung stehenden Webspaces im WebsoziCMS). Ermöglichen tut das ganze eine seriöse Kalkulation, die sicherlich nicht zu den Discountern am Markt gehört (wiewohl gerade der Soziserver bei den auf  ”SPD-Hosting” spezialisierten Angeboten mit das günstigste ist), aber auf der anderen Seite solche Extras ermöglicht ohne ständig an der Preisschraube drehen zu müssen.

Gerade im Bereich der Domains ist jetzt aber ein Kostenniveau erreicht, was es im Bereich einiger exotischerer Domainendungen nicht mehr erlaubt, die Preise stabil zu halten. Nun kann ich an dieser Stelle relativ leichten Herzens darüber schreiben, denn diese Endungen sind so exotisch, dass sie derzeit auf dem Soziserver niemand nutzt (es geht um .ws und .cc), es betrifft also nur eventuelle Neubesteller. Warum ich trotzdem darüber schreibe hat einen einfachen Grund: auch einige gebräuchlichere Endungen aus dem .cnoi-Bereich sind am Rande der Kalkulation, sollten sich die Kosten dafür weiter erhöhen, was früher oder später zu befürchten ist, werden wir nicht darum hin kommen auch unsere Preise zu erhöhen.

WebSozi- und Soziserver-Maskottchen

Der Stand ist aufgebaut (vielen Dank auch an die Hilfe vom WBH), die Technik steht (Internetverbindung diesmal sehr gut!!), nun kann es losgehen:  In der “Halle für Alle” (Halle 4) sind wir für alle Themen rund ums Internet zu finden. Solltet ihr auch in Berlin sein kommt gerne vorbei

Beim Verfassen des nächsten Soziserver-Newsletters kam mir ein Gedanke, den ich dann auch sozusagen “brandaktuell” mit in den Newsletter aufgenommen habe: wie hättet ihr Infos eigentlich gerne?

Bislang machen wir es so, dass wir Infos bevorzugt auf http://www.soziserver.de und im Forum der WebSozis veröffentlichen. Im Falle von Ausfällen oder Wartungen nutzen wir auch http://www.soziserver-status.de (die Seite bietet zudem den Vorteil extern gehostet zu sein, d.h. die Chance dass sie auch bei einem Totalausfall hier noch erreichbar ist ist sehr groß).

Newsletter versenden wir in aller Regel nur ein bis zwei mal im Jahr (meistens im Frühjahr und zum Ende des Jahres hin). Nun ist diese Frequenz zugegebenermaßen sehr niedrig, auf der einen Seite möchten wir Euch nicht mit Newslettern zuschmeißen, auf der anderen Seite gibt es selbst bei dieser Frequenz erfahrungsgemäß nach jedem Newsletterversand Beschwerden, warum man denn schon wieder Mails von uns erhalte…

Das ist also nicht ganz so einfach. Wie ist Eure Meinung dazu? Ist das so in Ordnung, sollten wir tendenziell mehr Newsletter verschicken oder evtl. auch gar nicht? Ich freue mich auf spannende Kommentare!

Die genaue Ursache wird noch analysiert. Vermutlich waren 2 Gründe dafür ausschlaggebend:

- seit Freitag Mittag hatten wir mit einer geänderten Serverumgebung experimentiert (u.a. PHP-Aufruf per FastCGI anstelle normalen CGI, für die technisch interessierten). Auch wenn diese natürlich vorab entsprechend getestet wurde kann man manches gerade in einer doch relativ komplexen Umgebung wie beim WebSoiCMS erst in einer Live-Umgebung getestet werden bzw. tritt erst in einer solchen Umgebung auf. Grundsätzlich sorgt gerade FastCGI für eine erheblich schnellere Verarbeitung und damit einen schnelleren Seitenaufbau z.B. Ausserhalb der Ausfälle war das – rein subjektiv – finde ich auch sehr gut zu beobachten, der Seitenaufbau war noch schneller als sonst schon. Allerdings scheint diese Umgebung noch ein Problem mit sehr vielen gleichzeitigen Aufrufen zu haben denn gleichzeitig

- wurden sämtliche WebSoziCMS-Seiten von einer Vielzahl “Amok-laufender” Bots “heimgesucht”, die den Servern sehr viel Arbeit bereitete. Natürlich haben wir nach Analyse alles dran gesetzt, diese Bots von den Servern auszusperren (sehr unangenehm aufgefallen ist dabei ein Bot namens Majestic), was soweit auch ganz gut klappte. Nichtsdestotrotz hatte die geänderte Serverumgebung nach wie vor Probleme mit dieser Konstellation, was weiter zu Ausfällen führte. Erst das zurückstellen der Serverumgebung auf den alten Stand brachte dann die gewünschte Stabilität (die Bots versuchen übrigens nach wie vor auf die Server zuzugreifen, nur dass das jetzt lastmäßig kein Problem mehr ist)

Was jetzt Ursache und Wirkung war ist noch unbekannt (wobei schwer vorstellbar ist, dass eine geänderte Serverumgebung schädliche Bots anlocken und dazu bringen soll, “Amok” zu laufen), so dass der Teil sehr wahrscheinlich eher nur Zufall war. Immerhin hat die Technik so Daten gewinnen können, die bei keinem Labortest so angefallen wären – insofern war das ganze trotz Stress und Ärger hoffentlich doch zu was nütze (ich hoffe, dass die Ausfälle für alle Beteiligten zu verkraften waren).

Mittelfristig (natürlich nach dem die Ursache der Probleme dieser Woche geklärt wurden) möchten wir gerne wieder die FastCGI-Serverumgebung nutzen, da diese rein performancetechnisch wesentliche Vorteile verspricht.

Runde 2 1/2 Jahre “bewohnen” wir schon unser Büro in der Lübecker Dr.-Julius-Leber-Straße. Bei Einzug habe ich unten an der Haustür  ein in eine Plastikhülle gestecktes selbst ausgedrucktes Firmenschild angebracht (aka mit doppelseitigem Klebeband angeklebt). Das ganze sollte ein Provisorium für wenige Wochen sein, bis ich Zeit hätte ein richtiges Firmenschild zu bestellen.

Neulich beim reinkommen fielen dann Anja und mir auf, dass da ja Immer noch das Provisorium hängt. Also nichts wie zum Schildermacher des Vertrauens (in dem Falle eher der Internetrecherche) und eins anfertigen lassen. Seit ein paar Tagen hängt es nun auch richtig an der Tür

Aber aus Provider- bzw. Supporter-Sicht ist es ein Graus. Nicht nur dass es (meist unnötigerweise) recht verschwenderisch mit den Server-Ressourcen umgeht. Es ist halt auch in Bedienung und Installation relativ simpel. Gut, dass ist jetzt eigentlich erstmal eine positive Eigenschaft, aber sie führt dazu dass sich auch Laien an die Installation ranwagen. Und diese unterschätzen den – trotz aller Einfachheit – vorhandenen Wartungsaufwand meistens grandios. So ein WordPress (aber natürlich auch jede andere selbst installierte Software) will gewartet werden, sprich es müssen Sicherheitsupdates von Kernsoftware und Plugins eingespielt werden. Dazu muss man die entsprechenden Webseiten und ggf. Mailinglisten beobachten, denn die in WordPress integrierte Update-Funktion ist zwar gut, aber auch hier führt Einfachheit halber dazu dass sich zu sehr darauf verlassen wird – vor einem veralteten Plugin, für dass es keine Updates mehr gibt gibt es da z.B. keine Warnung (und es gibt auch das eine oder andere aktuelle Plugin, welches per Konzept Sicherheitslücken öffnet).

Ausserdem ist WordPress soweit verbreitet, dass es ein lohnendes Angriffsziel für Hacker & Co. ist. Naturgemäß dauert es aber eine mehr oder weniger lange Zeit, bis Sicherheitslücken von den Entwicklern gefixt werden.

Und so ist es in 8 von 10 Fällen bei von uns festgestellter Schadhafter Software im Kundenwebspace  (sei es durch eigenes Monitoring oder durch Abuse- also Mißbrauchsmitteilungen anderer) so, dass ein WordPress beteiligt ist, sprich dort eine Sicherheitslücke in der Software oder Plugins ausgenutzt wurde.

Deswegen mag ich kein WordPress

Heute war es dann mal wieder soweit – unsere Papiervorräte mussten mal wieder aufgefüllt werden. Da glaubt man ja, als vorwiegend im Internet tätiges Unternehmen kann man auf Papier verzichten – aber weit gefehlt, auch hier werden normale Briefe geschrieben, Rechnungen, Mahnungen etc. fallen an und im Bereich der Buchhaltung läuft auch quasi alles in Papierform.

Der Vorrat aus dem Bild reicht demzufolge übrigens auch für etwa 1/2 Jahr