For developers: providers, REST API & React component

The User Access UI is powered by an open-source library, wpb-access-control — an extensible, per-resource access-control system that any WordPress plugin can embed. If you build on the AcrossAI stack, here’s what it gives you.

Checking access in PHP

One call answers the whole question:

$allowed = $manager->user_has_access(
    get_current_user_id(), // 0 = not logged in
    'my-namespace',        // your plugin’s namespace
    'my-resource'          // the specific resource key
);

Built-in & custom providers

Each dropdown option is a provider. Five ship in the box — wp_role, wp_user, wp_capability, bb_profile_type, mepr_membership. You can add your own by extending AbstractProvider and registering it through the plugin’s provider filter; if it exposes options, the React UI renders checkboxes for it automatically. Every provider also has ..._options and ..._has_access filters for fine-tuning.

REST API & React component

• REST API — manage rules from any client under wpb-ac/v1/{pluginSlug}/… (nonce-protected).
• React component — drop <AccessControl> (or a #wpb-access-control div) into an admin page and it wires itself to the REST API; props include pluginSlug, namespace, resourceKey, title, description and an onSave callback.
• Per-plugin isolation — each consumer gets its own database table, cache group and REST routes via a table slug, so two plugins on one site never collide.

Source & docs: the library lives at github.com/WPBoilerplate/wpb-access-control and its own database table (managed by BerlinDB) is created automatically on activation.