TangoCMS ist seit Oktober 2013 tot. Die Entwickler hatten seit längerem schon keine Zeit mehr gefunden, das Projekt weiter zu betreiben. Ach ja, so was passiert so oft bei diesen Software-Projekten, welche von Einzelnen oder einer Handvoll Enthusiasten in der Freizeit und ohne Bezahlung betrieben werden. Ich kenne das selbst …
Archiv der Kategorie: Webentwicklung
Elxis 4.1 Poseidon
Das Content-Management-System Elxis in der 4er-Generation ist ein deutlicher Fortschritt gegenüber der 3er-Generation. Doch wieso?
Halt! Erst mal muss ich meckern. Ich hatte gerade schon ein paar Sätze für den News-Bereich meiner Elxis-Testinstallation geschrieben, bin dann aber versehentlich durch eine falsche Tastenkombination von der Seite weg navigiert, und das Ergebnis war, dass mein Text futsch war. Das ist blöd, das ist ärgerlich und das passiert zum Beispiel bei WordPress nicht. Nun gut, jetzt weiß ich Bescheid, dass ich beim Schreiben von Artikeln in Elxis eben immer mal wieder zwischendurch von Hand abspeichern muss. Aus Fehlern wird man klug …
Doch zurück zum Thema. Nach einem Serverumzug kriegte ich Elxis 2009.3, genannt Aphrodite, nicht mehr ans Laufen. Egal, es war ja nur eine Testinstalltion ohne wichtigen Inhalte, und so installierte ich kurzerhand die aktuelle Version 4.1 mit dem kraftvollen Namen Poseidon. Von dieser Version, die Ende 2013 erschienen war, und auch von der vorhergehenden Version 4.0 Nautilus habe ich erst jetzt, Anfang Februar 2014, erfahren. Ich hatte mich längere Zeit überhaupt nicht mehr mit Elxis befasst.
Halt! Das nächste Ärgernis. Ich hatte den Artikel zu Ende geschrieben, speicherte ab … und wurde aus unerfindlichen Gründen aus dem System ausgeloggt. Nach dem erneuten Einloggen war schon wieder der zuletzt geschriebene Text weg! So macht das natürlich keinen Spaß und so kann man auch nicht effizient arbeiten. Aus dem Gedächtnis alles neu zu schreiben, dazu habe ich nun zu so später Stunde keine Lust mehr. Schade, Elxis, sehr schade, aber so hinterlässt dieses CMS keinen allzu guten Eindruck bei mir.
Inzwischen sind ein paar Tage vergangen, und ich will meine Bewertung nun zu Ende verfassen. Der Grund, warum ich aus dem System geschmissen worden war, waren gar nicht so unerfindlich, denn in den System-Optionen ist standardmäßig eingestellt, dass man nach fünfzehnminütiger Untätigkeit ausgeloggt wird. Einen News- oder Blogartikel zu schreiben, halte ich zwar nicht für eine Untätigkeit im klassischen Sinn, aber nun gut, woher sollte das Inhaltsverwaltung-System wissen, dass ich gerade am Schreiben war. Aus Sicherheitsgründen ist ein Ausloggen nach einer gewissen Zeit sicherlich sinnvoll. Da ich mich zu Hause am Heim-Computer allerdings einigermaßen sicher fühle, setzte ich die Zeit auf eine Stunde hoch.
Doch zurück zur Ausgangsfrage: warum ist Elxis 4 besser als 3?
Nun, wie schon angedeutet, ist das Sicherheitskonzept optimiert worden. Man könnte auch sagen, es ist überhaupt erst mal ein Sicherheitskonzept eingebaut worden. Dazu gehört neben dem automatischen Logout zum Beispiel auch die Möglichkeit, dass man das Administrations-Verzeichnis umbenennen kann (und sollte). Das ist dann schon mal eine nette Hürde für Bots oder Menschen, die ins System eindringen wollen. Ferner lässt sich das empfindliche Repository-Verzeichnis, das Logdateien usw. enthält, in einen per Webbrowser nicht erreichbaren Bereich auf dem FTP-Server verschieben (sofern der Webhoster das ermöglicht).
Weitere Neuerungen und Verbesserungen kann man in einem Vergleich genau nachlesen. In einigen Punkten wurde die Benutzerfreundlichkeit und Verwaltbarkeit vereinfacht. Interessant fand ich, dass Elxis 4 nicht mehr auf dem Mambo-Quellcode basiert, sondern offensichtlich komplett neu programmiert worden ist (Mambo ist ein seit 2008 nicht mehr weiterentwickeltes CMS, von dem es viele Derivate, sogenannte Forks gibt, wie etwa das bekannte Joomla!). Jetzt leistet das objektorientierte Framework Elxis OO framework die Arbeit hinter den Kulissen.
Ich werde sicherlich noch ein wenig mit Elxis herum experimentieren, aber es wird wahrscheinlich nicht zu meinen favorisierten Content-Management-Sytemen werden.
Meine Website ohne CMS
Ich habe es getan. Ich betreibe meine Website jetzt ohne Content-Management-System. Genauer gesagt, dieser Blogbereich hier läuft nach wie vor auf WordPress, aber die anderen Seiten, wie Startseite, Referenzen, Impressum usw., laufen ohne CMS. Vorher hatte ich für die Inhaltsverwaltung solcher Seiten Concrete5 eingesetzt.
Sprechen wir über die Gründe, die mich zu diesem Schritt bewogen haben. Und holen mal ein bisschen aus. Ein Web-CMS ist in der Regel ein fettes, schwergewichtiges Software-Monstrum. Es dient dazu, einem oder mehreren Benutzern zu ermöglichen, ohne HTML-Kenntnisse Inhalte zu bearbeiten, und zwar per Webbrowser. Man kann also auf eine sehr einfache Art und Weise Texte schreiben, Bilder einbinden, Diashows einrichten, Kontaktformulare zusammen klicken und vieles mehr. Und oft gibt es ein ausgefeiltes Rechtesystem, sodass verschiedene Benutzer etwa nur bestimmte Bereiche bearbeiten oder nur bestimmte Aufgaben erledigen dürfen. Die Angaben über diese Rechte werden in einer Datenbank gespeichert, ebenso die ganzen Seiteninhalte. Es gibt allerdings auch einige schlankere Einbenutzer-Systeme, welche die Seiteninhalte nicht in einer Datenbank, sondern als Textdateien auf dem Webserver speichern.
Eine wunderbare Sache also, wenn man so etwas den Kunden anbieten kann. Und mit dem von mir favorisierten Concrete5 kommen meine Kunden gewöhnlich sehr gut zurecht, weil es intuitiv zu bedienen ist.
Nur: was für einen Sinn hat so ein System für mich selbst? Ich als Webdesigner brauche keinen WYSIWYG-Editor, der den HTML-Quellcode vor mir abschirmt. Wenn ich, sagen wir mal, neue Referenzen einpflegen oder auch mal die Meta-Angaben überarbeiten will, bin ich wesentlich schneller mit HTML/PHP-Editor und FTP-Client. Und ich habe die volle Kontrolle über den Quellcode. Ich kann ihn schön schlank und übersichtlich halten. Ein CMS, so gut es auch sein mag, wird den Code immer zumindest ein bisschen aufblähen.
Dazu kommt noch, dass Datenbankzugriffe Zeit kosten. Content-Management-Systeme behelfen sich, indem sie die aus der Datenbank geholten Inhalte als Dateien auf dem Server zwischenspeichern, sodass bei weiteren Seitenaufrufen ein bisschen Zeit gespart wird. Aber wenn dem so ist, dann kann ich meine paar schmächtigen Inhalte doch gleich als Dateien speichern. So sagte ich mir.
Das Blog auf diese Weise zu betreiben, wäre hingegen, wie gesagt, keine Arbeitserleichterung. Obwohl … ich schlafe noch mal ein paar Nächte darüber.
Problem mit HTML5-Video in Opera und Chrome
Ich hatte kürzlich bei der Einbindung eines HTML5-Videos in die Website eines Kunden ein Problem. Es wollte einfach nicht flüssig starten. Ich entwickle Webseiten unter Windows 7 mit Opera und teste erst später mit anderen Browsern. Ich dachte zuerst an einen Fehler in meinem Quellcode, aber der war in Ordnung. Ich zog in Erwägung, dass der Server des Webhosters irgendwie schlecht konfiguriert sein könnte. Aber der Kunde klagte gar nicht über Schwierigkeiten, bei ihm lief das Video wohl ganz normal.
Schließlich testete ich mit Internet Explorer und Firefox. Da lief alles super. Chrome? Dieselben Probleme wie Opera. Nun gut, beide verwenden (in den aktuellen Versionen) dieselbe Rendering-Engine. Opera kann man vernachlässigen, der Marktanteil ist winzig, zumindest für Desktop-Computer – sehr wenige Benutzer verwenden ihn also. Aber in Chrome muss natürlich alles laufen.
Endlich kam ich auf die Idee, mal auf dem anderen Computer unter Linux zu testen. Und siehe da: keine Probleme. Aha, ich testete also, um sicher zu gehen, noch auf dem anderen Windows-Computer und einem der Notebooks, und überall lief alles fehlerfrei. Nach langer Suche im Netz kam mir der Verdacht, dass es an meiner Grafikkarte auf dem betreffenden PC liegen könnte. Ich installierte einen neuen nVidia-Treiber, aber das behob das Problem auch nicht.
Trotzdem: es muss an der Grafikkarte bzw. an nicht gut harmonierenden Hardware-Bauteilen in diesem einen PC liegen. Komisch nur, dass es mir bei anderen HTML5-Videos noch nicht aufgefallen ist. Warum läuft dieses eine einzige Video nicht? Sehr seltsam, das alles.
Solche ungewöhnlichen Phänomene und die damit verbundene Fehlersuche werfen einen natürlich zurück und bringen die ganze Zeitplanung durcheinander. Aber so ist das eben. Ich wollte ja unbedingt Webdesigner werden. 🙁
Nibbleblog: Plugins eindeutschen
Das datenbanklose Blogsystem Nibbleblog hat ein übersichtliches Admin-Backend bzw. Dashboard und ist wunderbar einfach zu bedienen. Hier kann man das – in der Grundeinstellung sehr spartanische – Blog mit Plugins aufpeppen, die sich mit einem einzigen Mausklick installieren lassen. Zum Beispiel lassen sich mit der Erweiterung Categories die Kategorien des Blogs im Frontend anzeigen, und die Besucher können die Artikel dann nach Kategorie filtern.
Allerdings gibt es für die Erweiterungen keine deutschen Sprachdateien, sodass die Beschriftungen im Backend in Englisch sind. Das kann man aber sehr leicht ändern. Man muss dazu per FTP die englische Sprachdatei (plugins/categories/languages/en_US.bit) auf den heimischen PC laden, mit einem Text- oder HTML-Editor öffnen, die englischen Texte durch deutsche ersetzen und die Datei als de_DE.bit speichern. Sie wird anschließend per FTP ins Verzeichnis hochgeladen. Diese .bit-Dateien sind ganz normale PHP-Dateien, nur mit geänderter Endung – warum der Programmierer das so handhabt, ist mir ein Rätsel.
Hier ist ein Beispiel einer deutschen Sprachdatei für das Kategorien-Plugin:
<?php
$_PLUGIN_CONFIG['LANG'] = array(
'NAME'=>'Kategorien',
'DESCRIPTION'=>'Zeigt alle Kategorien deines Blogs an und ermöglicht dem Benutzer, die Artikel nach Kategorie zu filtern.'
);
?>
Wenn das Nibbleblog-System auf die deutsche Sprache umgestellt wurde (Einstellungen -> Ländereinstellung), erscheinen nun im Dashboard Name und Kurzbeschreibung der Erweiterung in Deutsch. Im Frontend hingegen hat sich der Titel, also die Überschrift Categories, dadurch keineswegs geändert. Hier muss man aber noch weniger Hand anlegen, um das zu ändern: Dashboard -> Erweiterungen -> Erweiterungen verwalten -> Kategorien -> Konfigurieren -> Titel, und hier einfach Kategorien eintippen.
Fertig.
Bloggen mit Anchor CMS
Immer mal wieder kommen neue Blogsysteme auf den Markt. Da ich von Natur aus neugierig bin, teste ich immer mal ganz gerne. Vieles enttäuscht mich, aber einiges begeistert mich auch. Von Anchor CMS war ich gleich sehr angetan.
Die Installation geht sehr zügig vonstatten. System-Voraussetzungen sind mindestens PHP 5.3.6 und MySQL 5.2. Gleich bei der Installation kann man einen Administrator-Namen setzen, der aus Sicherheitsgründen bekanntlich möglichst nicht admin lauten sollte. Auch ein Passwort vergibt man selbst, es wird keins automatisch gesetzt. Mich hat ein bisschen gewundert, dass man nicht – wie allgemein üblich – aufgefordert wird, den Installationsordner zu löschen. Ich bin mir nicht sicher, ob der eventuell für spätere Updates benötigt wird und habe ihn zunächst nur umbenannt, sodass er von Fremden nicht erraten werden kann.
Wenn die Installation fertig ist, kann man sich einloggen und eigentlich gleich schon zu bloggen anfangen. Das installierte Standard-Theme kommt angenehm schlicht daher, sodass das Augenmerk auf die Inhalte und nicht das Design gelenkt wird. Auch der Verwaltungsbereich ist sehr aufgeräumt, man findet sich sofort zurecht.
Die Stärke von Anchor CMS liegt in der sehr einfachen Bedienung. Das System ist aufs Nötigste reduziert, es gibt keinen unnötigen, verwirrenden Ballast. Trotzdem findet man alle üblichen Blog-Bestandteile vor: Kategorien, Kommentare, Benutzerrechte. Zum Schreiben von Artikeln lässt sich die vereinfachte Seitenbeschreibungs-Sprache Markdown verwenden, aber auch pures HTML. Für jeden Artikel kann man einstellen, ob Kommentare erlaubt sein sollen oder nicht. Im Konfigurations-Menü lässt sich festlegen, ob man eine E-Mail erhalten möchte, wenn ein Kommentar abgegeben wurde, und auch, ob Kommentare sofort veröffentlicht oder erst geprüft werden sollen.
Ein paar Features fehlen noch, wie etwa eine Dateiverwaltung. Bilder muss man also von Hand per FTP auf den Server laden und dann in den Artikel einbinden. Anchor trägt allerdings auch noch die Versionsnummer 0.9.1 (Stand: November 2013) und es ist zu erwarten, dass noch mehr Funktionalität eingebaut wird. Auch die Möglichkeit, Erweiterungen einzubinden, soll noch geschaffen werden.
Eigene Themes lassen sich mit HTML-, CSS- und ein wenig PHP-Kenntnissen sehr gut erstellen. Es wird auf Smarty oder eine ähnliche Template-Engine verzichtet, und auch sonst ähnelt der Aufbau demjenigen von WordPress. Und ebenso wie bei WordPress lassen sich statische Seiten erstellen, zum Beispiel für ein Impressum. Sicherlich würde sich auch eine herkömmliche Website ohne Blog erstellen lassen, und daher wurde dem Namen Anchor wohl auch der Zusatz CMS verpasst – und ein Blog-System ist natürlich generell auch ein (aufs Bloggen spezialiertes) Content-Management-System.
Mir hat das Testen mit Anchor CMS viel Spaß gemacht, und ich überlege schon, ob und wo ich es vielleicht auch »in echt« einsetzen kann.
Die Syntax im WordPress-Title-Tag optimieren
Meta-Angaben, Seitentitel usw. für ein WordPress-Blog befinden sich ja im Head-Bereich der Theme-Datei header.php. Im Standardfall werden mittels WordPress-Funktionen der Blogname und der jeweilige Seitentitel im Browser ausgeben, was im Quelltext so aussieht:
<title><?php bloginfo('name'); ?> <?php wp_title(); ?></title>.
Wenn man jedoch nur den Titel, nicht aber den Blognamen ausgeben möchte und in den Quelltext
<title><?php wp_title(); ?></title>
schreibt, hat man immer im ausgegebenen Titel ganz links ein Leerzeichen. Vielleicht nicht tragisch, aber auch nicht wirklich sauber.
Gefunden habe ich eine Lösung im Blog des Webentwicklers Oliver Baty aus Chicago. Nein, eigentlich präsentiert er gleich mehrere Lösungen in einem einzigen Blogartikel, aber eine hat mir besonders zugesagt. Man muss nur wenige Zeilen Code in die functions.php im Theme-Ordner einfügen, um die Leerzeichen loszuwerden:
// Leerzeichen im Titel entfernen
function af_titledespacer($title) {
return trim($title);
}
add_filter('wp_title', 'af_titledespacer');
Quelle: ardamis.com/[…]/optimizing-the-syntax-in-the-wordpress-title-tag/
Sechs tödliche Website-Sünden
Auf CMS Critic kann man die sechs schlimmsten Sünden nachlesen, die man begehen kann, wenn man eine Website betreibt und – eigentlich – damit Erfolg haben will. Ich möchte hier weder den ganzen Beitrag vom Englischen ins Deutsche übersetzen und schon gar nicht dem Autor, Daniel Threlfall, den Inhalt klauen, aber aufzählen möchte ich die sechs Sünden dennoch:
- Du hast keine sozialen Medien.
- Du hast kein responsives Design.
- Dein CMS ist veraltet, fehlerhaft oder umständlich.
- Deine Website braucht lange zum Laden.
- Die Suchmaschinenoptimierung kümmert dich nicht.
- Du hast keine rechte Lust, Inhalte zu schreiben.
Zweifelsohne gibt es noch mehr Sünden, die man begehen kann, aber dies sind ganz sicher die tödlichsten. Denn sie führen dazu, dass die Website entweder gar nicht erst gefunden wird oder dass sich die Besucher nicht wohl fühlen und gleich wieder weg sind. Kunden gewinnen kann man auf diese Weise natürlich nicht. Daniel empfiehlt daher, diese Probleme schnellstmöglich aus der Welt zu schaffen.
Und wenn ich so durchs Web surfe, dann stelle ich fest, dass es wirklich viel zu tun gäbe.
Nibbleblog statt FlatPress
Ein Kommentator, der meinen älteren Artikel über das datenbanklose Blogsystem FlatPress gelesen hatte, schrieb, dass FlatPress unter PHP 5.5 nicht läuft. Darüber hinaus gibt es seit Januar 2012 keine Updates mehr, und auch früher schon wurde das System nur sehr zögerlich weiterentwickelt.
Wenn man also über keine MySQL-Datenbank verfügt oder aus anderen Gründen nicht WordPress, Serendipity oder ein anderes der »großen« Blogsysteme verwenden möchte, sollte man statt ausgerechnet FlatPress vielleicht etwas anderes wählen. Ich bin heute auf Nibbleblog gestoßen. Ich habe Nibbleblog (v3.6.1 “Echo”) noch nicht ausgiebig getestet, aber ein bisschen was kann ich schon dazu sagen:
Die Installation ging sehr schnell und einfach vonstatten, den Administratornamen und das Passwort kann man frei wählen. Leider wird die Passwortstärke nicht bewertet. Das Backend macht einen sehr aufgeräumten Eindruck, man findet sich sofort zurecht. Das Bloggen wird einem einfach gemacht, es sind folgende Beitragsarten auswählbar: Einfacher Post, Videopost, Zitat. Drei einfache Designthemen sind enthalten, individuelle sollten sich recht leicht selbst erstellen lassen. Denn es handelt sich bei den Themen um normale PHP-Dateien, die allerdings die Dateiendung .bit tragen, und natürlich CSS-Dateien. Ich habe die meisten der üblichen Blogfunktionen in Nibbleblog vorgefunden, auch eine Spamabwehr (für die man sich einen API-Schlüssel besorgen muss) und einen Atom-Feed. Vermisst habe ich allerdings eine Möglicheit zur zeitgesteuerten Veröffentlichung.
Insgesamt macht Nibbleblog auf mich einen sehr guten Eindruck. Wer schnell ein datenbankloses Weblog auf die Beine stellen möchte, kommt hier quasi im Handumdrehen zum Ziel. Und wer sich mit HTML, PHP und CSS auskennt, kann recht einfach ein eigenes Design erstellen. Selbstverständlich gibt es nicht die Fülle an Erweiterungen und Designvorlagen wie bei bekannteren Systemen.
Angriffe auf Joomla!-Systeme
Einer meiner Webhoster teilte vor wenigen Tagen per Newsletter mit, dass es in den letzten Monaten vermehrt zu Angriffen auf Joomla!-Systeme gekommen ist. Betroffen sind anscheinend vor allem Installationen, die vor Dezember 2012 gemacht wurden und den JCE (Joomla Content Editor) verwenden. Genaueres dazu ist unter folgenden Links nachzulesen:
www.joomla.de/[…]/171-sicherheitslücke-im-jce-editor.html
www.joomlacontenteditor.net/news/item/jce-231-released
Wie schon auf WordPress-Systeme kommt es nun auch vermehrt zu Brute-Force Angriffen auf die Joomla!-Administrator-Seite. Die sicherste Abwehr dürfte auch hier neben einem guten Passwort (sinnlose Zeichenkette aus mindestens zehn Zeichen, bestehend aus Groß- und Kleinbuchstaben, Ziffern und Sonderzeichen) ein zusätzlicher Passwortschutz per .htaccess-/.htpasswd sein.