The ability to manage access to your WordPress website URLs has been introduced in the AAM 5.6.0 and without Plus Package add-on is limited to manage access only to a literal URLs.
It is difficult to know upfront what exactly the website administrator may want to restrict on a WordPress website from users or visitors. AAM already does a good job managing access to the backend menu, posts & terms or API routers.
This may cover 80-90% of all possible use cases. However, to give you the complete control over all the WordPress website areas, we’ve introduced the frontend or backend areas of the WordPress website.
Note! The wildcard * match works only with Plus Package add-on and basically means that you can specify the subset of URIs that will be restricted. For example the URI /category/* restricts access to pages like /category/animals or /category/art. With the basic AAM version you can manage access only to literal URIs.
It is important to emphasize that AAM manages access to URIs with or without query ($_GET) parameters. The example of the URI without query parameters is /archive/2018. It means that when user enters this exact URI in browser (even with fake query parameters e.g. /archive/2018?f=1), access will be denied. However URI /archive/2018/01/20 is considered as completely different URI and will be not restricted. That is why it is called literal.
The example of URI with query parameters is /wp-admin/edit.php?post_type=page. This means that AAM will restrict access to the page /wp-admin/edit.php BUT only if one of the query parameters is post_type and its value is page. That is why if user enters /wp-admin/edit.php?post_type=post, AAM will not restrict access because post_type value is not equal to page; however if user enters /wp-admin/edit.php?post_type=page&p=2, access will be denied. Also, the order of query parameters is irrelevant.
Oh, you might be confused why in some instances I’m using URL while in others URI. The main difference between them is that URL is the absolute path to the website resource, while URI is relative (without HTTP schema and domain name).
Last however not least. Just restricting access to a website page is halfway job done. AAM also takes into consideration what should we do when access is denied. So basically you have the option to define how exactly to redirect the user when access is restricted.
AAM gives you 6 different options. For example, you can defining a custom HTML message, redirect to the existing page, show “Access Denied” message, or even invoke a custom callback function. All the options are self-explanatory and with no effort, you can figure out the right option for your specific needs.