Logo von Mediengestaltung Torsten Kelsch

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.

Alle Feeds in WordPress deaktivieren

Wenn man WordPress nicht zum Bloggen verwendet, sondern als Content-Management-System für eine sozusagen klassische Website ohne Blog- oder Newsbereich (was ich wohl nie tun würde, da es für diesen Zweck meines Erachtens ganz einfach geeignetere Systeme gibt), dann wird man in aller Regel auch keinen Feed anbieten wollen.

Doch wie kann man die Feedfunktion in WordPress komplett ausschalten? Die Antwort gibt uns Vladimir Simovic auf Perun.net in seinem Artikel WordPress: alle Feeds deaktivieren. Vielen Dank dafür!

WordPress-Suchmaschine für Entwickler

Kürzlich habe ich eine auf WordPress spezialisierte Suchmaschine namens WPSeek.com für Plugin-Entwickler und Theme-Autoren entdeckt. Hier kann man in ein Suchfeld WordPress-Funktionen, Filter, Aktionen und Konstanten eingeben, zu denen man nähere Informationen wünscht.

Nun ist es bloß leider so, dass einem ja die genauen Namen meistens nicht geläufig sind. Doch die Suchmaschine findet natürlich auch etwas, wenn man nur ein Wort eingibt, zum Beispiel category. Dann klappt unter dem Eingabefeld eine Liste der gefundenen Begriffe auf – und schließt sich nach kurzer Zeit wieder. Dumm, wenn man so schnell nicht auf einen der verlinkten Begriffe geklickt hat. Und komischer Weise passiert nichts, wenn man dann rechts neben dem Suchfeld das Lupensymbol anklickt; betätigt man allerdings die Eingabetaste, während der Cursor im Textfeld steht, wird unter dem Suchfeld eine Liste mit Vorschlägen ausgespuckt. Dieses Bedienkonzept ist meiner Meinung nach verbesserungswürdig. Doch auf jeden Fall findet man hier eine ganze Menge an Informationen und Quellcodes.

Meine ersten Anlaufstellen werden aber vermutlich immer die offizielle WordPress-Code-Dokumentation namens Codex sowie die Code-Referenz bleiben. Auf diesen beiden Plattformen findet man eigentlich alles, was man sucht und braucht.

Veröffentlichungsdatum in Nibbleblog nachträglich ändern

Wie kann man das Veröffentlichungsdatum eines Artikels im Blogsystem Nibbleblog nachträglich ändern? Diese Frage ist bei einem meiner Leser aufgetreten. Der Grund, warum das Datum überhaupt geändert werden soll, soll uns hier nicht interessieren, sondern allein die Frage, wie so eine Änderung zu bewerkstelligen ist.

Nibbleblog zeigt ja im Frontend das Veröffentlichungsdatum der Blogbeiträge an. Auch im Backend sieht man dieses Datum. Nur – wie kann man dieses nachträglich ändern? Denn eine Einstellungsmöglichkeit ist zunächst nicht vorhanden, das heißt, standardmäßig nicht voreingestellt (die mir vorliegende Version ist Nibbleblog 4.0.5 vom September 2015).

Nun, man muss dazu eine bestimmte Einstellung ändern. Man setzt ein Häkchen unter Dashboard > Einstellungen > Erweiterte Blogoptionen > Erweiterte Optionen für Posts. Fertig, das war’s. Jetzt erscheinen im Bearbeitungsmodus eines Blogartikels zusätzliche Optionslisten für das einzustellende Jahr, den Monat usw.

Nibbleblog: Erweiterte Otionen für Posts (1)

Nibbleblog: Erweiterte Otionen für Posts (2)

Kann man also auch Artikel vorfertigen, sodass sie erst zu einem späteren Zeitpunkt veröffentlicht werden? Die Antwort lautet: Nein. Denn erstens werden die Optionen zum Einstellen des Veröffentlichungszeitpunkts erst dann angezeigt, wenn ein als Entwurf gespeicherter oder bereits veröffentlichter Artikel erneut zum Bearbeiten geöffnet wird. Und zweitens nützt es auch gar nichts, das Datum vorzuverlegen, da der Artikel trotzdem gleich dann veröffentlicht wird, wenn man auf Veröffentlichen klickt. Das empfinde ich als Manko, weil ich es zum Beispiel von WordPress her gewohnt bin, mehrere Artikel auch schon mal an einem Stück zu schreiben, aber erst zeitversetzt veröffentlichen zu lassen.

Einbruchsversuche in WordPress-Blogs

In letzter Zeit (September 2015) bemerke ich wieder verstärkt Einbruchsversuche (Brute-Force-Attacken) in eigene oder von mir betreute WordPress-Blogs von unzähligen IP-Adressbereichen weltweit.

Die Benachrichtigungen bekam ich über das installierte Plugin Login Security Solution. Das Seltsame ist nur, dass ich per .htaccess-Datei den Zugriff auf die Datei wp-login.php auf den von meinem Internet-Service-Provider vergebenen IP-Adressbereich beschränkt habe (im Beispiel durch x symbolisiert):

# --- Adminbereich absichern ---
<Files wp-login.php>
Order Deny,Allow
Deny from all
Allow from xx.xxx.
</Files>

Also sollte doch ein Bot, der von einem anderen IP-Bereich aus angreift, gar nicht bis zur Login-Datei gelangt sein dürfen. Falls jemand eine Idee oder einen Hinweis hat, wäre es nett, dies in den Kommentarbereich zu schreiben.

Ich habe jetzt eine zusätzliche Sicherheit in die .htaccess-Datei geschrieben (wobei für domainname natürlich der richtige, eigene Domainname einzutragen ist):

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{HTTP_REFERER} !^http://(.*)?domainname\.de [NC]
RewriteCond %{REQUEST_URI} ^(.*)?wp-login\.php(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^(.*)?wp-admin$
RewriteRule ^(.*)$ - [F]
</IfModule>

Hoffen wir mal, dass dies bewirkt, dass nun kein Bot mehr von entfernten Domains aus die Blogs angreifen kann.

Eine weitere Möglichkeit wäre folgender Code (die vielen x stehen auch hier für die eigene IP-Adresse, von der aus man sich in sein Blog einloggt):

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_URI} ^(.*)?wp-login\.php(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^(.*)?wp-admin$
RewriteCond %{REMOTE_ADDR} !^xxx\.xxx\.xxx\.xxx$
RewriteRule ^(.*)$ - [R=403,L]
</IfModule>

Und was man noch darüber hinaus tun könnte, wäre, den Adminbereich durch eine weitere Authentifizierung abzusichern.

Das fehlende zweite Argument für wpdb::prepare()

Für eine Kunden-Website mit WordPress-Unterbau hatte ich einmal eine kleine Daten­bank­anwendung gebaut: Die Pfade zu den Logos der angeschlossenen Mitgliedsunternehmen wurden automatisch aus den Datensätzen einer Datenbanktabelle ausgelesen und an eine JavaScript-Slideshow weitergereicht. Bei einer Änderung eines Firmenlogos oder bei neu hinzugekommenen oder ausgeschiedenen Unternehmen wird ja sowieso die Datenbank geändert, und nun muss man nicht auch noch von Hand die Diaschau pflegen.

Das klappte auch lange Zeit sehr gut, aber vor einiger Zeit erschien eine Fehlermeldung über der Diaschau: Warning: Missing argument 2 for wpdb::prepare(), called in […]. In WordPress-Versionen ab 3.5 benötigt das $wpdb-Objekt zwei Argumente, vorher hatte eines genügt. Genauer gesagt: im Fall, dass eine WHERE-Klausel gesetzt wurde, werden zwei Argumente benötigt; aber offensichtlich auch, wenn man ORDER BY verwendet. Da es in diesem Fall kein sinnvolles zweites Argument geben kann, setzte ich NULL dahinter, und das Problem war erledigt.

global $wpdb;
$wpdb->show_errors();
$mitglieder = $wpdb->get_results (
    $wpdb->prepare (
        "SELECT logoundinfo
        FROM [Tabelle]
        ORDER BY firmenname ASC", NULL
    )
);

Genauere Angaben zur Verwendung der wpdb-Klasse findet man im sogenannten WordPress-Codex, also der Code-Referenz.

WordPress: Emojis loswerden

Als ich kürzlich in den WordPress-Quelltext einer Kunden-Website schaute, wunderte ich mich über den aufgeblähten Kopfbereich der untersuchten HTML-Datei. Da war ein JavaScript-Code, den ich nicht kannte und der ursprünglich nicht dort gewesen war, und zusätzlich gab es noch ein paar CSS-Angaben. Der Begriff wpemojiSettings fiel mir auf, und ich forschte erst mal nach, was ein Emoji ist. Nun, es ist ein Ideogramm, ähnlich wie ein Smiley oder Emoticon – der Begriff Emoji ist aber weiter gefasst und nicht auf Emotionen beschränkt.

Da ich den Quellcode gern schlank halte, aus Geschwindigkeitsgründen auf alles Überflüssige verzichten möchte und nicht zuletzt der Meinung bin, dass man im geschäftlichen Bereich ganz gut ohne alberne Bildschriftzeichen auskommen kann, stand die zweiteilige große Frage im Raum: »Wie ist der Mist da hinein gekommen und wie werde ich ihn wieder los?«

Die Antwort fand ich auf ehtio.de: Die Emojis kamen mit dem WordPress-Update 4.2, und loswerden kann man sie durch ein wenig Code in der Datei functions.php. Danke an Tim Ehling für seinen Blogartikel und die elegante Lösung!

CSS-Klassen des WordPress-Menüs abspecken

Ich versuche immer, meine HTML- und CSS-Quellcodes schlank zu halten. Erstens, weil man dann bei späteren Bearbeitungen besser durchblickt, und zweitens, weil Suchmaschinen es lieben, wenn Webseiten so beschaffen sind, dass sie deutlich mehr echten Inhalt als Layout-Angaben beinhalten.

Zum Beispiel trägt das benutzerdefinierte Menü von WordPress zu viel Ballast mit sich. CSS-Klassen, die zwar im Quelltext aufgeführt sind, aber gar nicht benötigt werden, blähen Webseiten unnötig auf und sollten entfernt werden. Was kann man tun?

Wie so oft liegt die Lösung darin, Code in die Datei functions.php, die man im Theme-Ordner findet, einzufügen. Aber wie? Das erfährt man von Monika in ihrem Blog texto.de. Da es in deutscher Sprache ist, schlage ich vor, bei Interesse ihren sehr gut erklärten Artikel HTML output von wp_nav_menu verringern zu lesen.

WordPress: Fehlender Home-Link in Navigation

In aller Regel wird man, wenn man ein WordPress-Blog erstellt, keinen Link zur Startseite im Navigationsmenü vorfinden. Man kann aber einen dorthin bekommen.

In dieser Kurzanleitung fangen wir mal ganz bei Null an und basteln uns eine Navigation selbst. Falls sie in dieser Form schon im Theme vorhanden ist, können die Punkte 1 bis 3 übersprungen werden.

Davon ausgegangen, dass es sich sich um ein selbst gehostetes WordPress handelt (also nicht um ein bei WordPress.com eingerichtetes) und dass wir natürlich FTP-Zugriff zum Webserver haben, dann sind folgende Schritte zu unternehmen:

  1. Menü-Funktion hinzufügen

    Um ein benutzerdefiniertes Menü zu ermöglichen, das dann übers Dashboard konfiguriert werden kann, folgenden Code der Datei functions.php im Theme-Ordner hinzufügen:

    add_action( 'init', 'my_custom_menus' );
     
    function my_custom_menus() {
        register_nav_menus(
            array(
                'primary-menu' => __( 'Primary Menu' ),
                'secondary-menu' => __( 'Secondary Menu' )
            )
        );
    }

    In diesem Fall wollen wir zwei Navigationsmenüs haben, eine Hauptnavigation und eine untergeordnete.

  2. Template-Datei modifizieren

    Unser Theme müssen wir jetzt mit den Navigationsmenüs ausstatten; dafür fügen wir folgenden Code ein, im Fall des Hauptmenüs wohl am ehesten in die Template-Datei header.php:
    <?php wp_nav_menu( array( 'theme_location' => 'primary-menu', 'menu_class' => 'primary', 'fallback_cb' => '') ); ?>.
    Mit dem Submenü verfahren wir ähnlich. – In unsere CSS-Datei können wir jetzt die Klasse primary-menu einfügen, um das Navigationsmenü zu gestalten. Die Fallback-Möglichkeit ist für den Fall gedacht, dass es überhaupt kein Menü gibt (weil zum Beispiel gar keine Subnavigation benötigt wird), dann wird nichts angezeigt.

  3. Menü im Dashboard erstellen

    Im Admin-Dashboard der WordPress-Installation klickt man jetzt auf Design > Menüs, wo man jetzt den Menübaukasten sieht. Dort kann man seine Navigationsmenüs auf einfache Weise konfigurieren.

  4. Homepage-Link im Navigationsmenü anzeigen

    Dumm ist nur, dass die Homepage (die Startseite) dennoch nicht in unserer Navigationsleiste angezeigt wird bzw. nicht im Menübaukasten als Menüpunkt erscheint. Auch hier liegt die Lösung darin, dass man die Datei functions.php im Theme-Ordner um etwas Code erweitern muss:

    function home_page_menu_args( $args ) {
        $args['show_home'] = true;
        return $args;
    }
    add_filter( 'wp_page_menu_args', 'home_page_menu_args' );

    Sobald dieser Code eingefügt worden ist, sollte das dazu führen, dass »Home« als Option unter dem »Seiten«-Widget auf der Menü-Verwaltungs-Seite erscheint, sodass man jetzt per Klick entscheiden kann, ob die Startseiten in der Navigation angezeigt werden soll oder nicht.

Quellen:
Box Model Junkie
WPBeginner

AddQuicktag, ein nützliches WordPress-Plugin

Frank Bültge, den man wohl als eines der deutschsprachigen WordPress-Urgesteine bezeichnen darf, hat vor Jahren eine recht lange Liste von nützlichen WordPress-Plugins vorgestellt, die er entwickelt hat, an denen er in irgendeiner Weise mitgewirkt hat oder die er empfiehlt.

Einer meiner Lieblinge ist AddQuicktag. Denn mit den vorgegebenen Quicktags (also den Schaltflächen, mit denen man auf einfache Weise häufig benötigte HTML-Elemente in den Textbereich des Editors einfügen kann) war ich nie so ganz zufrieden. Es fängt ja schon damit an, dass die Buttons b und i die Elemente <strong> und <em> erzeugen. In HTML5 haben aber bold und strong bzw. italic und emphasis völlig unterschiedliche Bedeutungen (was an dieser Stelle nicht näher ausgeführt werden soll). Darüber hinaus fehlen zum Beispiel öfters benötigte Sonderzeichen. Und natürlich wäre es wünschenswert, immer wiederkehrende Code- oder Text-Schnippsel als Schaltflächen in die Menüleiste des Editors aufnehmen zu können.

Mit AddQuicktag ist das alles auf eine sehr leichte Weise zu bewerkstelligen. Dieses Plugin erleichtert mir wirklich die Arbeit und beschleunigt das Erstellen von Blogartikeln.