JPKCom DB
Auf GitHub ansehen (öffnet in neuem Tab)

JPKCom Allow Block Types — Anleitung & Tipps

Block-Typen im Gutenberg-Editor pro Rolle freigeben oder sperren — Einstellungsseite, Export/Import und Praxis-Tipps zu JPKCom Allow Block Types.

JPKCom Allow Block Types legt pro WordPress-Rolle fest, welche Block-Typen der Block-Editor anbietet. Praktisch, um Redaktionen auf einen kuratierten Satz an Blöcken festzulegen und das Layout konsistent zu halten. Administratoren sehen immer alle Blöcke und sind nie betroffen.

Anleitung

Voraussetzungen

  • WordPress 7.0 oder neuer (getestet bis WordPress 7.1)
  • PHP 8.3 oder neuer

Installation

  1. Gehe im Admin-Bereich zu Plugins → Installieren und klicke auf Plugin hochladen.
  2. Wähle die ZIP-Datei des Plugins und klicke auf Jetzt installieren.
  3. Klicke auf Aktivieren.

Die Einstellungsseite

Unter Design → Block permissions findest du eine Matrix: jeder auf der Site bekannte Block-Typ als Zeile, jede Nicht-Administrator-Rolle als Spalte. Ein abgehaktes Kästchen sperrt den Block für diese Rolle. Eine frisch installierte Site startet mit nichts gesperrt — alle Blöcke bleiben verfügbar, bis du sie gezielt abschaltest.

Die Blöcke sind nach ihrer Block-Kategorie gruppiert. Blöcke aus einem gerade deaktivierten Plugin verschwinden nicht, sondern landen mit Warnmarkierung in einer Gruppe „Unregistered" — eine früher gesetzte Berechtigung geht also nie stillschweigend verloren und lässt sich bewusst entfernen, sobald der Block wirklich weg ist. Rollen, die den Block-Editor gar nicht nutzen können (keine edit_posts-Fähigkeit, z. B. Abonnent), sind standardmäßig ausgeblendet; ein Schalter über der Tabelle holt sie für Sites mit eigenen Rollen zurück.

Suchfeld, Kategorie-Filter und Spalten-Schalter grenzen die Tabelle ohne Neuladen ein — hilfreich, sobald die Liste bei vielen Block-Plugins in die Hunderte geht.

Welche Core-Blöcke es überhaupt gibt, listet die Core-Blocks-Referenz von WordPress (öffnet in neuem Tab).

Export & Import

Export lädt die aktuellen Einstellungen als JSON-Datei herunter, sodass sich eine einmal gebaute Matrix auf eine andere Site übertragen lässt.

Import schreibt beim Hochladen noch nichts: Nach der Dateiauswahl siehst du zuerst eine Vorschau — wie viele Rollen sich ändern würden, wie viele Block-Einträge das betrifft und welche Rollen- oder Block-Namen aus der Datei diese Site gar nicht kennt. Erst nach Bestätigung wird geschrieben. Importiert wird pro Rolle: Für jede in der Datei enthaltene Rolle ersetzt deren komplette Sperrliste den gespeicherten Stand; Rollen, die die Datei nicht erwähnt, bleiben unangetastet.

Erlaubte Blöcke abfragen: die Abilities API

Seit Version 3.1.0 registriert das Plugin eine nur lesende Ability, jpkcom-allow-blocks/list-allowed-blocks. Die Abilities API ist ein WordPress-Kernregister maschinenlesbarer Fähigkeiten — ein KI-Assistent, ein MCP-Client oder REST-Automatisierung kann damit vorher fragen, welche Blöcke sie überhaupt einsetzen darf, statt Inhalte zu schreiben, die der Editor anschließend ablehnt.

Die Antwort wird von derselben Filter-Funktion erzeugt, die auch der Editor bekommt — sie kann dem, was der Editor akzeptiert, also nicht widersprechen.

Zurück kommen zwei klar getrennte Dinge:

  1. die effektive Antwort für den aufrufenden Benutzer und
  2. wie die Einschränkung je Rolle konfiguriert ist.

Das sind zwei verschiedene Fragen, und die Trennung ist wichtig: Wer mehrere Rollen hat, ist nur von dem gesperrt, was alle seine Rollen sperren; wer ausgenommen ist, bekommt ohnehin alles, egal was in irgendeiner Rolle steht. Ausgenommen ist standardmäßig, wer manage_options hat — auch das ist über jpkcom_allow_blocks_is_exempt filterbar.

Die Ability verlangt die Fähigkeit edit_posts; die Antwort ist nur für jemanden aussagekräftig, der auch Inhalte bearbeitet. Komplett abschalten in der wp-config.php:

define( 'JPKCOM_ALLOW_BLOCKS_ABILITIES', false );

Enger ziehen lässt sich das über den Filter jpkcom_allow_blocks_ability_capability; wie die Ability nach außen sichtbar ist (REST-Route, MCP-Freigabe, Annotationen), steuert jpkcom_allow_blocks_ability_meta.

Tipps & Tricks

  • Umstieg von 2.x: Bis Version 2.x hatte das Plugin eine fest verdrahtete Liste von 17 Blöcken und keine Einstellungsseite. Diese Liste ist mit 3.0.0 entfallen. Wichtiger noch: Die alte Einschränkung griff faktisch nie — sie war innerhalb von if ( ! is_admin() ) registriert, der Block-Editor gehört aber zu wp-admin. Wer von 2.x kommt, sollte die Matrix nach dem Update also einmal bewusst durchgehen: Vorher war effektiv alles erlaubt, nachher ist es der Stand, den du dort setzt.
  • Breaking Change für eigenen Code: jpkcom_allowed_block_types() wurde ersatzlos entfernt — ohne Deprecation-Shim. Die Funktion lieferte immer dieselbe fest verdrahtete Liste, ein Shim hätte also nur veraltete Daten zurückgegeben. Rufst du sie in eigenem Code direkt auf, gibt es ab 3.0.0 einen Fatal Error.
  • Rollen-Logik: Die Einschränkung greift für Nicht-Admins — wer manage_options hat, sieht weiterhin alle Blöcke. Teste die Block-Auswahl daher mit einem Konto in einer niedrigeren Rolle (z. B. Redakteur/Autor). Wer ausgenommen ist, steuerst du über den Filter jpkcom_allow_blocks_is_exempt.
  • Nur in JavaScript registrierte Blöcke: Manche Blöcke sind der PHP-seitigen Registry nicht bekannt und tauchen deshalb nicht in der Tabelle auf. Solche Namen ergänzt du über den Filter jpkcom_allow_blocks_extra_block_names.
  • Keine Sicherheitsgrenze: Die Einschränkung wirkt auf den Inserter des Block-Editors. Sie ist keine Sicherheits- oder Inhaltsvalidierung — bereits vorhandene Blöcke im Inhalt bleiben bestehen, und wer Inhalte auf anderem Weg schreibt, ist davon nicht betroffen.
  • Deutsche Übersetzung: Seit 3.0.0 bringt das Plugin Übersetzungen für de_DE und de_DE_formal mit.
  • Reproduzierbare Updates: Ab Version 2.0.3 nutzt das Plugin sichere, selbst gehostete Updates über GitHub mit SHA256-Prüfsummen und arbeitet mit declare(strict_types=1).

Weiterführende Informationen