AAM / Developers

Make access a clear part of your code.

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.

PHP FrameworkAAM::api()JSON Access Policies
access-decision.phpPHP / AAM

01 / RESOLVE THE DECISION

$urls = AAM::api()->urls();

if ($urls->is_denied($_SERVER['REQUEST_URI'])) {
    // Handle denial in your custom workflow.
}
YOUR APPLICATION LOGICOne decision you can act on.
Services · Access levels · WordPress resources

The development problem

Permissions become difficult when the logic is scattered.

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.

01 / USERS

One person, several sources of access

Roles, direct user controls, defaults, and inherited settings can all affect the effective result.

02 / RESOURCES

More than a capability name

Features touch posts, URLs, admin surfaces, API routes, and other WordPress resources.

03 / MAINTENANCE

Rules need to stay explainable

Shared access conventions make it easier to review and adapt decisions as a product changes.

How the framework thinks

Access level. Service. Resource. Decision.

Use the same structure whether you are checking the current visitor, setting a rule for a role, or asking about a specific WordPress resource.

01

Choose an access level

Ask about the current user or visitor, or target a specific role or user.

02

Work with a service

Use AAM::api() to reach URLs, posts, capabilities, API routes, and other resources.

03

Use the decision

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

Target a role. Set a rule. Keep the intent visible.

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 ↗
EXAMPLE / POSTS SERVICEPHP
// Apply a rule for a specific WordPress role.
$posts = AAM::api()->posts('role:author');
$posts->deny(34, ['list', 'read']);

Build with the service API

Start with the WordPress resource your feature uses.

Each service documents its methods and the access questions it can answer. Follow the reference for the resource you need.

Browse the complete PHP Framework reference ↗

Access as a portable definition

Keep complex rules reviewable with JSON Access Policies.

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.

  • Describe allowed and denied operations
  • Attach policies to roles, users, visitors, or services
  • Review revisions when a rule changes
Explore JSON Access Policies ↗
science-editor.policy.jsonROLE / SCIENCE EDITOR

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"
      ]
    }
  ]
}
How to use itAttach this policy to the Science Editor role. The category slug is science; the role also needs the relevant WordPress editing and deletion capabilities. PostType and Term policy resources require AAM Premium.

Your path into AAM

Go from an access question to a working integration.

Build with intention

Make the next access decision one your code can explain.

Start in the PHP Framework reference, then go directly to the service your feature needs.

Explore the developer API →