Fryboyter

Fryboyter wird nun mit Hugo erzeugt

Bisher habe ich für fryboyter.de das CMS Bolt verwendet. Im Grunde bin ich damit auch zufrieden. Aber irgendwie habe ich in letzter Zeit immer weniger Lust die Updates zu installieren.

Daher habe ich mir in den letzten Wochen diverse Tools angesehen, mit denen man statische Webseiten erstellen kann. Man braucht also kein PHP, keine Datenbank usw. Somit entfällt auch das nervige Updaten der Seite.

Schlussendlich bin ich bei Hugo gelandet. Das hat im Grunde zwei Gründe. Zum einen besteht Hugo nur aus einer Datei und zum anderen werden die statischen Seiten sehr schnell erzeugt.

Was mich aber etwas beschäftigt hat war, wie ich die Seite bei neuen Artikeln möglichst einfach erzeugen und auf den Webspace hochladen kann.

Im Lab von Uberspace gibt es inzwischen eine Anleitung wie man Hugo installiert. Hierbei läuft Hugo als Dienst im Hintergrund und erzeugt die Seite neu sobald sich etwas geändert hat. Was aber zur Folge hat, dass ich mich wieder zeitnah um eventuelle Updates kümmern muss. Besser wäre es, wenn Hugo nur zum Erzeugen der Seite gestartet und danach wieder beendet wird. Das einfachste wäre es, sich per SSH mit dem Webspace zu verbinden, den neuen Artikel zu erstellen und dann Hugo manuell auszuführen. Einfach? Ja. Umständlich? Auf jeden Fall. Also kommt es auch nicht in Frage.

Die Lösung lautet, wie so oft, Git. Als erstes legt man auf dem Webspace außerhalb des Document Root ein Verzeichnis an. In diesem erzeugt man mittels “git init –bare” ein sogenannte Bare-Respository. Dies hat, im Gegensatz zu einem normalen Respository keinen Working Tree. Schaut man sich nun das Verzeichnis noch einmal an, findet man dort das Unterverzeichnis “hooks”. Mit diesen Hooks lassen sich bestimmte Dinge automatisieren. Zum Beispiel lassen sich Befehle ausführen wenn das Repository neue Daten erhalten hat. Hierfür legt man im Verzeichnis “hooks” die Datei post-receive an und befüllt diese beispielsweise wie folgt und macht diese dann noch ausführbar.

GIT_REPO=$HOME/repository/fryboyter.git
TMP_GIT_CLONE=$HOME/tmp/git/fryboyter
PUBLIC_WWW=/var/www/virtual/$USER/html/fryboyter
git clone $GIT_REPO $TMP_GIT_CLONE
~/bin/hugo -s $TMP_GIT_CLONE --cleanDestinationDir -d $PUBLIC_WWW
rm -Rf $TMP_GIT_CLONE
exit

Hiermit wird der Inhalt des Repository in ein temporäres Verzeichnis geklont. Danach löscht Hugo die bereits veröffentlichte Internetseite und erstellt diese neu. Danach wird das temporäre Verzeichnis gelöscht.

Was jetzt noch fehlt, sind die Daten mit denen man die Internetseite erzeugt. Diese erzeugt man auf dem eignene Rechner. Wenn dies erledigt ist, wechselt man in das betreffende Verzeichnis und führt folgende Befehle aus.

git init
git add .
git commit -m "Beschreibung des Commit"

Hiermit erstellt man ein lokales Repository, fügt alle Dateien des Verzeichnis hinzu und erstellt einen Commit. Läde man das ganze mittels “git push $adresse_des_repository” hoch wird automatisch die Datei post-receive ausgeführt und die Internetseite wird autoamtisch erzeugt. Um zukünftig die Seite zu aktualisieren, erzeugt / ändert man die betreffende Datei im lokalen Repository, erstellt einen neuen Commit und läd die Änderungen mittels git push hoch.

OSBN | Allgemein

Fryboyter.de ohne Matomo

Ich habe mich eben entschlossen, den Code für Piwik / Matomo von Fryboyter.de zu entfernen. Somit werden aktuell nun keine Statistiken über die Besucher mehr erstellt. Dafür läd die Seite nun noch schneller. Die Gründe sind eigentlich relativ einfach.

Zum einen Funktioniert der iFrame für das die Opt-Out-Funktion auf einem Uberspace 7 nicht, da dort “Response Header” gesetzt werden, die man aktuell selbst nicht ändern kann. Zudem gibt es wohl auch aufgrund der DSGVO die eine oder andere Tretmine auf die auch Betreiber nichtkommerzieller Seiten treten können. Von den Geiern das Abmahnindustrie will ich gar nicht erst anfangen. Da für mich eigentlich nur interessant war, das ein x-belieber Nutzer Artikel X für einen Zeitraum von Y aufgerufen hat, hatte ich Piwik / Matomo auch nur sehr rudimentär genutzt. Aber selbst diese Informationen habe ich in den letzten Wochen und Monaten immer seltener abgerufen. Zudem kommt auch noch hinzu, dass in letzter Zeit immer weniger Nuter erfasst wurden, was vermutlich an der “Do-Not-Track-Funktion” der Browser sowie der Sperre durch die Ad-Blocker liegt. Kurz gesagt, Piwik / Matomo bringt mir immer weniger und sorgt mit etwas Pech auch noch für Probleme. Also weg damit. Zukünftig muss ich mich halt auf mein Bauchgefühl bzw. auf die abgegebenen Kommentare verlassen, welche Themen interessant sind und welche nicht.

Sollte ich mich eines Tages wieder für Piwik / Matomo entscheiden, werde ich hier entsprechend darauf hinweisen.

OSBN | Allgemein

Fryboyter.de nun mit Code Highlighter

Vor ein paar Monaten bin ich von Wordpress auf Bolt CMS umgestiegen. Hierbei musste ich auf die eine oder andere Funktion verzichten. Unter anderem auf einen Code Higlighter. Es gibt zwar zwei Plugins, aber diese sind leider veraltet und funktionieren mit Bolt 3.x nicht und ich bekomme es nicht gebacken diese entsprechend anzupassen.

Daher hatte ich mit CSS etwas zusammengebastelt um Codebeispiele zumindest als solche zu kennzeichnen. Das Ergebnis war mehr schlecht als recht. Bei zu langen Zeilen musste man beispielsweise horizontal scrollen. Und Zeilennummern gab es auch keine mehr. Blöd wenn man den Code an einer bestimmten Stelle erklären will.

Ich habe mich daher dazu entschlossen einen Code Highlighter zu installieren. Entschieden habe ich mich schlussendlich für Prism. Zukünftig wird nun Code farblich hervorgehoben und Zeilennummern ink. Umbruch gibt es nun auch wieder.

#!/bin/bash 
echo "Wie ist Ihr Name?"
read ANTWORT
if [ "$ANTWORT" == "root" ]
    then
        echo "Hallo, Administrator. Das ist eine sehr lange Zeile um einen Zeilenumbruch zu provozieren."
    else
        echo "Hallo, Anwender."
fi

Der ganze Spaß hat aber auch Nachteile. Zum einen muss ich nun einige Artikel anpassen, da ich oft zu faul war, die richtige Klasse bei den Code-Tags zu hinterlegen (z. B. <code> anstelle von <code class=“language-bash”>. Und für die Zeilennummern muss ich die <pre> Tags um <pre class=“line-numbers” style=“white-space:pre-wrap;”> erweitern. Naja muss ich halt wieder das fleißige Bienchen spielen… Ein weiterer Nachteil ist, dass die Seite nun ca. 12 KB schwerer ist, da nun eine Javascript-Datei und eine CSS-Datei zusätzlich geladen werden. Ich denke das ist zu verkraften.

OSBN | Allgemein

Index.twig des Fryboyter-Themes

Da ich gefragt wurde, wie ich das auf fryboyter.de verwendet Theme erstellt habe, habe ich mir gedacht ich mache mal eine Artikelreihe daraus in der ich die 9 Twig-Dateien erkläre.

Fangen wir mal mit der Datei index.twig an. Diese wird angezeigt, wenn man die Hauptseite aufruft.

{% include '_header.twig' %}
<div class="header"><h1><a href="{{ paths.hosturl }}">Fryboyter</a></h1></div>
<div class="container">
    <div class="row">
        <div class="col-lg-8 col-lg-offset-2 col-md-10 col-md-offset-1">
            {% setcontent records = "entries/latest/5" allowpaging %}
                {% for record in records %}
                    <h2><a href="{{ record.link }}">{{ record.title }}</a></h2>
                        {% if record.taxonomy is defined %}
                            {% for type, values in record.taxonomy %}
                            <div class="article-info">Veröffentlicht am {{ record.datepublish|localdate("%d. %B %Y") }} unter:
                            {% for link, value in values %}
                            <a href="{{ link }}">{{ value }}</a>{% if not loop.last %} & {% endif %}
                            {% endfor %}
                            | <a href="{{ record.link }}#isso-thread">Comments</a> </div>
                            {% endfor %}
                        {% endif %}
                    {{ record.body }}
                    <hr/>
                {% endfor %}
            {{ pager('', 3, '_sub_mypager.twig') }}
        </div>
    </div>
</div>
<div class="footer">{% include '_footer.twig' %}</div>
</body>
</html>

Twig bietet die Möglichkeit bestimmte Bereich einer Seite in extra Dateien auszulagern. Mittels include kann man diese dann wie im Baukasten zusammensetzen. In diesem Fall wird in Zeile 1 somit die Datei _header.twig importiert.

In Zeile 2 wird mittels path.hosturl auf die Adresse der Seite verlinkt. In dem Fall also https://fryboyter.de/. Zieht man die Seite irgendwann man auf eine andere Domain um, braucht man hier die Adresse nicht händisch ändern.

In Zeile 6 werden die letzten 5 Einträge aus der Datenbank herausgefischt. Allowpaging ermöglicht es, dass man am Ende einer Seite auf weitere Seiten mit wiederrum 5 Artikeln wechseln kann.

Ab Zeile 7 wird definiert wie jeder einzelne Artikel angezeigt wird.

In Zeile 8 wird als erstes der Titel inkl. entsprechenden Link eines Artikels ausgegeben.

Zeile 9 bis 17 ist schon etwas aufwändiger. Hier wird erst einmal geprüft ob dem betreffende Artikel Taxonomien zugeordnet wurden. Auf dieser Seite wären das die Kategorieren wie osbn oder Allgemein. Wenn dem so ist, wird unter der Zeile der Artikelüberschrift das Datum der Veröffentlichung, gefolgt von den zugeordneten Kategorien angezeigt. Die Anzeige der Kategorien erfolgt hierbei in einer Schleife, so dass zwischen den Kategorien ein & angezeigt wird. Zum Schluss wird am Ende noch die Anzahl der vorhandenen Kommentare angezeigt und auf die Kommentarfunktion verlinkt (Zeile 18).

In Zeile 21 wird dann der Haupttext des Artikels angezeigt (ich arbeite nie mit Teasern).

Zeile 24 bindet die Datei _sub_mypager.twig ein. Hiermit wird am Ende einer Seite der Umschalter angezeigt mit dem man die Seiten wechseln kann.

Abschließend wird in Zeile 28 die Datei _footer.twig importiert.

OSBN | Allgemein

Nachbesserungen an Bolt CMS

Eigentlich war es mir schon klar, dass der Umstieg nicht so klappt wie erhofft. Bisher sind es aber nur ein paar Kleinigkeiten die schnell behoben werden konnten.

Zum einen stand in der PHP-Datei die den OSBN-Feed erstellt noch die Testdomain auf der ich die ganze Zeit an Bolt gebastelt habe. Somit hat gestern der Artikel von mir auf osbn nicht auf fryboyter.de sondern planetlinux.de verlinkt. Mea culpa. Hier habe ich zum einen die PHP-Datei geändert und zum anderen eine 301-Weiterleitung per .htaccess eingerichtet.

Das zweite Problem war mir anfangs nicht ganz klar. Ein Leser von fryboyter.de hat mir mitgeteilt, dass er keine Artikel direkt aufrufen kann, sondern nur die Hauptseite. Schnell bin ich auf die Fehlermeldung “Impossible to access an attribute (“id”) on a null variable” gestoßen die sich auf die Datei record.twig bezieht die für die Anzeige einzelner Artikel zuständig ist. Dort gibt es unter anderem folgenden Code.

{% if user.id == 'X' %}
| <a href="{{ paths.bolt }}editcontent/entries/{{ record.id }}">Bearbeiten</a>
{% endif %}

Hiermit wird geprüft, ob der Nutzer der die Seite aufruft die Id X hat. Wenn ja, wird ein Link angezeigt mit dem man den Aritkel bearbeiten kann. Und genau wegen diesem Code knallt es. Aber warum?

In der Hauptkonfiguration von Bolt gibt es folgenden Bereich…

# Use strict variables. This will make Bolt complain if you use {{ foo }},
# when foo doesn't exist.\
strict_variables: false

Tja hier hatte ich wohl das false auf true geändert um leere bzw. nicht vorhandene Variablen zu unterbinden. Und genau das ist die Ursache des Problems. Anstelle aus dem true wieder ein false zu machen, habe ich einfach obigen Code so abgeändert, dass erst einmal geprüft wird ob user.id definiert ist. Wenn ja, erfolgt die Prüfung auf ID X und wenn nicht, passiert gar nichts.

{% if user.id is defined %}
{% if user.id == 'X' %}
| <a href="{{ paths.bolt }}editcontent/entries/{{ record.id }}">Bearbeiten</a>
{% endif %}
{% endif %}

OSBN | Allgemein