# Ein falsches Gefühl der Sicherheit durch Testing Veröffentlicht: 24. September 2026 von Matze – Kommentar hinterlassen Als ich Version 2.0.0 von Block Control veröffentlichte, war ich sehr erfreut und zufrieden mit dessen neuen Tests. Wie falsch ich doch lag … Diese neue Version war die erste mit Ende-zu-Ende-Tests, also tatsächlichen Tests innerhalb eines Browsers, die sich durch die Funktionen des Plugins klicken. Zudem liefen die Tests über alle unterstützten PHP-Versionen, damit keine Fehler in PHP-Versionen auftreten, die ich selbst auf keinem meiner Systeme verwende. ## Das Symptom Nach der Veröffentlichung von Block Control 2.0.0 wartete ich darauf, dass das Release auch verfügbar wird, da man derzeit nach der Veröffentlichung über WordPress.org sechs Stunden warten muss. Theoretisch hätte man es auch manuell herunterladen können – was ich hätte tun sollen – aber das tat ich eben nicht. Und so kamen am nächsten Tag mehrere Meldungen, dass die Aktualisierung die jeweilige Website mit einem fatalen Fehler in PHP komplett zerschossen hat. ## Das Problem Das eigentliche Problem war schnell gefunden: Nachdem alle Tests durchgelaufen sind, werden die Plugin-Dateien an WordPress.org übertragen. Einige Dateien und Ordner werden dabei ausgeschlossen, in der Regel Projektdateien, die nur für die Entwicklung benötigt werden. Einer dieser Ordner war der Ordner `src`. Innerhalb des Plugins liegt dort der rohe React-Code, der mit dem Block-Editor interagiert. Die Bibliothek eines Drittanbieters zur Erkennung mobiler Geräte hat allerdings ebenfalls einen `src`-Ordner – und darin liegt der eigentliche PHP-Code für die Erkennung. Ihn auszuschließen bedeutete demnach, dass PHP-Dateien fehlten – und das führte zum fatalen Fehler. Der eigentliche Fehler war, dass ich den Ausschluss nicht auf meinen eigenen `src`-Ordner beschränkt habe. ## Die Lösung Als unmittelbaren Workaround schloss ich einfach nur meinen eigenen `src`-Ordner aus und veröffentlichte das Ganze als Version 2.0.1, was dann auch funktionierte. Aber das war nur ein Teil davon und diente lediglich dazu, den Schaden zu begrenzen. In den folgenden Tagen arbeitete ich an einer echten Lösung: Während des Deployments erstelle ich nun eine ZIP-Datei, die exakt dieselbe Struktur hat wie die Daten, die an WordPress.org gehen. Diese wird anschließend in einem WordPress Playground installiert und aktiviert, sodass ich sicherstellen kann, dass diese Version im normalen Betrieb nicht zu einem fatalen Fehler führt. Am Ende sind Tests eben nur so gut wie ihre Abdeckung. Was man übersieht und nicht testet, kann kaputtgehen. Fühl dich mit deinen vorhandenen Testmethoden also nicht zu sicher – irgendetwas übersiehst du ganz sicher. 🥲 An alle, die vor der korrigierten Version auf 2.0.0 aktualisiert haben: Es tut mir wirklich leid!

# A false sense of security through testing Published: September 24, 2026 by Matze – Leave a comment When announcing version 2.0.0 of Block Control, I was very happy and satisfied with its new tests. How wrong I was … This new version was the first one that contained end-to-end testing, meaning that there were actual tests within a browser to click through the plugin’s functionality. It also ran the tests through all supported PHP versions, which was explicitly made so that no errors in PHP versions arrive I don’t use personally on any of my systems. ## The symptom After releasing Block Control 2.0.0, I waited for the plugin release to get available, since you currently have to wait 6 hours after publishing it via WordPress.org. In theory, you could download it manually – which I should have done – but I didn’t. And so, on the next day, several reports stated that the update completely broke their site with a fatal error in PHP. ## The problem The actual problem was identified fast: after all running tests, the plugin files get send to WordPress.org. Some files and folders are excluded from it, usually some project files only required for development. One of those folders was the folder `src`. Within the plugin itself, that’s where the raw React code lays that interacts with the block editor. However, the third-party library to detect mobile devices also has a `src` folder and it contains the actual PHP code for the detection. Leaving it out meant that PHP files were missing – and thus resulting in a fatal error. The actual error was that I didn’t limit the exclusion of only my `src` folder. ## The solution As an immediate workaround, I just excluded my own `src` folder and published it as version 2.0.1, which worked fine then. But that was only one part of it and just to minimize the damage. The following days, I worked on an actual solution: During deployment, I now create a ZIP file that has the exact same structure as the data sent to WordPress.org. This one gets then installed and activated within a WordPress Playground so that I can make sure that this version won’t result in a fatal error during regular use. In the end, testing is only as good as its coverage. If you miss something and don’t test it, it may break. Don’t feel overly secure with your available testing methods. You’re most certainly missing something. 🥲 To all having updated to version 2.0.0 before the fixed version: I’m truly sorry!

# Block Control 2.0.0 veröffentlicht Veröffentlicht: 27. August 2026 von Matze – Kommentar hinterlassen Heute ist ein schöner Tag für alle, die Block Control verwenden, da Version 2.0.0 eine neue Funktion zum Ausblenden nach Breakpoints mitbringt. Der WordPress Core hat in Version 6.9 die Einstellung für die Block-Sichtbarkeit hinzugefügt, um das Ausblenden von Blöcken innerhalb bestimmter Viewports zu ermöglichen. Da Block Control bereits ein praktisches Werkzeug ist, um Blöcke unter bestimmten Bedingungen auszublenden, stand es außer Frage, auch diese Funktionalität zu adaptieren und in einem einzigen Werkzeug zu vereinen. ## Nach Viewport ausblenden Mit Version 2.0.0 erlaubt dir Block Control, einzelne Viewports auszuwählen, in denen ein Block dann ausgeblendet ist. Die Standard-Viewports von WordPress (oder deiner `theme.json`) sind direkt verfügbar, aber auch das Hinzufügen individueller ist möglich. Einmal hinzugefügt, kann ein individueller Viewport dann auf der gesamten Website verwendet werden. Die integrierte Prüfung für individuelle Breakpoints gibt zudem direktes Feedback, ob der hinzugefügte Breakpoint tatsächlich gültig ist und im Browser funktioniert. Du kannst auch mehrere Media Querys hinzufügen, sodass er Block nur ausgeblendet, wenn alle Media Querys zutreffen. ## Mehr Informationen über angewendete Einstellungen Ähnlich wie bei der Core-Funktionalität zeigt die Dokumentübersicht nun ein kleines Symbol mit einem Tooltip an, wenn Sichtbarkeitseinstellungen für diesen Block gelten. Zusätzlich wurde das Icon in der Block-Seitenleiste verbessert und zeigt nun ebenfalls den Tooltip an. Wenn keine Sichtbarkeitseinstellungen mehr greifen, erhalten Screenreader-Nutzende jetzt eine entsprechende Benachrichtigung, und der Fokus wird auf das Sichtbarkeits-Panel anstatt auf das Seitenelement verschoben. ## Abhängigkeiten-Upgrade Der Grund für das große Update auf Version 2 ist die Aktualisierung der Bibliothek zur Erkennung mobiler Endgeräte, wodurch nun mindestens PHP 8.0 erforderlich ist. Dies führte auch zu einer überarbeiteten Codebasis mit moderneren Funktionen im Vergleich zur alten Version, die noch mit PHP 5.6 kompatibel sein musste. ## Tests Keine Funktion, die man direkt sieht, aber für mich erwähnenswert: Block Control ist jetzt mein erstes Plugin mit Ende-zu-Ende-Tests. Das bedeutet, dass sowohl die eigentliche JavaScript-Oberfläche im Browser als auch das Frontend (und ob die Funktion zum Ausblenden von Blöcken funktioniert) automatisch getestet werden. Diese Tests laufen zudem unter allen unterstützten PHP-Versionen von 8.0 bis 8.5, um Fehler durch inkompatiblen Code zu vermeiden. Es ist außerdem vollständig gegen Unit-Tests, statischer Code-Analyse und Code-Stil getestet. ## Das war’s Das waren die größten Änderungen für Block Control 2.0.0. Alle nennenswerten Änderungen findest du im Änderungsprotokoll.