Extend core app (Events/Hooks/Actions/Filters)

We've recently upgraded our CMS, which was a single entity, and replaced it with a centralised core.

We're now running into the scenario where we need to add functionality, similar to hooks I guess, to certain aspects of the CMS. An example is trying to deploy page permissions in our ACL. Where page permissions can be defined on a user/role basis. Because permissions have a "key" - 'page.read' - individual pages need to somehow render within the permissions page. Our permissions are basic based on CRUD and uses Entrust (with a few adaptations).

I've, albeit not entirely great, deployed a base version which contains actions and uses events. Then those actions are fired on "GET" and "POST".

Event::listen('page.pages.OnGet', 'PagePermissionsOnGet'); // Retrieves View
Event::listen('page.pages.OnPost', 'PagePermissionsOnPost'); // Updates permissions

Event::listen('category.categories.OnGet', 'CategoriesPermissionsOnGet');
Event::listen('category.categories.OnPost', 'CategoriesPermissionsOnPost');

I know that events shouldn't really be used in this way - but I can't really see a way of hooking into our core dynamically in the way we need to. Has anyone come across this before or know of a better way to achieve this desired functionality? I suppose you could say it's similar to Wordpress' actions/filters.

Thanks.

Mithrandir

7 years ago

Level 50

I am at a loss as to what you are trying to accomplish and with what. I understand the words, but not their meaning...

You have "upgraded your single entity CMS to a centralised core"... I don't know what that means to your code.

"Deploy page permissions in our ACL"... Is that a Policy that determines whether the user can access a specific page?

"Individual pages need to somehow render within the permissions page"... I don't know where the rendering comes into play and why they need to render within the permissions page (what IS the permissions page in this context?) just because they have a key

"I know that events shouldn't really be used in this way"... I don't know what "this way" means to you. Usually when using events in Laravel, you would create individual listeners for the actions you want to perform when a certain event happens. A "page.pages.OnGet" event is really not very descriptive - unless it means "A page was served" in which case I would argue that this is Controller logic? Reacting to the incoming request (be it GET or POST) is Controller domain...

Where in the code are these events triggered?

very confused about pretty much every sentence in your post :)

tickteam-darylp

7 years ago

Level 3

@MITHRANDIR - Sorry - it's probably not the most eloquently put! I'll try to explain better.

We use an ACL to define what users can do. Each permission [page.create/read/update/delete] is listed to define user abilities. Pretty standardised facilities that you may have come across with Entrust/Cartalyst.

What we're trying to acheive, and I'll use "pages" as an example again, is to list individual pages so that content can be filtered out when viewing/editing within the administrator control panel - not front end. With permissions as they currently are, it's not really achievable with a single permission key. Therefore we need to hook into to display a list of pages.

An Event, as I've described, was the only way I could get the content outputting where I needed. Looking at what I provided I've just renamed them to:

Event::listen('permissions.pages.Get', 'PagePermissionsGet');               // Retrieves Data
Event::listen('permissions.pages.Update', 'PagePermissionsUpdate');             // Updates page specific permissions

Event::listen('permissions.categories.Get', 'CategoriesPermissionsGet');    // Retrieves Data
Event::listen('permissions.categories.Update', 'CategoriesPermissionsUpdate');  // Updates category specific permissions

I hope that clarifies it a little better.

Please or to participate in this conversation.