{"id":316803,"date":"2026-06-16T07:29:50","date_gmt":"2026-06-16T07:29:50","guid":{"rendered":"https:\/\/wordpress.org\/plugins\/qaiyo-access-manager\/"},"modified":"2026-06-17T10:32:47","modified_gmt":"2026-06-17T10:32:47","slug":"qaiyo-access-manager","status":"publish","type":"plugin","link":"https:\/\/wordpress.org\/plugins\/qaiyo-access-manager\/","author":23510315,"comment_status":"closed","ping_status":"closed","template":"","meta":{"version":"1.1.0","stable_tag":"1.1.0","tested":"7.0","requires":"5.8","requires_php":"7.4","requires_plugins":null,"header_name":"Qaiyo Access Manager","header_author":"Qaiyo","header_description":"Extend WordPress permission management: control which plugins and custom post types each role or individual user can see and manage.","assets_banners_color":"1c2036","last_updated":"2026-06-17 10:32:47","external_support_url":"","external_repository_url":"","donate_link":"","header_plugin_uri":"https:\/\/qaiyo-plugins.com\/qaiyo-access-manager","header_author_uri":"https:\/\/qaiyo-plugins.com","rating":0,"author_block_rating":0,"active_installs":0,"downloads":102,"num_ratings":0,"support_threads":0,"support_threads_resolved":0,"author_block_count":0,"sections":["description","installation","faq","changelog"],"tags":{"1.0.0":{"tag":"1.0.0","author":"qaiyo","date":"2026-06-16 07:29:17"},"1.1.0":{"tag":"1.1.0","author":"qaiyo","date":"2026-06-17 10:32:47"}},"upgrade_notice":{"1.1.0":"<p>Important security fixes: custom post type rules now block guests, and plugin-level rules now block a restricted plugin&#039;s own admin pages. Recommended for all users.<\/p>","1.0.0":"<p>First public release of Qaiyo Access Manager.<\/p>"},"ratings":[],"assets_icons":{"icon-256x256.png":{"filename":"icon-256x256.png","revision":3579751,"resolution":"256x256","location":"assets","locale":"","width":256,"height":256}},"assets_banners":{"banner-1544x500.png":{"filename":"banner-1544x500.png","revision":3574138,"resolution":"1544x500","location":"assets","locale":"","width":1544,"height":500}},"assets_blueprints":{},"all_blocks":[],"tagged_versions":["1.0.0","1.1.0"],"block_files":[],"assets_screenshots":{"screenshot-1.png":{"filename":"screenshot-1.png","revision":3574138,"resolution":"1","location":"assets","locale":"","width":1600,"height":900},"screenshot-2.png":{"filename":"screenshot-2.png","revision":3574138,"resolution":"2","location":"assets","locale":"","width":1600,"height":900},"screenshot-3.png":{"filename":"screenshot-3.png","revision":3574138,"resolution":"3","location":"assets","locale":"","width":1600,"height":900},"screenshot-4.png":{"filename":"screenshot-4.png","revision":3574138,"resolution":"4","location":"assets","locale":"","width":1600,"height":900},"screenshot-5.png":{"filename":"screenshot-5.png","revision":3574138,"resolution":"5","location":"assets","locale":"","width":1600,"height":900}},"screenshots":{"1":"Plugin access rules per role, with Allow\/Deny mode and user-level overrides.","2":"Custom post type access control.","3":"The Access Matrix \u2014 every plugin and post type against every role.","4":"The read-only Capabilities inspector.","5":"Settings: restricted notice, login redirects, admin-bar and dashboard options.","6":"Tools: JSON import \/ export."}},"plugin_section":[262246],"plugin_tags":[1912,2007,895,1915,2461],"plugin_category":[54,58],"plugin_contributors":[267332],"plugin_business_model":[],"class_list":["post-316803","plugin","type-plugin","status-publish","hentry","plugin_section-dashboard-widgets","plugin_tags-access-control","plugin_tags-cpt","plugin_tags-permissions","plugin_tags-roles","plugin_tags-user-management","plugin_category-security-and-spam-protection","plugin_category-user-management","plugin_contributors-qaiyo","plugin_committers-qaiyo"],"banners":[],"icons":{"svg":false,"icon":"https:\/\/ps.w.org\/qaiyo-access-manager\/assets\/icon-256x256.png?rev=3579751","icon_2x":"https:\/\/ps.w.org\/qaiyo-access-manager\/assets\/icon-256x256.png?rev=3579751","generated":false},"screenshots":[{"src":"https:\/\/ps.w.org\/qaiyo-access-manager\/assets\/screenshot-1.png?rev=3574138","caption":"Plugin access rules per role, with Allow\/Deny mode and user-level overrides."},{"src":"https:\/\/ps.w.org\/qaiyo-access-manager\/assets\/screenshot-2.png?rev=3574138","caption":"Custom post type access control."},{"src":"https:\/\/ps.w.org\/qaiyo-access-manager\/assets\/screenshot-3.png?rev=3574138","caption":"The Access Matrix \u2014 every plugin and post type against every role."},{"src":"https:\/\/ps.w.org\/qaiyo-access-manager\/assets\/screenshot-4.png?rev=3574138","caption":"The read-only Capabilities inspector."},{"src":"https:\/\/ps.w.org\/qaiyo-access-manager\/assets\/screenshot-5.png?rev=3574138","caption":"Settings: restricted notice, login redirects, admin-bar and dashboard options."}],"raw_content":"<!--section=description-->\n<p>Qaiyo Access Manager extends WordPress's built-in permission system. Out of the box, WordPress only lets you assign broad roles (editor, author, contributor\u2026). This plugin lets administrators set <strong>fine-grained access rules for individual plugins and custom post types<\/strong>, at both the role level and the individual user level \u2014 without writing code or touching <code>functions.php<\/code>.<\/p>\n\n<p>Hide WooCommerce from editors, give a single freelancer access to one custom post type, stop contributors from seeing a page builder, redirect each role to its own landing page after login, or protect a block of content on the front end with a shortcode. Administrators always keep full access and can never be locked out.<\/p>\n\n<p><strong>Plugin &amp; content access<\/strong><\/p>\n\n<ul>\n<li><strong>Plugin-level access control<\/strong> \u2014 Decide which roles can see and manage each installed plugin. The plugin is hidden from the Plugins screen, its action links are removed, and its admin menu pages are removed and blocked (including direct-URL access) for restricted roles. This governs visibility and admin access; it is not a substitute for a plugin's own internal capability checks.<\/li>\n<li><strong>Custom post type access control<\/strong> \u2014 Restrict any custom post type (WooCommerce Products, ACF field groups, portfolios, events\u2026) per role, across the admin menu, list\/edit queries, single front-end views (with a configurable redirect) and the core REST API. Content types registered with their own capabilities are also enforced at the capability level, so guests and unauthorised roles are blocked, not just hidden.<\/li>\n<li><strong>Allow \/ Deny mode per rule<\/strong> \u2014 Each rule can either allow only the checked roles, or deny the checked roles and leave everyone else untouched \u2014 whichever needs fewer clicks.<\/li>\n<li><strong>User-level overrides<\/strong> \u2014 Allow or deny a specific user regardless of their role. User rules always win over role rules.<\/li>\n<li><strong>Access Matrix<\/strong> \u2014 A bird's-eye grid of every plugin and post type against every role, so you can audit your whole site at a glance.<\/li>\n<li><strong>Native capability hints<\/strong> \u2014 Next to each plugin and post type, see which roles already hold the relevant WordPress capabilities, so your rules and core roles never silently conflict.<\/li>\n<\/ul>\n\n<p><strong>Roles, login &amp; front end<\/strong><\/p>\n\n<ul>\n<li><strong>Login redirect by role<\/strong> \u2014 Send each role to its own URL right after login.<\/li>\n<li><strong>Restricted content redirect<\/strong> \u2014 Choose where logged-in users land when they open a single item of a content type they cannot access (home, 404, login or a custom URL).<\/li>\n<li><strong>Frontend protection shortcode<\/strong> \u2014 <code>[qaiyo_protect role=\"editor\" deny=\"subscriber\" logged_in=\"yes\" cap=\"edit_posts\"]\u2026[\/qaiyo_protect]<\/code> shows or hides content by role, login state or capability, with an optional replacement message.<\/li>\n<li><strong>Customizable restricted notice<\/strong> \u2014 Pick the style (info \/ warning \/ error \/ none) and text shown to restricted users, with <code>{user_name}<\/code>, <code>{site_name}<\/code> and <code>{admin_email}<\/code> placeholders.<\/li>\n<\/ul>\n\n<p><strong>Admin experience<\/strong><\/p>\n\n<ul>\n<li><strong>Capabilities inspector<\/strong> \u2014 A read-only, searchable capability \u00d7 role matrix that flags core vs plugin capabilities. It never changes your roles \u2014 it just shows you what they already hold.<\/li>\n<li><strong>Dashboard summary widget<\/strong> \u2014 A WordPress Dashboard widget showing how many plugins and post types are restricted and how many user-level overrides are active, for an at-a-glance health check.<\/li>\n<li><strong>Hide the admin bar<\/strong> \u2014 Remove the frontend toolbar for selected roles.<\/li>\n<li><strong>Hide individual admin bar items<\/strong> \u2014 Strip specific nodes from the top toolbar per role.<\/li>\n<li><strong>Hide dashboard widgets<\/strong> \u2014 Remove dashboard widgets per role.<\/li>\n<li><strong>Update permissions<\/strong> \u2014 Let non-admin roles update plugins and\/or themes without granting full administrator access (applied at runtime, fully reversible).<\/li>\n<li><strong>JSON import \/ export<\/strong> \u2014 Back up every rule to a JSON file, or migrate your whole configuration to another site.<\/li>\n<li><strong>Explore Qaiyo plugins<\/strong> \u2014 An in-admin overview of the Qaiyo plugin family, with a notice on your Qaiyo screens when a newer version of an installed Qaiyo plugin is available.<\/li>\n<\/ul>\n\n<p><strong>Built for the real world<\/strong><\/p>\n\n<ul>\n<li><strong>Administrators are protected<\/strong> \u2014 Anyone with <code>manage_options<\/code> always has full access and cannot be restricted.<\/li>\n<li><strong>AJAX save<\/strong> \u2014 Rules are saved without a page reload.<\/li>\n<li><strong>Translation ready<\/strong> \u2014 Ships with 11 languages: English, Hungarian, German, French, Spanish, Japanese, Portuguese, Italian, Russian, Turkish and Polish.<\/li>\n<li><strong>Translation-plugin compatible<\/strong> \u2014 Plays nicely with WPML, Polylang and TranslatePress; internal translation post types are excluded automatically.<\/li>\n<li><strong>WordPress standards<\/strong> \u2014 Nonce verification, capability checks, sanitized input and escaped output throughout.<\/li>\n<\/ul>\n\n<p><strong>Looking for more?<\/strong> Qaiyo Access Manager Pro adds an editable click-to-toggle matrix, rule presets, user groups, bulk actions, temporary (time-limited) access, an activity log, admin page hiding, meta box control and email notifications.<\/p>\n\n<!--section=installation-->\n<ol>\n<li>Upload the <code>qaiyo-access-manager<\/code> folder to <code>\/wp-content\/plugins\/<\/code>, or install it from the Plugins \u2192 Add New screen.<\/li>\n<li>Activate the plugin from the WordPress admin Plugins page.<\/li>\n<li>Open <strong>Access Manager<\/strong> in the admin sidebar.<\/li>\n<li>Use the Plugins and Post Types tabs to set role and user-level rules, and the Settings tab for login redirects, the restricted notice and admin-bar options.<\/li>\n<\/ol>\n\n<!--section=faq-->\n<dl>\n<dt id=\"what%20happens%20if%20no%20roles%20are%20assigned%20to%20a%20plugin%20or%20cpt%3F\"><h3>What happens if no roles are assigned to a plugin or CPT?<\/h3><\/dt>\n<dd><p>It stays accessible to everyone. Rules are opt-in: an item is only restricted once you add a rule for it.<\/p><\/dd>\n<dt id=\"can%20administrators%20be%20restricted%3F\"><h3>Can administrators be restricted?<\/h3><\/dt>\n<dd><p>No. Anyone with the <code>manage_options<\/code> capability always keeps full access, by design, so you can never lock yourself out.<\/p><\/dd>\n<dt id=\"how%20does%20the%20user-level%20override%20work%3F\"><h3>How does the user-level override work?<\/h3><\/dt>\n<dd><p>User rules take priority over role rules. A denied user cannot access the item even if their role is allowed, and an allowed user can access it even if their role is not.<\/p><\/dd>\n<dt id=\"what%20is%20the%20difference%20between%20allow%20and%20deny%20mode%3F\"><h3>What is the difference between Allow and Deny mode?<\/h3><\/dt>\n<dd><p>Allow mode means only the checked roles get access. Deny mode means the checked roles lose access and everyone else keeps it. Pick whichever is fewer clicks for your situation.<\/p><\/dd>\n<dt id=\"how%20do%20i%20protect%20content%20on%20the%20front%20end%3F\"><h3>How do I protect content on the front end?<\/h3><\/dt>\n<dd><p>Use the shortcode, for example: <code>[qaiyo_protect role=\"editor,shop_manager\"]Visible only to these roles.[\/qaiyo_protect]<\/code>. Combine the attributes <code>role<\/code> (allow list), <code>deny<\/code> (deny list), <code>logged_in<\/code> (yes\/no), <code>cap<\/code> (a capability) and <code>message<\/code> (text shown instead when the content is hidden).<\/p><\/dd>\n<dt id=\"does%20the%20capabilities%20tab%20change%20my%20roles%3F\"><h3>Does the Capabilities tab change my roles?<\/h3><\/dt>\n<dd><p>No. It is a read-only inspector. Editing capabilities is intentionally out of scope so WordPress's core role system stays untouched.<\/p><\/dd>\n<dt id=\"will%20restricting%20a%20custom%20post%20type%20also%20block%20it%20on%20the%20front%20end%20and%20in%20the%20rest%20api%3F\"><h3>Will restricting a custom post type also block it on the front end and in the REST API?<\/h3><\/dt>\n<dd><p>Yes. CPT rules are enforced across the admin menu, list and edit queries, single front-end views (with a configurable redirect), and the core (<code>\/wp\/v2\/<\/code>) REST API \u2014 and guests are blocked too, not just logged-in users. For content types registered with their own capabilities (most plugin CPTs, e.g. WooCommerce Products), the rules are additionally enforced at the WordPress capability level, which also covers custom REST controllers. Content types that share the generic post\/page capabilities are enforced through the menu, query, front-end and core REST layers rather than at the capability level, to avoid affecting unrelated content.<\/p><\/dd>\n<dt id=\"does%20plugin-level%20access%20fully%20disable%20a%20plugin%20for%20a%20role%3F\"><h3>Does plugin-level access fully disable a plugin for a role?<\/h3><\/dt>\n<dd><p>It removes the plugin from the Plugins screen and removes and blocks its admin menu pages (including direct-URL access) for the restricted roles, which stops normal use through the dashboard. It does not rewrite that plugin's own internal capabilities or its private AJAX\/REST endpoints. For a hard capability boundary around a specific plugin feature, combine plugin-level rules with the plugin's own role settings or a capability manager.<\/p><\/dd>\n<dt id=\"is%20it%20compatible%20with%20wpml%2C%20polylang%20and%20translatepress%3F\"><h3>Is it compatible with WPML, Polylang and TranslatePress?<\/h3><\/dt>\n<dd><p>Yes. The plugin excludes the internal post types used by translation plugins and does not interfere with language-based content filtering.<\/p><\/dd>\n<dt id=\"what%20happens%20when%20the%20plugin%20is%20uninstalled%3F\"><h3>What happens when the plugin is uninstalled?<\/h3><\/dt>\n<dd><p>By default your rules are preserved so they return if you reinstall. You can opt in (Settings \u2192 Tools) to delete all rules and settings on uninstall instead.<\/p><\/dd>\n\n<\/dl>\n\n<!--section=changelog-->\n<h4>1.1.0<\/h4>\n\n<ul>\n<li>Security: custom post type rules now also block logged-out visitors. Previously guests were treated as allowed, so allow-list rules did not protect single front-end views or the REST API against them.<\/li>\n<li>Security: plugin-level rules now remove and block (including direct-URL access) a restricted plugin's own admin menu pages \u2014 not just hide it from the Plugins screen. Single-file plugins are covered too.<\/li>\n<li>Hardening: CPT capability enforcement now applies only to content types with their own custom capabilities, and resolves the real post type from the target object \u2014 preventing over- or under-blocking of content types that share the core post\/page capabilities.<\/li>\n<li>Correctness: JSON payloads (rule save, import, options) are now decoded before sanitization instead of after, so multi-line and special characters are preserved.<\/li>\n<li>UX: added a clear security warning to the plugin\/theme update-permissions setting.<\/li>\n<li>Performance: cached admin-menu ownership resolution and bulk-loaded override users to avoid per-row queries.<\/li>\n<li>Docs: corrected developer-hook names (qaiyo_access_manager_* prefix) and clarified the scope of plugin- and CPT-level access.<\/li>\n<\/ul>\n\n<h4>1.0.0<\/h4>\n\n<ul>\n<li>Initial release.<\/li>\n<li>Plugin-level access control per role.<\/li>\n<li>Custom post type access control per role (wp-admin, front end and REST API).<\/li>\n<li>Allow \/ Deny mode for every rule.<\/li>\n<li>User-level overrides (allow\/deny per user), taking priority over role rules.<\/li>\n<li>Access Matrix overview of every plugin and post type against every role.<\/li>\n<li>Read-only Capabilities inspector (core vs plugin capabilities flagged).<\/li>\n<li>Native capability hints shown next to each plugin and post type.<\/li>\n<li>Dashboard summary widget (restricted plugins \/ post types \/ active user overrides).<\/li>\n<li><code>[qaiyo_protect]<\/code> frontend content protection shortcode (role \/ deny \/ logged_in \/ cap \/ message).<\/li>\n<li>Login redirect by role.<\/li>\n<li>Restricted content frontend redirect (home \/ 404 \/ login \/ custom URL).<\/li>\n<li>Customizable restricted-access notice (style + text with placeholders).<\/li>\n<li>Hide the frontend admin bar, individual admin bar items and dashboard widgets per role.<\/li>\n<li>Plugin \/ theme update permissions for non-admin roles (runtime, reversible).<\/li>\n<li>JSON import \/ export of all rules.<\/li>\n<li>\"Explore Qaiyo plugins\" overview with update notices for installed Qaiyo plugins.<\/li>\n<li>11 bundled languages: English, Hungarian, German, French, Spanish, Japanese, Portuguese, Italian, Russian, Turkish, Polish.<\/li>\n<li>Compatible with WPML, Polylang and TranslatePress.<\/li>\n<\/ul>","raw_excerpt":"Control which plugins and post types each role or user can access, with allow\/deny rules, per-user overrides and a frontend shortcode.","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin\/316803","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin"}],"about":[{"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/types\/plugin"}],"replies":[{"embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/comments?post=316803"}],"author":[{"embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wporg\/v1\/users\/qaiyo"}],"wp:attachment":[{"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/media?parent=316803"}],"wp:term":[{"taxonomy":"plugin_section","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_section?post=316803"},{"taxonomy":"plugin_tags","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_tags?post=316803"},{"taxonomy":"plugin_category","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_category?post=316803"},{"taxonomy":"plugin_contributors","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_contributors?post=316803"},{"taxonomy":"plugin_business_model","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_business_model?post=316803"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}