AAM Plugin Reference

Thank you so much for your interest in one of the most powerful and flexible WordPress access control plugin Advanced Access Manager (aka AAM).

This documentation contains the complete list of all features that AAM 5.0 or higher has. Some of the sections have reference to articles that explain related feature in more details.

If you are not sure where to start exploring AAM functionality or how to use to it to manage access to your website, you may consider to check the Get Started page.

AAM is the free WordPress plugin that hosts by the official WordPress plugin repository. To install it, simply go to your WordPress website backend area and navigate to the Plugins->Add New. Here you can search for Advanced Access Manager and install it on your website.

Please Note! AAM is the WordPress plugin, so you need to have already WordPress CMS installed in order to use it.

Upon AAM activation, no additional steps are required. You will be able to find the new AAM menu item on the main admin menu sidebar.

AAM is quite complex plugin with over 200 different features where most of the development time was spent on creation of the intuitive and easy-to-use UI to maximize webmaster’s efficiency.

The UI interface is divided into 6 distinct areas that are designed to either display important information or to give you the ability to do some specific set of actions. There are also several pieces of functionality that go beyond the AAM page and are integrated with WordPress UI like Access Manager Metabox or Access Link.

The Subject, in AAM context, is a general definition for role, individual user, visitor or default access to everybody. Other words the Subject is who you manage access for.

Each time you change subject on the Users/Roles Manager area, the current subject banner is adjusted accordingly. This gives you the visual confirmation for who are you managing access to.

The current subject can be highlighted with two colors. The red color means that you are managing access to the highest allowed user level or to the default access for everybody. That is why be careful as you can accidentally restrict access to your user.

Notice! Access to AAM UI is customizable and you can grand access to certain features for anybody who is registered on your website. For example you can give ability for your Editors to manage access to Posts & Pages. For more information about this feature please check How to manage access to AAM page for other users article.

The blue color indicates that you are managing access for role or user that has lower user level than you do.

The Main Panel is were all the magic happens. Here you have all the necessary set of tool to manage access to your website frontend, backend and API areas.

The panel is divided on two sub-areas:

• – list of tabs (features) like Backend Menu, Capabilities, Login Redirect etc.;
• – control area is the place were you actually manage access settings;

Each tab contains collection of tools grouped by logical meaning and they are described in-depth further in this documentation.

AAM is highly customizable plugin. There are multiple ways you can alter its behavior and the easier one is through the Settings Area.

The layout here is similar to the Main Panel where all settings are grouped based on the logical meaning. Here you can find the most widely used settings organized by following groups:

• Core Settings – settings that change the way AAM UI behaves as well as some of the WordPress core features;
• Content Settings – all the settings that are related to the website content management;
• Security Settings – enhance your website security with few useful features;
• ConfigPress – area where you can enter additional configurations that change the way AAM core works;

AAM comes with set of premium extensions that you can purchase in our online store as well as several free extensions that can be downloaded from the Extensions area.

You can create your own custom extension. For more information check the Developers Reference page.

Users/Roles Manager is the place where you can manage list of roles, users, visitors as well as default access for everybody. It has a lot of neat features and they all are described in-depth in the Users/Roles Manager section.

The Notification Manager was added in the AAM v4.0 to visually show important notifications that require webmaster attention.

Note! Mostly these notifications are warning and do not stop AAM to function properly. However it is strongly recommended to address and resolve any notification as soon as it is discovered.

By default every post, page or custom post type will have additional metabox added to the edit screen that allows to manage access to it for any user, role, visitor or default access to everybody for frontend, backend and API areas.

The metabox can be turned off with Render Access Manager Metabox option.

AAM comes with its own secure login widget & shortcode that you can use to drop on your frontend page. It has couple cool features that can significantly improve your website security.

The secure login functionality can be turned off with Secure Login. For more information about secure login widget check How does AAM Secure Login works article.

For your convenience, each post, page, custom post type, category, custom hierarchical taxonomy and user have additional Access action link that upon click leads straight to the AAM page.

Note! The “Access” row action is not rendered for users that do have access to AAM page or do not have ability to manage Posts & Terms feature. “Access” action will not be rendered on All Users screen if user does not have aam_manage_users capability or user is not an administrator. It is also not rendered on list of posts screen when all Frontend Access Control, Backend Access Control and API Access Control options are disabled.

Available with AAM v5.9 or higher.

AAM allows webmaster to assign multiple roles per user however to keep it backward compatible, this feature is disabled by default. You can enable it on the Settings Area with the Multiple Roles Support option.

Keep in mind that there is a lot of complexity involved in merging access settings for users that have multiple roles assigned. This is due to the possibly access settings ambiguity. For example if user Lesley has Editor and Contributor roles assigned where first role allows access to certain pages and second role does not, there is no right answer to what AAM should do when Lesley tries to access those pages. For more information about this topic please refer to the WordPress access control for users with multiple roles artcle.

AAM comes with the ability to export all the settings and import that to a different website. You can find AAM settings AAM Exporter on the Tools->Export page. Here you can customize the set of settings that you would want to export.

The AAM Importer can be found on the Tools->Import page. The importer accept valid AAM JSON file with access settings.

This is just an example of the valid JSON document with AAM settings that Exporter generates.

{
    "version": "5.9",
    "plugin": "advanced-access-manager",
    "datetime": "2019-02-25 11:50:11",
    "metadata": {
        "system": "roles,utilities,configpress",
        "roles": "menu,toolbar,metabox,post,redirect,route",
        "users": "menu,toolbar,metabox,capability,post,redirect,route",
        "visitor": "metabox,post,redirect,route",
        "default": "menu,toolbar,metabox,post,redirect,route"
    },
    "dataset": {
        "_options": {
            "_user_roles": "eyJhZG1pbmlzdHJhdG9yIjp7Im5hbWUiOiJBZG1pbmlzdHJhdG9yIiwiY2FwYWJpbGl0aWVzIjp7InN3aXRjaF90aGVtZXMiOnRydWUsImVkaXRfdGhlbWVzIjp0cnVlLCJhY3RpdmF0ZV9wbHVnaW5zIjp0cnVlLCJlZGl0X3BsdWdpbnMiOnRydWUsImVkaXRfdXNlcnMiOnRydWUsImVkaXRfZmlsZXMiOnRydWUsIm1hbmFnZV9vcHRpb25zIjp0cnVlLCJtb2RlcmF0ZV9jb21tZW50cyI6dHJ1ZSwibWFuYWdlX2NhdGVnb3JpZXMiOnRydWUsIm1hbmFnZV9saW5rcyI6dHJ1ZSwidXBsb2FkX2ZpbGVzIjp0cnVlLCJpbXBvcnQiOnRydWUsInVuZmlsdGVyZWRfaHRtbCI6dHJ1ZSwiZWRpdF9wb3N0cyI6dHJ1ZSwiZWRpdF9vdGhlcnNfcG9zdHMiOnRydWUsImVkaXRfcHVibGlzaGVkX3Bvc3RzIjp0cnVlLCJwdWJsaXNoX3Bvc3RzIjp0cnVlLCJlZGl0X3BhZ2VzIjp0cnVlLCJyZWFkIjp0cnVlLCJsZXZlbF8xMCI6dHJ1ZSwibGV2ZWxfOSI6dHJ1ZSwibGV2ZWxfOCI6dHJ1ZSwibGV2ZWxfNyI6dHJ1ZSwibGV2ZWxfNiI6dHJ1ZSwibGV2ZWxfNSI6dHJ1ZSwibGV2ZWxfNCI6dHJ1ZSwibGV2ZWxfMyI6dHJ1ZSwibGV2ZWxfMiI6dHJ1ZSwibGV2ZWxfMSI6dHJ1ZSwibGV2ZWxfMCI6dHJ1ZSwiZWRpdF9vdGhlcnNfcGFnZXMiOnRydWUsImVkaXRfcHVibGlzaGVkX3BhZ2VzIjp0cnVlLCJwdWJsaXNoX3BhZ2VzIjp0cnVlLCJkZWxldGVfcGFnZXMiOnRydWUsImRlbGV0ZV9vdGhlcnNfcGFnZXMiOnRydWUsImRlbGV0ZV9wdWJsaXNoZWRfcGFnZXMiOnRydWUsImRlbGV0ZV9wb3N0cyI6dHJ1ZSwiZGVsZXRlX290aGVyc19wb3N0cyI6dHJ1ZSwiZGVsZXRlX3B1Ymxpc2hlZF9wb3N0cyI6dHJ1ZSwiZGVsZXRlX3ByaXZhdGVfcG9zdHMiOnRydWUsImVkaXRfcHJpdmF0ZV9wb3N0cyI6dHJ1ZSwicmVhZF9wcml2YXRlX3Bvc3RzIjp0cnVlLCJkZWxldGVfcHJpdmF0ZV9wYWdlcyI6dHJ1ZSwiZWRpdF9wcml2YXRlX3BhZ2VzIjp0cnVlLCJyZWFkX3ByaXZhdGVfcGFnZXMiOnRydWUsImRlbGV0ZV91c2VycyI6dHJ1ZSwiY3JlYXRlX3VzZXJzIjp0cnVlLCJ1bmZpbHRlcmVkX3VwbG9hZCI6dHJ1ZSwiZWRpdF9kYXNoYm9hcmQiOnRydWUsInVwZGF0ZV9wbHVnaW5zIjp0cnVlLCJkZWxldGVfcGx1Z2lucyI6dHJ1ZSwiaW5zdGFsbF9wbHVnaW5zIjp0cnVlLCJ1cGRhdGVfdGhlbWVzIjp0cnVlLCJpbnN0YWxsX3RoZW1lcyI6dHJ1ZSwidXBkYXRlX2NvcmUiOnRydWUsImxpc3RfdXNlcnMiOnRydWUsInJlbW92ZV91c2VycyI6dHJ1ZSwicHJvbW90ZV91c2VycyI6dHJ1ZSwiZWRpdF90aGVtZV9vcHRpb25zIjp0cnVlLCJkZWxldGVfdGhlbWVzIjp0cnVlLCJleHBvcnQiOnRydWUsImRlbGV0ZV9jb21tZW50Ijp0cnVlLCJhcHByb3ZlX2NvbW1lbnQiOnRydWUsImVkaXRfY29tbWVudCI6dHJ1ZSwicXVpY2tfZWRpdF9jb21tZW50Ijp0cnVlLCJzcGFtX2NvbW1lbnQiOnRydWUsInJlcGx5X2NvbW1lbnQiOnRydWUsInRyYXNoX2NvbW1lbnQiOnRydWUsInVuYXBwcm92ZV9jb21tZW50Ijp0cnVlLCJ1bnRyYXNoX2NvbW1lbnQiOnRydWUsInVuc3BhbV9jb21tZW50Ijp0cnVlfX0sImVkaXRvciI6eyJuYW1lIjoiRWRpdG9yIiwiY2FwYWJpbGl0aWVzIjp7Im1vZGVyYXRlX2NvbW1lbnRzIjp0cnVlLCJtYW5hZ2VfY2F0ZWdvcmllcyI6dHJ1ZSwibWFuYWdlX2xpbmtzIjp0cnVlLCJ1cGxvYWRfZmlsZXMiOnRydWUsInVuZmlsdGVyZWRfaHRtbCI6dHJ1ZSwiZWRpdF9wb3N0cyI6dHJ1ZSwiZWRpdF9vdGhlcnNfcG9zdHMiOnRydWUsImVkaXRfcHVibGlzaGVkX3Bvc3RzIjp0cnVlLCJwdWJsaXNoX3Bvc3RzIjp0cnVlLCJlZGl0X3BhZ2VzIjp0cnVlLCJyZWFkIjp0cnVlLCJsZXZlbF83Ijp0cnVlLCJsZXZlbF82Ijp0cnVlLCJsZXZlbF81Ijp0cnVlLCJsZXZlbF80Ijp0cnVlLCJsZXZlbF8zIjp0cnVlLCJsZXZlbF8yIjp0cnVlLCJsZXZlbF8xIjp0cnVlLCJsZXZlbF8wIjp0cnVlLCJlZGl0X290aGVyc19wYWdlcyI6dHJ1ZSwiZWRpdF9wdWJsaXNoZWRfcGFnZXMiOnRydWUsInB1Ymxpc2hfcGFnZXMiOnRydWUsImRlbGV0ZV9wYWdlcyI6dHJ1ZSwiZGVsZXRlX290aGVyc19wYWdlcyI6dHJ1ZSwiZGVsZXRlX3B1Ymxpc2hlZF9wYWdlcyI6dHJ1ZSwiZGVsZXRlX3Bvc3RzIjp0cnVlLCJkZWxldGVfb3RoZXJzX3Bvc3RzIjp0cnVlLCJkZWxldGVfcHVibGlzaGVkX3Bvc3RzIjp0cnVlLCJkZWxldGVfcHJpdmF0ZV9wb3N0cyI6dHJ1ZSwiZWRpdF9wcml2YXRlX3Bvc3RzIjp0cnVlLCJyZWFkX3ByaXZhdGVfcG9zdHMiOnRydWUsImRlbGV0ZV9wcml2YXRlX3BhZ2VzIjp0cnVlLCJlZGl0X3ByaXZhdGVfcGFnZXMiOnRydWUsInJlYWRfcHJpdmF0ZV9wYWdlcyI6dHJ1ZX19LCJhdXRob3IiOnsibmFtZSI6IkF1dGhvciIsImNhcGFiaWxpdGllcyI6eyJ1cGxvYWRfZmlsZXMiOnRydWUsImVkaXRfcG9zdHMiOnRydWUsImVkaXRfcHVibGlzaGVkX3Bvc3RzIjp0cnVlLCJwdWJsaXNoX3Bvc3RzIjp0cnVlLCJyZWFkIjp0cnVlLCJsZXZlbF8yIjp0cnVlLCJsZXZlbF8xIjp0cnVlLCJsZXZlbF8wIjp0cnVlLCJkZWxldGVfcG9zdHMiOnRydWUsImRlbGV0ZV9wdWJsaXNoZWRfcG9zdHMiOnRydWV9fSwiY29udHJpYnV0b3IiOnsibmFtZSI6IkNvbnRyaWJ1dG9yIiwiY2FwYWJpbGl0aWVzIjp7ImVkaXRfcG9zdHMiOnRydWUsInJlYWQiOnRydWUsImxldmVsXzEiOnRydWUsImxldmVsXzAiOnRydWUsImRlbGV0ZV9wb3N0cyI6dHJ1ZX19LCJzdWJzY3JpYmVyIjp7Im5hbWUiOiJTdWJzY3JpYmVyIiwiY2FwYWJpbGl0aWVzIjp7InJlYWQiOnRydWUsImxldmVsXzAiOnRydWV9fX0=",
            "aam-utilities": "eyJjb3JlLnNldHRpbmdzLnJlc3RmdWwiOiIwIiwiY29yZS5zZXR0aW5ncy54bWxycGMiOiIwIiwidWkuc2V0dGluZ3MucmVuZGVyQWNjZXNzQWN0aW9uTGluayI6IjAiLCJjb3JlLnNldHRpbmdzLmJhY2tlbmRBY2Nlc3NDb250cm9sIjoiMSIsImNvcmUuc2V0dGluZ3MuZnJvbnRlbmRBY2Nlc3NDb250cm9sIjoiMCIsImNvcmUuc2V0dGluZ3MuYXBpQWNjZXNzQ29udHJvbCI6IjAiLCJ1aS5zZXR0aW5ncy5yZW5kZXJBY2Nlc3NNZXRhYm94IjoiMCIsImNvcmUuc2V0dGluZ3MubG9naW5UaW1lb3V0IjoiMSIsImNvcmUuc2V0dGluZ3Muc2luZ2xlU2Vzc2lvbiI6IjEiLCJjb3JlLnNldHRpbmdzLmJydXRlRm9yY2VMb2Nrb3V0IjoiMSIsImNvcmUuc2V0dGluZ3MuZ2V0U3RhcnRlZCI6IjAifQ==",
            "aam-configpress": "IiI=",
            "aam_menu_role_editor": "eyJtZW51LWVkaXQucGhwP3Bvc3RfdHlwZT1wYWdlIjoiMSIsImVkaXQucGhwP3Bvc3RfdHlwZT1wYWdlIjoiMSIsInBvc3QtbmV3LnBocD9wb3N0X3R5cGU9cGFnZSI6IjEiLCJtZW51LWVkaXQtY29tbWVudHMucGhwIjoiMSIsIm1lbnUtdG9vbHMucGhwIjoiMSIsInRvb2xzLnBocCI6IjEiLCJzaXRlbWFwIjoiMSJ9",
            "aam_type_aam_reference_role_editor": "eyJ0ZXJtfGJhY2tlbmQuZGVsZXRlIjoiMSIsInBvc3R8YmFja2VuZC5kZWxldGUiOiIxIn0=",
            "aam_type_policy_reference_role_editor": "eyJwb3N0fGJhY2tlbmQuZGVsZXRlIjoiMSIsInRlcm18YmFja2VuZC5kZWxldGUiOiIxIn0=",
            "aam_type_post_role_editor": "eyJwb3N0fGJhY2tlbmQuZGVsZXRlIjoiMSIsInRlcm18YmFja2VuZC5kZWxldGUiOiIxIn0=",
            "aam_term_7|category_role_editor": "eyJwb3N0fGJhY2tlbmQubGlzdCI6IjAiLCJwb3N0fGJhY2tlbmQuZWRpdCI6IjAiLCJwb3N0fGJhY2tlbmQucHVibGlzaCI6IjEiLCJwb3N0fGJhY2tlbmQuZGVsZXRlIjoiMSJ9"
        }
    }
}

Note! AAM will not allow to import access settings to the website that does not have matching AAM version and you will get “Version of exported settings do not match current AAM version error message during the import steps.

To be truly expert in the WordPress access management, you have to be aware of all the conceptual and functional aspects of the WordPress core.

In the end of the day, AAM is just the useful tool that helps you to customize your website access and security however it is your responsibility to be familiar with how WordPress core works so you can do administrative tasks more effectively.

Note! You do not have to be an expert in programming to understand concepts mentioned in this reference however by knowing them, you can save many-many hours of work and hundreds or even thousands of dollars.

WordPress is based on the hybrid of Role-Based Access Control (RBAC) and Access Control List (ACL) models. It is designed to give the ability for a website owner to control what other users can or cannot do based on the assigned role. On other hand, it has the limited ability to customize access for a specific user. This part is explained in-depth in the What is a WordPress user article.

It is very critical to understand the WordPress Roles & Capabilities as it is the core concept for access management.

With the good understanding of roles and capabilities you can creating complex membership platforms or simply manage access to restricted parts of your websites with little to no effort.

By default, the WordPress website has Administrator, Editor, Author, Contributor and Subscriber roles. The crucial difference between them is in the amount of assigned capabilities that sometimes is mistakenly referred to “user or role levels”.

The User Levels concept was introduced to the WordPress 1.5, replaced with Roles and Capabilities in 2.0 and finally announced as deprecated in 3.0. In the current WordPress implementation, the user levels are represented as the list of capabilities level_0 to level_10 and they do not have any impact on the user permissions.

To learn more in-depth about the roles please refer to the What is a WordPress role article.

WordPress comes with straight-forward user management functionality. You can create unlimited number of users and delegate different responsibilities based on the assigned role(s).

List of all users can be found in the backend on the All Users page, however it is accessible only for users that have list_users capability or for administrators.

The default WordPress functionality does not support the idea of user status. Every registered user is considered as active however with AAM you have the ability to deactivate users without actually deleting them or even setup temporary user account. For more information about this please refer to How to manage WordPress users article.

Anybody who is not authenticated (logged in) is a visitor. Typically they have access only to the frontend side of a website and have limited abilities to interact with frontend features.

WordPress core has almost no tools to manage what visitors can or cannot do on the frontend side. AAM has a lot of features that you can utilize to manage access not only to the frontend content and widget but also access to the other aspects of the website like RESTful API endpoints or legacy WordPress AJAX endpoints.

For more detailed information about the WordPress visitors, please check Who is a WordPress visitor article.

Capability is the core concept in the WordPress access management as it literally defines what authenticated user is authorize to do. It is important to emphasize that it is heavily utilized for the backend side of a website however that does not mean that it can’t be used on the frontend or API levels.

The Roles & Capabilities article is probably the best reference to all predefined core capabilities that come with default WordPress installation.

To learn more about WordPress capabilities and how you can use AAM to manage them, please refer to the What is a WordPress capability article.

Frontend is the publicly facing part of the WordPress website. Typically it is rendered by the active theme and consists of pages, posts, categories widgets and menus.

WordPress core does not have any abilities to manage access to it however AAM has a lot of neat feature that can be used. You can manage access almost to every part of your frontend.

For more information please refer to the What is the WordPress frontend article.

Backend is usually restricted part of the WordPress website. This is the place were only authenticated users have access to.

Typically the list of tasks that authenticated user can perform in the backend is defined by the assigned capabilities. That is why it is very important to understand the concept of capabilities.

For more information about backend and how AAM manages access to it please check What is the WordPress backend article.

There are many different ways to programmatically connect to a WordPress website however two became dominant in past 10 years. One API type is based on XML-RPC standard and another is RESTful.

With AAM you can manage access to individual API endpoints for any role, individual user or visitors as well as complete disable them.

WordPress hooks is the subject of interest to developers rather than none technical users however it is beneficial to understand the concept because majority of customization utilize hooks.

Hooks are programmatic actions and filters that can be used by developers to “hook into” some functionality. For example AAM hooks into the functionality that retrieves the list of posts from the database and filter out all posts that are hidden for currently authenticated user or visitors.

The User Activity Extension uses hooks to listen to different user actions and stores all related information into the audit log.

There are few core WordPress functions that developers can use to register new hooks. Internally they are executed the same way with the only difference in returned result. The add_action function does not return any result while add_filter action has to return the input value either unmodified or modified, otherwise it will break the chain of functions that may hook to the same event. It is also important to pay attention to the priority attribute as lower priorities are executed first.

A lot of access management tasks cannot be accomplished just with roles and capabilities that is why you may noticed that developers refer to different hooks that can be utilized to accomplish desired objectives. Please do not hesitate to start forum conversation if you are not sure how to accomplish some of the tasks.

WordPress functionality is built around the concept of posts. Every page, post or custom post type (CPT) is a post and the only thing that differentiate them is the post_type.

Below is the visual representation of the relationship between post and post type.

All posts are stored in the database table wp_posts and the post_type colum defines the actual post type.

AAM plugin has many access options that you can use to manage very granular access to any post.

For more information about the concept of posts please refer to the What is a WordPress post article.

Taxonomy is basically the way to group content together by some logical meaning. There are two different types of taxonomies: hierarchical and tags, where hierarchical taxonomy allows you to create a nested tree of terms while tag is a linear.

For example post category is a hierarchical taxonomy and you can create a complex tree of categories with sub-categories. However post tags is a linear list of tags that can be assigned to a post.

AAM works only with hierarchical taxonomies and greatly enhance your ability to manage access to large amount of posts that are grouped. For more information about the taxonomy check What is a WordPress taxonomy article.

AAM has the most sophisticated access settings inheritance mechanism that is available for the WordPress CMS. It takes in consideration all WordPress core relationships between website resources. Under resource I mean any post, taxonomy, user, role, menu, metabox etc.

With Role Hierarchy extension you can even create a hierarchical tree of WordPress roles where all child roles inherit settings from parent.

It is very important to understand how it works because with this knowledge you have endless possibilities. Within minutes you can create a complex membership portal that typically would cost you thousands of dollar to implement from scratch.

For more information about inheritance mechanism please refer to How does AAM inherits access settings article.

AAM utilizes the deprecated User Levels concept to enhance WordPress backend security.

When you activate AAM, it automatically restricts the ability for privileged users to manage other users and roles that have higher user level. For example you may want to add admin access to couple freelance website developers however do know what them to be able to manage your “super” admin user. This way you can simply create a custom capability level_11 and assign it only to your user.

For more information about this feature please check WordPress Users and Roles Filter article.

AAM has internal caching that stores access settings to posts and terms because this is the most time and resource consuming procedures due to access inheritance mechanism.

It is important to emphasize that cache is stored per each individual user separately and is automatically cleared if user’s role is changed. It is also automatically cleared if any changes detected for hierarchical terms like categories or posts, pages or custom post types.

For more information about AAM cache, please refer to the How does AAM cache works article.

ConfigPress is the AAM configuration engine that is based on INI format. Basically it is a key/value pair of various configurations that define how separate AAM features work.

For example, by default, only users that have administrator capability can access AAM UI however with page.capability key you can redefine different capability and user with that specific capability assigned will be able to get access to the AAM UI.

You can find ConfigPress tab on the Settings Area and all the AAM related settings should be grouped in [aam]

By default only users with administrator capability can access AAM functionality (so basically only users with Administrator role).

This behavior can be overwritten with a different capability, especially when there is a need to grand access to some of the AAM features for other users that are not necessarily administrators.

[aam]
page.capability = edit_posts

For more information about managing access to the AAM page, please refer to the How to manage access to AAM page for other users

Define the order of places where AAM will check for JWT token in a HTTP request to the WordPress website. By default it checks in headers, post, query (GET) and finally cookie.

[aam]
; Check only in the HTTP Headers
authentication.jwt.container = "header"

For more information about JWT token, please refer to the How to authenticate WordPress user with JWT token

Note! AAM by default uses the symmetric algorithm to issue and validate JWT token, so you would have to explicitly specify one of the asymmetric algorithms with authentication.jwt.algorithm setting.

Define the absolute path to the public certificate that is used to verify a JWT token when asymmetric algorithms RS256, RS384 or RS512 is used.

[aam]
authentication.jwt.publicKeyPath = "/var/certs/jwtRS512.key.pub"

For more information about JWT token, please refer to the How to authenticate WordPress user with JWT token

Note! AAM by default uses the symmetric algorithm to issue and validate JWT token, so you would have to explicitly define the absolute path to a private certificate with authentication.jwt.privateKeyPath setting if the WordPress instance issues JWT as well as absolute path to the public certification with authentication.jwt.publicKeyPath setting if the WordPress instance validates provided JWT token.

Define the algorithm that is used to sign a JWT token. The valid values are HS256, HS512, HS384, RS256, RS384 or RS512.

[aam]
authentication.jwt.algorithm = "RS512"

For more information about JWT token, please refer to the How to authenticate WordPress user with JWT token

Note! AAM by default uses the symmetric algorithm to issue and validate JWT token, so you would have to explicitly specify one of the asymmetric algorithms with authentication.jwt.algorithm setting.

Define the absolute path to the private certificate that is used to sign a JWT token when asymmetric algorithms RS256, RS384 or RS512 is used.

[aam]
authentication.jwt.privateKeyPath = "/var/certs/jwtRS512.key"

For more information about JWT token, please refer to the How to authenticate WordPress user with JWT token

To prevent accidental user meta overload, AAM implement ring-buffer approach to the list of JWT tokens that each user account can have. By default, user may have up to 10 tokens registered and upon 11^th token registration, the first token is automatically removed.

Note! AAM automatically removes invalid or expired JWT tokens during the attempt to use it.

[aam]
authentication.jwt.registryLimit = 1

For more information about JWT token, please refer to the How to authenticate WordPress user with JWT token

Define the secret key that is used to sign JWT token for available the symmetric algorithms HS256, HS512 and HS384. By default AAM uses SECURE_AUTH_KEY value that is defined in the main wp-config.php file however it make sense to define a custom secret phrase if it has to be shared between different parties.

[aam]
authentication.jwt.secret = "oZfnEb^r`MF-pYk|&2qJ?_7.gEr~!JSau,`Pqxe7`johSuc8U)D~4S-wY+l_u+"

For more information about JWT token, please refer to the How to authenticate WordPress user with JWT token

JWT authentication is something that was added to the AAM v5 and is fantastic way to programmatically authenticate requests to the WordPress website.

By default any JWT token that is issued by AAM is valid for 24 hours however it can be adjusted to whatever time span is needed.

[aam]
;keep token valid for 30 days
authentication.jwt.expires = 2592000

For more information about JWT token, please refer to the How to authenticate WordPress user with JWT token

Implemented in AAM v5.9.4

All the tokens that are issued through aam/v1/authenticate, by default are not refreshable. This means, that when token expires, either application or user, has to resupply authentication credentials to obtain a new token.This behavior can be overwritten so you can allow any token to be refreshed as long as it is still valid and not revoked.

FYI! I’m not following the concept of Refresh Token defined by Auth0 as I find it redundant. My take here is following – when your driver license expires, you do not bring some random document that allows you to obtain a new driver license; you bring your expiring license.

[aam]
authentication.jwt.refreshable = true

For more information about JWT token, please refer to the How to authenticate WordPress user with JWT token

Significantly reduce the possibility for successful brute force attacks by delaying authentication process. Normally it takes around 50-100 milliseconds for the production website to check if provided username/password pair is valid so one thread can technically brute force 10-20 passwords per second and over 17 million passwords per day.

Delaying authentication process even to 1 second significantly reduces chance for success to this type of attack. When Login Timeout feature is enabled, AAM by default delays the authentication response for 1 second however you can override this default value.

[aam]
;delay the authentication for 5 seconds
security.login.timeout = 5

Note! Try to keep the timeout value low. Recommended is 1-2 seconds. You do not want your users to wait 20 seconds after they entered username and password, right?

Define the length for the account lockout when number of authentication attempts exceeds the allowed threshold. The tracking is done by user’s IP address and authentication attempts are tracked when Brute Force Lockout option is enabled.

[aam]
;lock user account for 1 hour
security.login.period = 1 hour

Define the number of times user is allowed to unsuccessfully authenticate before account gets temporarily locked for predefined period of time. The tracking is done by user’s IP address and authentication attempts are tracked when Brute Force Lockout option is enabled.

[aam]
;lock user account after 5 unsuccessful attempts to authenticate
security.login.attempts = 5

The default number of authentication attempts is 20.

Available since AAM v5.9.4.

AAM comes with internal Caching Mechanism that stores results for the most time and resource consuming operations.

With the large websites, the cache for each individual user can get really big, pretty fast. This is due to the fact that AAM builds cache “on-demand”, which means it’ll keep appending new data to the cache registry when user keep requesting new content to read, download etc.

With AAM v5.9.4 I’ve implemented ring buffer approach to the cache where by default AAM will cache only up to 1000 access settings. This way the webmaster has the ability to control how much cache data to store per each user.

[aam]
;store up to 1000 access settings
core.cache.limit = 1000

Note! The 1000 access settings in the cache is still considerably small amount of data. We are talking here about maybe couple kilobytes per user.

AAM comes with internal Caching Mechanism that stores results for the most time and resource consuming operations.

It is useful to disable cache when you are doing custom development involving AAM API or you troubleshoot issues related to access and security management.

[aam]
;disable AAM cache
core.cache.status = disabled

AAM allows to create a temporary user accounts as well as define the action that is automatically executed when account expires. One of the allowed actions is “Delete User Account”. When this happens, all the content that temporary user created is assigned to the administrator for the website.

This option allows you to define user ID that is going to be used as new author for the content.

[aam]
;My John Smith user has ID 34
core.reasign.ownership.user = 34

To learn more about creating temporary user accounts please refer to the “WordPress: Temporary User Account, Login With URL & JWT Token” article.

All AAM 5 extensions are not normal WordPress plugins. They all get placed in the separate directory outside of the typical /wp-content/plugins folder. The default to AAM extensions is /wp-content/aam/extension folder and in some cases it may not satisfy the file structure that either hosting provider or business requirements enforce.

This setting allows to redefine the absolute path to the AAM extensions folder.

[aam]
core.extension.directory = "/usr/www/extensions"

Note! AAM does not perform any additional checks if folder contains actual extensions or not. You can confirm that extensions were loaded on the Extensions Area.

AAM is the massive plugin with over 200 different features included in basic version and even more with extensions. That is inevitable that certain features should be customizable based on webmaster’s business needs.

I’m taking minimalistic approach to the AAM UI, so the Settings Area contains the list of settings that are the most used. The list has been distilled from the thousands of support questions that I’ve handled for past several years.

Way more customizations are available with ConfigPress as well as WordPress Hooks.

The Get Started tab is more like an informational part of the AAM UI. It has been added in AAM 5 for beginners and contains some useful information regarding where to start with AAM. You may disable this tab is you just want to focus on managing access to your website resources.

By default, the ability to edit or delete any capability is disabled to prevent from unforced mistakes. So many inexperienced WordPress users lost control over their websites because they did not pay closer attention to what they do. That is why the decision was made to disable the ability to edit or delete existing capabilities unless it is explicitly enabled.

When option is enabled, two additional icons are available for each capability: “Edit” and “Delete”.

In case you need to grand access for other privileged users to manage capabilities however you would like to prevent certain very critical capabilities from being managed, you may consider to create an Access Policy that filters out those capabilities. The AAM Policy Reference page has all necessary information on how to make this happen.

To learn more about the ability to manage capabilities with AAM please refer to How to manage WordPress capabilities article.

Enable or disable access control for the Backend area.

Keep this option disabled if you are not managing access to your website backend side. This may increase your website performance.

By disabling the Backend Access Control feature, AAM UI will adjust accordingly and following features will be removed:

• – Backend Menu tab;
• – Admin Toolbar tab;
• – Metaboxes & Widgets tab;
• – On the Posts & Terms tab the Backend sections;
• – On the Access Denied Redirect tab the Backend section;

Enable or disable access control over the Frontend area.

Keep this option disabled if you are not managing access to your website frontend side. This may increase your website performance.

By disabling the Frontend Access Control feature, AAM UI will adjust accordingly and following features will be removed:

• – On the Posts & Terms tab the Frontend sections;
• – On the Access Denied Redirect tab the Frontend section;

Enable or disable access control over the RESTful or RPC-XML APIs.

Keep this option disabled if you are not managing access to your website API side. This may increase your website performance.

By disabling the API Access Control feature, AAM UI will adjust accordingly and following features will be removed:

• – On the Posts & Terms tab the API sections;
• – The API Routes tab;

Access Manager Metabox, by default, is added to every edit screen for posts, pages, media attachments, CPTs, categories or custom taxonomies. You can disable this metabox if there is no need to manage access to your website content or you simply want to hide it.

Note! The Access Manager Metabox is not rendered for users that do have access to AAM page or do not have ability to manage AAM Posts & Terms feature. It is also not rendered when all Frontend Access Control, Backend Access Control and API Access Control options are disabled.

The “Access” row action is added by default to list of users, posts and taxonomies. It can be disabled if not needed.

Note! The “Access” row action is not rendered for users that do have access to AAM page or do not have ability to manage Posts & Terms feature. “Access” action will not be rendered on All Users screen if user does not have aam_manage_users capability or user is not an administrator. It is also not rendered on list of posts screen when all Frontend Access Control, Backend Access Control and API Access Control options are disabled.

AAM has its own secure login widget and shortcode that you can add to your content. It is the AJAX-based login functionality that does everything what default WordPress login has and very well integrated with AAM core.

Additionally it takes in consideration security settings that AAM has that can significantly improve your website security.

For more information about secure login feature please check How does AAM Secure Login works article.

XML-RPC API is one of the major features that WordPress core offers. It allows other applications to programmatically communicate with a WordPress website and do things like fetch list of posts, edit existing pages or create new. The complete list of available actions you can find in the official WordPress codex.

With AAM you have ability to completely disable the XML-RPC API and any attempts by other applications to work with a website through XML-RPC API will be denied.

Note! If you are looking to disable only certain components of the XML-RPC API, you better consider to restrict them with API Routes feature.

There are quire few talks online about either this feature should be enabled or disabled so my recommendation is going to following:

Recommendation. If you do not understand what is XML-RPC and/or you absolutely sure that not a single active plugin on your website uses it, then keep XML-RPC API disabled.

WordPress 5.0 or higher and Gutenberg editor requires to have RESTful API enabled at all times. Otherwise you will be not able to edit your website content.

RESTful API is probably the most popular way to programmatically connect your website with other applications or even another WordPress website. It is widely used these days by many plugins. Even AAM has few RESTful endpoints declared for things like JWT authentication or payment webhooks.

With AAM you have ability to completely disable the RESTful API and any attempts by other applications to work with your website through this channel will be denied.

Note! If you are looking to disable only certain RESTful endpoints, you may consider to restrict them with API Routes feature.

Recommendation. If you do not understand what is RESTful API and/or you absolutely sure that not a single active plugin on your website uses it, then keep RESTful API disabled.

Since AAM v5.9.2 this feature is enabled by default.

The JWT authentication feature adds additional HTTP endpoint to the WordPress RESTful API that allows to authenticate requests to the WordPress website with JWT token.

For more information about JWT authentication feature please check How to authenticate WordPress user with JWT token article.

Historically AAM supported only single role per user due to a lot of complexity that comes with managing access settings for user that has multiple roles assigned; especially when role settings contradict each other.

With AAM v5.5 the Multiple Roles Support has been added however by default this feature is disabled to keep backward compatibility.

For more information about multiple roles support please refer to the WordPress access control for users with multiple roles article.

Sometime there is a need to disable the ability to install or load AAM extensions. For example WordPress VIP environment is very strict about what can be installed and they require to disable any file system interaction that are triggered by any plugin.

By disabling AAM Extension Support, AAM will not load any installed extensions as well as Extensions Area will be removed from the area panel.

AAM has internal job that utilized WordPress cron job functionality to check periodically if there are any new updates available for already installed extensions. If your WordPress website is on the intranet or behind restricted firewall, it makes sense to disable the AAM cron job.

Note! AAM does not trigger a cron job if there are no extensions installed.

When AAM triggers a cron job there are only 3 pieces of information shared with aamplugin.com server: website domain, list of premium licenses and unique AAM ID that was assigned to your domain. This information is used only to track where premium licenses have been installed as typically all AAM licenses are valid for one live domain only.

To learn more about AAM information privacy please check our Privacy Policy page.

WordPress multisite network does not have any options to manage access to sub-site for users that do not belong to it. That is why any user or visitor can access all sites in the network.

By enabling Multisite None-Member Restriction option, AAM will block access to sites for users that are not members of the sites (not added as users of the site).

Note! AAM will control only frontend access. To restrict user to access backend area for any site, simply do not add user to the site’s user list.

AAM is probably the only free plugin that gives the ability to manage physical access to all your media assets. By enabling Media Files Access Control option, all restricted to READ media assets will not be accessible to view or download.

Note! Additional steps are required to configure this feature. For more information please check How to manage access to the WordPress media library article

Deprecated! This option has been deprecated and removed in the AAM v5.4 version. AAM functionality was highly optimized and can be used on large website without performance impacts. The description below is applicable only for AAM versions lower than v5.4

Enabling Check Post Visibility feature may slow-down the website performance with large amount of posts, pages or media library.

WordPress core database and functionality is not normalized for granular access management to its resources like posts, pages or categories. It would be much easier if all the Website content and relations between different content types were static however in reality this is not true. We consistently adding new posts and categories, changing how they are organized, creating new users and roles. AAM successfully takes in consideration these facts however it comes with the cost.

When Check Post Visibility option is enabled AAM applies settings inheritance mechanism for each fetched post or term and cache result per each user. When there is large amount of posts, AAM will do it in small portions.

It is recommended to keep this feature disabled if you are not planning to use Posts & Terms access option LIST or LIST TO OTHERS.

By default, AAM lets you manage access to post types that are public (check the public parameter’s definition) however this might not satisfy all possible scenarios.

For example, the frontend menus are typically list of hidden post types nav_menu_item that are references to the actual posts, pages, categories or links. The mentioned post type is hidden (not public) that is why you need to explicitely enable the ability to manage them. Upon enabling, you should be able to see more post types available for access control on the Posts & Terms tab.

Note! Available with Plus Package extension only.

WordPress, by default does not provide the ability to group your pages in categories the same way as posts. This might be very useful if you are planning to manage access to multiple pages. Upon enabling this feature, you will be able to group pages into categories the same way as posts.

Note! Available with Plus Package extension only.

WordPress, by default does not provide the ability to group your media assets in categories. This might be very useful if you are planning to manage access to the group of media assets. Upon enabling this feature, you will be able to group media assets into categories the same way as Posts.

Note! Available with Plus Package extension only.

It is quite common when you have to assign more than one category (any hierarchical taxonomy) to a post. In some instances you may have multiple hierarchical taxonomies registered for a post.

AAM by default takes in consideration only access settings from the first category and ignores others however by enabling Support Multiple Categories option, AAM will fetch access settings for all assigned hierarchical taxonomies and merge them as following:

• – By default the denied access option has higher priority. For example if for Category A all posts are allowed to READ, however for Category B all posts are restricted to READ, then any post that has Category A and Category B will be restricted;
• – If ConfigPress option access.merging.preference^* is set to allow then with the same scenario as above, the post will be permitted.

Note! The LIST and LIST TO OTHERS options are the only exception to these rules due to a lot of constrains with the way WordPress posts are stored in the database. AAM will show a post if any of the assigned categories allow to LIST or LIST TO OTHERS.

* You should have Plus Package 3.5.1 or higher for this feature.

Note! Available with Plus Package extension only.

Allow AAM to inherit access settings from a parent post (any hierarchical post type like pages) before trying to inherit settings from a parent category or default settings.

For more information about AAM post access inheritance mechanism please check How to manage access to the WordPress content article.

The Login Timeout is the easiest and the most efficient way to slow down any brute-force attacks on your website. Typically when you send a login request to the WordPress core, it takes about 50 to 100 milliseconds to get response. By enabling Login Timeout option, the login request slows down to 1 second. So technically this means that it will slow down any attack x10 to x20 times and significantly reduce change for criminals to get access to your website.

Just a thought! If you concern that slowing down login for 1 second will negatively impact user experience please answer yourself this question. Does it really so bad for user to wait 1 second for one-time login?

For more information about AAM Secure Login functionality please refer to the How does AAM Secure Login works article.

The One Session Per User option ensures that the same user is logged in at one location only. So for example if John Dawn logged in the school library in the morning and forgot to logged out, he can simply login from his home computer or even mobile phone and this will destroy the active session that he opened in the school library. Very good feature if you want to reassure that there is only on session per user active on the website.

For more information about AAM Secure Login functionality please refer to the How does AAM Secure Login works article.

By enabling the Brute Force Lockout option, AAM will count number of login attempts per IP address and if there are 20 failed consequent attempts to login, all further request will be automatically blocked for next 20 minutes.

For more information about AAM Secure Login functionality please refer to the How does AAM Secure Login works article.

Available with AAM v5.7 or higher.

Rethink the way you approach access and security management to your WordPress website. Define your own access policies and attach them to any user, role, visitors or even programmatic application.

To learn more about AAM Policy please refer to the AAM Policy Reference page.

One of the most popular features that AAM offers is the ability to restrict access to the backend menu items. AAM not only filters out restricted menus and submenus but is also prevents direct access to them.

To learn more about admin menu and how AAM manages access to it, please check How to manage WordPress backend menu article.

With AAM v5.4 or higher you have the ability to filter out unnecessary items from the top admin toolbar.

Note! Admin Toolbar feature is not intended to restrict direct access to URLs and should be used only to remove unnecessary items from the top admin toolbar. Use Backend Menu tab to restrict direct access to backend pages or utilize the great power of roles and capabilities.

If you are looking to complete hide admin toolbar on the frontend for any roles or individual users, you can create a custom capability show_admin_bar and make sure that it is not checked for desired role or user.

Another useful feature that comes with basic AAM plugin is the ability to manage list of metaboxes and widgets on both Frontend and Backend.

Metaboxes and widgets are parts of the backend and frontend, designed to do very specific tasks. You can find metaboxes on edit post, page or custom post type pages. For example “Publish”, “Categories”, “Custom Fields” etc. are metaboxes.

Widgets typically are rendered either on the Home page of the admin Dashboard or on the sidebar of the website frontend.

The AAM v5.3.4 or higher also filters out restricted widgets from the Appearance->Widgets backend page.

To learn more about metaboxes and widgets and how AAM manages them, please refer to the How to hide WordPress metaboxes and widgets article.

This is the most powerful and also very sensitive part of the entire website. Be careful because you can easily loose control over your website or restrict group of users from doing critical tasks without even noticing that.

On this tab you have absolutely all necessary tools to manage list of capabilities for any role or even individual user.

To learn more about the concept of capability and how AAM manages them please check What is a WordPress capability article.

AAM also introduces numerous custom capabilities that you can be utilized to enhance your website functionality. All the available AAM custom capabilities are listed below.

Note! All custom AAM capabilities are not created automatically during plugin activation, however you can add them manually when needed. You can learn more on how to manage WordPress capabilities with AAM from the “How to manage WordPress capabilities” article.

By default only users with Administrator role have access to the AAM page and features however you can change this behavior by adding a custom aam_manager capability.

This is the first-tier access capability to AAM functionality. You still need to assign additional custom capabilities to your user or role for very specific features. For example aam_manage_admin_menu for Backend Menu or aam_manage_posts for Posts & Terms.

To learn more about managing access to the AAM page and features, please refer to the How to manage access to AAM page for other users article.

Note! The aam_manager capability has to be assigned prior to aam_manager_admin_menu capability as well as at least on type of subjects (users, roles, visitors or default) has to be allowed to manage too.

Grand permission to manage access to the Backend Menu feature.

Note! For users that has this capability assigned, any access settings to the backend menu will be disregarded however users will be able to manage access only to the backend menu items they have access to. For example if you allow to manage Backend Menu for Editor role, then editors will be not able to manage access to menu items that require administrator privileges.

Note! The aam_manager capability has to be assigned prior to aam_manage_admin_toolbar capability as well as at least on type of subjects (users, roles, visitors or default) has to be allowed to manage too.

Grand permission to manage access to the Admin Top Toolbar feature.

Note! The aam_manager capability has to be assigned prior to aam_manage_metaboxes capability as well as at least on type of subjects (users, roles, visitors or default) has to be allowed to manage too.

Grand permission to manage access to the Metaboxes & Widgets feature.

By giving the ability for other user to manage to capabilities is almost like giving the complete access to the website. You have to really trust your user in order to give access to this section.

Note! The aam_manager capability has to be assigned prior to aam_manage_capabilities capability as well as at least on type of subjects (users, roles or default) has to be allowed to manage too.

Give the ability for user to manage all Capabilities.

Note! You can manage more granular access to each capability with AAM Policy. You can basically specify what capabilities can be listed, toggled or deleted.

Note! The aam_manager capability has to be assigned prior to aam_manage_posts capability as well as at least on type of subjects (users, roles or default) has to be allowed to manage too.

Give the ability for user to manage Posts & Terms feature. This capability is also used to check if user has the ability to work with Access Manager Metabox on the post’s edit screen.

Note! Available with AAM v5.9.2 or higher. The aam_manager and aam_manage_users capabilities have to be assigned prior to aam_manage_jwt capability.

Give the ability for user to manage JWT Tokens feature.

Note! The aam_manager capability has to be assigned prior to aam_manage_access_denied_redirect capability as well as at least on type of subjects (users, roles or default) has to be allowed to manage too.

Give the ability for user to manage Access Denied Redirect feature.

Note! The aam_manager capability has to be assigned prior to aam_manage_login_redirect capability as well as at least on type of subjects (users, roles or default) has to be allowed to manage too.

Give the ability for user to manage Login Redirect feature.

Note! The aam_manager capability has to be assigned prior to aam_manage_logout_redirect capability as well as at least on type of subjects (users, roles or default) has to be allowed to manage too.

Give the ability for user to manage Logout Redirect feature.

Note! The aam_manager capability has to be assigned prior to aam_manage_404_redirect capability as well as aam_manage_default capability.

Give the ability for user to manage 404 (Not Found) Redirect feature.

Keep in mind that 404 redirect can be managed only on the default level. This is the artificial constrain because we do not really found any use-cases for having different 404 redirect vary per user. Please do not hesitate to provide feedback.

Note! Available with IP Check extension only. The aam_manager and aam_manage_visitors capabilities have to be assigned prior to aam_manage_ip_check capability.

Give the ability for user to manage access to a website by visitor’s IP address or referred host with IP Check feature.

For more information about IP Check functionality, please refer to the How to maange access to WordPress website by IP address article.

Note! The aam_manager capability has to be assigned prior to aam_manage_settings capability.

Give the ability for user to manage Settings area. This includes Core, Content, Security settings as well as ConfigPress settings.

Note! The aam_manager capability has to be assigned prior to aam_manage_uri capability as well as at least on type of subjects (users, roles or default) has to be allowed to manage too.

Give the ability for user to manage URI Access feature.

Note! The aam_manager capability has to be assigned prior to aam_manage_policy capability as well as at least on type of subjects (users, roles or default) has to be allowed to manage too.

Give the ability for user to manage Access Policies feature. For more information about AAM Policies please refer to the AAM Policy Reference page.

Note! The aam_manager capability has to be assigned prior to aam_manage_extensions.

Give the ability for user to manage AAM Extensions area. Keep in mind that this capability will allow user to install, activate and deactivate any extension. It also allows users to see license numbers for each premium extension.

Note! If user knows license number, he can use this information to transfer the license to any other domain on the License Page.

Note! The aam_manager capability has to be assigned prior to aam_manage_extensions.

Give ability for users to see the AAM console panel with AAM notifications.

Note! The aam_manager capability has to be assigned prior to aam_manage_default capability.

Give the ability for user to Manage Default Access for everybody. For more information about the concept of default settings, please refer to the How to define default WordPress access settings article.

Warning! The Default access settings are propagated to all users and roles, including administrators. Be very careful to give this capability for not qualified users.

Note! The aam_manager capability has to be assigned prior to aam_manage_visitors capability.

Give the ability for user to Manage Visitors (unauthenticated users).

Note! The aam_manager capability has to be assigned prior to aam_manage_roles capability.

Give the ability for user to Manage Roles however keep in mind that the list of roles will be filtered based on the current user level so user will be able to see and manage only roles that have lower user level.

There are also several additional capabilities aam_create_roles, aam_edit_roles, aam_delete_roles that can be used to manage more granular access to what exactly user can do with the list of roles.

Note! The aam_manager capability has to be assigned prior to aam_manage_users capability.

Give the ability for user to Manage Roles however keep in mind that the list of users will be filtered based on the current user level so user will be able to see and manage only users that have lower user level.

There are also couple additional capabilities aam_toggle_users and aam_switch_users that can be used to manage more granular access to what exactly user can do with other users.

Note! The aam_manager and aam_manage_roles capabilities have to be assigned prior to aam_create_roles capability.

Give the ability for user to create a new role on the AAM page.

Note! The aam_manager and aam_manage_roles capabilities have to be assigned prior to aam_create_roles capability.

Give the ability for user to edit existing roles.

Note! User is allowed to manage roles that have the same or lower user level. For more information about users/roles filtering please refer to the Users/Roles Filter section.

Note! The aam_manager and aam_manage_roles capabilities have to be assigned prior to aam_create_roles capability.

Give the ability for user to delete any existing role however only if there are no users assigned to it.

Note! User is allowed to manage roles that have the same or lower user level. For more information about users/roles filtering please refer to the Users/Roles Filter section.

Note! The aam_manager and aam_manage_users capabilities have to be assigned prior to aam_toggle_users capability.

Allow other users to lock/unlock existing user accounts however only accounts that are allowed.

Note! The aam_manager and aam_manage_users capabilities have to be assigned prior to aam_switch_users capability.

Allow other users to switch (impersonate) existing user accounts however only to accounts that are allowed. So basically if user has Editor role, he’ll be not able to switch to user with Administrator role.

This capability is deprecated in AAM 5.9. Use aam_manage_settings capability instead.

Note! The aam_manager capability has to be assigned prior to aam_manage_settings capability.

Give the ability for user to manage ConfigPress tab.

Note! The aam_manager capability has to be assigned prior to aam_manage_api_routes capability as well as at least on type of subjects (users, roles or default) has to be allowed to manage too.

Give the ability for user to manage API Routes feature.

Note! The aam_manager capablity have to be assigned prior to show_admin_notices capability.

Allow other users to see AAM notifications on the AAM page.

This is the custom capability that you have to create manually if it is not on the list of capabilities.

AAM automatically filters out the list of roles and users that have higher User Level. This way webmaster does not have to worry about users with lower privilege level modifies or deletes users with higher level.

The manage_same_user_level capability, when exists (means it was manually created on the Capabilities tab) allows user to manage users and roles up to the same User Level.

For example if you have two or more administrators, you can create manage_same_user_level capability and uncheck it for all admin users except yours. This way other admins will be not able to create another administrator user or manage your account or any other admin account.

This is the custom capability that you have to create manually if it is not on the list of capabilities. Upon creation, all users and roles that do no have this capability explicitly assigned, will not be able to manage post’s^* permalink.

The edit_permalink allows user to change post’s permalink on the post edit screen.

This is the custom capability that you have to create manually if it is not on the list of capabilities. Upon creation, all users and roles that do no have this capability explicitly assigned, will not be able to see “Screen Options” tab.

The “Screen Options” tab allows user to alter the backend layout. The show_screen_options capability allows user to manage what metaboxes, layout or any additional screen options registered by third-party plugins or themes.

This is the custom capability that you have to create manually if it is not on the list of capabilities. Upon creation, all users and roles that do no have this capability explicitly assigned, will not be able to see “Help” tab.

The “Help” tab typically contains additional information about the current page and is more like a reference for user. The show_help_tabs capability allows user to see the “Help” tab.

Warning! Be careful. Depriving Administrator role or your admin user from this capability will immediately lock you down from accessing Backend area of the website.

This is the custom capability that you have to create manually if it is not on the list of capabilities. Upon creation, all users and roles that do no have this capability explicitly assigned, will not be able to access Backend site of a website.

The access_dashboard capability has been created to allow webmasters to completely restrict Backend area for all users and roles that do no have this capability explicitly assigned.

Due to the fact that all legacy AJAX calls from the Frontend area typically are sent to the /wp-admin/wp-ajax.php endpoint, AAM will also restrict them because the is_admin() core function returns true. In this case you have to create a new custom capability allow_ajax_calls.

Deprecated and removed in AAM v5.9.2 due to a lot of confusion on how it should work. Eventually majority of the plugins and themes will transition to the RESTful API instead of old-school /wp-admin/wp-ajax.php endpoint.

This is the custom capability that you have to create manually if it is not on the list of capabilities.

The allow_ajax_calls is the complimentary capability for the access_dashboard capability that permits AJAX requests to the /wp-admin/wp-ajax.php endpoint from the Frontend area.

There are still a lot of plugins and themes that use old way to send AJAX calls to wp-ajax.php endpoint that is treated by WordPress core a the Backend area of a website. If you are restricting access to the backend with the access_dashboard capability, it is most likely you would have to also create allow_ajax_calls as it might break any frontend functionality that relies on legacy WordPress core AJAX handler.

This is the custom capability that you have to create manually if it is not on the list of capabilities. Upon creation, all users and roles that do no have this capability explicitly assigned, will not be to see the Admin Toolbar on the Frontend area.

The top Admin Toolbar, by default is shown on the Frontend after user authentication. That is something that now always needed, especially when website administrator does not want other users to have access to the Backend area.

WordPress core already offers the ability to disable the top admin toolbar for any individual user, however this process may be time consuming because webmaster has to go to each user’s profile one-by-one and disable toolbar.

As an option, you can create a custom show_admin_bar capability and assign it only to roles or users that toolbar has to be shown.

Note! The aam_manager capability has to be assigned prior to aam_view_help_btn capability.

This is just a “cosmetic” capability that allows user to see the HELP button on the top right corner of the AAM page.

AAM Access Policy is very powerful and sensitive part for the website security. Each policy is a custom post type aam_policy where all the WordPress core default capabilities that control different aspects of the post’s life-cycle are overwritten with AAM custom capabilities.

For more information about capabilities for post types please refer to the get_post_type_capabilities official WordPress codex page.

The edit_policy overrides the default WordPress core edit_post capability and if aam_edit_policy is not defined, AAM checks if user has administrator capability.

AAM Access Policy is very powerful and sensitive part for the website security. Each policy is a custom post type aam_policy where all the WordPress core default capabilities that control different aspects of the post’s life-cycle are overwritten with AAM custom capabilities.

For more information about capabilities for post types please refer to the get_post_type_capabilities official WordPress codex page.

The aam_read_policy overrides the default WordPress core read_post capability and if aam_read_policy is not defined, AAM checks if user has administrator capability.

AAM Access Policy is very powerful and sensitive part for the website security. Each policy is a custom post type aam_policy where all the WordPress core default capabilities that control different aspects of the post’s life-cycle are overwritten with AAM custom capabilities.

For more information about capabilities for post types please refer to the get_post_type_capabilities official WordPress codex page.

The aam_delete_policy overrides the default WordPress core delete_post capability and if aam_delete_policy is not defined, AAM checks if user has administrator capability.

AAM Access Policy is very powerful and sensitive part for the website security. Each policy is a custom post type aam_policy where all the WordPress core default capabilities that control different aspects of the post’s life-cycle are overwritten with AAM custom capabilities.

For more information about capabilities for post types please refer to the get_post_type_capabilities official WordPress codex page.

The aam_delete_policies overrides the default WordPress core delete_posts capability and if aam_delete_policies is not defined, AAM checks if user has administrator capability.

AAM Access Policy is very powerful and sensitive part for the website security. Each policy is a custom post type aam_policy where all the WordPress core default capabilities that control different aspects of the post’s life-cycle are overwritten with AAM custom capabilities.

For more information about capabilities for post types please refer to the get_post_type_capabilities official WordPress codex page.

The aam_edit_policies overrides the default WordPress core edit_posts capability and if aam_edit_policies is not defined, AAM checks if user has administrator capability.

AAM Access Policy is very powerful and sensitive part for the website security. Each policy is a custom post type aam_policy where all the WordPress core default capabilities that control different aspects of the post’s life-cycle are overwritten with AAM custom capabilities.

For more information about capabilities for post types please refer to the get_post_type_capabilities official WordPress codex page.

The aam_edit_others_policies overrides the default WordPress core edit_others_posts capability and if aam_edit_others_policies is not defined, AAM checks if user has administrator capability.

AAM Access Policy is very powerful and sensitive part for the website security. Each policy is a custom post type aam_policy where all the WordPress core default capabilities that control different aspects of the post’s life-cycle are overwritten with AAM custom capabilities.

For more information about capabilities for post types please refer to the get_post_type_capabilities official WordPress codex page.

The aam_publish_policies overrides the default WordPress core publish_posts capability and if aam_publish_policies is not defined, AAM checks if user has administrator capability.

This is the custom AAM capability and has to be created manually if not present on the list of capabilities.

When created, any user or role that does not have this capability explicitly assigned, will not be able to change password on the Profile page.

For more information about how this capability is used, check Restrict User’s Password Change policy.

This is the custom AAM capability and has to be created manually if not present on the list of capabilities.

When created, any user or role that does not have this capability explicitly assigned, will not be able to change passwords for other users. This is useful capability when you have multiple administrators however do not want them to change passwords for other users or potentially for your admin user.

AAM plugin has the most powerful and sophisticated set of tools to manage access to the website posts, pages, media, custom post types, categories and taxonomies. Flexible inheritance mechanism and multiple levels of default settings makes AAM the best content management plugin that is available for the WordPress CMS.

You can manage access to your content for any role, individual user or visitors for frontend, backend and API levels.

To learn more in-depth about content access control please check How to manage access to the WordPress content article.

Hide any post on the website Frontend, Backend or API sides. AAM filters out selected post from all menus or lists however it can be accessed with direct URL.

Please Note! Prior to AAM v5.9.3, there was one constrain related to multiple-roles support. When user has more than one role assigned, AAM will enforce to hide any post that has LIST option checked disregarding other roles that actually allow to LIST a post. With AAM v5.9.3 or higher this limitation has been resolved.

For example, you can hide the page “Sample Page” for all users with the Subscriber role but if user has direct URL to the page, he will be able to access it.

With Plus Package extension access control is also available for taxonomies or you can even setup default access to any registered post type (e.g. Posts, Pages, Media etc.).

Note! Available with Plus Package extension only.

Similar to the LIST option however a post is hidden for everybody except the author (whoever is listed as an author of a post). It is also probably one of the most confusing options and requires additional explanation.

List to others technically means that you restrict to show a post to none-authors within the scope that you manage access to. For example, if on the Users/Roles Manager you selected Editor role, then LIST TO OTHERS means, that restricted post will be hidden from all users that have Editor role and are not the author of a post.

Keep in mind! It absolutely makes no sense to use LIST TO OTHERS option for an individual user because that particular user cannot be “others” as well as “others” can not be that user. That is why LIST TO OTHERS options is not displayed when you manage access to posts or terms for an individual user.

If you want to hide posts from all users except authors, then you should switch to manage default access settings. These settings are propagated to all users and roles automatically unless overwritten.

Note! If LIST TO OTHERS and LIST options are both checked, then AAM disregards LIST TO OTHERS option.

Restrict access to read a post. If LIST option is not checked, then the post is still listed but direct access to it is restricted. Any attempt to access a post will be denied and user will be redirected based on the Access Denied Redirect rule.

Media library is the exception. To learn more about this topic check How to manage WordPress media access article.

Note! Available with Plus Package extension only.

Similar to the READ option however the post is restricted for reading and viewing for everybody except an author (whoever is assigned as author or a post). It is also one of the most confusing options and requires additional explanation.

Read by others technically means that you restrict to read a post to none-authors within the scope that you manage access to. For example, if on the Users/Roles Manager you selected Contributor role, then READ BY OTHERS means, that a post will be restricted to read by all users that have Contributor role and are not the author of a post.

Keep in mind! It absolutely makes no sense to use READ BY OTHERS option for an individual user because that particular user cannot be “others” as well as “others” can not be that user. That is why READ BY OTHERS options is not displayed when you manage access to posts or terms for an individual user.

If you want to restrict access to read posts by all users except authors, then you should switch to manage default access settings. These settings are propagated to all users and roles automatically unless overwritten.

Note! If READ BY OTHERS and READ options are both checked, then AAM disregards READ BY OTHERS option and the author will not be able to read his own posts.

Limit access to read a post by showing a custom teaser message. It is useful to use this option when there is a need to prompt user to do some action like login or renew subscription plan.

The teaser message can be either plain text or valid HTML. For example with this custom HTML message the following can be shown instead of the post’s content.

<div class="text-center">
    <img src="https://aamplugin.com/imgs/access-key.svg" width="64" />
    <h2>Access Denied</h2>
    <p class="text-muted">Please contact our system administrator for more information</p>
</div>

Define how many times a post can be opened to read, view or download. This option is available only for authenticated users as there is no really secure way to track visitor’s activity.

Some plugins track visitor’s activity with cookies, browser local or session storages or even through IP. All these methods have limitations and cannot be used to reliably identify visitors. That is why READ COUNT option is not available for visitors.

After user reaches defined threshold, access to a post will be denied and user will be redirected based on the Access Denied Redirect rule.

The read counter increments right after the threshold is set. The counter is stored in the wp_usermeta table as aam-post-[post-id]-access-counter meta key. There is no option to reset this counter from the AAM UI. The meta key has to be deleted manually when there is a need to reset the counter.

Manage the ability for users to write comments on a post. For example you can restrict access for visitors to write comments on any post to reduce the amount of spam.

The option is equivalent to the “Allow Comments” checkbox that you can see on the “Quick Edit” panel for any post or page.

Note! You also have the option to completely restrict commenting for any defined post type by setting Default Access for all posts. The Plus Package extension is required for this feature.

Redirect user to a different location based on the specified redirect rule when user tries to access a post.

There are several possible redirect rules:

1. Redirect to existing page. Will redirect user to a different page.
2. Redirect to the URL. Will redirect user to a specified URL.
3. Trigger PHP callback function. Will trigger callable and valid PHP callback.

Note! If you just want to restrict access to a post, then use READ option instead.

Available with WordPress v4.7.0 or higher.

Password protect a post. This is very similar to the password protected feature that WordPress core offers however AAM extends it and allows to setup a single password for any category or all posts. For example you can define a single password for all pages but overwrite it for one specific page; or set a single password for all articles in the Tutorials category.

Check this video to find out how you can protect all the posts with a single password.

Note! It has been reported several times that some of the custom themes do not support password protected template. In this case you would have to work with your theme developer and if any questions, you may refer your developer to me via email support@aamplugin.com

Define time limit for a post to be accessible. For example you can allow subscribers to access your posts in the Science category only until January 15^th 2019. After that the access will be automatically restricted and any attempts to access posts inside the Science category will redirect user based on the access denied redirect rules.

For more information about this feature please refer to How to set expiration date on any WordPress content article.

Note! Available with E-Commerce extension only and can be enhanced with Plus Package extension.

Start selling access to your website content (any post, page, media asset, custom post type, category, custom taxonomy etc.). This feature is based on the simple idea where authenticated user has access to the restricted content only if he/she purchased access to it. Otherwise user will be automatically redirected to conduct a purchase or teaser message will be displayed to do so.

Note! For more information about this feature, please refer to the How to monetize access to the WordPress content article.

The EDIT option is used for both posts and terms to control access to edit/update them by users. When access is restricted, then user has the able only to preview or delete a post or a term.

Any attempts to edit restricted posts or terms result in redirecting user based on the Access Denied Redirect rule.

Note! The basic AAM version allows to manage access to posts (any post, page, custom post type or media asset). With Plus Package extension you also can manage access to hierarchical terms.

Note! Available with Plus Package extension only.

Similar to the EDIT option however a post is restricted for editing for everybody except an author (whoever is assigned as author to a post). It is also one of the most confusing options and requires additional clarification.

Edit by others technically means that you restrict to edit a post to none-authors within the scope that you manage access to. For example, if on the Users/Roles Manager you selected Contributor role, then EDIT BY OTHERS means, that a post is going to be restricted for editing by all users that have the Contributor role and are not the author of a post.

Keep in mind! It absolutely makes no sense to use EDIT BY OTHERS option for an individual user because that particular user cannot be “others” as well as “others” can not be that user. That is why EDIT BY OTHERS options is not displayed when you manage access to posts or terms for an individual user.

If you need to restrict access to edit posts by all users except authors, then you should switch to manage default access settings. These settings are propagated to all users and role automatically unless overwritten.

Note! If EDIT BY OTHERS and EDIT options are both checked, then AAM disregards EDIT BY OTHERS option and the author will not be able to edit his own posts.

Restrict the ability to trash or permanently delete a post or a term. Any attempts to trash or delete a post or a term will be discarded.

Note! The basic AAM version allows to manage access to posts (any post, page, custom post type or media asset). With Plus Package extension you also can manage access to hierarchical terms.

Note! Available with Plus Package extension only.

Similar to the DELETE option however a post cannot be deleted by anybody except an author (whoever is assigned as author to a post). It is also one of the most confusing options and requires additional clarification.

Delete by others technically means that you restrict to delete a post by none-authors within the scope that you manage access to. For example, if on the Users/Roles Manager you selected Editor role, then DELETE BY OTHERS means, that a post cannot be deleted by all users that have Editor role and are not the author of a post.

Keep in mind! It absolutely makes no sense to use DELETE BY OTHERS option for an individual user because that particular user cannot be “others” as well as “others” can not be that user. That is why DELETE BY OTHERS options is not displayed when you manage access to posts or terms for an individual user.

If you need to restrict access to delete posts by all users except authors, then you should switch to manage default access settings. These settings are propagated to all users and role automatically unless overwritten.

Note! If DELETE BY OTHERS and DELETE options are both checked, then AAM disregards DELETE BY OTHERS option and the author will not be able to delete his own posts.

Restrict access to publish an existing post if it haven’t been published yet. Great option if you want to restrict the ability for other users to publish content without reviewing it first. Any attempts to publish a post will result is saving a post with Pending Review status.

Note! The basic AAM version allows to manage access to individual posts (any post, page, custom post type or media asset) only. To restrict the ability to publish new posts, you need to have Plus Package extension. This way you can define the default access to all posts for any user or role.

Note! Available with Plus Package extension only.

Similar to the PUBLISH option however a post cannot be published by anybody except an author (whoever is assigned as author or a post). It is also one of the most confusing options and requires additional clarification.

Publish by others technically means that you restrict to publish a post by none-authors within the scope that you manage access to. For example, if on the Users/Roles Manager you selected Editor role, then PUBLISH BY OTHERS means, that a post cannot be published by all users that have Editor role and are not the author of a post.

Keep in mind! It absolutely makes no sense to use PUBLISH BY OTHERS option for an individual user because that particular user cannot be “others” as well as “others” can not be that user. That is why PUBLISH BY OTHERS options is not displayed when you manage access to posts or terms for an individual user.

If you want to restrict access to publish posts by all users except authors, then you should switch to manage default access settings. These settings are propagated to all users and role automatically unless overwritten.

Note! If PUBLISH BY OTHERS and PUBLISH options are both checked, then AAM disregards PUBLISH BY OTHERS option and the author will not be able to publish his own posts.

Note! Available with Plus Package extension only.

Restrict access to browse a category’s content. A category can be any hierarchical term either default WordPress core term (like post category) or any custom term registered by third-party plugin/theme (like WooCommerce, BuddyPress etc).

The term, itself, is visible and is listed on the website frontend. However when user clicks on it or tries to fetch content via API, access will be denied and user will be redirected based on the Access Denied Redirect rule.

Note! Available with Plus Package extension only.

Restrict the ability to create new posts. This option is available only for default post type access level so technically you can either allow to create new posts or not. Any attempts to create a new post will be denied with WordPress core message “Sorry, you are not allowed to access this page.”

Note! There is no way to restrict access to create new posts for specific category simply because WordPress does not know what category will be chosen after hit Create New button. If there is a need to limit the list of categories user can create posts in, simply hide unnecessary categories with the LIST option and redefine the default category.

AAM plugin gives you several way to improve user experience with HTTP redirects.

Currently AAM offers 4 different types of redirects and all, except 404 redirect, can be customized for any role, individual user or visitor.

Note! All the features that are related to redirect are included in the free AAM version. There is no need to purchase any premium extensions.

Access Denied Redirect is very useful and granular feature that allows to define what AAM should be doing when access is denied for some restricted resource.

The UI functionality is self-explanatory however to eliminate any possible questions, please refer to the How to redirect WordPress user when access is denied article.

By default, WordPress redirects user to the Backend area after successful authentication. In lots of cases this might not be the ideal user flow. With the Login Redirect feature you can redefine this behavior for any role or even individual user.

For example, you can redirect all users that have Subscriber role to any Frontend page or URL, rather than to the Backend, however all Editors, redirect to list of posts page on the Backend.

The login redirect feature may not work if you are using third-party plugin or any custom functionality for the login process. We strongly encourage you to check our free AAM Secure Login feature.

Redefine logout redirect for any role or individual user. By default, logged out user is redirected to the WordPress login screen which is not convenient at all. With this feature you can change to redirect user to the website homepage or any other page and URL.

AAM allows you to define custom 404 redirect when page was not found on the website. The 404 redirect can be defined only on the default access level as it is less-likely you need the ability to define 404 redirect for specific user or role.

For more information about this feature you can check How to redirect on WordPress 404 error article.

The API Routes feature is available with AAM v5.3 or higher and allows to manage access to individual endpoints for XML-RPC and RESTful APIs. You literally can deny access to almost any endpoint for any role, user or anonymous requests.

For better RESTful API experience, you might want to consider JWT Authentication that is already available in basic AAM version.

The URI Access feature is available with AAM v5.6 or higher and allows to manage access to any page on your website as long as it is rendered by WordPress core or third party application that loads WordPress core.

For more information about this feature check How to restrict access to any WordPress website URL article.

The JWT Tokens feature is available with AAM v5.9.2 or higher and allows to manage list of JWT tokens that are associated with current user. This means that you can see the JWT Tokens tab only when you manage access to an individual user.

Note! Any user may have multiple valid JWT tokens and with AAM v5.9.2 any of those tokens can be revoked by deleting it. To prevent from overloading user account with countless number of tokens, AAM implement a ring-buffer approach to the list of tokens. By default each account may have up to 10 tokens and if 11^th token is created, it is actually replaces the first token on the list. You can increase or decrease this limit with authentication.jwt.registryLimit ConfigPress option.

For more information about this feature check Ultimate guide to WordPress JWT authentication article.

AAM comes with couple tools that you can use on the Settings Area.

The Clear Cache tool literally clears all AAM related cached data. Typically the cache is stored in the database tables however it may be stored elsewhere (depending on the website setup).

The Clear All Settings tool is very useful when you need to completely reset all AAM settings and kinda start from fresh.

AAM comes with internal caching mechanism that is heavily used to cache time and resource consuming computations like determining correct access settings for posts and pages or fetching the list of access policies.

You have the option to manually clear the AAM cache on the Settings Area which is one of the first steps that you should perform when something is not working as expected or you just want to make sure that the latest access settings are applied correctly.

AAM automatically clears the cache for specific user or all the users depending on the change. For example if you assign post to a new category, AAM will automatically clear the cache so a new set of access settings can be inherited.

To start fresh, you have the ability to clear All AAM Settings on the Settings Area. This removes all the database records that AAM created in _options, _postmeta and _usermeta table except two options inside the _options table: aam-extensions and aam-uid.

The aam-extensions contains the list of all installed AAM extensions and premium licenses associated to those extensions. The aam-uid contains the unique auto-generated ID that is tight to your website. This ID is used only to track extension download activities.

Keep in mind that changes to the list of Roles and Capabilities are permanent and AAM does not reset them.

Users/Roles Manager is the sidebar panel on the AAM page that allows you easily navigate between roles, users, visitors or switch to manage default access settings for everybody.

By default only Administrator role full access to all the tabs for this panel and you have the option to grant a limit access to any tab for other users. To learn more about this please check How to manage access to AAM page for other users article.

Note! This tab will show the list of roles that current user has access to. AAM automatically filters out roles with the higher User Level from the list. You can learn more about Users/Roles Filter feature.

WordPress allows you to have unlimited number of roles however it does not have ability to manage them. The Roles tab contains the list of all roles that are defined on your website.

To learn more about role management please refer to the How to manage WordPress roles article.

Note! This tab will show the list of users that current user has access to. AAM automatically filters out users with the higher User Level from the list. You can learn more about Users/Roles Filter feature.

With AAM Users tab you can see the list of all your users to manage access, block, define temporary user account or switch to any user to verify permissions.

To learn more about user management, please check How to manage WordPress users article.

One of the biggest features that AAM has is the ability to manage access to the WordPress website resources for visitors (users that are not authenticated). Because visitors do not have identity, special privileges or access to the Backend side of the website, webmaster can manage access to the website content, Frontend widgets and publicly exposed API endpoints.

It is important to understand who is considered as visitor, so please refer to the What is a WordPress visitor article.

One of the most powerful aspects in the AAM functionality is the ability to define the default access for everybody to any website resource. So technically everybody (including Administrator role, your admin user and visitors) inherits default access settings unless overwritten.

For more information about default access settings management, please check How to define default WordPress access settings article.

Note! AAM main focus is on providing the reliable set of features to manage access to the WordPress resource while AAM shortcodes are just a separate bonus tools that may not work the way you anticipate. Please read the documentation for each shortcode carefully and do your experiments. If something is not working as expected, do not hesitate to open the thread on the AAM Forum.

Technically there is only one AAM shortcode which is [aam]. However it serves different purposes depending on the context attribute and currently AAM supports three different contexts:

– content is used to manage access to the part of a post’s or page’s content;
– login represents the AAM Secure Login widget;
– loginRedirect can be used to display a link that navigates user to the login form and upon authentication back to the original page.

FYI! Stay connected with AAM on twitter or subscribe to AAM newsletters as I’m already planning to build several Gutenberg block that will replace shortcodes.

Manage access to certain parts of a page, post or custom post type’s content with [aam] shortcode. You can find more information about this shortcode in the How to filter WordPress post content article.

List of available attributes:

• show – Comma-separated list of role IDs, user IDs or IP addresses to show content for;
• hide – Comma-separated list of role IDs, user IDs or IP addresses to hide content from;
• limit – Comma-separated list of role IDs, user IDs or IP addresses to limit content for;
• message – Message to show if “limit” is defined attribute is defined;
• callback – Callback function that return content;

The [aam context=”login”] shortcode is used to drop login form on your website page. To find more information about this shortcode please refer to the How does AAM secure login works article.

List of available attributes:

• id – Unique login form ID. Default: random unique string;
• user-title – Greeting message. Default: Howdy, %username%;
• redirect – Redirect to page after successful login. Default: value in the __GET “redirect_to”;
• callback – Custom PHP callback function that returns login form. Default: none;

The [aam context=”loginRedirect”] shortcode is useful when you want to render link or button that leads to the default WordPress login form. Upon successful login, user will be redirected back to the previous page.

List of available attributes:

• class – Link HTML class. Default: none;
• callback – Custom PHP callback function that returns login button. Default: none;
• label – If this shortcode does not wrap any content (stand-alone), then define what text label should be used for login link. Default: Login to continue;

AAM is very flexible WordPress plugin that can be easily extended based on the business need. It already comes with several free and premium extensions that you can find on the Extensions Area.

Note! AAM extensions are not typical WordPress plugins and should not be treated as such. All AAM extension are installed in special directory that is outside of the default WordPress plugin directory.

There are two possible ways of installing AAM extension:

1. From the Extensions Area. If you purchased a premium extension, then you can insert the license here and AAM will automatically download and install extension for you. For free extensions, you can simply click on Download button right next to the extension name.

2. Manual installation. For example if you are behind the company firewall or your website has some troubles sending remote request to our server, you can download any extension and follow the manual installation instruction from the How to install AAM extension manually article.

Plus Package is the premium extension that can be purchased from the online store.

Plus Package extends the default AAM Posts & Terms feature and allows you to manage access to post types, terms and taxonomies. Additionally, on demand, it can register two custom hierarchical taxonomies for pages and media assets so you can group your content into categories the same way it is done with posts.

Plus Package is the ultimate solution when you need to manage access to the restricted WordPress content and it has all necessary set of tools for that.

For more information about Plus Package extension, please refer to the Plus Package page.

AAM IP Check is the premium extension that can be purchased from the online store.

Manage access to your website based on visitor’s IP address or referred host. Very useful extension if you looking to restrict access to the WordPress website for range of IPs or references from unwanted websites.

For example, you can restrict access to your website for everybody who comes from the 10.1.0.0 – 10.1.255.255 IP range or visitors that come from www.somebaddomain.com. You can also do opposite way, “blacklist” or IP addresses and referred domains and allow only few (whitelist them).

For more information about IP Check extension, please refer to the AAM IP Check page.

AAM Role Hierarchy is the premium extension that can be purchased from the online store.

WordPress has linear role structure, so technically this means that a role cannot have a parent role. This limitation is eliminated with the help of Role Hierarchy extension.

For example, if you want to setup a website where Editors have the ability to manage posts however Regional Editors can manage posts only in regional category, while National Editor in national category, then you can simply define a generic Editor role where Regional Editor and National Editor inherit all access settings from parent Editor. From here you can customize only want is needed for a specific sub-role.

For more information about Role Hierarchy extension, please refer to the AAM Role Hierarchy page.

E-Commerce is the premium extension that can be purchased from the online store.

Start monetizing access to your website content with the help of E-Commerce extension. This extension gives you the ability to sell access to your website content with online merchants like Stripe and Braintree (PayPal company).

For more information about E-Commerce extension, please refer to the AAM E-Commerce page.

Multisite is the free AAM extension.

The Multisite extension allows you to manage access to all your sites from one centralized Network Panel. It has few convenient ways to switch between sites as well as sync access settings across all sites.

For more information about Multisite extension, please refer to the AAM and WordPress Multisite support article.

User Activities is the free AAM extension. It is also quite experimental and limited. There is a long list of TODO items that are currently on my backlog list of things.

User Activities extension tracks basic activities that users perform on the WordPress website. It is also very flexible extension and with some additional configuration you can literally track anything as long as there is a way to hook into a process with WordPress core hooks.

For more information about User Activities extension, please refer to the How to track any WordPres user activity article.

Social Login is the free AAM extension and current it is still an alpha version.

Allow your visitors to login to your website with social networks like Facebook, Twitter, LinkedIn or Google. This extension adds few icons under the WordPress login form that allows visitor to choose the way to login to your website.

For more information about Social Login extension, please refer to the How does AAM Social Login works article.

Complete Package is the bundle of premium extension that can be purchase from the online store.

Get the complete list of all premium extensions in one package. All future premium extensions will be included in the bundle for no additional cost.

For more information about Complete Package, please refer to the AAM Complete Package page.

AAM Development Package is the subscription plan for complete bundle of premium AAM extensions that can be purchase from the online store.

All the premium AAM extension are valid for one live domain only however this the Development Package you can install complete list of AAM extensions on unlimited number of websites as long as you keep annual subscription active.

For more information about Development Package, please refer to the AAM Development Package page.

There is no such a thing as “perfect plugin”. No matter how simple or complex functionality is, somewhere and for somebody it will not work as expected. A lot of times it has nothing to do with the plugin itself but rather misunderstanding of the features it offers or it is impacted by other plugin, or unusual website setup. That is why I firmly believe that quality of the plugin is not defined by how it was built, but how it is supported.

Please do not hesitate to use AAM Forum as soon as you start experiencing troubles, however consider to check How to troubleshoot AAM article.