Een custom WordPress management omgeving bouwen

Gezien vanuit het perspectief van de gebruiker kent WordPress twee omgevingen waar een gebruiker mee te maken kan hebben, de blog-omgeving én de wp-admin. Het idee is dat de blog-omgeving voor het lezen van informatie is en de wp-admin voor het beheer.

Om een gebruiker zelf dingen te laten bewerken heb je daardoor twee mogelijkheden. In de wp-admin is héél veel geregeld waardoor het relatief eenvoudig is om dingen te bewerken. Wat je vooral moet regelen als developer is er voor zorgen dat de gebruiker niet te veel kan bewerken. Het is dus vooral een kwestie van de juiste bevoegdheden.

Er zit echter ook een stevig nadeel aan de wp-admin. Het heeft een bepaalde structuur die heel erg dwingend is. Daarnaast is het goed regelen van de permissies ook een uitdaging. Ook het fine-grained regelen van permissies is een uitdaging. Om die structuur heen werken is op zich ook geen probleem zolang je de WordPress API’s correct gebruikt. Dat is dan alleen wel weer aanzienlijk meer werk.

Het belangrijkste nadeel is wat mij betreft niet zozeer technisch van aard. Wanneer een gebruiker ziet dat die met WordPress werkt dan geeft dat een bepaald gevoel geeft. Heel veel mensen werken zelf voor hun huis-tuin-en-keuken blogs ook met WordPress. De associatie daarmee wil je in veel gevallen vermijden.

Het alternatief is om de gebruiker zaken te laten managen via de blog-omgeving van WordPress. Het probleem daarvan is dat je in principe alles zelf zal moeten ontwikkelen. Dat begint al met de routing. Je eigen management omgeving moet op een bepaalde uri bereikbaar zijn. Er moeten daarom nieuwe routes aan WordPress worden toegevoegd. Die routes laat je verwijzen naar de custom management omgeving.

Op dit moment ben ik zelf bezig om zo’n omgeving te bouwen. Dat doe ik als prototype. Daarbij heb ik een héél snelle methode gekozen. Ik heb routes in WordPress aangemaakt die ik naar een bepaalde “page” laat verwijzen. De management interface zelf heb ik gebouwd in de template van de page.

Deze opzet is best “dirty”. Voor het bouwen van een prototype is dat helemaal niet erg. Daarnaast leunt de prototype op de applicatie die gebouwd is op basis van het Wpx framework. Op die manier is de hoeveelheid PHP-code in het template beperkt tot hetgeen dat absoluut noodzakelijk is om de custom management interface te laten werken.

Juist omdat elke vorm van structuur ontbreekt in het prototype heb ik gemerkt dat er vanzelf structuur komt in de custom management omgeving. De structuur die is ontstaan is even eenvoudig als doeltreffend. De gebruiker heeft altijd een bepaalde post die actief is, die post wordt weergegeven, bewerkt, een relationship weergegeven of bewerkt.

De routes van de post zijn daarom als volgt weer te geven, waarbij elke %action% en volgende %sub_action% facultatief zijn: /beheer/%post_id%/%action%/%sub_action1%/%sub_action2%/%sub_action3%/%sub_action4%/

De routes én query variabelen die ik aan WordPress heb toegevoegd om dit mogelijk te maken staan hieronder. In volgende blogs zal ik de verdere ontwikkeling van het prototype van mijn custom management omgeving voor WordPress beschrijven.

add_rewrite_rule('beheer/([^/]*)/([^/]*)/([^/]*)/([^/]*)?$','index.php?pagename=beheerder&beheer_id=$matches[1]&action=$matches[2]&sub_action1=$matches[3]&sub_action2=$matches[4]&subb_action3=$matches[5]','top');
add_rewrite_rule('beheer/([^/]*)/([^/]*)/([^/]*)/([^/]*)?$','index.php?pagename=beheerder&beheer_id=$matches[1]&action=$matches[2]&sub_action1=$matches[3]&sub_action2=$matches[4]','top');
add_rewrite_rule('beheer/([^/]*)/([^/]*)/([^/]*)?$','index.php?pagename=beheerder&beheer_id=$matches[1]&action=$matches[2]&sub_action1=$matches[3]','top');
add_rewrite_rule('beheer/([^/]*)/([^/]*)?$','index.php?pagename=beheerder&beheer_id=$matches[1]&action=$matches[2]','top');
add_rewrite_rule('beheer/([^/]*)/?$','index.php?pagename=beheerder&beheer_id=$matches[1]','top');

add_rewrite_tag('%beheer_id%', '([^/]*)');
add_rewrite_tag('%action%', '([^/]*)');
add_rewrite_tag('%sub_action1%', '([^/]*)');
add_rewrite_tag('%sub_action2%', '([^/]*)');
add_rewrite_tag('%sub_action3%', '([^/]*)');