About Custom Page Roles

Gives you page level permission control for view access.

Category 1Proof of Concept
Proof of concept modules are designed as examples or starting points for others to build from. May not be ideal for users wanting to plug-n-play.
Category 2Users and Access
Modules dealing with access in ProcessWire via Users, Roles or Permissions.
Release StateAlpha
Non-stable. Not yet intended for use in production environments. *
Module Version0.0.1
Class NameCustomPageRoles
Compatibility2.1, 2.2, 2.3, 2.4
Date AddedJuly 25, 2012
Recommended ByNew recommendations may take up to 1 day to appear.


Attached is a module that gives you page level access control for view access in PW 2.1 (and should work in 2.2 as well, but not yet tested). It's fairly basic, but gets the job done and it's something to at least start from. I've tested it to make sure everything works, but not exhaustively, so let me know if you run into any issues with it.


1. Copy the attached file (CustomPageRoles.module) to /site/modules/
2. Click 'Check for new modules' in Setup > Modules.
3. Click the install button for 'Custom Page Roles'.

It will automatically add a field called 'page_roles' to your fields list. Add this field to any templates that you want to have page-level access control. Now when you edit a page using a template that has this field, you'll have checkboxes for roles that you can choose to define access from.

When at least one role is checked, the page has access control authority for 'view' permission, rather than the template. When no roles are checked, then it will check the parent page to see if it has a page_roles field and delegate control to it. That parent's page_roles field is used in the same manner. As a result, you can inherit up (or down) the tree as long as the parents have page_roles fields. Authority will be given to whatever parent ultimately defines access (by having at least one role checked).

If a page has a page_roles field with nothing selected, and it's parent doesn't have a page_roles field, then access inheritance stops and access control is deferred to the template. As an extra security measure, I've also set it up so that a page's template has to allow 'view' access in order for a page using it to inherit access from a parent page. Though I'm not sure if I should keep it this way... But here's the thinking: page level access control is a little bit dangerous in that one change can affect a lot of children (grandchildren, etc.), so that extra security is just so that the superuser exercise additional control where they deem necessary.

This is similar to access control in PW 2.0 except that it's a little simpler (and perhaps less powerful) in that all the roles are inherited as a group rather than individually. Though this also means less ambiguity, which is a good thing. But ultimately this module is just a starting point and you all may want to suggest improvements or take it further.


The main caveat here is that this does not affect results returned from $pages->find(), $page->children(), etc. Those are purely controlled at the template level. Here's two scenarios where that could affect you:

1. If access is allowed by your template, but not by your page, your page may still appear in search results and API functions like $page->find() and $page->children(). That doesn't mean the user can view the page, only that it may appear in searches. If you don't want that to happen, you'd have to take the same approach that you did in PW 2.0. When outputting a list of pages, skip over any where $page->viewable() returns false.

2. I think this will be an uncommon situation, but if you have guest access disabled in a template, but enabled on the page, the page is not going to show up in API functions that return PageArray. To make it show up, you'd have to add: "check_access=0" to your selector, like this: $page->children("check_access=0").