Logo von Mediengestaltung Torsten Kelsch

Concrete5, Version 8: Absenderadresse des Kontaktformulars

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.

Pagekit: Meta-Beschreibung nachrüsten

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.

concrete5: Nicht die Willkommens-Seite nach dem Einloggen anzeigen

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.

Willkommen zurück
(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.

Weiterleitung nach der Anmeldung

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.

Benutzer weiterleiten zu

Gefunden habe ich diese Lösung im Forum von concrete5.

concrete5: RSS-Feed eigener Inhalte einrichten

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.

Seitenliste-Block: RSS-Feed anzeigen

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.

Seitenliste-Block: RSS-Symbol

Siehe auch: concrete5-Forum

TextPress

TextPress ist ein datenbankloses Blogsystem, das ich Mitte 2016 getestet habe. Bevor ich meine Testinstallation vom Server schmeiße, will ich aber noch kurz über meine Erfahrungen schreiben.

Ist TextPress denn gut?

Berechtigte Frage, denn TextPress gehört ganz sicher nicht zu den bekannten und relevanten Blogsystemen, und da sollte man vorsichtig sein, bevor man so etwas produktiv einsetzt. Warum ich mich dann überhaupt damit befasse, ist leicht beantwortet: Ich bin neugierig, probiere gern Dinge aus und bin so auch schon öfters auf gute Software jenseits des Mainstreams gestoßen.

Und wie handhabt man es?

Wie oben schon gesagt, ist TextPress ein Blogsystem, das ohne Datenbank auskommt, also ein sogenanntes Flat-File-System. So weit, so gut. Es gibt allerdings auch kein Backend, was ich so nur bei wenigen anderen kleinen Systemen vorgefunden habe. Statt dessen schreibt man die Beiträge auf dem lokalen Computer mit einem Texteditor in Markdown-Syntax, speichert sie als Reintextdateien ab und lädt diese per FTP-Client, zum Beispiel FileZilla, auf den Server hoch. Das mag für Webdesigner in Ordnung sein; für Personen, die nicht sehr web-affin sind, ist so etwas natürlich kaum brauchbar. Dazu kommt, dass TextPress von einem einzelnen Entwickler programmiert wird, keine nennenswerte Community hat und die Dokumentation spärlich ist.

Ein weiteres Manko ist, dass TextPress sich nicht in ein Unterverzeichnis installieren lässt, ohne dass es Chaos mit den Pfaden gibt. Jedenfalls habe ich es nicht geschafft, die Konfigurations-Datei und die .htaccess-Datei entsprechend korrekt einzustellen – irgendetwas klappte immer nicht. Bei einer Installation in eine Subdomain anstatt in ein Unterverzeichnis läuft aber alles, wie es soll.

Menüeinträge werden leider nicht automatisch generiert, was ich eigentlich von einem CMS erwarte; natürlich kann man sie mit ein bisschen Handarbeit anlegen. Doch auch sonst nimmt einem die Software nicht wirklich viel Arbeit ab. Gut finde ich eigentlich nur, dass man Blogartikel in der einfachen Markdown-Syntax schreiben kann und TextPress dieses Markdown dann in HTML konvertiert. Doch das bieten heutzutage diverse andere Blog- und Inhaltsverwaltungs-Systeme auch.

Fazit, Quellen, Alternativen

Fazit: Textpress ist so la-la bis och-nö.

Information (in englischer Sprache): textpress.shameerc.com
Download: github.com/shameerc/TextPress

Alternativen: Bludit, Fansoro, HTMLy, Mecha oder Monstra, die ich nach und nach hier kurz vorstellen werde.

Kanboard: There is no suitable CSPRNG installed on your system

Kanboard ist eine Projektverwaltungs-Software, die sich am Kanban-Prinzip orientiert. Sie ist Open Source und lässt sich auf dem eigenen Webserver installieren; ein Standard-Hosting-Paket mit PHP und MySQL/MariaDB, PostgreSQL oder SQLite 3 reicht aus.

Nach dem Update von einer ziemlich alten auf eine neue Version wurde meine Kanboard-Installation nicht mehr angezeigt. Statt dessen war die Fehlermeldung zu lesen: There is no suitable CSPRNG installed on your system. Bei meinen Recherchen fand ich heraus, dass es mit den Pfad-Einstellungen zu temporären Dateien oder mit der open_basedir-Restriktion zu tun haben könnte – beides PHP-Konfigurationen. Aber entsprechende Änderungen an den Einstellungen über die Verwaltungsoberfläche meines Webhosters halfen nicht.

Was man tun kann, wird in den FAQ von Kanboard erläutert. Darauf stieß ich, als ich die Dokumentation von Kanboard durchsuchte. Eine der Möglichkeiten besteht darin, die Domain oder Subdomain von PHP 5 auf PHP 7 umzustellen. Und das war die Maßnahme, die bei mir auch funktionierte.

Lokale Web-Entwicklungsumgebung: Z-WAMP statt Wamp-Server

Um PHP-Dateien und Datenbankzugriffe auf dem lokalen PC testen zu können, installiert man sich ja bekanntlich eine Entwicklungsumgebung. Man kann alles einzeln installieren, also zum Beispiel den Apache-HTTP-Server, einen MySQL- oder Maria-Datenbankserver und natürlich die Programmiersprache PHP. Der Konfigurationsaufwand ist allerdings beträchtlich, und so greift man doch lieber zu einem fertigen Paket. Solche Pakete nennen sich WAMP (Windows-Apache-MySQL/MariaDB-PHP), LAMP (Linux-etc.) und MAMP (Mac-etc.).

Bisher hatte ich immer Wamp-Server benutzt, das auf zwei PCs gut lief. Doch nachdem ich den zweiten Rechner von Windows® 7 auf 10 umgestellt hatte, wollte der Apache-Teil dieses Wamp-Servers nicht mehr laufen, der Apache-Dienst ließ sich einfach nicht starten. Aber es gibt ja noch etliche andere WAMP-Stacks. Der Uniform Server gefiel mir ganz gut, ebenfalls der EasyPHP Devserver, aber letzten Endes landete ich bei Z-WAMP und blieb begeistert an ihm hängen.

Z-WAMP benötigt keine Installation. Man entpackt eine Zip-Datei und das war’s. Die Konfiguration beschränkte sich in meinem Fall darauf, in der Apache-Konfigurationsdatei anzugeben, welches Verzeichnis als localhost anzusehen ist, und dann noch die Datenbanken aus dem alten Wamp-Server-Ordner in den Z-WAMP-Unterordner vdrive\.sys\mysql\data zu kopieren. Ach ja, die bisherigen Datenbankbenutzer mussten noch neu eingerichtet werden. Übrigens, man sollte alle eventuell noch vorhanden vorherigen WAMP-Installationen deinstallieren, um Konflikte zu vermeiden. Die Datenbanken waren bei der Deinstallation von Wamp-Server sogar erhalten geblieben, aber natürlich sollte man (nicht nur vor solchen Aktionen) immer zuverlässige Backups angefertigt haben (externe Festplatte, FTP-Server, …).

Z-WAMP startet sehr schnell und lief bisher auf beiden Rechnern zuverlässig.

URLs mit oder ohne Querstrich am Ende

Bei einem Blick auf die Adressleiste des Browsers fällt auf, dass viele Blog- und Content-Management-Systeme die Webseiten an den Webbrowser ohne Dateiendung ausliefern, also ohne .html oder .php.

Nun kann es Fälle geben, wo Teile des Webauftritts, etwa ein Blog oder Newsbereich, über ein CMS laufen, daneben aber auch statische, von Hand erstellte Seiten existieren. Wir wollen nicht über den Sinn oder Unsinn solcher gemischten Umgebungen diskutieren – Gründe kann es verschiedene geben.

In einem anderen Artikel hatte ich schon darüber geschrieben, wie man die Anzeige der Dateiendungen unterdrückt. Das hat bei mir übrigens bei einem Webhoster funktioniert, bei einem anderen nicht.

Heute soll es darum gehen, wie man einen Schrägstrich am Ende des URL erzeugt oder entfernt (um die statischen Seiten in der Adresszeile des Browsers genauso aussehen zu lassen wie die durchs CMS erzeugten Seiten). Und das bewerkstelligt man dadurch, dass man folgenden Code in die Datei .htaccess (im Falle eines Apache-HTTP-Servers) einträgt:

Ohne Trailing-Slash:
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)/$ /$1 [L,R=301]

Mit Trailing-Slash:
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*[^/])$ /$1/ [L,R=301]

Quelle des Codes: Stack Overflow

Dateiendung .php aus dem URL entfernen

Viele Content-Management-Systeme bieten an, die Dateiendung .php aus dem URL, also aus der Webadresse, zu entfernen. Mit einem Mausklick ist das in aller Regel erledigt. Dies kann aus verschiedenen Gründen gewünscht sein. Was aber, wenn man ein Webseite von Hand erstellt hat und ohne CMS arbeitet?

Des Rätsels Lösung ist ein Eintrag in der Datei .htaccess, die auf Apache-HTTP-Servern üblich ist und verschiedenste Anweisungen enthalten kann. Die wenigen Zeilen Code, die man eintragen muss, lauten folgendermaßen:

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME}.php -f
RewriteRule ^([^/]+)/$ $1.php

Quelle:
Diesen Tipp von Dejan Jacimovic habe ich gefunden auf StuntCoders.