Alternatief voor User Role Editor: vijf vragen vóór de overstap

Wie een alternatief voor een rechtenplugin zoekt, heeft meestal geen fout meegemaakt, maar een gat opgemerkt: een klant ziet menu-items die hem niets aangaan. Een beveiligd bericht staat toch ergens. Of er valt niet meer te zeggen wie wanneer welk recht heeft gekregen. Vijf vragen zetten dat op een rij.

Vraag 1: houdt de regel ook zonder backend stand?

Dat is de belangrijkste, en je kunt hem in een minuut zelf beantwoorden. Beveilig een bericht zo dat alleen een bepaalde rol het mag zien. Log uit. Roep /wp-json/wp/v2/posts?search= aan met een woord uit dat bericht.

Staat de inhoud in het antwoord, dan verandert je regel alleen de weergave. De REST API van WordPress is standaard bereikbaar, en die bevraagt andere plekken in de code dan een berichtenlijst in de backend. Kakapo Roles dwingt de zichtbaarheidsregel daar uitdrukkelijk ook af — juist daarom is deze test de snelste manier om een rechtenplugin te beoordelen.

Doe deze test ook met de plugin die je nu gebruikt, voordat je overstapt. Soms zit het gat ergens anders — bijvoorbeeld in een paginabouwer die content via een eigen endpoint uitlevert.

Vraag 2: kan iemand zichzelf meer rechten geven?

Een rechtenplugin die iedereen met toegang tot de interface toestaat de eigen rol op te waarderen, heft zijn eigen doel op. WordPress heeft daar een hook voor — get_editable_roles() —, die bepaalt welke rollen iemand überhaupt mag bewerken. Vraag aan het alternatief: wordt die gerespecteerd, op elke plek?

In een multisite-netwerk komt er een tweede grens bij: rollen gelden daar deels netwerkbreed. Wie ze vanaf een subsite overschrijft, wijzigt ze voor alle sites van het netwerk — ook voor de sites die niet van hem zijn.

Vraag 3: kun je de backend opruimen?

Rechten zeggen wat iemand MAG. Voor een klant is net zo belangrijk wat hij ZIET. Een redacteur die twaalf menu-items voor zich heeft waarvan er tien geblokkeerd zijn, heeft geen veilige, maar een onoverzichtelijke backend.

Controleer daarom of het alternatief verder gaat dan rollen en rechten: beheermenu per rol, mediabibliotheek beperken tot eigen bestanden, widgets en navigatiemenu's, toegestane shortcodes, doorverwijzing na het inloggen. Kakapo Roles heeft dat ingebouwd — bij veel plugins van dit type zijn het losse uitbreidingen of codefragmenten.

Vraag 4: kun je nalezen wat er is gewijzigd?

Rechten wijzig je zelden en meestal onder tijdsdruk. Een halfjaar later rijst de vraag waarom een rol iets mag. Zonder logboek is het antwoord een vermoeden.

Vraag aan het alternatief: is er een wijzigingslogboek, en staat daarin WIE WANNEER WELK recht heeft gekregen of verloren? Kakapo Roles houdt er een bij en legt daarin ook de wijzigingen vast die via toewijzing en migratie lopen.

Vraag 5: moet ik dat op elke site opnieuw opbouwen?

Wie meerdere installaties beheert, bouwt dezelfde rechtenstructuur meerdere keren — en wijkt daarbij elke keer een beetje af. Na een jaar zijn vijf sites vijf uitzonderingen. Controleer daarom of de structuur te exporteren en in te lezen is, en wat er bij het inlezen met bestaande rollen gebeurt: aanvullen of vervangen?

Kakapo Roles kan beide en zegt vóór het inlezen welke van de twee wegen is gekozen. ‘Vervangen’ (in het Duits: „Ersetzen“) is de gevaarlijkere — die moet daarom uitdrukkelijk worden bevestigd.

De checklist in het kort

Wat je vóór de overstap moet doen

1. Leg de huidige toestand vast — welke eigen rollen er zijn en welke rechten daaraan hangen.
2. Maak een back-up. Rechten zitten in de database, een misser raakt alle gebruikers tegelijk.
3. Bouw de structuur na in de nieuwe plugin en vergelijk die regel voor regel.
4. Log per rol in met een testgebruiker en kijk wat die echt ziet.
5. Doe de REST-test uit vraag 1.
6. Schakel de oude plugin uit in plaats van hem te verwijderen — voor twee weken.

Twee rechtenplugins tegelijk schrijven in dezelfde rollen, en wie het laatst opslaat, wint. Wijzig in de overgangsperiode alleen in een van beide iets.

Veelgestelde vragen