Jump to content

Generic hook for filtering pages


Jeroen Diderik
 Share

Recommended Posts

Hi all,

I've been working on this for ages, but I cannot seem to find a generic way to exclude pages (subtree's)  from the admin interface depending on a known rootParent id.

My case:

I have a site-tree like:

HOME

 - Client A

 - Client B

 - Client C

My subdomain determines which client we are. I have a hookAfter in a custom module that attaches to: ProcessPageList::execute

This filters the tree so that when the user logs in at: clientA.domain.com the pagetree in the admin interface only shows:

HOME

 - Client A

Thus filtering by rootParent

But, I'm trying to hook into for example the Pages::find to make a more generic way of filtering, so that also the Search (ajax or lister) are working correctly. They now also return pages from the other subtrees like Client B etc.

Is there a workable 'generic' hook to filter results within processwire?

Background on setup:

My setup is done this way to have a shared /site/modules, /site/assets, /site/logs etc. but to have a client specific /site-clienta/templates

My core code in this application (it's not a public site, it's actually a narrowcasting system) is centrally managed within /site/

And templates are maintained within a clients' /site-client

It is all running in the same database (so that I don't have to maintain multiple instances/code/settings etc)

I made some changes in /index.php so that I have a $siteCore and a different $siteDir, this way, only templates are in the clients site directory. The siteCore also has templates, which are in code included in the clients templates if needed...

This setup works great and is remarkably easy to maintain (shared templates, custom templates (overrides), central modules, shared users, etc.)

The only thing missing is filtering all pagetree results (everywhere, but now mainly search/ajax results) by client rootParent.

I looked into using permissions/roles, but the hassle to maintain it is not worth it... I already know by the domainname what to do, so I don't want to implement a different layer... The current setup allows me to very quickly add a new client by simply create a rootParent with a pageName like: site-clientD and a directory /site-clientD and /site-clientD/templates and I'm ready to customize it where needed, letting the core handle defaults etc.

Link to comment
Share on other sites

You should really use the permission system instead of trying to overwrite behavior all over the place. It's build for that. The Dynamic-Roles module let's you assign access to pages depending on more dynamic rules than just the viewed template. As soon as the view access to pages is gone a user cannot access them in any way as long as you're not explicitly allow it. 

You can for example add a page-field to the user, which holds all the rootPages the user has access to. Than you'll have a dynamic role for each client, which gives all users, which have the right rootPage present in that field access to the whole tree. As soon as you've access to the root page the user can also see all subpages, if the access is granted by the template access management. 

Link to comment
Share on other sites

Hi,

I understand what you are saying, I actually did that (sort-of) in a different site, using a pagefield in a user profile to 'connect' them to a page (in this case a hostel somewhere in the tree) and used that in the front-end to give them access to specific functionality as 'hostel owner'.

This time I'm trying to customize the backend of processwire and don't wan't to mess with processwire's core files (apart from index.php which actually works great and is do-able when upgrading to newer versions, since this is the only file I need to manually check :-)

I'll give the Dynamic-Roles module a go and see if it brings me what I'm trying to accomplish throughout the application and hides the rootPages a client has no access to.

Thx for the input!

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...