Danke für eure lieben Reaktionen.
doerek meine Entscheidung hat nichts mit Geld zu tun. Natürlich haben die Plugins gerade am Anfang Geld abgeworfen, aber weder so viel, dass sie die Arbeit bezahlt hätten, noch das ich davon hätte leben können. Sollte es Updates für die Plugins geben, werden diese kostenfrei und für alle zugänglich gemacht 
Ich hatte mir heute das Thema bei WoltLab durchgelesen. Auch wenn es recht schnell abdriftet möchte ich zumindest ein bisschen kommentieren. Wenn auch nicht auf WoltLab:
Ja es war eine Kurzschlussreaktion, aber so wie Sunny C. schon geschrieben hat, war die Schnur schon länger am brennen. Hier eine ausführliche, wenn auch bestimmt nicht vollständige Liste der Themen die zu meiner Entscheidung geführt haben:
- Mit jeder Version wird die API immer restriktiver. Begründet wird das damit, dass eine riesige API zu einem riesigen Aufwand der Pflege bedeutet. Das die Updates von Version zu Version aber jedes Mal so anstrengend sind, liegt nicht an der riesigen API, sondern das sie z.B. die Javascript Architektur 2x auf den Kopf gestellt haben oder Dinge entfernen ohne für Alternativen (gerne bessere) zu sorgen.
- Die Umstellung von FontAwesome 4 auf 6 habe ich zuerst begeistert gelesen. Leider habe ich dann festgestellt, dass WoltLab sich eine proprietäre und meiner Meinung nach unnötige API dazu ausgedacht hat, die nahezu jedes Feature von FontAwesome 6 kaputt macht und keinen vernünftigen Support für FontAwesome Pro bietet.
- Die Entwicklung von Features exklusiv für die WoltLab Cloud. Ich kann verstehen, dass die Liveaktualisierung eine gewisse Infrastruktur erfordert, die WL nicht mit der Software ausliefern kann und deshalb nicht für jeden Kunden genutzt werden kann. Dennoch hätte man die Schnittstelle zugänglich machen können, damit die die Infrastruktur dafür bereitstellen können, auch nutzen können.
- Geplante Änderungen zum Thema Events: Weg von Events die an festen Stellen gefeuert werden, hin zu wiederverwendbaren Events, die an vielen Stellen gefeuert werden und der Entwickler des Events festlegt, welche Parameter enthalten sein sollen. Den Gedanken finde ich gut. Wenn ich wissen möchte, ob ein User eingeloggt wurde, egal wie, macht das Beispiel eines UserLoggedIn Events durchaus Sinn. Möchte ich aber konkret das LoginForm verändern, bringt mir dieses Event gar nichts. Auch die Tatsache, dass der Event Entwickler vorher festlegt, welche Parameter dem Event mitgibt ist gut gemeint, beschränkt aber die Nuztung der Events auf die Vorstellungskraft des Event Entwicklers. Boxxer wäre so wahrscheinlich nie möglich gewesen. Aktuell gibt es noch die festen Events und eine Mischung wäre wahrscheinlich die beste Lösung. Der Satz aus der Doku WoltLab Suite 5.5 introduces the concept of dedicated, reusable event classes. Any newly introduced event will receive a dedicated class lässt aber befürchten, dass das nicht der Plan von WoltLab ist.
- Aktuelles Thema: Ich freu mich, dass WL letztendlich den Fehler korrekt behoben hat. Meine Unterstellung, dass WL lieber ihre eigene API kaputt macht, als ein Feature zu unterstützen, das sie selbst nicht brauchen, kommt von WL erster Antwort auf das Thema:
Quoteder Sinn und Zweck von abortPrevious() ist es, eine noch laufende Abfrage abzubrechen, die an denselben Endpoint gerichtet ist. Ein Anwendungsbeispiel dafür sind Vorschläge bei einem Eingabefeld, bei denen sich die Eingabe ändert, bevor die Antwort eingetroffen ist.
- Die Methode war nicht dafür gedacht beliebige Requests abzusenden, sondern um laufende Abfragen zu beenden, bevor eine neue an denselben Endpoint gerichtet Abfrage gestartet wird. Das sah man dann auch im ersten Fix von WL. Der zweite Fix kam (Achtung Unterstellung/Vermutung) meiner Meinung nach daher, dass sie keine Lösung gefunden haben, die nur ihren Use Case abdeckt und die API nicht kaputt macht. Das Ganze ist besser verpackt als meine direkten Worte. Wer weiß, ob es diese Lösung ohne diese Worte gegeben hätte. Dazu dass es zwei getrennte Fehler gewesen sind: Glaube ich ehrlich gesagt nicht. Als ich den ersten Fix gesehen habe, war mir innerhalb von 3 Sekunden klar, dass nicht funktionieren kann. Die WL sind gute Entwickler, sehr gute sogar, sonst würde die WoltLab Suite nicht so gut sein. Mich würde deshalb sehr wundern, wenn sie nicht gewusst haben, dass die Änderung die API brechen würde. Aber Fehler sind menschlich, vielleicht vertue ich mich auch (s.o. warum ich das nicht glaube)
Deswegen bleibt der Status Quo erstmal bestehen. Wie gesagt mit den Plugins bestreite ich nicht meinen Lebensunterhalt und ich habe einfach nicht die Motivation in meiner Freizeit durch mMn Entwickler unfreundliche Entscheidungen gefrustet zu werden. Da kann ich mir sehr viel schöneres vorstellen. Wie schon gesagt werden ich euch nach wie vor Support bieten und keine Version mit Fehlern stehen lassen (auch wenn sich die aktuelle Fehlersuche in Boxxer schwierig gestaltet 
)
LG, David
! Erstes Ziel ist es die vorhanden Plugins - wie sie sind - auf WSC 6.0 zu bringen. Neue Features oder Anpassungen wird es erst mit Folgeversionen geben. Mit dem Update endet der Support für die 5.x Versionen. Bitte habt dafür Verständnis, dass ich leider keine Zeit aufbringen kann zwei Code-Stände meiner Plugins zu pflegen.
