Kategorie: eproi pur

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.