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.
Currently AAM 5 or higher is stable and reliable tool that works perfectly fine with brand new WordPress installation. 9 out of 10 support requests that I’ve received are related to lack of good understanding of how AAM features work and typically I reply with a reference to one of articles in the Help section.
In rare occasions, users report issues that are very specific to their’s website setup or actually bugs in the AAM plugins. These types of requests I treat with extra attention and typically, with user’s cooperation, issues get resolved them within hours. That is why please do not be surprised if I’ll ask your website admin or even FTP credentials to trace down an issue.
Below you can find the list of the most common support requests grouped by the AAM features. Please at least glance through them before considering to send me a message when something is not working as expected.
The most common issue with backend menu access management is that user is not able to restrict access to some very specific menu item because it is not listed. This is due to the fact that some plugins do not follow the WordPress development standards and introduce dynamic capabilities that are assigned to user only. The good example of such plugins are Gravity Forms and Contact Form 7. That is why you will be not able to manage access to those plugins for roles. It is possible only for individual user. For more information about this subject, please check How to manage WordPress backend menu article.
Metaboxes and Widgets
There are two possible issues that you might experience. The first one is that AAM fails to initialize the list of metaboxes and widgets. This is 100% guarantee if your website does not allow to perform HTTP requests to itself. In order for AAM to initialize the list, it has to visit each page of your website to collect metaboxes and widgets. That is why if your website does not have ability to send HTTP request (typically with cURL, websocket etc.) your list will remain uninitialized. In this case you would have to contact your hosting provider and clarify why this is the case.
Another issue is when you do not see metabox or widget that is needed to be restricted. This is very common to conditional metaboxes and widgets when they are displayed only if some conditions are met. For example you will not be able to see Post Revisions metabox if it is a new post. In this case use Init URL button on the top right corner.
Please note! AAM does not have ability to restrict access to the specific parts of metaboxes and widgets. You either can show or hide the whole metabox or widget. It also does not have any ability to make them “read-only”.
Post & Terms
Access management to the WordPress posts, pages, custom post type and hierarchical taxonomies is the core concept behind AAM plugin. That is why you can find many different ways to manage access to them. Based on my experience supporting thousands of customers, I know that less than 3% of all requests related to posts and pages access management are bugs, rest is misunderstanding of how WordPress core and AAM work.
If you are not able to restrict access to some post, page or custom post type, there are few reasons for that. The most common is caching. A lot of sites have installed all kinds of caching plugins or even server cache like Memcache. Make sure that cache is cleared each time you finished making changes to Posts & Pages settings.
Sometimes there are “special kind of pages”. For example, blog archive page or WooCommerce shopping/product pages. This types of pages are treated internally by WordPress core as “archive page” and technically are collections of posts or custom post types. That is why it is not possible to manage access to them.
Finally if you feel like nothing is working as expected, it is most likely you are missing something in your settings. Check How to manage WordPress post and category access article to learn more about this topic. Additionally you can check our collection of videos on the Youtube channel.
Access to WordPress media assets was always very tricky and challenging part for AAM plugin or any other similar plugins. It is coming from the fact that all physical media assets are stored in the sub directory of the site which makes them easily accessible with direct URL. Additionally the core WordPress functionality that is related to media file handling is so broad and complex that it is really hard to follow the logic which lead to many unpredictable scenarios depending on the website setup. On our end we treat any support request that is associated with media access with extra attention and more than happy to help you out upon request.
However if you are not able to restrict access to your files, please make sure that you carefully followed the instructions in the How to manage WordPress media access article. A lot of times, our clients simply missed on of the important steps.
If you still can’t figure out the solution, then please do not hesitate to contact me.