Plugin Reference

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

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

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 a free WordPress plugin that hosts on 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.

AAM is a 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.

Note! By default, AAM is allowed for any user that belongs to the WordPress standard Administrator role. If there is more than one administrator on a website, consider defining more explicitly who actually has the ability to manage access. For more information check How to manage access to AAM page for other users article.

AAM is quite a complex plugin with over 200 different features where most of the development time was spent on the creation of the intuitive and easy-to-use UI to maximize the 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 Secure Login Widget.

The “subject”, in the AAM context, is a general definition for a role, individual user, visitor, or default access to everybody. In other words, the “subject” is who you manage access to.

Each time you change subject on the Users/Roles Manager area, the Current Subject top 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 user level (typically Administrator role or users that belong to it) or to the default access for everybody. That is why be careful as you can accidentally restrict access to your user.

The blue color means that the subject has lower user level than the maximum defined. For example, in the default WordPress installation, there are 11 user levels from 0 to 10. In this case, any role or user that does not have user level 10, will be highlighted with blue.

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 Main Panel is where all the magic happens. Here you have all the necessary set of services to manage access to your website frontend, backend, and API areas.

The panel is divided into two sub-areas:

• – List of Services (aka features or tabs) like Backend Menu, Capabilities, Login Redirect etc.;
• – Control Area is the place were you actually manage access settings;

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

AAM is a 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 the following groups:

• Services – lsit of all registered AAM services that you can enabled/disable on-demand. Very useful way to optimize your website performance if you are concern about it;
• 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 (posts, pages, media, taxonomies, etc.) 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 add-ons that you can purchase in our online store. On the add-ons area you can see the list of all official AAM add-ons, learn more about them and use acquired license key to download an add-on.

The Users/Roles Manager is the place where you can manage the 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 4.0.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 noted.

By default, AAM renders the Access Manager widget on the user’s edit screen as a convenient way to manage access to a website’s resources. This way you can define all the necessary access settings to a specific user while managing his/her profile.

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

By default, every post, page or custom post type will have additional metabox added to the edit screen that allows managing access to it for any user, role, visitor or default access to everybody. This is just a convenient way to define access settings to your content without leaving the edit screen.

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

AAM comes with its own secure login widget that can be used to drop on your frontend page. It has a couple cool features that can significantly improve your website security.

The secure login functionality can be turned off by disabling the “Secure Login” service. For more information about secure login widget check How does AAM Secure Login works article.

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 possible access settings ambiguity. For example, if user Lesley has Editor and Contributor roles assigned where the 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 article.

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

At the end of the day, AAM is just a useful set of services 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 and 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, Subscriber roles and virtual role Superadmin for multisite setup. 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 are the subject of interest to developers rather than none technical users however it is beneficial to understand the concept because the majority of customization utilizes 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 probably 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 into consideration all WordPress core relationships between website resources. Under resource we 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 dollars 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 a higher user level. For example, you may want to add admin access to couple of 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.

This service can be deactivated by disabling the “User Level Filters” option.

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

With AAM 6.7.0 we officially started to include the AAM CLI command in the basic version. Prior to the 6.7.0 version, some AAM CLI commands were available with a free custom add-on.

In this section, we are covering all the official commands and more will be added depending on the users’ demand.

Install any premium AAM add-on with the obtained license key.

$ wp aam addon-install <license>
# OPTIONS

<license>
: Valid and active license key obtained from aamplugin.com store

# EXAMPLES

  wp aam addon-install AAM0000000000001

The addon-install command downloads premium addon from our official artifactory and unzip it to the plugins directory (typically /wp-content/plugins). From here you can use wp plugin commands to facilitate all other operations like activation, updates, etc.

Available with AAM 6.7.0 or higher.

Export all or a very specific subset of AAM settings.

$ wp aam export [--settings] [--roles] [--configpress] [--config] [--policies]
# OPTIONS

[--settings]
: Export all access controls (e.g. Backend Menu, Posts & Terms, Login Redirect, etc.)

[--roles]
: Export WordPress core list of roles and capabilities

[--configpress]
: Export ConfigPress configurations

[--config]
: Export AAM configurations (all the settings defined on the AAM Settings Area)

[--policies]
: Export all defined AAM access policies

# EXAMPLES

  wp aam export --roles > /tmp/aam-export.json
  wp aam export > /tmp/aam-export.json
  wp aam export --settings --policies > /tmp/aam-export.json

Note! Due to non-negotiable rules that we obey since AAM 6.0.0, AAM cli command does not write exported settings into any files. You can use a regular STDOUT to forward exported settings into given filepath (e.g. > /tmp/aam-export.json).

Available with AAM 6.7.0 or higher.

Import all or a very specific subset of AAM settings.

$ wp aam import [] [--settings] [--roles] [--configpress] [--config] [--policies]
# OPTIONS

[<payload>]
: JSON-formatted payload and if omitted, the payload is taken from STDIN

[--settings]
: Import all access controls (e.g. Backend Menu, Posts & Terms, Login Redirect, etc.)

[--roles]
: Import WordPress core list of roles and capabilities

[--configpress]
: Import ConfigPress configurations

[--config]
: Import AAM configurations (all the settings defined on the AAM Settings Area)

[--policies]
: Import all defined AAM access policies

# EXAMPLES

  wp aam import < /tmp/aam-export.json --roles
  wp aam import < /tmp/aam-export.json
  wp aam import < /tmp/aam-export.json --settings --policies

Note! Due to non-negotiable rules that we obey since AAM 6.0.0, AAM cli command does not read any files outside of its own plugin directory. You can use a regular STDIN to load settings from given filepath (e.g. < /tmp/aam-export.json).

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.

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 implements the ring-buffer approach to the list of JWT tokens that each user account can have. By default, a user may have up to 10 tokens registered and upon 11^th token registration, the first token is automatically removed.

[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 5.0.0 and is a great 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 = "+30 days"

Note! Since AAM 6.0.4 release, the authentication.jwt.expires may contain the numeric value that represents number of seconds the token is valid from the time of issueing. For more information about this change, please refer to the following forum thread.

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

Requires premium IP Check add-on 4.1.0 or higher.

The ipstack free-tier does not have included SSL encryption and all the API requests are sent via unsecure HTTP protocol. You can find more details about pricing on this page.

We anticipate that the majority of the users that need the geo-location service will start with the free tier and that is why the default protocol will be HTTP. If you upgrade your tier to at least BASIC, it is strongly encouraged to also change ipstack API protocol to https

[aam]
ipstack.schema = "http"

Requires premium IP Check add-on 4.1.0 or higher.

For debugging and testing purposes, we allow defining one static IP address so you can test your access rules. For example, when you prepare an access policy that prevents anybody outside of the European countries to access certain parts of your website, you need an easy way to emulate a different user’s IP addresses. Upon confirming that everything is working as expected, the ipstack.test.ip has to be removed or commented out.

[aam]
ipstack.test.ip = "165.72.200.11"

Requires premium IP Check add-on 4.1.0 or higher.

To optimize website performance and reduce the number of API request to the freemium geo-location ipstack service, AAM implements internal ring-buffer cache that stores, by default 200 latest responses. This way, for a user that comes from the same IP address, AAM sends only one API call to the ipstask service and caches the response in the database.

[aam]
ipstack.cache.limit = 200

Requires premium IP Check add-on 4.1.0 or higher.

License key for the freemium for the geo-location ipstack service. The service is used to determine user physical location based on the IP address. This way you can define access rules based on the user’s geographical location.

[aam]
ipstack.license = "a2910aex2sa43310963490e099a239v0"

Note! For companies that manage secrets seperately, AAM also checks for the environment variable AAM_IPSTACK_LICENSE.

Not yet documented. Sorry...

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.

Available with AAM 6.2.0 or higher.

Define what group of settings are allowed to be exported. The default value is settings,config,roles where:

• settings – all AAM access settings;
• config – all AAM settings and ConfigPress configurations;
• roles – all roles and capabilities

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

We are 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 we handled in the past several years.

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

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.

AAM comes with few additional UI elements that go beyond AAM page. To speed-up access management for administrators, additional metabox is rendered while editing posts, pages or custom post types (Post Access Manager Metabox) and on edit user screen (User Access Manager Widget). The “Render Access Manager Metabox” option disables them all.

Note! The access manager metaboxes are not rendered for users that do have access to AAM page or do not have ability to manage any of the AAM services.

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.

Requires free plugin AAM Protected Media Files 1.1.0 or higher.

The default behavior, when access is denied to any protected media file, is to return HTTP 401 Unauthorized response. This might not satisfy the needs when a user needs to be redirected to a different location. The “Invoke Access Denied Redirect” option invokes Access Denied Redirect service and redirects a user based on the settings defined on the Frontend Redirect tab.

FYI! The Backend Redirect settings are not applicable to the media files because of all the HTTP requests that serve physical files are part of the frontend area.

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.

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.

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.

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.

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.

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.

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.

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

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

If you are looking to complete hide the toolbar on the frontend for any roles or individual users, you can create a custom capability aam_show_toolbar 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 5.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, 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 lose 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 the Administrator role have access to the AAM page and features however you can change this behavior by adding the custom aam_manager capability.

This is the first-tier access capability to AAM functionality. You still need to assign additional custom capabilities to grand access to very specific features. For example aam_manage_admin_menu for the “Backend Menu” feature or aam_manage_content for the “Posts & Terms” feature.

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_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 Toolbar service.

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 service.

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

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 Access Policy. You can basically specify what capabilities can be listed, toggled, deleted or edit.

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_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 Post Access Manager Metabox on the post’s edit screen.

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 service.

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.

Not yet documented. Sorry...

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_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_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_addons.

Give the ability for user to manage Add-Ons area.

Note! If user knows license number, he/she 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_show_notifications.

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.

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 service.

Note! By creating aam_show_admin_notices capability, all the users and roles that do no thave explicitly assigned this capability, will not be able to see any admin notifications.

Manage if users can see the top admin notification like “New WP update is available…” or “Plugin XXX is not configured…”. In the example below, we enabled few plugins that show top admin notifications and if user does not have aam_show_admin_notices capability assigned, these notification will be hidden

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 aam_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 aam_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 aam_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 the “Help” tab.

The “Help” tab typically contains additional information about the current page and is more like a reference for user. The aam_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 the backend area of your website.

This is a 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 not have this capability explicitly assigned, will not be able to access Backend site of a website.

The aam_access_dashboard capability allows webmasters to completely restrict Backend area for all users and roles that do no have this capability explicitly assigned.

FYI! For more information about restricting access to the backend are, check How to lockdown WordPress backend article.

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 not have this capability explicitly assigned, will not be to see the Toolbar on the Frontend area.

The top 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 toolbar for any individual user, however this process may be time-consuming because a webmaster has to go to each user’s profile one-by-one and disable the toolbar.

As an option, you can create a custom aam_show_toolbar capability and assign it only to roles or users that toolbar can 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 the 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 a website Frontend, Backend or API levels. AAM filters out selected post from all menus or lists however it can be accessed with direct URL.

Note! Prior to AAM 5.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 HIDDEN option checked disregarding other roles that actually allow to show a post. With AAM 5.9.3 or higher this limitation has been eliminated.

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 add-on access control is also available for taxonomies and terms or you can even setup default access to any registered post type (e.g. Posts, Pages, Media etc.).

Note! Available with Plus Package add-on only.

Similar to the HIDDEN 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 HIDDEN 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 HIDDEN 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 HIDDEN 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 HIDDEN TO OTHERS and HIDDEN options are both checked, then AAM disregards HIDDEN TO OTHERS option.

Restrict access to read a post. If HIDDEN 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 add-on only.

Similar to the RESTRICTED 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 RESTRICTED TO 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 RESTRICTED 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 RESTRICTED TO 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 RESTRICTED TO OTHERS and RESTRICTED options are both checked, then AAM disregards RESTRICTED TO 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 a 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>

FYI! If you need to show also excerpt of your post/page, you can include the [excerpt] shortcode while defining the teaser message.

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 the LIMITED 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.

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 add-on is required for this feature.

Redirect the user to a different location based on the specified redirect rule when the 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. Redirect to login page. Will redirect visitor to the login page and back after successful authentication.
4. Trigger PHP callback function. Will trigger callable and valid PHP callback.

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

Available with WordPress 4.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.

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 add-on only and can be enhanced with Plus Package add-on.

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 add-on you also can manage access to hierarchical terms.

Note! Available with Plus Package add-on 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 add-on you also can manage access to hierarchical terms.

Note! Available with Plus Package add-on 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 add-on. This way you can define the default access to all posts for any user or role.

Note! Available with Plus Package add-on 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 add-on 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.

Not yet documented. Sorry...

Note! Available with Plus Package add-on 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 HIDDEN option and redefine the default category.

Note! Available with IP Check 4.0.0 add-on only.

Manage access to the content based on a user’s IP address, host a user came from or URL query parameter. A very useful feature if you need to restrict the ability for users to see your content that are coming from unwanted IP space or websites.

You have the ability to create an unlimited number of access rules that may cancel others. For example, by default, you can restrict access to all your posts for users that come from China, however, allow if referred URL contains ref=HT0012 query parameter, or even if a user is coming from mytrusteddomain.com domain.

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 defining 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 service 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 service 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 service, you can change to redirect a 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 service is available with AAM 5.3.0 or higher and allows to manage access to individual endpoints the RESTful API. 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 5.9.2 or higher and allows to manage a list of JWT tokens that are associated with the 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.

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’s main focus is on providing a reliable set of features to manage access to the WordPress resource while AAM shortcodes are just 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 contact us.

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;
– loginForm displays secure login form;
– loginRedirect can be used to display a link that navigates user to the login form and upon authentication back to the original page.

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;

Not yet documented. Sorry...

Not yet documented. Sorry...

AAM is a very flexible WordPress plugin that can be easily extended based on the business need. It already comes with several premium add-ons that you can find on the Add-Ons Area.

AAM add-ons are typical WordPress plugins and can be installed like through the “Plugins->Add New” page or manually. There are two possible ways to download an add-on when you have a valid license key.

1. From the Add-ons Area. Enter a license key on the Add-ons area and click on Download button. This should prompt your to download a ZIP archive that later you can upload on the Plugins->Add New page or via FTP

2. Download add-on from the License Page. Each license key has a dedicated License Page. If a license is still valid, you’ll be able to download a ZIP archive on that page and enter a domain that will be associated with the license.

Plus Package is the premium add-on 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 the necessary sets of tools for that.

For more information about Plus Package add-on, please refer to the Plus Package page.

IP Check is the premium add-on that can be purchased from the online store.

Manage access to your website based on a visitor’s IP address or referred host. Very useful extension if you looking to restrict access to the WordPress website for a 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 the opposite way, “blacklist” or IP addresses and referred domains and allow only a few (whitelist them).

For more information about IP Check add-on, please refer to the IP Check page.

Role Hierarchy is the premium add-on that can be purchased from the online store.

WordPress has a 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 add-on.

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 add-on, please refer to the Role Hierarchy page.

Complete Package is the bundle of premium add-ons that can be purchase from the online store.

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

For more information about Complete Package, please refer to the Complete 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.