Konzertheld.de

Umwege verbessern die Ortskenntnis

Zufällige Artikel

Ausgewählte Infos

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

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 -- <datei>

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 <params>

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.

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:

  1. #!/bin/bash
  2. # Get all konzertheld backup files reverse ordered (konzertheld_yyyy_mm_dd_hh_mm.sql.gz)
  3. FILES=`ls konzertheld_* -r`
  4. # Initiate
  5. i=0
  6. LWNR=0
  7. # Go
  8. for f in $FILES
  9. do
  10.   i=`expr $i + 1`
  11.   # skip first 10 backups
  12.   if [ $i -gt 10 ]
  13.   then
  14.     # Get the database name by extracting the substring before the position of the first _
  15.     # echo ${f:0:`expr index "$f" _`-1}
  16.     # Get the date part by extracting a 10 long substring from the position after the first _
  17.     DATUM=${f:`expr index "$f" _`:10}
  18.     DATUM=${DATUM//_/-}
  19.     # Get week number
  20.     WNR=`date +%V -d $DATUM`
  21.     # If we already had that week number this is an older backup from that week. Delete it!
  22.     if [ $LWNR -eq $WNR ]
  23.     then
  24.       echo $f
  25.     fi
  26.     # 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.
  27.     LWNR=$WNR
  28.   fi
  29. 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...

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.

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.

 1 2 3 4 Älter »

Icons by http://www.famfamfam.com/lab/icons/silk/

Photo copyright by me unless noted