Antispam Bee ist ein beliebtes Plugin für WordPress. Man kann wirklich sagen, dass es sich hierbei um eine fleißige Biene im Bereich der Bekämpfung von Spam-Kommentaren handelt. Es lassen sich diverse Filterkriterien ein- oder ausschalten und konfigurieren.
Besonders mächtig sind die sogenannten Regulären Ausdrücke oder Regular Expressions, denn damit kann man Spam anhand von selbst festgelegten bösen Wörtern im Absender, der angegebenen Webadresse oder im Kommentartext ausfiltern.
Im vorigen Artikel, Concrete5 in Version 8.x läuft nicht unter PHP 7, hatte ich beschrieben, dass ich bei einem bestimmten Webhoster concrete5 in den aktuellen Achter-Versionen unter PHP 7 nicht ans Laufen kriege. Nach Inanspruchnahme des Supports von Webhoster.de AG fiel bei mir endlich der Groschen, sodass ich heute die Lösung präsentieren kann:
Im Plesk-Backend hat man die Möglichkeit, bestimmte PHP-Einstellungen zu verändern. Wichtig im Falle des im vorigen Artikel beschriebenen Problems ist die Einstellung session.save_path. Läuft die Website unter concrete5 8 und PHP 7, muss hier stehen: {WEBSPACEROOT}{/}{:}{TMP}{/}
Unter concrete5 6 und PHP 5 muss hingegen eingetragen sein: /var/lib/php/session
Bei anderen Webhostern gibt es möglicherweise andere Lösungswege, vielleicht wird als Backend etwas anderes als Plesk eingesetzt, und oft kann man als Kunde auch gar nichts an den PHP-Einstellungen ändern. Dann muss man Kontakt zum Support aufnehmen.
Zu bemerken wäre noch, dass nach meinen Erfahrungen concrete5 6 nicht mit PHP 7 läuft, sondern nur mit PHP 5; concrete5 7 hingegen müsste mit PHP 7 laufen. Allerdings sollte man am besten auf den aktuellen Zweig 8 von concrete5 umstellen – dies ist die fortschrittlichste und leistungsfähigste Version und wird ständig weiterentwickelt.
Nachtrag 1: Inzwischen habe ich eine Lösung gefunden, die ich im Artikel Lösung: concrete5 in Version 8 unter PHP 7 vorstelle.
Nachtrag 2: Im Kommentar hat jemand von concrete5.de eine Lösung vorgeschlagen, die meiner oben erwähnten ähnelt:
Den Session Handler in die Datenbank zu packen, ist keine gute Idee, dies würde die Datenbank unnötig belasten.
Die Fehlermeldung haben wir oft bei Servern erlebt, die PLESK nutzen. Da /var/lib/php/session direkt unter dem Root-Verzeichnis des Servers abzulegen ist, ist es, wegen Schreibrechte, unmöglich dort die Sessions abzulegen. Man kann entweder die Schreibrechte des Ordners session ändern, oder einfacher, die Sessions woanders speichern. Beispiel: var/lib/php/session ohne Anfangs-Slash, dann wären die Sessions im relativen Pfad.
Wahrscheinlich hängt es vom Webhoster und dessen Einstellungen ab, aber bei einem bestimmten Hoster kriegte ich concrete5 in den aktuellen Versionen 8.x und unter PHP 7.x nicht ans Laufen. Es erschien beim Installationsversuch die Fehlermeldung:
is_dir(): open_basedir restriction in effect. File(/var/lib/php/session) is not within the allowed path(s): (/var/www/vhosts/[…]/:/tmp/).
Nun existiert zwar eine Lösung hierfür. Bei der Installation gibt man an, dass die Sessions nicht in Dateien, sondern in der Datenbank gespeichert werden sollen:
(Aufs Bild klicken zum Vergrößern)
Zusätzlich erstellt man eine Datei namens concrete.php, schreibt dort das Folgende hinein und lädt sie nach /application/config hoch:
<?php
return array(
'session' => array(
'handler' => 'database'
)
);
Doch das half in einem meiner Fälle auch nicht; concrete5 ließ sich einfach nicht installieren, sondern erst dann, als ich auf die ältere PHP-Version 5.6.32 umgeschaltet hatte.
Es war auch schon einmal vorgekommen, dass mit den oben genannten Workarounds concrete5 sich zwar nicht in ein Unterverzeichnis und auch nicht in eine Subdomain installieren ließ, jedoch in den Hauptbereich. Warum mal dieses, mal jenes und mal gar nichts funktioniert, noch zumal bei demselben Webhoster, will sich mir einfach nicht erschließen. Ich erkenne kein Muster. Und nach mehrmaligen stundenlangen Fummeleien schwindet natürlich auch so langsam meine Begeisterung für dieses CMS.
Das Galerie-Plugin 2J Gallery für WordPress führte in meiner Testumgebung dazu, dass die Absätze, die im WordPress-Editor eingegeben worden waren, im Frontend nicht mehr angezeigt wurden. Ein Blick in den Quelltext zeigte, dass das Element <p></p> im gesamten Blog völlig fehlte, weswegen also auch keine Absätze gebildet wurden. ›Nicht gut‹, dachte ich mir. Die Deinstallation des Plugins ließ die Texte wieder normal aussehen.
Kürzlich habe ich ein sehr schlankes, ja geradezu minimalistisches Blog-Management-System gefunden, das vermutlich noch recht neu ist, und es nennt sich minim – der Name ist offensichtlich Programm. Es ist in PHP programmiert, datenbanklos, lizenzkostenfrei verwendbar und quelloffen. Jeder, der über genügend PHP-Programmierkenntnisse verfügt, kann minim also an seine Bedürfnisse anpassen oder weiterentwickeln (und in solcher erweiterten Fassung auch wieder der Gemeinschaft zuführen).
Nachtrag: Es gibt einen neueren, ergänzenden Artikel zu minim.
Es gibt zwar ein Backend, das man bei Bedarf in der Datei config.php aktivieren kann, aber im Backend findet man keinen Editor, mit dem man seine Blogartikel schreiben könnte (man kann nur wenige Dinge tun wie etwa Artikel löschen). Statt dessen benutzt man einen lokalen Reintext-, Markdown- oder HTML-Editor, speichert den erstellten Blogbeitrag lokal ab und lädt die Datei im Markdown-Format und mit der Dateiendung .md per FTP in das Verzeichnis entries hoch. Am besten vergibt man als Dateinamen Nummern oder kalendarische Angaben wie Y-m-d; die Artikel werden nämlich anhand der Dateinamen absteigend sortiert.
Ein RSS-Feed wird automatisch erstellt und ist erreichbar, indem man an den URL /?rss anhängt (oder falls minim in einem Unterverzeichnis installiert ist, eben /minim/?rss). Ich habe testweise einen solchen Feed abonniert (in Thunderbird), und er wird einwandfrei erkannt und angezeigt.
Zu Recht könnte man fragen, ob minim nicht einfach nur ein neues, datenbankloses Blogsystem ist, das von der Welt nicht gebraucht wird. Und, zugegeben, es ist sicherlich nichts für Leute, die sich die üblichen Blog-Funktionalitäten wünschen.
Suchmaschinen-Optimierung dürfte mit minim unmöglich sein. Die URLs werden gebildet durch solche schrecklichen Dinge wie /?entry1 – hübsch, suchmaschinenrelevant und benutzerfreundlich kann man das nicht nennen. Und da eine Kommentarfunktion fehlt, dürfte es schwierig werden, eine Blogger-Gemeinschaft mit gegenseitiger Verlinkung aufzubauen.
Ferner vermisst man auch Kategorien und Verschlagwortung, was von vielen Benutzern wohl als zu einem Blog gehörend erachtet wird. Doch vielleicht kommen in folgenden Versionen ja solche Funktionen noch nach und nach dazu.
Dennoch: Ich meine, auch so ein extrem schlankes Blogsystem hat seine Daseinsberechtigung. Im Falle eines privaten, persönlichen Blogs ist nicht jedem die Auffindbarkeit in den Suchmaschinen wichtig. Vielleicht soll es ja noch nicht einmal öffentlich sein; man könnte es über Webserver-Einstellungen gegen fremden Zugriff schützen (.htpasswd-Datei im Falle eines Apache-HTTP-Servers). Und natürlich wäre auch ein Tagebuch auf dem lokalen PC denkbar – vorausgesetzt, ein lokaler Webserver und PHP sind installiert.
Aufgesetzt ist minim jedenfalls extrem schnell, und wer sich mit Markdown auskennt, wenn nicht gar mit HTML, kann in Nullkommanichts anfangen, Artikel zu schreiben.
Fazit: In bestimmten Fällen geeignet.
Ich bin kürzlich auf das Blogsystem Chyrp Lite gestoßen, und es hat mich zunächst begeistert. Doch die Begeisterung wurde ein wenig getrübt, als ich auf einige Schwachstellen stieß.
Chyrp Lite ist ein Fork des nicht mehr weiterentwickelten Blogsystems Chyrp. Es ist leichtgewichtig, wurde in PHP programmiert und ermöglicht das Schreiben von Artikeln auf einfache, intuitive Weise. Die Installation ging tatsächlich schnell und einfach. Chyrp Lite benötigt eine Datenbank, man kann sich zwischen SQLite und MySQL/MariaDB entscheiden.
Nach der Installation meldete ich mich am System mit den von mir vergebenen Daten an und konnte gleich schon loslegen. Man versteht das System sofort, auch wenn es keine deutsche Übersetzung gibt. Der Adminbereich kommt sehr aufgeräumt und übersichtlich daher. Er ist in die vier Bereiche Write, Manage, Settings und Extend aufgeteilt, die sich ja von selbst erklären. Der Bereich Write ist natürlich derjenige, der später am häufigsten benutzt werden wird. Er ist per Registerkartenreiter in Page und Text unterteilt, sodass man sehr einfach sowohl Seiten als auch Blogartikel erstellen kann. Beide werden nach Veröffentlichung automatisch in der Navigation angezeigt, die bei dem Standard-Theme in der linken Seitenleiste zu sehen ist.
Chyrp Lite ist mehrbenutzerfähig. Vorgegebene Gruppen sind Admin, Member, Friend, Banned und Guest. Ferner gibt es eine Import- und Exportfunktion, die ich allerdings nicht ausprobiert habe. Importiert werden können Beiträge und Seiten im ATOM-Format und Benutzer und Gruppen im JSON-Format – vermutlich nur aus anderen Chyrp-Lite-Installationen, vielleicht aber auch aus dem eingestellten Chyrp.
Doch nicht alles ist ganz rund bei Chyrp Lite. Die zunächst aufs Nötigste beschränkte Funktionalität lässt sich über mitgelieferte Erweiterungen ausbauen. Ich habe zuallererst die Kategorien aktiviert, aber ich finde keinen Weg, welche anzulegen. Das soll zwar im Adminbereich unter Manage machbar sein, aber dort gibt es so eine Möglichkeit gar nicht. Das ist natürlich blöd. Ein Blogsystem ohne Kategorien ist für mich im großen Ganzen nicht vollständig. Sicherlich kann man Kategorien über die Datenbank handhaben, aber das kann ja nicht der Sinn der Sache sein, und ob sie dann im Adminbereich auch selektierbar sind und alles so funktioniert, wie es soll, weiß ich nicht.
Nachtrag (August 2019): Der Gruppe, die Kategorien anlegen können soll, muss die entsprechende Berechtigung gegeben werden (Administration > Verwalten > Gruppen). Dass der Gruppe Administratoren diese Berechtigung nicht standardmäßig zugeordnet wird, wundert mich allerdings.
Ferner kommen sich wohl bestimmte Erweiterungen untereinander in die Quere: Das Modul Pingable, das Pingbacks ermöglicht, versteht sich nicht mit dem Modul Comments. Was eventuell sonst noch nicht richtig klappt, kann ich noch nicht sagen, da ich Chyrp Lite bisher nur recht oberflächlich getestet und noch nicht auf Herz und Nieren geprüft habe. Aber die genannten Punkte sind für mich eigentlich schon K.O.-Kriterien genug, da es ja nicht gerade einen Mangel an leistungsfähigen Blog-Engines gibt. Man muss allerdings zu Gute halten, dass Chyrp Lite ja noch sehr jung ist. Die Fehler werden hoffentlich nach und nach beseitigt werden, denn Potenzial hat dieses schlanke Blogsystem.
Auch werden keine Sprachdateien außer Englisch mitgeliefert, sodass die Oberfläche, sowohl im Frontend als auch im Backend, nicht beispielsweise auf Deutsch umgeschaltet werden kann. Wer will, kann sich aber die Mühe machen, selber Sprachdateien zu erstellen, und zwar im POT-Format, zum Beispiel mit Poedit.
Nachtrag (August 2019): In Version 2019.02 werden neben Englisch die Sprachen Deutsch, Italienisch und Chinesisch mitgeliefert.
Was mir nicht ganz klar ist: Es gibt als Erweiterungen sowohl Modules als auch Feathers. Was nun der Unterschied sein soll und warum man überhaupt eine Unterscheidung vorgenommen hat, verstehe ich hier genauso wenig, wie ich es etwa bei Joomla! verstehe. Etliche andere Content-Management-Systeme unterscheiden da nicht, da sind eben alles Add-ons, Plug-ins oder wie auch immer sie jeweils genannt werden.
Chyrp Lite ist schnell aufgesetzt, einfach zu bedienen und im Vergleich zu alten, etablierten Blogsystemen sehr leichtgewichtig (Vergleich: Chyrp Lite 863 Dateien der Gesamtgröße 4,4 MB, WordPress 1645 Dateien der Gesamtgröße 25,7 MB). Es gibt einige Erweiterungen und eine Handvoll Themes (= Motive, Gestaltungen, Erscheinungsbilder). Das ist nichts im Vergleich zu der Fülle an Zusätzen, die es etwa für WordPress gibt, aber ein Dschungel aus Tausenden von Erweiterungen ist ja auch nicht wirklich notwendig. Wer also schnell zu einem intuitiv zu bedienenden, schlanken Blog kommen will und milde über die paar momentan noch vorhandenen Kinderkrankheiten (Stand: September 2017) hinwegsehen kann, sollte sich Chyrp Lite einfach mal anschauen.
Im Jahr 2012 schrieb ich in meinem Artikel concrete5: Absender im Kontaktformular (2), dass standardmäßig die Absenderadresse des Kontaktformulars von concrete5 diejenige des Superadministrators ist. Der dürfte in vielen Fällen ein Webdesign-Dienstleister sein. Natürlich soll der Absender die E-Mail-Adresse des Kunden, nicht die des Dienstleisters sein – also die Adresse des Website-Inhabers. Mein damaliger Lösungsvorschlag hatte sich auf die concrete5-Version 5.6 bezogen. In den aktuellen Achter-Versionen muss man ein wenig anders vorgehen. Hier die Lösung für concrete5 in der Version 8:
Es muss eine PHP-Datei im Ordner application/config erstellt werden mit dem Dateinamen concrete.php, und diese muss folgenden Code beinhalten:
<?php
return array(
'email' => array(
// The system default sender (Group A)
'default' => array(
'address' => 'info@domain.de',
'name' => 'Unternehmensname', // this can be left out
),
// The individual senders (Group B)
// Form block:
'form_block' => array(
'address' => 'info@domain.de',
),
// User registration email validation messages
'validate_registration' => array(
'address' => 'info@domain.de',
'name' => 'Unternehmensname', // this can be left out
),
// Forgot password messages
'forgot_password' => array(
'address' => 'info@domain.de',
),
),
);
Die Beispiel-Daten, info@domain.de und Unternehmensname, müssen natürlich durch die echten Daten ersetzt werden. Die Datei kann bei Bedarf weitere Einträge für andere Konfigurationszwecke beinhalten.
Bei der Analyse einer bestimmten Website mit Seitwert stellte sich heraus, dass die Meta-Beschreibung (description) fehlte, die relevant für Suchmaschinen ist. Die Website wird mit dem CMS Pagekit betrieben, und seltsamerweise fügt dieses CMS zwar die Beschreibungen, die man im Backend eingibt, als og:description in den Quellcode ein (das Open-Graph-Protokoll ist von Bedeutung für soziale Medien), aber eben nicht als herkömmliche Meta-Beschreibung.
Dieses Manko kann man durch das Plugin Metadesc beheben, das es erst seit März 2017 gibt – es ist also zu dem Zeitpunkt, da ich diesen Blogartikel schreibe, noch sehr neu. Ich habe es erst heute entdeckt und gleich eingebaut – und es funktioniert wunderbärchen.
Standardmäßig ist das Web-CMS concrete5 so eingestellt, dass der Benutzer nach dem Einloggen ins System auf einer Art Willkommens-Seite landet, dem sogenannten Schreibtisch. Dort erhält man allerlei Informationen rund um concrete5, zum Beispiel, was es für Sonderangebote gibt, welche Erweiterungen gerade im Fokus stehen oder welche Tutorien aktuell angeboten werden.
(Aufs Bild klicken zum Vergrößern)
Wen das alles nervt, der kann concrete5 in der Version 8 sehr einfach so einstellen, dass man auf der Startseite landet oder einer beliebigen anderen (in früheren Versionen musste man eine Konfigurationsdatei ändern). Dazu meldet man sich am System an und navigiert zu System & Einstellungen > Anmeldung & Registrierung > Weiterleitung nach der Anmeldung. Und dort kann man dann eine von drei Möglichkeiten auswählen.
Wie gesagt, voreingestellt ist Schreibtisch, und ich stelle gewöhnlich um auf Startseite. Dann sieht man die Startseite des Webauftritts vor sich, da das Dashboard in concrete5 ja kein abstraktes Backend ist, sondern man immer die Seiten in der »echten« Ansicht vor sich sieht.
Gefunden habe ich diese Lösung im Forum von concrete5.
Mit dem CMS concrete5 lassen sich die unterschiedlichsten Webauftritte realisieren. Es bietet auch die Möglichkeit, ein Blog oder einen News-Bereich einzurichten – allerdings ist das meiner Ansicht nach in concrete5 nicht wirklich elegant gelöst und intuitiv genug. Es gibt Add-ons für diesen Zweck, aber auch mit Bordmitteln kriegt man es hin. Gewöhnlich bietet man mit einem Blog oder Neuigkeiten-Bereich auch einen RSS-Feed an, sodass Interessierte anonym die aktuellen Nachrichten abonnieren können. Wie man so einen Feed in concrete5 einrichtet, darum geht es in diesem Beitrag.
Kurz ein paar Sätze zur Erklärung: Ein Weblog ist in aller Regel so strukturiert, dass jeder Artikel eine eigene Seite ist und die Blog-Startseite eine bestimmbare Anzahl aktueller Artikel auflistet. Ein Umwandler ruft nun diese HTML-Seiten auf und baut sie in ein XML-Format um, wodurch die Daten so aufbereitet werden, dass Feed-Leseprogramme die Struktur erkennen und die Inhalte darstellen können. Das Design der Webseite ist in der XML-Datei nicht enthalten, und jeder Feed-Reader gestaltet die Artikel etwas unterschiedlich.
Doch jetzt zur Sache, Schätzchen! Wie setzen wir so etwas in concrete5 um? Nun, wir erstellen erst einmal eine Seite, die als Blog-Startseite dienen soll. Zu dieser Seite können wir schon einmal eine oder zwei Unterseiten als Dummys erstellen und ein bisschen Beispieltext hinein schreiben. Auf die Blog-Startseite kommt nun ein Seitenliste-Block, der die Unterseiten auflisten soll. Es sind etliche Einstellungen vorzunehmen; wichtig in diesem Zusammenhang hier ist, dass bei RSS-Feed anzeigen die Wahlmöglichkeit Ja ausgewählt wird.
Nachdem die Seitenliste fertig eingerichtet worden ist, zeigt sich das RSS-Symbol neben der eigentlichen Liste. Benutzer können nun den Feed in ihrem Feed-Reader abonnieren.
Siehe auch: concrete5-Forum