One person, several sources of access
Roles, direct user controls, defaults, and inherited settings can all affect the effective result.
AAM / Developers
Use the AAM PHP Framework to manage WordPress access controls and resolve decisions for users, roles, and visitors. Put those decisions to work in the features and workflows you build.
01 / RESOLVE THE DECISION
$urls = AAM::api()->urls();
if ($urls->is_denied($_SERVER['REQUEST_URI'])) {
// Handle denial in your custom workflow.
}The development problem
A role check in one place, a content restriction in another, and an API rule somewhere else make the final answer hard to trace. AAM gives your code a common model for storing controls and asking for access decisions.
Roles, direct user controls, defaults, and inherited settings can all affect the effective result.
Features touch posts, URLs, admin surfaces, API routes, and other WordPress resources.
Shared access conventions make it easier to review and adapt decisions as a product changes.
How the framework thinks
Use the same structure whether you are checking the current visitor, setting a rule for a role, or asking about a specific WordPress resource.
Ask about the current user or visitor, or target a specific role or user.
Use AAM::api() to reach URLs, posts, capabilities, API routes, and other resources.
Let the plugin enforce supported restrictions, or handle the result in your own application logic.
The PHP Framework resolves access controls and preferences. The AAM plugin enforces its supported restrictions; custom workflows must act on framework results themselves.
A real starting point
Services can work with a specific access level. Here, the posts service applies a restriction to the Author role for one post.
Read the full quick start ↗// Apply a rule for a specific WordPress role.
$posts = AAM::api()->posts('role:author');
$posts->deny(34, ['list', 'read']);Build with the service API
Each service documents its methods and the access questions it can answer. Follow the reference for the resource you need.
Resolve access to a WordPress URL in a custom flow.
02 / SERVICEManage and check access decisions for content.
03 / SERVICEWork with route-level access decisions for REST endpoints.
04 / SERVICEInspect whether an access level is allowed or denied a capability.
05 / SERVICEManage and check access to administrative menu items.
06 / SERVICEWork with WordPress identities through framework services.
Access as a portable definition
Policies define access to WordPress resources and actions in structured JSON. Use them to document reusable decisions, review changes, and adapt a policy to a new environment.
DENY BY DEFAULT · ALLOW SCIENCE POSTS
{
"Statement": [
{
"Effect": "deny",
"Resource": "PostType:post:posts",
"Action": [
"Edit",
"Delete"
]
},
{
"Effect": "allow",
"Resource": "Term:category:science:posts",
"Action": [
"Edit",
"Delete"
]
}
]
}science; the role also needs the relevant WordPress editing and deletion capabilities. PostType and Term policy resources require AAM Premium.Your path into AAM
Get the AAM::api() entry point and a first service example.
Open quick start ↗02 / BUILDFind the methods for your resource and access level.
Browse services ↗03 / EXTENDUse structured JSON when access rules need to be portable and reviewable.
Read policy docs ↗Build with intention
Start in the PHP Framework reference, then go directly to the service your feature needs.