Meine Antwort war ein eigenes WordPress-Plugin für Sportvereine. Nicht für diesen einen. Für alle.

Das klingt nach Größenwahn für ein Dorfprojekt. Ich erkläre, warum es das Gegenteil war.

Der Reflex heißt: für den bauen, der fragt

Wenn dich ein Verein um Hilfe bittet, baust du für diesen Verein. Das ist keine bewusste Entscheidung, das ist die Voreinstellung. Die Anforderungen kommen von dort, die Beispiele kommen von dort, und irgendwann steht der Vereinsname im Quelltext. Nicht aus Faulheit, sondern weil jede einzelne Abkürzung in dem Moment vernünftig aussieht.

Man weiß ja, dass die Halle in Ober-Olm liegt. Also setzt man den Kartenmittelpunkt dorthin. Man weiß, dass die Vereinsfarbe ein bestimmtes Blau ist. Also steht das Blau im Stylesheet. Man weiß, dass der Verein Deutsch spricht. Also schreibt man die Beschriftungen auf Deutsch hin, statt sie übersetzbar zu machen.

Jede dieser Abkürzungen spart eine Viertelstunde. Zusammen entscheiden sie darüber, ob das Ergebnis jemals ein zweites Mal benutzt werden kann.

Die Frage, die alles gedreht hat

Ich habe mir irgendwann während der Anforderungsphase die Liste angeschaut und gefragt: Ist hier eigentlich irgendetwas speziell?

Sportarten mit Untergruppen. Trainingszeiten, die sich im Sommer ändern. Trainer, die man ansprechen kann. Hallen und Sportplätze. Ferien, in denen nichts stattfindet, außer Ferienbetreuung. Angebote, die im Beitrag enthalten sind oder extra kosten.

Das ist kein TV Ober-Olm. Das ist jeder Sportverein in Deutschland. Der Turnverein im Nachbardorf hat dieselbe Struktur, nur andere Namen drin. Und der Fußballverein zwei Orte weiter hat sie auch, plus Mannschaften und Spielbetrieb.

Wenn das Problem nicht speziell ist, ist die Lösung es auch nicht. Und dann ist es eine schlechte Idee, sie speziell zu bauen.

Was es schon gab, und warum es nicht passte

Fertige Lösungen gibt es reichlich. Kalender-Plugins, Event-Plugins, Vereinsverwaltungen mit Mitgliederdatenbank und Beitragseinzug, Baukästen für eigene Inhaltstypen.

Das Problem war nie die fehlende Funktion. Das Problem war, wer die Lücke dazwischen füllt.

Ein Kalender-Plugin kennt Termine, aber keine Sportarten. Es weiß nicht, dass „Leichtathletik Kinder“ im Sommer draußen und im Winter drinnen stattfindet, und schon gar nicht, dass in den Osterferien alles ausfällt. Eine Vereinsverwaltung fängt bei Mitgliedern und Beiträgen an, also bei einem Thema, das der Verein gar nicht auf der Website haben will. Und mit einem Baukasten für Inhaltstypen kann man sich das alles zusammenklicken, aber dann hat man genau das gebaut, was ich vermeiden wollte: ein System, dessen Logik nur der versteht, der es zusammengeklickt hat.

Der Ehrenamtliche, der in zwei Jahren die Trainingszeit von dienstags auf mittwochs ändern soll, muss sonst verstehen, wie drei Systeme zusammenhängen. Genau diese Verständnislast ist der Grund, warum Vereinswebsites verwaisen.

Ein Werkzeug, das den Verein bereits kennt, verlangt das nicht. Es fragt nicht „welchen Inhaltstyp möchten Sie anlegen“, sondern zeigt ein Feld für Trainingszeiten.

Die Entscheidung fiel am ersten Tag

Das ist der Teil, den ich selbst erst beim Nachschauen gemerkt habe, und er gefällt mir.

Der allererste Commit im Projekt heißt „Initialer Stand: Konzept Club Sports Manager (TVOO-Relaunch)“, vom 17. August. Vereinsprojekt, schon im Titel. In derselben Datei, im selben Commit, steht die zwölfte Entscheidung:

Bewusst produkt- statt vereinsspezifisch, damit jeder Sportverein es nutzen kann. „TVOO“ ist nur unsere Installation, nicht der Produktname.

Bevor eine einzige Zeile Code existierte, stand fest, dass der Verein ein Anwendungsfall ist und nicht das Ziel. Das ist keine nachträgliche Verklärung einer Erfolgsgeschichte. Das ist datiert und nachlesbar, und ich war selbst überrascht, wie früh das war.

Der Grund war übrigens nicht Weitsicht. Der Grund war Bequemlichkeit in der richtigen Richtung: Ich wollte nicht in einem Jahr dasselbe nochmal bauen, wenn der Schützenverein fragt.

Was die Entscheidung im Alltag bedeutet

Sie klingt nach einem Satz im Konzept. In Wirklichkeit ist sie eine tägliche Disziplin, und man verliert sie ständig aus den Augen.

Ein paar Monate später, kurz vor der Veröffentlichung, bin ich das Projekt nochmal auf Vereinsspezifisches durchgegangen. Ich hatte ja alles generisch gebaut, dachte ich.

Gefunden habe ich: einen fest eingetragenen Kartenmittelpunkt, der auf Rheinhessen zeigte. Eine Kennung, mit der sich das Plugin beim Geocoding-Dienst vorstellte und die den Vereinsnamen enthielt. Einen Rückfall-Hostnamen in den Kalender-Exportdateien, der auf unseren Server zeigte. Und einen Platzhalter für die Markenfarbe, der eben nicht neutral war.

Nichts davon war falsch für den TV Ober-Olm. Alles davon war falsch für jeden anderen.

Das ist die eigentliche Arbeit hinter „generisch bauen“. Nicht die Architektur, nicht das saubere Trennen von Schichten. Sondern immer wieder die Frage: Weiß dieser Code gerade etwas, das er nicht wissen darf?

Was das kostet, und wer es bezahlt

Ehrlich gesagt: Es dauert länger. Spürbar.

Jede Annahme wird zu einer Einstellung. Jede Beschriftung wird übersetzbar, also brauchst du Sprachdateien und einen Weg, sie zu prüfen. Jede Adresse im System muss konfigurierbar sein, weil ein Verein in Österreich eine andere Struktur will als einer in Hessen. Aus zwei Zeilen werden fünfzehn.

Diese Zeit bezahlt der Verein mit. Er bekommt sein Ergebnis später, als wenn ich ihm eine maßgeschneiderte Seite hingestellt hätte.

Im Gegenzug bekommt er etwas, das ein Auftragsprojekt nie hat: Das Ding gehört ihm nicht allein, also hängt es auch nicht an mir allein. Es liegt öffentlich, es bekommt Aktualisierungen, es hat eine Dokumentation, die nicht aus meinem Kopf kommt. Wenn ich morgen keine Lust mehr habe, steht der Verein immer noch besser da als mit einer Maßanfertigung von jemandem, der weg ist.

Das war von Anfang an das Ziel: Hilfe zur Selbsthilfe. Ein Produkt ist die belastbarere Form davon als ein Gefallen.

Der Name war die letzte Konsequenz

Irgendwann braucht das Ding einen Namen, und der Name entscheidet mit, wofür man es hält.

„TVOO-Kalender“ wäre der ehrliche Name für ein Vereinsprojekt gewesen. Geworden ist es Squadeno – Club Sports Manager: ein beschreibender Teil, der sagt, was es tut, und ein Markenteil davor. Die Software heißt bewusst nicht nach dem Verein, für den sie zuerst gebaut wurde. Wenn sie es täte, würde sie niemand sonst installieren, egal wie generisch der Code darunter ist.

Dass mir ausgerechnet bei diesem Namen später noch jemand reingeredet hat, und zwar das Review von WordPress.org, ist eine eigene Geschichte. Die kommt in Teil 4.

Fazit

Ich bin nicht losgezogen, um ein Produkt zu bauen. Ich wollte einem Verein helfen, dessen Angebot meine Tochter nutzt.

Der Umweg über „für alle statt für einen“ hat das Projekt größer gemacht, langsamer und anstrengender. Er ist trotzdem die richtige Entscheidung gewesen, und der Grund ist banal: Eine Maßanfertigung ist nur so lange gut, wie der Schneider erreichbar ist.

Das Plugin liegt inzwischen kostenlos im WordPress-Verzeichnis, und es gibt eine eigene Seite dazu. Wie so ein Ding in wenigen Wochen entsteht, ohne auseinanderzufallen, kommt in Teil 3. Was das Review daran auszusetzen hatte, in Teil 4.

Der Beitrag Ein WordPress-Plugin für Sportvereine statt einer Website für einen Verein erschien zuerst auf Das ist die Welt von Thomas.

Es gab keinen dramatischen Moment, an dem das klar wurde. Keinen Anruf, kein „wir haben ein Problem“. Meine Tochter ist im Verein aktiv, und wir schätzen das Angebot hier im Ort sehr. Wer im Dorf ein Kind hat, landet früher oder später in diesem Verein.

Und wer wissen will, wann dort was stattfindet, landet auf der Website. Genau da fing es an zu haken.

Was man findet, wenn man hinschaut

Die Seite des TV Ober-Olm läuft auf einem Web-Baukasten. Die Angebote sind nach Altersgruppen sortiert, Kleinkinder, Kinder und Jugend, Erwachsene, Senioren, Outdoor, Kurse. Eltern-Kind-Turnen, Gerätturnen, Leichtathletik, Tischtennis, Taekwondo, Yoga, Pilates, Zumba, Wandern, Genussradeln. Ein beachtliches Angebot für ein Dorf.

Nur: Wann trainiert die Leichtathletik-Gruppe der Kinder? Wo? Und ist nächste Woche überhaupt, oder sind Ferien?

Die Antwort steht irgendwo. Manchmal im Fließtext einer Seite, manchmal in einem PDF, manchmal gar nicht. Die Anmeldung läuft über ein Word-Formular zum Herunterladen. Parallel lag noch eine halbfertige WordPress-Testinstanz herum, mit einem Kalender-Plugin, das niemand mehr genau zuordnen konnte, und einer Unterseite /sportangebote/, die teilweise ins Leere lief.

Das ist kein Vorwurf an irgendwen. Das ist der Normalzustand. Ehrenamtliche pflegen eine Website neben Job, Familie und dem eigentlichen Vereinsleben, mit Werkzeugen, die sie sich nicht ausgesucht haben, und nach Anleitungen von jemandem, der vor drei Jahren weggezogen ist.

Irgendwann bin ich auf Jasmin aus dem Vorstand zugegangen und habe gefragt, ob wir da nicht mal was Besseres machen wollen.

Die Falle, in die ich fast getappt wäre

Der naheliegende Reflex als ITler: Ärmel hoch, ich bau euch das.

Das Angebot ist gut gemeint und in aller Regel ein Bärendienst. Denn was dabei herauskommt, ist eine schöne Website und ein Verein, der jetzt von genau einer Person abhängt. Beim nächsten Trainerwechsel schreibt mir jemand eine WhatsApp. Bei der nächsten Ferienbetreuung auch. Nach zwei Jahren bin ich der Webmaster auf Lebenszeit, und wenn ich keine Lust mehr habe, steht der Verein schlechter da als vorher, weil er sich die Pflege inzwischen abgewöhnt hat.

Genau dieses Muster hatte den alten Zustand ja erst erzeugt.

Also war die Ansage von Anfang an eine andere: Ich mache euch das nicht. Ich sorge dafür, dass ihr es könnt. Hilfe zur Selbsthilfe, im wörtlichen Sinn.

Das klingt nach einer netten Geste. Tatsächlich ist es die deutlich härtere Aufgabe. Eine Website bauen kann ich an einem Wochenende. Ein Pflegemodell bauen, das Laien nach einem halben Jahr Pause noch bedienen, ist Arbeit an einer ganz anderen Stelle.

Die eine Anforderung, die zählte

Aus dem Erstgespräch sind sieben funktionale Anforderungen hervorgegangen. Eigene Seite je Sportart. Auffindbarkeit über Google, weil Leute nach „Taekwondo Ober-Olm“ suchen und nicht nach dem Verein. Termine je Sportart im Kalender. Ansprechpartner sichtbar. Ferien als geblockte Zeiten. Ferien-Events. Kostenangaben.

Und dann stand unter „nicht-funktionale Anforderungen“ ein Satz, der die eigentliche Aufgabe beschreibt:

Einfache Pflege durch Mitglieder (Laien), nicht nur durch Technik-Profis. Oberste Priorität.

Wer das ernst nimmt, entwirft anders. Jede Funktion muss sich fragen lassen, ob sie die Pflege leichter oder schwerer macht. Und die ehrliche Antwort lautet bei den meisten Funktionen: schwerer.

Ich habe das damals so aufgeschrieben und beim Lesen ein paar Wochen später gemerkt, dass ich es an der falschen Stelle einsortiert hatte. Das war keine Nebenbedingung. Das war die Anforderung. Die anderen sieben waren nur die Liste dessen, was dabei herauskommen sollte.

Ein Verein hat keine Termine, er hat einen Trainingsplan

Der Kern des Ganzen ist eine einzige Entscheidung, und sie ist nicht technisch.

Ein Verein hat keine Termine. Er hat einen Trainingsplan. Dienstags um 17 Uhr Leichtathletik Kinder, in der Halle, außer im Sommer, dann draußen auf dem Sportplatz. Das ist die Wahrheit über den Verein. Alles andere sind Ableitungen davon.

Die alte Logik war umgekehrt: Der Kalender war die Wahrheit, und jemand musste ihn befüllen. Also entstanden Einzeltermine, per Hand, Woche für Woche. Oder eben nicht, was häufiger vorkam. Und wenn Ferien waren, mussten sie einzeln wieder gelöscht werden.

Die neue Logik: Der Trainingsplan ist die Quelle, der Kalender die Ausgabe. Man pflegt „dienstags 17 Uhr, Sommersaison, Sportplatz“ ein einziges Mal. Die Termine entstehen daraus von selbst. Die Ferien liegen zentral als Schließzeiten und blocken automatisch, ohne dass jemand irgendwo etwas löscht. Fällt ein einzelnes Training aus, sagt man genau diesen einen Termin ab, direkt am Termin, mit zwei Klicks.

Klingt banal. Es ist der Unterschied zwischen einer Website, die gepflegt wird, und einer, die verwaist.

Was Anforderungserhebung im Ehrenamt anders macht

Im Job mache ich das beruflich. Anforderungsanalyse heißt dort: Stakeholder identifizieren, Workshops ansetzen, Fachbereiche befragen, Ergebnisse abstimmen. Es gibt Termine, Protokolle und jemanden, der für die Freigabe zuständig ist.

Im Verein gibt es das alles nicht. Es gibt Leute, die ihre Freizeit hergeben, und die haben keine Lust auf einen Workshop über Informationsarchitektur. Man bekommt keine Anforderungsliste. Man bekommt Sätze wie „die Seite ist halt kompliziert“.

Der Unterschied in der Arbeitsweise ist deshalb weniger groß, als man denkt, aber er liegt woanders: Man muss die Anforderung erraten, die niemand ausspricht. Niemand sagt „unsere oberste Priorität ist, dass Laien das pflegen können“. Das sagt keiner, weil es für den, der drinsteckt, so selbstverständlich ist, dass es keiner Erwähnung wert scheint.

Meine einzige Gegenmaßnahme: alles aufschreiben, auch das, was nebenbei gesagt wird, und es später nochmal lesen. Genau dabei ist mir aufgefallen, dass ich den wichtigsten Satz unter „nicht-funktional“ abgelegt hatte.

Und dann?

Am Ende der Anforderungserhebung stand ein Bild davon, wie Pflege funktionieren muss, damit sie stattfindet. Ein Trainingsplan als Quelle. Ferien, die zentral einmal gepflegt werden. Eine eigene Seite je Sportart, weil Leute nach „Taekwondo Ober-Olm“ suchen. Trainer, die ihren eigenen Kram anfassen dürfen, ohne alles andere kaputt machen zu können.

Was nicht dastand: womit man das baut.

Die naheliegende Antwort wäre gewesen, ein paar fertige WordPress-Plugins zusammenzustecken und dem Verein zu erklären, wie sie zusammenhängen. Ich habe mich dagegen entschieden, und zwar aus einem Grund, der mit dem TV Ober-Olm nur am Rande zu tun hat.

Darum geht es in Teil 2. – to be continued ….

Der Beitrag Vereinswebsite selbst pflegen: Die Anforderung, die niemand ausgesprochen hat erschien zuerst auf Das ist die Welt von Thomas.

Nur: Ein Release, für das man sich konzentrieren muss, geht irgendwann schief.

Warum mich das SVN von wordpress.org so genervt hat

Mein Entwicklungsprozess sieht bei jedem Projekt gleich aus. Alles liegt in meinem GitLab, feature/* zweigt von integration ab, integration von master. Die CI lintet, testet, baut ein Paket. Wenn das Paket grün ist, ist es das Ergebnis, mit dem ich weiterarbeite. Das ist mein Takt, seit Jahren, über alle Projekte hinweg.

wordpress.org spielt bei dem Spiel nicht mit. Das Plugin-Verzeichnis läuft auf Subversion, mit der klassischen Struktur aus trunk, tags und assets. Kein Git, keine Pull Requests, kein Tag-Objekt. Ein Release ist dort ein Verzeichnis, das du kopierst. Und assets ist nicht mal Teil des Plugins, da liegen Banner, Icon und Screenshots für die Store-Seite.

Von Hand heißt das jedes Mal: SVN auschecken, Dateien nach trunk kopieren, neue Dateien mit svn add anmelden, gelöschte mit svn delete abmelden, svn copy trunk tags/4.4.0, committen. Sechs Handgriffe, in der richtigen Reihenfolge, mit einem Passwort, das ich mir nie merke. Alle zwei Monate, also selten genug, dass ich jedes Mal in meinen alten Notizen nachgesehen habe, wie das nochmal ging.

Der Beweis, dass das nicht funktioniert, lag jahrelang im veröffentlichten trunk. Aus den Handbetrieb-Zeiten schleppte mein Plugin .project, .buildpath und .settings mit sich herum, Eclipse-Altlasten von einem Rechner, den ich längst nicht mehr habe. Aufgefallen ist es erst, als der offizielle WordPress Plugin Check bei mir in der Pipeline lief und mir sagte: „Hidden files are not permitted.“ Die Dateien lagen also im Store-Download, jahrelang, bei jedem, der das Plugin installiert hat. Beschwert hat sich nie jemand.

Ein zweiter Punkt, über den ich beim ersten Versuch gestolpert bin und der in keiner Doku fett genug steht: Das SVN-Passwort ist nicht dein wordpress.org-Passwort. Du legst es separat im Profil unter „Account & Security“ an. Ich war eine ganze Weile überzeugt, mein Zugang sei kaputt.

Die Grundidee: SVN ist kein Arbeitsplatz, sondern ein Ausgabegerät

Der Denkfehler war, das SVN als zweites Repository zu betrachten, in dem ich irgendwie auch arbeite. Sobald man es als Drucker begreift, löst sich die Sache auf. Git ist die Wahrheit. Das SVN bekommt fertige Ware geliefert und interessiert mich sonst nicht.

Praktisch bedeutet das: Kein Mensch checkt das Plugin-SVN mehr aus. Ein Skript kennt die sechs Handgriffe, die CI ruft es auf, und die Zugangsdaten liegen als maskierte CI/CD-Variablen in GitLab:

SVN_USERNAME = mein wordpress.org-Benutzername (case-sensitiv)
SVN_PASSWORD = das separate SVN-Passwort aus dem Profil

Das ist die ganze Konfiguration. Alles andere steckt in Skripten, die im Repo liegen und die ich lokal genauso aufrufen kann.

Was passiert, bevor überhaupt jemand an SVN denkt

Die Pipeline hat sechs Stufen: image, lint, test, quality, build, deploy. Bis es zum Deploy kommt, kann die Pipeline an vier Stellen vorher Nein sagen.

Stufe 0, das eigene CI-Image. Alle Jobs laufen in einem Base-Image, das die Pipeline selbst baut: PHP 8.1 mit den nötigen Extensions, Composer, wp-cli, MySQL-Client und, wichtig für später, subversion und rsync. Gebaut wird es mit Kaniko, also ohne Docker-Daemon und ohne Docker-in-Docker. Das Ergebnis landet in meiner eigenen Container-Registry, der Layer-Cache gleich daneben. Vorher hat jeder Job sein apt-get install selbst gemacht, was pro Lauf Minuten gekostet hat und bei jeder Netzstörung rot war.

Stufe 1, Lint. PHPCS mit dem WordPress-Coding-Standard, strikt auf den modernen Kern in plugin/src (null Errors), dazu die PHP-8.1-Kompatibilitätsprüfung auf dem gesamten Plugin. Das Plugin ist alt, es gibt noch prozedurale Dateien aus der Frühzeit. Die wandern nach und nach in plugin/src und werden dort dann automatisch mitgeprüft. Ich finde das ehrlicher, als den Standard auf alles zu werfen, tausend Findings zu sehen und den Job dann dauerhaft auf allow_failure zu stellen. Dazu PHPStan auf Level 5 mit phpstan-wordpress und composer audit für bekannte Schwachstellen in den Abhängigkeiten.

Stufe 2, Test. Die komplette PHPUnit-Suite gegen ein echtes WordPress. Als Service läuft mariadb:10.11, bin/install-wp-tests.sh zieht sich WordPress 6.5 samt Test-Library, dann läuft PHPUnit. Auf integration ist dieser Job die eigentliche Freigabe: Nur wenn er grün ist, darf nach master gemergt werden. Das erzwinge ich zusätzlich in GitLab über geschützte Branches und „Pipelines must succeed“, weil eine Regel, die nur in einem YAML-Kommentar steht, keine Regel ist.

Stufe 3, Quality. Hier läuft der offizielle Plugin Check von wordpress.org, also genau das Werkzeug, mit dem auch das Plugin-Team schaut. Der Job baut sich ein Wegwerf-WordPress in /tmp, hängt das Plugin per Symlink ein und prüft es. Die Schwelle steht bei warning, nicht bei error: null Fehler und null Warnungen, sonst bricht die Pipeline.

Das war unbequem. Die alten Warnungen, vor allem DirectDatabaseQuery an meinem lokalen Bild-Cache, musste ich einzeln durchgehen: echte Findings gefixt, die unvermeidbaren Fehlalarme mit einem begründeten phpcs:ignore versehen. Danach war die Liste leer, und seitdem ist jede neue Warnung ein echtes Signal. Gefunden hat der Job unter anderem die Eclipse-Altlasten von oben, die mir in fünf Jahren Handbetrieb nie aufgefallen sind.

Kleiner Nebeneffekt, der mich lange geärgert hat: Sobald ein Branch einen offenen Merge Request hat, lief bei mir alles doppelt, einmal als Branch-Pipeline und einmal als MR-Pipeline, auf demselben Commit. Drei Regeln im workflow-Block räumen das auf, und auto_cancel: on_new_commit: interruptible beendet alte Läufe, wenn ich nachschiebe. Bei einer Pipeline, die für jeden Lauf ein komplettes WordPress installiert, merkt man das direkt an der Wartezeit.

Der Build: was ins Paket gehört und was nicht

Auf master entsteht das eigentliche Auslieferungspaket, per bin/build-plugin.sh. Das Skript macht zwei Dinge, die wichtiger sind als das Zippen selbst.

Erstens liest es die Version aus plugin/readme.txt, aus dem Feld Stable tag. Das ist bei wordpress.org die Angabe, die entscheidet, was ausgeliefert wird. Zweitens vergleicht es sie mit der Version: im Plugin-Header. Weichen die voneinander ab, bricht es ab:

VERSION=$(grep -i "^Stable tag:" "${PLUGIN_DIR}/readme.txt" | head -1 | sed 's/.*: *//' | tr -d '[:space:]')
HEADER_VERSION=$(grep -iE "^\s*Version:" "${PLUGIN_DIR}/portraitarchiv-store.php" | head -1 | sed 's/.*: *//' | tr -d '[:space:]')
if [ "$HEADER_VERSION" != "$VERSION" ]; then
    echo "FEHLER: Header-Version ($HEADER_VERSION) != readme Stable tag ($VERSION)"
    exit 1
fi

Der Grund für die Härte: Eine falsch getaggte Version bekommst du bei wordpress.org nicht mehr zurück. Es gibt kein Zurückziehen, nur ein weiteres Release hinterher, und der Store zeigt in der Zwischenzeit fröhlich die kaputte Version an.

Das Zip enthält einen Top-Level-Ordner mit dem Plugin-Slug, so wie WordPress es beim Installieren erwartet, und IDE- sowie VCS-Reste sind per rsync-Exclude ausgeschlossen. Es geht zusätzlich als Artefakt in die Pipeline, versioniert, 5 Tage haltbar. Damit habe ich für jede ausgelieferte Version das exakte Paket zum Download, ohne im SVN zu wühlen.

Der Deploy: vierzig Zeilen, die das SVN erledigen

bin/deploy-svn.sh ist der Kern. Der Ablauf ist genau der Handbetrieb von früher, nur eben aufgeschrieben.

Version lesen, SVN auschecken, trunk synchronisieren:

svn checkout --quiet "$SVN_URL" "$BUILD_DIR"

rsync -a --delete \
    --exclude='.svn' --exclude='.git' \
    --exclude='.settings' --exclude='.project' --exclude='.buildpath' \
    "${PLUGIN_DIR}/" "${BUILD_DIR}/trunk/"

--delete ist hier das entscheidende Flag. Ohne das wächst der trunk bei jedem Release, weil gelöschte Dateien einfach liegen bleiben. Genau so entstehen die Altlasten, die ich oben beschrieben habe.

Danach die Store-Assets aus .wordpress-org nach assets, ebenfalls mit --delete. Dann der Schritt, den man von Hand am liebsten vergisst: SVN muss man mitteilen, welche Dateien neu sind und welche verschwunden sind.

svn add --force . --quiet
svn status | awk '/^!/ {print $2}' | xargs -r svn delete --quiet

Das ! in der Statusausgabe steht für „laut SVN vorhanden, im Dateisystem weg“. Ohne diese Zeile scheitert der Commit oder, schlimmer, er läuft durch und lässt Dateien im Verzeichnis, die du längst gelöscht hast.

Dann der Tag. Und zwar bedingt:

if svn ls "${SVN_URL}/tags/${VERSION}" >/dev/null 2>&1; then
    echo "==> Tag ${VERSION} existiert bereits im SVN – überspringe Tag-Erstellung"
else
    svn copy --quiet "trunk" "tags/${VERSION}"
fi

Das ist mir wichtiger geworden, als es aussieht. Der Deploy läuft bei mir auf jedem master-Commit, also auch bei einem Nachtrag am Changelog ohne Versionsbump. Wenn der Job dann am schon existierenden Tag stirbt, ist meine Pipeline rot, obwohl alles in Ordnung ist. Seitdem kann ich den Job zweimal laufen lassen, ohne vorher nachzudenken, und traue mich deshalb auch, ihn mal von Hand anzustoßen.

Am Ende ein einziger Commit, der trunk, assets und den neuen Tag zusammen veröffentlicht:

svn commit --username "$SVN_USERNAME" --password "$SVN_PASSWORD" \
    --non-interactive --no-auth-cache -m "Release ${VERSION}"

Zwei Details noch. Das Skript kennt DRY_RUN=1, dann bereitet es alles vor und zeigt nur den svn status. So habe ich es entwickelt, ohne das öffentliche Verzeichnis als Testumgebung zu benutzen. Und in der Pipeline steht der Job auf interruptible: false. Alle anderen Jobs dürfen abgebrochen werden, wenn ich einen neuen Commit nachschiebe. Ein halb übertragener SVN-Commit dagegen ist öffentlich sichtbarer Murks.

Der Git-Tag: dieselbe Version in beiden Welten

Nach erfolgreichem SVN-Push setzt ein zweiter Job denselben Tag im Git, also 4.4.0 hier und tags/4.4.0 dort. Damit finde ich Monate später zu jeder ausgelieferten Version den Commit, ohne zu raten. Bei einer Support-Anfrage ist das immer die erste Frage, die ich mir selbst stellen muss: Welchen Stand hat der Kunde da eigentlich installiert?

Und hier bin ich in eine Falle gelaufen, die nichts mit WordPress zu tun hat. Der eingebaute Weg über das release:-Keyword in GitLab CI hat bei mir nicht funktioniert: Der Runner-Step delegiert intern an glab, und glab kennt keine Option, die TLS-Prüfung zu überspringen. Meine GitLab-Instanz läuft mit selbstsigniertem Zertifikat, also endete jeder Versuch bei x509: certificate signed by unknown authority. Die Lösung war, release-cli direkt im Script aufzurufen. Das spricht die Releases-API an, akzeptiert --insecure-https und liest Server-URL, Projekt-ID und Job-Token selbst aus den vordefinierten CI-Variablen.

tag:release:
  stage: deploy
  needs: ["deploy:svn"]
  interruptible: false
  image: registry.gitlab.com/gitlab-org/release-cli:latest
  script:
    - 'VERSION=$(grep -i "^Stable tag:" plugin/readme.txt | head -1 | sed ''s/.*: *//'' | tr -d ''[:space:]'')'
    - >
      release-cli --insecure-https create
      --tag-name "$VERSION" --ref "$CI_COMMIT_SHA" --name "$VERSION"
      --description "Release $VERSION - Changelog siehe plugin/readme.txt"

Wer eine GitLab-Instanz mit ordentlichem Zertifikat hat, kann bei release: bleiben. Ich schreibe es trotzdem hin, weil die Fehlermeldung nach einem Zertifikatsproblem im Repository aussieht und man erstmal an der völlig falschen Stelle sucht.

Was ich beim zweiten Plugin anders gemacht habe

Vor ein paar Wochen habe ich für einen Sportverein hier im Ort ein Plugin gebaut. Die sind mit ihrer Verwaltung ziemlich am Anschlag, Termine, Mannschaften, Ansprechpartner, das alles per Mail und Excel. Weil ich das Ergebnis sowieso brauchbar finde, wollte ich es auch veröffentlichen, und damit stand ich wieder vor derselben SVN-Strecke.

Diesmal war es eine Stunde Arbeit statt eines Abends, weil das Muster stand. Vier Dinge habe ich dabei bewusst anders gelöst, und die zeigen ziemlich gut, wo die Shop-Pipeline noch die erste Ausbaustufe ist.

Online geht das Artefakt, nicht das Repository. Im Shop synchronisiert das Deploy-Skript den plugin/-Ordner aus dem Arbeitsverzeichnis. Im neuen Plugin ist die Quelle ausschließlich das gebaute Zip aus dem Build-Job. Das Skript entpackt es und schiebt genau diesen Inhalt ins SVN. Der Unterschied ist keine Kosmetik: So kann prinzipiell nichts online gehen, was nicht vorher gebaut, getestet und geprüft wurde, und Entwicklungsdateien können gar nicht erst mitrutschen.

Der Checkout bleibt schlank. Ein vollständiger Checkout des Plugin-SVN holt jedes alte Release mit. Beim ersten Plugin fällt das nicht auf, bei Version 40 schon. Also sparse:

svn checkout --quiet --depth immediates "$SVN_URL" "$CHECKOUT"
# trunk und assets vollständig, tags nur als Verzeichnisliste
svn update --quiet --set-depth infinity trunk
svn update --quiet --set-depth immediates tags

Der Inhalt alter Tags interessiert niemanden, ich muss nur wissen, welche es schon gibt.

Der Deploy ist sichtbar, wartet aber auf mich. Im Shop läuft er auf jedem master-Commit automatisch. Beim neuen Plugin steht er als manueller Job in der Pipeline und wartet auf den Play-Knopf, und mit einer gesetzten Variable WPORG_DEPLOY=1 läuft er automatisch durch. Zwei Regelzweige, weil GitLab einen Job, dessen Regel nicht greift, gar nicht anlegt, und eine leere Stage zeigt die Oberfläche nicht an. Mir war wichtig, dass ich die Stage sehe, auch wenn gerade nichts rausgehen soll.

Der Tag-Job stellt die richtige Frage. Das ist der Fehler, auf den ich am wenigsten stolz bin. Im Shop hängt der Tag-Job an einer changes-Regel auf plugin/readme.txt, damit er nur bei einem Versionsbump feuert. Klingt vernünftig, ist aber die falsche Frage. Die Regel fragt „hat sich diese Datei in diesem Commit geändert?“, entscheidend wäre „fehlt der Tag?“. Am 29. August ist mir das aufgefallen: Ein Deploy, den ich von Hand angestoßen hatte, blieb ohne Git-Tag zurück, weil der Commit die readme nicht angefasst hatte. Der neue Job läuft nach jedem erfolgreichen SVN-Deploy und entscheidet selbst:

if release-cli --insecure-https get --tag-name "$VERSION" >/dev/null 2>&1; then
  echo "==> Release ${VERSION} existiert bereits – kein neuer Tag."
  exit 0
fi

Dieselbe Idempotenz-Idee wie beim SVN-Tag. Prüfe den Zustand, nicht das Ereignis.

Dazu noch eine Kleinigkeit, die ich beim zweiten Mal sauberer gelöst habe: Die Version steht dort an drei Stellen, in der readme.txt, im Plugin-Header und in einer PHP-Konstante fürs Cache-Busting. Es gibt genau ein Skript, das sie ermittelt und dabei alle drei auf Gleichheit prüft. Build, Deploy und Tag greifen darauf zu. Im Shop steckt derselbe Vergleich noch im Build-Skript selbst.

Was es gebracht hat

Ein Release ist bei mir jetzt ein Merge nach master und, beim neuen Plugin, ein Klick. Ich muss nichts über Subversion wissen, während ich das mache. Der Teil, der früher Konzentration gebraucht hat, ist der Teil, über den ich am wenigsten nachdenke.

Der zweite Gewinn ist der, mit dem ich nicht gerechnet habe: Weil das Deployen billig geworden ist, veröffentliche ich häufiger. Vorher habe ich Fixes gesammelt, bis sich der Aufwand „lohnt“. Version 4.3.0 mit den signierten Bild-URLs wäre früher ein Ereignis gewesen, für das ich mir einen ruhigen Abend freihalte.

Wenn ich nochmal bei null anfinge, würde ich zwei Dinge sofort anders machen: das gebaute Artefakt deployen und nicht das Arbeitsverzeichnis, und den Plugin Check vom ersten Tag an als hartes Gate laufen lassen, bevor sich Altlasten ansammeln, die dann jahrelang im Store liegen. Die vier Punkte aus dem zweiten Plugin ziehe ich beim Shop nach, das steht auf der Liste.

Und das SVN? Interessiert mich inzwischen ungefähr so sehr wie der Druckertreiber.

Der Beitrag WordPress-Plugin mit GitLab CI nach SVN deployen: mein Release läuft auf einen Klick erschien zuerst auf Das ist die Welt von Thomas.

Aber manchmal gibt es Projekte, bei denen man nicht Nein sagen kann.

Ein guter Freund hat im Januar das Restaurant seiner Eltern übernommen – ein Familienbetrieb, der inzwischen in fünfter Generation geführt wird. Als ich mir die bestehende Webseite angesehen habe, war ich ehrlich gesagt erschrocken. Nicht, weil jemand „schlecht gearbeitet“ hätte, sondern weil sie dem, was dieses Restaurant ausmacht, einfach nicht gerecht wurde.

Und genau da begann es.

Warum WordPress – und warum Mainz?

Gerade für regionale Unternehmen rund um Mainz braucht es keine überladene Agentur-Webseite. Was es braucht, ist eine Seite, die:

• das Gefühl des Ortes transportiert
• Vertrauen schafft
• einfach zu pflegen ist
• und bei Google gefunden wird

WordPress ist dafür nach wie vor mein Werkzeug der Wahl. Nicht, weil es hip ist, sondern weil es funktioniert. Sauber umgesetzt, mit klarer Struktur und ohne unnötigen Ballast, ist WordPress eine extrem starke Basis – besonders für lokale Unternehmen im Raum Mainz.

Mehr als nur „eine neue Webseite“

Ich wollte keine Webseite bauen, die „okay“ ist.
Ich wollte eine Seite, die dem Restaurant gerecht wird.

Eine Seite, bei der man beim Durchklicken merkt:
Hier steckt Herz drin. Hier isst man nicht einfach nur – hier wird Tradition gelebt.

Also habe ich mir Zeit genommen. Habe reduziert statt aufgeblasen. Habe auf bewährte WordPress-Module gesetzt und nur dort eingegriffen, wo es wirklich nötig war. Kein Schnickschnack, kein lautes Design – sondern Klarheit, Wärme und Ruhe.

Eine Seite, die sich richtig anfühlt

Die neue Webseite ist inzwischen online:
https://goldeneslamm-bodenheim.de/

Und zum ersten Mal seit sehr langer Zeit kann ich sagen:
Diese Webseite gefällt mir wirklich. Nicht nur technisch, sondern als Ganzes.

Sie fühlt sich stimmig an.
Sie passt zum Restaurant.
Und sie macht Lust darauf, dort einen Tisch zu reservieren.

Genau das sollte eine gute Webseite tun.

WordPress Mainz – manchmal macht man eine Ausnahme

Ich weiß, dass ich solche Projekte normalerweise nicht anbiete. Aber dieses hier zeigt, warum ich WordPress mag – und warum ich es gerade für Unternehmen in und um Mainz weiterhin für das richtige Werkzeug halte.

Manchmal entsteht etwas Gutes, weil man nicht nach einem Auftrag sucht, sondern weil man helfen möchte.

Und manchmal ist genau das der Unterschied.

Der Beitrag WordPress Mainz: Warum ich diese Webseite trotzdem gebaut habe erschien zuerst auf Das ist die Welt von Thomas.

Warum überhaupt ein neues Modul?

Mehr oder weniger Regelmäßig kommt es dazu, dass Amazon* seine Prozesse ändert. Anfangs konnte man über die UI HTML-Code mit Bildern etc. erstellen. Dann musste man das über das Backend machen, dann gab es eine API. Nun hat sich Amazon gedacht, es wäre clever die API zu drosseln, wenn man zu wenige Verkäufe hat was dazu führt, dass die Artikel nicht mehr angezeigt werden und weniger verkauft werden … Kein Kommentar dazu.

Möchte man jedoch einen einfachen Link, ggf. mit einem Foto und einer Beschreibung anzeigen und zu Amazon* verlinken benötigt man mehr als den bereitgestellten HTML-Link. Die Informationen die man selbst benötigt um einen Link zusammen zu bauen sind überschaubar (Link, Titel, Beschreibung, ID), also ist eine echte Abhängigkeit aus meiner Sicht nicht notwendig und über eine kleine Datenbanktabelle recht einfach umsetzbar.

ChatGPT: erstelle mir ein WordPress-Modul

Es war Sonntag und ich saß mit dem Notebook am Wohnzimmertisch. Ich dachte mir ich könnte doch einfach mal ChatGPT fragen, ob es nicht Lust hätte mir ein WordPress-Modul zur Verwaltung der Referal Links zu erstellen. Ich eröffnete einen Chat und hatte nach nur 2 Prompts das erste funktionierende Modul. Als erstes fragte ich ChatGPT ob dies eine Möglichkeit kennt die Produkte zu integrieren:

Wie kann ich einen Amazon Artikel auf meiner Seite mit Name, Bild und Beschreibung anzeigen wenn ich einen Partner Account habe aber mein API Access limitiert ist?

Die Antworten zeigten unterschiedliche Möglichkeiten auf wie kostenpflichtige Module welche Amazon Scrapen über den Einsatz von Dienstleistern bis hin zur manuellen Erstellung der Anzeigen. Also fragte ich

Ich denke es ist am einfachsten, wenn ich mir hier selbst was bastle
Kannst du mir ein WordPress Modul erstellen? Dies soll folgende Funktionen haben

Das Modul hat eine Datenbanktabelle in welcher die relevanten Daten gespeichert werden (Amazon-Produkt-ID, URL zum anzuzeigenden Bild, Titel des Produktes, Optionale Beschreibung, Link zum Artikel)

Die Daten sollen über eine Maske im Adminbereich des Modules gepflegt werden können
Über einen Shortcode sollen die Artikel in einen Beitrag integriert werden – Beispiel

Produkt nicht gefunden.

Wenn es integriert wird soll ein HTML Snippet in die Seite integriert werden bei welchen die entsprechenden Daten des Produktes zur ID angezeigt werden

Die Snippets sollten in externen Dateien pflegbar und erweiterbar sein.

Das Modul soll ‚Simple Amazon Referral‘ heissen

Um ehrlich zu sein habe ich nicht sonderlich viel erwartet doch das Ergebnis war direkt einsetzbar. ChatGPT erstellt mir eine erste Version des Modules welches den Vorgaben von WordPress entsprach, die Datenbank aufsetzte und sämtliche Vorgaben erfüllte.

ChatGPT setzt auch Anpassungswünsche um

Nachdem die erste Version des Modules bereits recht gute Ergebnisse erzielte und ein erster PoC erfolgreich war versuchte ich, das Modul weiter zu verbessern. Hierbei blieb ich einfach im gleichen Chat und teilte meine Wünsche mit:

• Erstellung weiterer Anzeige-Templates
• Shortcode erweitern um Auswahl des Templates
• weitere Shortcode zur Erstellung eines Textlinks
• Angabe der Datenbank-ID oder der Produkt-ID im Shortcode

Am „Ende“ ist ein Modul entstanden welches ich, ohne eigene Anpassungen, direkt einsetzen könnte. Die Qualität überraschte mich wirklich enorm.

Code nach kleinem Review veröffentlicht

Ich gebe zu, dass ich ChatGPT nicht vertraut und den Code nochmal geprüft habe. Auch habe ich mir manuell nochmal die Vorgaben von WordPress zur Entwicklung von Modulen durchgelesen (mein letzte Modul ist doch schon ein paar Jahre her). Allerdings musste ich selbst nichts verbessern was ich nicht über Prompts durch ChatGPT übernehmen lassen konnte.

In den offiziellen WordPress Modulkatalog habe ich das Modul nun nicht übernommen, dennoch entschied ich mich dazu es auf Github abzulegen.

Das gesamte Modul ist unter GitHub unter dem Namen ‚Simple Amazon Referral‚ bereitgestellt. Mal sehen wie sich das ganze weiter entwickelt …

ChatGPT als Gefahr für die Softwareentwicklung?

Wenn ich mich mit Bekannten unterhalte kommt häufig die Frage auf, ob ChatGPT (oder andere LLMs) nicht eine Gefahr für die Softwareentwicklung darstellen. Ich selbst sehe das nicht so sondern sehe in den LLMs Möglichkeiten zu Optimierung. Schon heute unterstützen mich die Modelle in meiner täglichen Arbeit (inzwischen auch in meinem Berufsleben) und nehmen mir „leichte Arbeiten“ zum Teil ab. Hier und da werde ich korrigiert oder auf Fehler hingewiesen. Ich persönlich sehe die Large Language Modelle eher als eine neue Technik an die man als guter ITler kennen und beherrschen sollte.

Wie seht Ihr das?

Der Beitrag Simple Amazon Referral – WordPress Modul durch ChatGPT erschien zuerst auf Das ist die Welt von Thomas.

Bildmaterial von externen Quellen nutzen

Die wenigsten Webseitenbetreiber sind nebenbei noch Fotografen, möchten aber dennoch die eigenen Artikel ansprechend gestalten. Schnell stellt sich die Frage woher man das geeignete Bildmaterial nehmen kann, ohne sich auf die schiefe Bahn zu begeben. Ich selbst bediene mich, sofern ich Bildmaterial benötige, 2 Plattformen welche lizenzfreie Bilder anbieten:

• pixabay
• unsplash

Beide Plattformen stellen lizenzfreies Bildmaterial zur Verfügung. Die Datenbank kann bequem nach Keywords durchsucht und das entsprechende Bildmaterial heruntergeladen werden. Das verwendete Bildmaterial muss (oder sollte zumindest der Fairness halber) entsprechend gekennzeichnet werden. Ich selbst stelle diese Kennzeichnung als ein Bildverzeichnis dar in welchem jedes verwendete Bilder mit einem Link zum Urheber versehen wird.

ImageSourceControl- Bildquellen und Urheberrechte verwalten

Das Plugin Image Source Control ist im WordPress Plugin-Verzeichnis zu finden. Die Verwendung des Plugins ist denkbar einfach. Einmal installiert prüft das Plugin (sofern es so konfiguriert wird) jedes in der Mediathek veröffentlichte Bild. Bei jedem Bild kann hinterlegt werden ob es ein eigenes oder ein Bild aus einer externen Quelle ist. Wird ein neues Bild hochgeladen erscheint auf jeder Seite ein Hinweis, dass ein Bild vorliegt, bei welchem noch keine Quelle definiert ist.

Natürlich verfügt das Plugin noch über diverse Konfigurationsmöglichkeiten, welche glücklicherweise alle Selbsterklärend sind (zumindest aus meiner Sicht). Die Konfiguration selbst ist im WordPress-Adminbereich unter Einstellungen > Bildquellen zu finden.

Quellverzeichnis als eigene Page anzeigen

Ich bin ein Freund davon transparent mit dem Thema der Bildrechte umzugehen. Ich freue mich darüber, dass es Menschen gibt, die sich bereiterklären Ihr Bildmaterial anderen zur Verfügung zu stellen. Ein Link zum Urheber ist da wohl das Mindeste.

Aus diesem Grund verfügen all meine Seiten, bei welchen ich Bildmaterial aus externen Quellen verwende, über eine Quellverzeichnis. Diese Seite lässt sich mit Hilfe des Plugins vollautomatisch erstellen und sorgt dafür, dass das Verzeichnis immer aktuell ist.

Um ein solches Quellverzeichnis zu erstellen muss lediglich eine neue Seite in WordPress angelegt werden. An der Stelle, an welcher das Verzeichnis erscheinen soll, ist ein kleiner Shortcode einzufügen:

 [isc_list_all per_page="25"]

Der Parameter ‚per_page=“25″‚ sorgt dafür dass je Seite 25 Images angezeigt werden. Natürlich kann dieser Paramrter frei definiert werden, ich selbst komme mit den 25 ganz gut aus.

Der Beitrag Bildquellen und Urheberrechte in WordPress verwalten erschien zuerst auf Das ist die Welt von Thomas.

Zwar wurde die Seite vollständig geladen, diverse Plugins waren jedoch ohne Funktion. Hierbei wurde das Plugin zwar geladen aber diese waren inaktiv.

Dank der JavaScript Console konnte die Ursache schnell gefunden werden – offensichtlich wurde mit dem Update auf WordPress 5.5 auch ein Update in den JQuery-Libraries durchgeführt. Hierdurch kommt es zu einem Fehler bei der jquery migrate Funktion welche von diversen Plugins (unter anderem auch dem Yoast SEO) genutzt wird. Die Console ist voll von Fehlern.

WordPress 5.5 update Plugins fehlerhaft – einfache Problemlösung

Nachdem ich mich ein wenig mit Google in diversen Foren und dem Supportbereich von WordPress herumgeschlagen habe wurde schnell klar, dass dies natürlich kein Einzelfall ist. Glücklicherweise wurde seitens WordPress bereits ein Plugin bereitgestellt welchen diesen Fehler behebt. Weitere Informationen dazu sind direkt im Supportbereich zu finden.

Die Lösung: Enable jQuery Migrate Helper

Die Lösung des Problemes ist ebenfalls im Plugin-Verzeichnis von WordPress zu finden. Das Plugin „Enable jQuery Migrate Helper“ löst das Problem mit einem Workaround. Dieser Workaround soll den Entwicklern der Plugins mehr Zeit verschaffen so dass diese Ihre eigenen Plugins an die neuen Anforderungen anpassen können.

Das Plugin ist recht schnell installiert. In die Pluginverwaltung gehen und dort das Plugin „Enable jQuery Migrate Helper“ suchen. Danach einfach per Buttonclick installieren und aktivieren. Schon ist der Fehler behoben und die Plugins sind wieder lauffähig.

Quickfix deinstallieren wenn Plugins nachgezogen

Das hier genannte Vorgehen ist lediglich als Quickfix zu betrachten. Das Plugin sollte nur so lange installiert sein bis die Pluginhersteller selbst nachgezogen und ein Update bereitgestellt haben. Selbiger Hinweis ist ab der Installation des Plugins auch im Adminbereich von WordPress zu finden:

jQuery Migrate Helper
Right now you are using the Enable jQuery Migrate Helper plugin to enable support for old JavaScript code that uses deprecated functions in the jQuery JavaScript library. You will see warnings about these functions while using WordPress administration, but they will not be shown on the front-end of your site. To check if there are any warnings generated by your theme please look in the browser console.

If you get warnings, you should check the theme or plugin that generated them for an update. There will very likely be one you can install. When you have updated your plugins and themes, and there are no more warnings, please deactivate Enable jQuery Migrate Helper.
* A script, a file, or some other piece of code is deprecated when its developers are in the process of replacing it with more modern code or removing it entirely.

Quelle: Adminbereich von WordPress nach Installation des Plugins

Achtet also bitte selbst darauf die Updates eurer Plugins und Themes zu installieren sofern diese zur Verfügung stehen.

Der Beitrag WordPress Plugins fehlerhaft nach Update auf 5.5 erschien zuerst auf Das ist die Welt von Thomas.

Umso wichtiger war es das Ihre Internetseite endlich auf den neuesten Stand gebracht wurde. In meinem Urlaub hatte ich hierfür uneingeschränkte Zeit und das Ergebnis kann sich, aus unserer Sicht, durchaus sehen lassen.

Die neue Webseite wurde, natürlich, mit WordPress umgesetzt und ist unter LovelyWords.eu erreichbar.

Bei der Erstellung der Seite wurde Wert auf die Suchmaschinenoptimierung gelegt. Suchbegriffe wie Freie Trauung Mainz oder auch Freie Traurednerin Mainz standen hierbei im Focus. Ich bin gespannt wie lange es dauert bis die Seite bei den einzelnen Suchmaschinen indiziert ist und ob die Anstrengungen Ihren Zweck erfüllen.

Der Beitrag Urlaub effektiv genutzt – neue Webseite erschien zuerst auf Das ist die Welt von Thomas.

Kann ich eigentlich bei WordPress auch Widgets oder ganze Sidebars je nach Inhalt des Beitrages anpassen oder ersetzen?

Warum? Das war mein erster Gedanke. Nach einigen Gesprächen ist die Idee aber doch ganz sinnvoll und wird inzwischen auch hier in diesem Blog eingesetzt.

dynamische Sidebars – warum ist das Sinnvoll?

Statische Sidebards neben Blogeinträgen ergeben durchaus Ihren Sinn. Die Platzierung einer Suchfunktion, Übersicht der Kategorien oder Tagcloud sorgt dafür, dass der Besucher entspannt navigieren kann. Was ist aber nun, wenn wir innerhalb dieser Sidebar themenbezogene Inhalte, sagen wir z.B. mal einen aktuellen Aktienkurs des Unternehmens über welches hier gerade geschrieben wird, positionieren möchten?

In diesem Fall ergeben dynamische Sidebars durchaus Sinn. Nach ein wenig Recherche und der Prüfung einiger Plugins bin ich auf das Plugin ‚Content Aware Sidebars‚. Dieses Plugin liefert so einiges an intelligenten Funktionen mit deren Hilfe auf Basis des Inhaltes Sidebars ausgetauscht oder (in der Premium-Variante) nur ergänzt werden können.

Wie ist das Plugin aufgebaut?

Das Plugin gibt es in einer kostenlosen und einer Premium-Variante. Ich selbst setze aktuell noch die kostenlose Variante ein da diese für meine Bedürfnisse ausreichend Funktionen liefert. Zugegeben, ich muss hier und da einen Umweg gehen da ich keine Sidebars ergänzen, sondern nur vollständig ersetzen kann, dennoch können meine Anforderungen erfüllt werden.

Das Plugin selbst arbeitet mehr oder weniger selbsterklärend. Im ersten Schritt findet sich in der Hauptnavigation ein neuer Bereich mit dem Titel „Context Aware“ wieder. Hierüber lassen sich die neuen Sidebars anlegen und konfigurieren. In meinem Fall (siehe Screenshot) habe ich hier 2 Sidebars hinzugefügt, eine mit dem Titel Werbebeiträge und eine für Beiträge ohne Werbung.

Für jede dieser Sidebars wurde im Bereich „Widgets“ eine neue Sidebar angelegt. Über diesen Bereich kann ich nun, wie gewohnt, der entsprechenden Sidebar die von mir gewünschten Widgets hinzufügen und diese somit so individuell gestalten wie ich möchte.

Um die Sidebars nun dynamisch nutzen zu können müssen im Bereich der Sidebarverwaltung (Menüpunkt ‚Context Aware‘) Kriterien angelegt werden und welchen Umständen die Sidebar anzuzeigen ist. Hier stehen eine Vielzahl von Optionen zur Verfügung welche ausgewählt werden können. In meinem Beispiel (siehe folgende Screenshots) zeige ich die Sidebar „Werbebeiträge“ immer dann an, wenn der entsprechende Artikel das Schlagwort „werbung“ enthält.

Die Konfigurationsmöglichkeiten sind sehr mächtig. So können neben einfachen Stichworten oder Kategorien sogar unterschiedliche Zeiträume angegeben werden in welchen eine Sidebar zu sehen sein soll (oder eben nicht). Aus meiner Sicht sind hier wirklich coole Features versteckt.

Wo setze ich dynamische Sidebars ein?

Ich hasse Blogbeiträge, welche nur den Sinn und Zweck von Werbung haben. Dennoch möchte ich hin und wieder einfach einmal über gute Erfahrungen berichten dürfen ohne mir gleich Gedanken darüber zu machen wie ich das ganze Kennzeichnen muss. Aus diesem Grund habe ich mir eine Sidebar gebaut, welche bei Beiträgen erscheint, welche tendenziell Werbung enthalten. Hierzu füge ich den Beiträgen den Tag „Werbung“ hinzu und schon erscheint eine abgewandelte Sidebar mit dem entsprechenden Hinweis.

Ich selbst empfinde diese Lösung als sehr einfach und bin froh, das Plugin gefunden zu haben. Mal sehen, vielleicht finde ich ja noch weitere Einsatzgebiete

Der Beitrag dynamische Sidebars in WordPress – Content Aware Sidebars erschien zuerst auf Das ist die Welt von Thomas.