Alle Artikel zu #programmieren


Blogger-Alphabet: C wie Code

Runde 3 im Blogger-Alphabet, diesmal geht es um ein Thema, das mir wirklich liegt: Den (Programmier-)Code hinter dem Blog. Dank vieler kostenloser Hostingplattformen kann man sich als Blogger ja aussuchen, wie sehr man sich damit beschäftigt, von gar nicht über ein bisschen für das Design oder ein bisschen mehr für Plugins bis sehr intensiv. Das befürworte ich sehr, denn tatsächlich lässt sich ein brauchbarer Blog ohne Programmierkenntnisse erstellen, was die Bloggerwelt denen geöffnet hat, die nicht aus der IT kommen. Dass manche Blogs optisch ein Griff ins Klo sind, ist ein anderes Thema (und bei D wie Design an der Reihe).

Wer nicht programmieren kann, ist allerdings an das System gebunden, das er nutzt, und muss mit dessen Vor- und Nachteilen leben. Ich fing damals mit einem selbst installierten Wordpress auf einem Standard-Webhosting-Paket an, damit war ich schon deutlich freier als man es beispielsweise bei Blogspot wäre, aber Wordpress war mir zu schwerfällig und ich wollte auch auf Serverseite mehr bestimmen können. Letzteres ist inzwischen mit einem eigenen virtuellen Server auch umgesetzt, soll hier aber gar nicht Thema sein.

Mehr Freiheit bei dem Content-Management-System hinter dem Blog gab und gibt mir Habari. Das Projekt ist inzwischen wohl leider als tot anzusehen, da keiner der Hauptentwickler mehr Zeit dafür hat, läuft aber hier noch stabil und wird daher im Einsatz bleiben so lange es geht. Ich habe selbst im Laufe der Jahre zahlreiche Änderungen daran vorgenommen und so manche Funktion hinzugefügt, daher ist mir der Quellcode bestens vertraut. Mein Admin-Backend tut genau das, was ich will. Plugins von anderen Habari-Usern und eigene Plugins geben mir die Funktionalität, die ich brauche, aber nicht mehr. Trotz ziemlich schwachem Server lädt die Seite sehr schnell. Fehlt etwas oder ist etwas defekt, kann ich das selbst lösen. Dass ich schon vor dem Bloggen jahrelang programmierte (nicht nur in PHP, wie es hier verwendet wird, sondern auch in Visual Basic und C#), hat sich also definitiv ausgezahlt.

Habari ist kein System für Leute, die Angst vor der Technik haben. Es bietet standardmäßig nur sehr rustikalen Bedienkomfort, nicht jede Funktion steht in einem Plugin bereit, das sofort funktioniert, und es gibt vergleichsweise wenig fertige Designs zur Auswahl. Das hier verwendete Design habe ich selbst entworfen und programmiert. Wenn man bereits programmieren kann, ist es sehr leicht, sich einzuarbeiten; es gibt auch noch das ein oder andere weitere Design von mir.

Dabei arbeite ich beim Programmieren, ähnlich wie ich meine Beiträge hier ohne grafischen Editor schreibe, mit einer sehr einfach gestrickten Umgebung. Private Projekte werden direkt auf dem Liveserver getestet, berufliche lokal. Beim Texteditor schwöre ich nach wie vor auf Notepad++, für den ich sogar Wine unter Linux installiert habe. Er ist vor allem in der Geschwindigkeit und Zuverlässigkeit ungeschlagen. Darüber hinaus ist die Bedienoberfläche aufgeräumt, der meiste Platz steht dem Code zu, und trotzdem gibt es alle Funktionen, die ich mir wünsche.

In mehrfacher Hinsicht arbeite ich also, was das Bloggen und Programmieren angeht, anders als der Durchschnittsuser. Meine Methoden wären sicher nicht für jeden geeignet und ich würde sie auch nicht uneingeschränkt empfehlen, ich erziele damit aber das beste Ergebnis. Das klappt vor allem durch jahrelange Übung und Erfahrung - wer keine Ahnung hat, sollte definitiv nicht gleich einen Server mieten und versuchen, mit ein bisschen PHP was zusammen zu schrauben. Es ist keine Schande, Shared Hosting oder einen Blogging-Dienstleister zu verwenden. Auf spiller.me gibt es eine gelungene Artikelserie zum Thema "Ich möchte bloggen", die all denen ans Herz gelegt sei, die einsteigen wollen oder noch nicht so richtig angekommen sind. Und allen, die zumindest teilweise bereits die Kontrolle über ihre Technik übernommen haben: Hurra! Willkommen in einer Welt voller frustrierender Stunden und wertvoller Erfolgserlebnisse. hahahah



Nützliche Git-Kommandos

Nach und nach gewöhne ich mich an Git, so dass das Arbeiten damit angenehm wird. Noch angenehmer wird es mit ein paar nicht ganz so grundlegenden Befehlen und Einstellungen.

git config core.filemode false
Änderungen an Dateiberechtigungen ignorieren.

In dem Zusammenhang auch nützlich ist:

find . -type d -exec sudo chmod 755 {} +
Ich habe, unwissend wie ich frischer Linux-User bin, nämlich einfach 755 auf alles gesetzt, um Verzeichnisse beschreibbar bzw. lesbar zu machen - dadurch änderten sich auch die Berechtigungen der Dateien in meinen Git-Verzeichnissen. Das ist eigentlich Blödsinn. Während nämlich bei Verzeichnissen 7 (rwx) als Berechtigung notwendig ist, um sie nicht nur zu lesen (r), sondern auch zu verwenden (x), ist das bei Dateien meistens nicht erforderlich - es sei denn, sie werden tatsächlich in der Konsole als Skript gestartet.

Korrigiert habe ich das dann mit chmod 644 -R . und dem obigen Befehl, also erst 644 auf alles und dann 755 auf alle Verzeichnisse. Noch schöner wäre es gewesen, direkt 644 nur auf Dateien zu setzen (type f für find)...

git checkout --
Eine Datei zurücksetzen, also Änderungen daran verwerfen. Wenn datei durch ./* ersetzt wird, kann man damit auch sehr einfach und ohne Nebenwirkungen unerwünschte größere Änderungen verwerfen, z.B. wenn man git pull auf einem falschen Branch ausgeführt hat.

git commit --amend
Den letzten Commit abändern, zum Beispiel die Nachricht ändern oder weitere Dateien hinzufügen oder Dateien wieder rausnehmen. Einfach so tun, als würde man die Änderungen mit einem neuen Commit durchführen, sie wird dann mit dem vorherigen zusammengefügt.

git reset --soft HEAD^
Den letzten Commit wieder auflösen. Danach sieht das Verzeichnis wieder so aus wie vor dem Commit: Alle Änderungen, die in dem Commit enthalten waren, sind nun wieder "unstaged" - nicht im Repo niedergeschrieben.



Veraltete Datenbank-Backups löschen

Dank des Perl-Skripts von MySQLDumper laufen Datenbank-Backups bei mir vollautomatisch. Mit der Funktion des regelmäßigen Aufräumens war ich aber nicht ganz zufrieden. Ich wollte gerne, dass immer die zehn neuesten Backups behalten werden und von den älteren nur noch eins pro Woche. Das geht mit folgendem Bash-Skript:

#!/bin/bash # Get all konzertheld backup files reverse ordered (konzertheld_yyyy_mm_dd_hh_mm.sql.gz) FILES=`ls konzertheld_* -r` # Initiate i=0 LWNR=0 # Go for f in $FILES do i=`expr $i + 1` # skip first 10 backups if [ $i -gt 10 ] then # Get the database name by extracting the substring before the position of the first _ # echo ${f:0:`expr index "$f" _`-1} # Get the date part by extracting a 10 long substring from the position after the first _ DATUM=${f:`expr index "$f" _`:10} DATUM=${DATUM//_/-} # Get week number WNR=`date +%V -d $DATUM` # If we already had that week number this is an older backup from that week. Delete it! if [ $LWNR -eq $WNR ] then echo $f fi # Set the last week number to the current one. So if the next backup is from a different week it will be kept, if not, deleted. LWNR=$WNR fi done

So werden von den älteren immer alle bis auf eines aus einer Woche gelöscht. Wenn man nur automatisiert backupt, kann man das natürlich auch ohne die Wochennummer machen und einfach jedes siebte Ei jede siebte Datei löschen, aber mit der obigen Methode werden auch alte Backups gelöscht, die man mal manuell angelegt hat. So wie ich an Tagen, an denen alle zehn Minuten die Datenbank explodieren könnte, so dass ich ständig Backups anstoße...



Neues Spamschutz-System auf Konzertheld.de

Irgendwann im letzten Jahr ging es auf Konzertheld.de plötzlich los mit größeren Spam-Problemen und schnell war klar: So geht das nicht weiter. Ich nutze Habari für meinen Blog (zu dessen Kernprogrammiererteam ich neuerdings übrigens gehöre) und das mitgelieferte Standard-Antispam-Plugin erkennt nur ganz offensichtlichen Spam. Also Kommentare voller Links und wilder Zeichen.

Zwar müssen Kommentare von neuen Kommentatoren wie Peter_SwissWatches erst genehmigt werden, die Seite sieht also von außen sauber aus, aber zwischen den ganzen Fake-Kommentaren versteckte sich eben immer wieder mal einer, den ich freischalten wollte. Dank preapproved wurden immerhin schonmal alle automatisch freigeschaltet, die ich schonmal von Hand freigeschaltet hatte.

Dazu kam dann die von mir aufgemotzte simpleblacklist, die automatisch Kommentator-Mailadressen, -URLs und -IPs aufnimmt, wenn ich einen Kommentar als Spam markiere. Eine weitere Arbeitserleichterung, aber der Kampf gegen den Spam fühlte sich immer noch wie ein Kampf an.

Ein Captcha für alle Besucher war für mich keine Option. Also musste einer her, der intelligent entscheidet, wer den Captcha bekommt. Ein paar werden es in letzter Zeit gemerkt haben: Die Funktion gibt es hier seit einiger Zeit, aber bisher löschte sie das Kommentarformular nach dem Abschicken, wenn der Captcha eingeblendet wurde. Damit ist jetzt Schluss, mit Hilfe der anderen Programmierer habe ich das Problem in den Griff bekommen. Nun wird der Captcha nur Leuten angezeigt, die hier noch nie kommentiert haben (oder die eine neue Mailadresse oder URL haben), alle anderen werden wie gewohnt sofort freigeschaltet.

Der technische Hintergrund: Der modifizierte ReCaptcha prüft mittels eines Validators, ob der Autor des Kommentars schon früher freigeschaltet wurde. Das Ergebnis wird in einer Session-Variable gespeichert. Schlägt die Validierung fehl, wird das Formular zurück gewiesen. Beim erneuten Anzeigen wird anhand der Session-Variable erkannt, dass diesmal der Captcha mit rein soll. Codetechnisch ist das Element des Formulars die ganze Zeit da. Das ist nötig, damit der Formularinhalt erhalten bleibt. Erfolgte die Prüfung aber noch nicht oder wurde der Autor bestätigt, bleibt das Element aber leer, der Besucher sieht also keinen Captcha und bekommt auch das Javascript dafür gar nicht erst ausgeliefert.



Habari Plugin: View all your posts at once

Sometimes it might be useful to view your posts not with a maximum number of X per page but all at once. I made a plugin that adds a rewrite rule you can have a normal multiple view as you would on every normal page, except there is no pagination. Please note that loading might take a long time depending on how many posts you have and how many media is in them. The plugin will use the same output (short, full or whatever you have) as usually.

There is a view for really all published posts and one you can customize by choosing the content types you want in there. Also you can decide whether one of them should not be active. More instructions are available once you installed it (just unpack to your plugins folder).

It's called allposts and it is available on GitHub. You can download the source code with Git or use the zip package for Habari 0.9.



Hinweis auf veralteten Browser für Blogs

Jeder Website-Programmierer weiß, dass es ätzend ist, mit alten Browsern arbeiten zu müssen. Außerdem haben veraltete Browser Sicherheitslücken, die nicht mehr geschlossen werden, weil der Aufwand der Pflege alter Versionen auch für den Herausgeber zu groß ist. Trotzdem verwenden viele Menschen veraltete Browser. Vor allem beim auf Windows vorinstallierten Internet Explorer ist das verbreitet, da dieser trotz Windows-Updates nicht automatisch aktualisiert wird und auch nicht auf Updates hinweist.

Für CMS- und Blogbetreiber gibt es da eine nette Hilfestellung. Auf browser-update.org gibt es ein kleines Javascript, welches einen dezenten und doch unübersehbaren Hinweis einblendet, falls der Besucher der Seite einen veralteten Browser benutzt. Wie genau "veraltet" definiert wird, kann man dabei dem Herausgeber überlassen (dann ist es immer dann soweit, wenn der Herausgeber den Support einstellt) oder selber bestimmen.

Für Habari, die Plattform, auf der Konzertheld.de läuft, habe ich selbst ein passendes Plugin geschrieben. Damit lässt sich das Javascript automatisch einbinden und wahlweise über die Plugin-Konfiguration selbst Browserversionen festlegen. Das Plugin ist öffentlich verfügbar und über Git bearbeitbar auf GitHub unter habari-extras.



Habari: Bricks - Textbausteine für Posts

Aus der Not heraus habe ich vor einiger Zeit ein Plugin entwickelt, mit dem sich beliebige Textbausteine in Habari einfügen lassen. Ich wollte die immer gleichen Codeschnipsel für die Bewertungen im {ph} automatisiert einfügen. Außerdem hatte ich gerade meinen Habari-Ordner verschoben und damit einen Großteil der Links zerstört.

Bricks bringt Abhilfe für beides. Die Version 0.1 besitzt noch keine schöne Konfigurationsoberfläche, funktioniert aber bereits zuverlässig. Einem Block wird ein Name zugewiesen und ein Inhalt. Der Name muss eindeutig sein und darf nur aus alphanumerischen Zeichen sowie Bindestrichen und Unterstrichen bestehen. Nach der Syntax [Name]=[Inhalt] wird der Block in die Konfiguration eingetragen und kann dann sofort genutzt werden, dazu muss nur der Name in geschweiften Klammern in den Code eines Artikels eingefügt werden. Auch andere Plugins können mit einbezogen werden, so nutze ich einen Block für die oben eingebundene Info zum Projekt Hörsturz, der die Footnote-Syntax verwendet.

Funktionen

  • Benutzerdefinierte Blöcke: Beliebiger Inhalt kann per Textbaustein in Artikel eingefügt werden.
  • Standardblock für interne Links: Der Block "i" wird immer durch den aktuellen Habaripfad ersetzt. Jeder Link, der mit einem i in geschweiften Klammern beginnt und danach relativ zum Habari-Stammpfad angegeben wird, funktioniert auch nach einem Umzug des Habari-Ordners noch.

Installation

Plugin herunterladen, ggf. entpacken und in einen Unterordner nach /user/plugins hochladen/verschieben. In der Pluginübersicht aktivieren. Fertig.

Deinstallation

Plugin deaktivieren und Ordner entfernen. Angelegte Textbausteine werden zur Zeit nicht entfernt. Der Eintrag "bricks__bricks" in der Optionstabelle der Habari-Datenbank muss von Hand entfernt werden.

Download

Git-Repository (aktuelle Entwicklerversion)

---



Bugfix für RN Tag Cloud

Irgendwann, nachdem ich angefangen hatte, häufiger über Events zu schreiben und vor allem auch über TEN SING, fiel mir auf, dass die Tag Cloud die dadurch eingeführten neuen Tags gar nicht berücksichtigt. Jetzt bin ich dem mal nachgegangen und stellte fest, dass ich das zuständige Plugin aus irgendeinem Grund nur Posts vom Typ "Eintrag" berücksichtigt, meine Eventberichte also außen vor blieben. Das ist jetzt behoben.

Für Habari-Nutzer, die ebenfalls die RN Tag Cloud nutzen: In der Plugin-Datei sind drei Funktionen betroffen, nämlich get_total_tag_usage_count(), get_most_popular_tag_count() und build_tag_cloud( $num_tag ). In allen drei Funktionen muss in der SQL-Abfrage

$sql = "

der erste WHERE-Parameter, nämlich der, der nach Content-Typ filtert, entfernt werden. Sieht danach so aus:

WHERE p.status = {$post_status}

Die weiter oben liegende Zeile mit der Definition der Variable, die den Content-Typ angibt, kann dann auch entfernt werden.