Kategorie: eproi pur

In der heutigen Zeit hat sich immer mehr durchgesetzt, Softwareprojekte mithilfe einer Versionierungssoftware zu entwickeln. Vorteile gibt es dabei tatsächlich nicht nur für Teams. Auch „Soloprojekte“ können von einer solchen Versionierung profitieren. Am Markt gibt es sehr verschiedene Systeme und dann stellt sich noch die Frage: Selbst hosten oder lieber einen Account bei einem größeren Anbieter nutzen? Ein Komplettüberblick für alle Varianten mit allen Vor- und Nachteilen kann es nicht geben. Wir wollen aber an dieser Stelle unseren Weg aufzeigen und vielleicht auch dokumentieren, warum der Anfang zwar gut war, bald aber nicht mehr so praktikabel.

Ausgangssituation

Aktuell gibt es bei uns nur „Soloprojekte“ also Projekte, bei denen ein Entwickler sich um die Programmierung innerhalb des Projektes kümmert. Perspektivisch könnte es aber auch passieren, dass so ein Projekt mit anderen zusammen bearbeitet wird – sei es Externen oder aber auch interne Mitarbeiter. Deswegen wurde zwischendurch beschlossen, für alle Projekte bereits eine Versionierung aufzusetzen. Auch mit dem Hintergrund, dass es immer mal wieder vorkommt, dass eine gewünschte Änderung dann doch nicht das passende für den Kunden ist. Das ist mit der Versionierung kein Problem: Richtig aufgesetzt kann man eine Änderung rasch zurücknehmen und bekommt einen sauberen Stand – ohne sich Gedanken machen zu müssen, ob man jetzt noch eine Codezeile vergessen haben könnte.

Der Anfang: selbst gehostet oder bei einem Anbieter?

Ok, der Wunsch war also da: Es sollte eine Versionierung eingeführt werden. Doch damit kamen erst mal die Fragen. Welches System passt überhaupt? Und danach: Wird ein großer Anbieter genutzt oder wird das auf einem eigenen Server selbst gehostet? Gleich vorweg: Wir haben uns fürs selbstgehostete Modell entschieden. Warum? Auch weil es ein bisschen mehr Kontrolle darüber liefert, wo die Daten liegen… Stichwort DSGVO und Co. Aber der Reihe nach.

Schnell war hier klar es sollte etwas wie „git“ sein. Weithin bekannt und auch schon aus anderen Projekten und der Beschäftigung als Angestellter vertraut. Damit waren die Variationen schon mal eingeschränkt. Nach kurzer Recherche war dann auch klar, dass mit Gitea eine „Git-Version“ bereitsteht, die einfach zu installieren ist und damit perfekt geeignet für eine selbstgehostete Variante. Da auf dem passenden Server sonst nichts weiter laufen sollte an zusätzlichen Services haben wir also einen „nackten“ Server aufgesetzt, mit den notwendigen Dingen wie Apache, Datenbank und Co ausgestattet und Gitea darauf eingerichtet. Anschließend konnte nach Einrichtung der SSH Keys und eines Tortoise Git Systems auf dem eigenen Windowsrechner sofort mit dem Anlegen und Versionieren unserer Projekte begonnen werden.

Was bietet Gitea?

Kurz zusammengefasst: Gitea fußt auf der git-Software auf, ist aber bewusst etwas schlanker gehalten. Einige Randfunktionen bietet Gitea nicht, das war aber zu dem Zeitpunkt kein Problem. Es ging ja nur erst mal darum, etwas zu Versionieren. Und das kann Gitea genauso wie Gitlab oder andere Softwares dieser Art. Selbst mit Branches und Merges hat Gitea kein Problem. Wirklich? Naja nicht ganz. Bei den Branches gibt es schon die erste Einschränkung.

Erste „Probleme“ mit Gitea…

Branches kann Gitea aber bei den Merge-Requests geht nur Sekt oder Selters. Heißt konkret: Ein Branch kann mittels Merge-Requests nur in seiner Gesamtheit abgelehnt oder angenommen werden. Es ist nicht möglich, einige Änderungen in den Hauptpfad zu committen und andere zurückzuweisen. Wir haben das auch festgestellt, als auf einmal in einem Projekt vollkommen unvermittelt noch ein weiterer Externer Programmierer vom Auftraggeber zugelassen wurde und es auf einmal darum ging, die eigenen Änderungen mit den Änderungen des Kollegen so zusammen zu bekommen, dass am Ende alles erhalten blieb, was notwendig war. Wir haben das hier versucht über eben einen Branch, in dem erst mal die Änderungen des Anderen eingespielt wurden und dann sollte über einen Merge-Request das ganze vereinigt werden. Gitea zeigte auch brav alle Änderungen an. Aber eine Funktion, die die Übernahme bestimmter Änderungen zuließ während anderes nicht übernommen würde gab es nicht. Eben Sekt oder Selters. 😉

Das war dann jedenfalls für uns der Moment, nochmal zu überdenken, ob ein Gitea wirklich weiterhelfen kann. Aber was gibt es für Optionen?

Ein Seitenblick: Gitlab vs. Gitea

Wie bereits erwähnt fußen mehrere Angebote auf git auf. Am bekanntesten neben Gitea dürfte Gitlab sein. Etwas mächtiger in den Funktionalitäten und etwas schwieriger aufzusetzen. Wir haben uns daran gewagt und werden in einem weiteren Post nochmal versuchen zusammenzufassen, auf was besonders geachtet werden sollte.

PHPUnit-Tests gibt es schon seit über 20 Jahren. Bisher haben wir aber für unsere Entwicklungen eher auf „klassische“ Tests gesetzt. Heißt: Wir haben eine Software geschrieben und diese dann auf einem Testsystem „live“ ausprobiert. Um unsere Softwarequalität aber zu steigern und gleichzeitig Programmierstandards zu pflegen haben wir beschlossen in Zukunft bei der PHP-Entwicklung auch auf PHPUnit-Tests zu setzen. Ein erster Erfahrungseinblick.

Ausgangssituation

Wir hatten sowieso gerad ein neues Projekt am Start – diesmal wieder die Entwicklung eines WordPress-Plugins – und Ende letzten Jahres gerade auf der betterCode()-Konferenz für den Bereich PHP nochmal oder wieder von PHPUnit als „Test-Suite“ gehört. Da ja Stillstand bekanntlich den Tod bedeutet haben wir also mutig beschlossen, unsere Softwarequalität mithilfe dieses Tools einmal gehörig voranzubringen.

Natürlich behalten wir auch unsere bisherige Testmodalität mit der Testinstallation bei. Schließlich soll ja auch das Aussehen und die Funktionalität im Browser getestet werden. Die PHPUnit-Tests werden wir aber zukünftig verstärkt einsetzen um bereits vorab generelle Tests aufzubauen, die einfach verhindern, dass wir schon mit ganz rudimentären Fehlern an den Start gehen, wie z.B. ein vergessenes Semikolon am Ende oder eine zu viel geöffnete oder geschlossene Klammer…

Also wir hatten ein brandneues Projekt mit ohne irgendwas. Lokal haben wir einen Apache am Laufen und auch einen MariaDB-Server. Etwas googlen brachte uns dann noch den Hinweis, das es auch für WordPress eine Art „development“ Zweig gibt, mit dem man dann auch in PHPUnit testen können soll. Gesagt getan…

Einrichten und erst mal Testen der Testumgebung

Ja richtig: Bevor man sowas nutzen kann muss man das ja erst mal einrichten. Wir haben also erstmal das WordPress-Verzeichnis hingestellt und dann ging der Spaß auch schon los: Zum Einrichten hat uns das große Internet verraten, dass wir vermittels npm und grunt das ganze so aufsetzen können, dass es für unsere Unit-Tests läuft. Das war aber mal gar nicht so einfach. Es gab node und npm aber wir mussten zunächst die Pfade in die Umgebungsvariablen bringen bzw. verbessern, da node und npm ursprünglich über Visual Studio (manchmal entwickeln wir auch in C# ;))  auf das System kam und in dem Ordner noch nicht anständig wollte. nachdem wir das soweit hatten und auch alles sauber loslief, haben wir ins passende Plugin-Verzeichnis unser neues „Plugin“ kopiert und dann einen Ordner Tests angelegt.

PHPUnit-Tests – jetzt aber!?

Um erst mal warm zu werden haben wir erst mal ganz einfache Tests geschrieben. Wir wollten zunächst nur prüfen, ob unser Plugin aktiviert wurde, einen Menüeintrag im Adminmenu erzeugt und die Adminseite im Ansatz beim Aufruf der URL irgendwas an Inhalt erzeugt. Da kam aber schon die erste Frage in uns auf: Wie aktiviert man denn ein Plugin, wenn man gerade nicht die WordPress-typische Pluginseite vor der Nase hat? Etwas knifflig. Wir befragten also wieder das Internet und dort hieß es: Einfach in der Datenbank in den Optionen das Plugin unter den aktivierten Plugins mit eintragen. Ok – also auf die lokale DB mittels phpMyAdmin gegangen und: Die Datenbank ist ja leer? Moment – wir hatten doch vorhin mittels npm und grunt das ganze „installaliert“? Offenbar gereicht diese „Installation“ aber nicht soweit, dass auch eine DB ordentlich angelegt wird. Das Internet riet dazu, aus einer anderen frischen WordPress-Installation einfach die WordPress-eigenen Tabellen zu importieren. Gut also auch das erledigt.

Jetzt aber zu den Tests? Noch nicht ganz. Unser geschriebener Test hatte als erstes Problem das die Ausgabe bereits erzeugt wurde, bevor das PHPUnit-Testgebilde seine Ausgabe gestartet hat. Ein klassisches Problem von Output vor den Headern. Aber auch sonst gab es haufenweise Probleme. Es genügte nicht die wp-load.php einzubinden und ggf. noch die wp-config. Es musste tatsächlich für alle benötigten Funktionen jeweils die passende wp-* Datei eingebunden werden in die Testklasse.

Erstes Fazit

Naja so ganz zufrieden sind wir mit den Bedingungen noch nicht. Eigentlich war nicht der Plan, alle Dateien „manuell“ einzubinden nur um dann einen Test fahren zu können. Der Plan war, eine Art WordPress-Instanz zu haben, in der man dann vielleicht noch mittels einfacher Hooks oder ähnlichem die benötigten Seiten und Eigenschaften aufrufen kann. Das hat bisher noch nicht geklappt. Aber vielleicht finden wir auch dafür demnächst nochmal eine etwas charmantere Konfiguration. Wir lernen ja noch… Und ach ja: Die Tests sind am Ende erfolgreich verlaufen. 😉

WordPress: wp_set_object_terms und zwei Kuriositäten aus der Praxis

WordPress bietet für die programmatische Zuweisung von Taxonomien zu einem Post — etwa einem Bild — eine praktische Funktion:

wp_set_object_terms()

So hilfreich sie ist, so hat sie doch ein paar Tücken.
Zum einen prüft die Funktion nicht, ob zwischen dem Post und dem Term bereits eine Relation besteht. Das ist bekannt und wird auch in der WordPress‑Entwicklerdokumentation beschrieben.

In der Praxis gibt es jedoch zwei weitere Kuriositäten, über die man leicht stolpert.

1. Mehrere Terms nacheinander setzen? Vorsicht.

Wenn man versucht, mehrere Terms nacheinander einzeln zuzuweisen — also nicht als Array, sondern in mehreren Funktionsaufrufen — landet am Ende nur eine einzige Relation in der Datenbank.
Hat man drei Terms, verschwinden zwei davon einfach.

Lösung

Alle Terms in ein Array packen und dieses Array an wp_set_object_terms() übergeben.
Nur dann werden alle Relationen korrekt berücksichtigt.

2. Typisierung der Term‑IDs ist entscheidend

Ein weiteres Problem betrifft die Typisierung der übergebenen Werte.
Wenn man Term‑IDs nicht explizit typisiert, kann es passieren, dass WordPress einige Werte als Strings interpretiert — mit entsprechend unerwarteten Ergebnissen.

Beispiel

(int)$term_id

oder beim Befüllen eines Arrays:

array_push($term_ids, (int)$term_id);

Ohne diese Typisierung kann WordPress intern durcheinanderkommen, weil nicht sauber geprüft wird, was tatsächlich in $term_id steckt.

Fazit

Mit diesen beiden Vorsichtsmaßnahmen — Terms immer als Array übergeben und IDs sauber typisieren — verhält sich wp_set_object_terms() so, wie man es erwarten würde.

Dass WordPress an dieser Stelle so wenig prüft, ist allerdings bemerkenswert.

Vielleicht ergibt sich irgendwann die Gelegenheit, auszuprobieren, was passiert, wenn man der Funktion bewusst „unsaubere“ Strings übergibt…

ASP.NET Core, Blazor und der verschwundene „Authenticated User“

Wir arbeiten aktuell an einer Eigenentwicklung auf Basis von C# ASP.NET Core und Blazor.
Im Zuge dieser Entwicklung haben wir natürlich auch die vom Framework bereitgestellte Login‑Mechanik implementiert. Und wie es bei .NET‑Updates manchmal ist: Nach einem Update funktionierte plötzlich nichts mehr so, wie es sollte.

Der Login selbst lief scheinbar korrekt durch. Im Konsolenlog erschien „User logged in“, aber in den nachfolgenden Bereichen — dort, wo Daten basierend auf dem aktuellen Benutzer geladen werden sollten — meldete das System plötzlich, dass kein „authenticated user“ vorhanden sei.
Merkwürdig.

Parallel dazu sorgten verschiedene Rücksetzungen von NuGet‑Paketen dafür, dass das Projekt in der Visual Studio 2022 Preview gar nicht mehr starten wollte. Die Lösung dafür war simpel: Projekt in der regulären Visual Studio 2022 Version öffnen. Die Preview war ursprünglich installiert worden, als MAUI, Blazor und .NET 8 gerade frisch integriert wurden — inzwischen aber nicht mehr notwendig.

Der eigentliche Fehler blieb jedoch bestehen:
Seite aufrufen → Weiterleitung zum Login → erfolgreicher Login → zurück zur ursprünglichen Seite → Benutzer nicht authentifiziert → keine Daten.

Die Anwendung ist eine hybride Blazor‑App, bestehend aus einem serverseitigen und einem clientseitigen Teil. Beide müssen — damit die Authentifizierung sauber funktioniert — den passenden AuthenticationStateProvider implementieren. Das war auch der Fall.

Allerdings hatte sich im Update‑Chaos unbemerkt ein Scope verändert:

builder.Services.AddScoped<AuthenticationStateProvider, PersistingRevalidatingAuthenticationStateProvider>();

war plötzlich zu

builder.Services.AddScoped<AuthenticationStateProvider, IdentityRevalidatingAuthenticationStateProvider>();

geworden.

Offenbar vertragen sich beide Varianten nicht besonders gut — zumindest nicht so, dass beide Seiten einer hybriden Blazor‑App zuverlässig mitbekommen, dass ein Benutzer erfolgreich eingeloggt wurde.
Nach der Rückumstellung funktionierte die Authentifizierung sofort wieder.

Woher die Änderung ursprünglich kam, können wir nicht sagen — und haben an der Stelle auch nicht weiter nachgeforscht. Wahrscheinlich hätte auch die umgekehrte Variante (beidseitige Umstellung auf IdentityRevalidatingAuthenticationStateProvider) funktioniert.

Wichtig war: Der Scope musste auf beiden Seiten konsistent sein.
Danach lief alles wieder stabil.