AAM Access Settings Inheritance Mechanism

WordPress CMS manages different types of information, from simple tags and posts to users and roles. Nothing in WordPress exists in complete isolation and things are related to each other either directly or indirectly.

For example, a single post always relates to some category, while category may have another parent category; pages have authors where each author is a WordPress user that has one or more roles assigned; roles have capabilities and even can have parent roles.

Do not think about any WordPress resource (post, page, menu, widget, etc.) as independent thing. Always keep in mind its relationship to other resources and most importantly what others can or cannot do with them.

Because everything is the WordPress relates to each other in more like hierarchical order, it is natural to think that all the settings or properties are propagated down the hierarchical chain too. For example, a WordPress user typically has one or more parent roles assigned and that is why a combined list of role capabilities is automatically inherited by users.

Advanced Access Manager takes into consideration all the relationships between WordPress resources, users/roles and automatically inherits access settings and properties accordingly. Additionally to this, AAM introduces the concept of “Default” settings that allows a website owner to define default access settings for users, roles and visitors all together.

Note! It would be very impractical to define the same access settings for each WordPress role one-by-one, especially when you have dozens of custom roles. That is why the “Default” access settings can be so handy. For example, if you have 15 custom roles that should not have access to manage pages, you can define default access for everybody by restricting access to manage pages and if necessary override (give the ability to edit pages) only for some very specific roles or individual users.

How does AAM inheritance work?

Settings inheritance is quite complicated feature to implement, especially when it comes to content access management. There are so many permutations of possibilities and in some cases, they contradict each other. Luckily AAM does it all for you out-of-box and takes care of all these complicated things.

The image below visually shows how a user or visitor (for simplicity, moving forward, both will be called the user) inherits access settings. Each time the user interacts with a WordPress website, AAM, at first, checks if the user has any explicit settings defined. If none, then AAM checks if the user has a parent role and inherits access settings from it. Finally, if neither the user nor a parent role has any access settings defined, then AAM inherits access settings from the default settings.

AAM General Access Inheritance

Note! By default, WordPress does not have ability to define parent roles and the list of roles is linear. With premium Role Hierarchy add-on you can create a complex role hierarchy tree.

It gets way more complicated when managing access to WordPress content like posts, pages, custom post types, categories, and custom taxonomies. The reason for this is that any page may have a parent page or any post may have one or more parent categories, as well as all this, typically is changing while more content is created.

This article is designed to give a general introduction to the access settings inheritance. For more detailed information about WordPress content access control, please refer to the How to manage access to the WordPress content article.

Learn more » How to manage access to the WordPress content

Conclusion

WordPress CMS already has a well-defined concept of users, roles and capabilities. These are very fundamental blocks that AAM plugin uses to give you endless possibilities to manage access to website resources on the frontend, backend or even API levels.

All the information that WordPress manages is organized in more like hierarchical tree where the top is “Default” settings while the bottom is the user, and access settings and properties are propagated down the tree unless overwritten.

Get notified about important updates and new features (no more than one email per month).