System Filters

This page documents filters for filesystem access and the permission gates of the editor.

Every permission filter receives a single boolean and is also exposed as a PHP helper (unbk_css_can_write(), unbk_library_can_use(), …) you can call from your own code. The AI assistant has its own gates: see ai/chat/can_use and ai/mcp/can_use.

Filter	Description
unblock/filesystem	Filesystem access control
unblock/css/can_read	Read permission for the global CSS
unblock/css/can_write	Write permission for the global CSS
unblock/settings/can_write	Write permission for the plugin settings
unblock/library/can_use	Browse and insert library patterns
unblock/library/can_manage	Create, edit and delete libraries and patterns

filesystem

Control whether the plugin can write to the filesystem. Unblock uses WP_Filesystem to generate asset files (CSS, JS) and write debug logs. When disabled, assets are inlined instead and log files are not created.

Disable this on hosting environments that block filesystem writes (e.g., read-only containers, restricted shared hosting).

Parameter	Type	Description
$enabled	bool	Whether filesystem is enabled

Default: true

Example: Disable on Restricted Hosting

add_filter( 'unblock/filesystem', function( $enabled ) {

    if ( defined( 'DISALLOW_FILE_MODS' ) && DISALLOW_FILE_MODS ) {
        return false;
    }

    return $enabled;

} );

css/can_read

Filter the read permission for the global CSS. The unblock/v1/css REST endpoint exposes selectors, variables, and at-rules to the block editor.

Parameter	Type	Description
$allowed	bool	Whether the current user can read CSS

Default: current_user_can( 'edit_posts' ) — calibrated on the minimum capability required to enter the block editor.

Helper: unbk_css_can_read()

You probably don't need this filter

Restricting read access below the default breaks the block editor preview for excluded roles — selectors, variables, and at-rules silently fail to load, and blocks render without their custom styles with no error message.

The public front-end is unaffected: rendering happens server-side from the stored options, not via REST.

This filter is provided for symmetry with can_write and for niche multi-tenant scenarios. In most cases, leave it untouched.

css/can_write

Filter the write permission for the global CSS. Writes mutate the global selectors, variables, and at-rules registries.

Parameter	Type	Description
$allowed	bool	Whether the current user can write CSS

Default: current_user_can( 'manage_options' ) — admin only.

Helper: unbk_css_can_write()

Example: Grant Write Access to Editors

add_filter( 'unblock/css/can_write', function( $allowed ) {

    if ( current_user_can( 'edit_others_posts' ) ) {
        return true;
    }

    return $allowed;

} );

Editor UI follows the filter

The block editor's management surfaces (selector creation, inline rename, visual style controls, font library, inspector panel, manager modal) are gated client-side via WP's native canUser('update', { kind: 'unblock', name: 'css' }). That check inspects the REST OPTIONS Allow header, which reflects this filter — so granting write access here automatically reveals the corresponding UI.

The AI assistant and the pattern library follow it too: a user without write access gets no CSS tool in the chat and inserts library patterns without their styles.

settings/can_write

Filter the write permission for the plugin settings (unblock/v1/settings REST endpoint and the Settings tab of the manager).

Parameter	Type	Description
$allowed	bool	Whether the current user can write settings
$group	string	Settings group ('admin', 'frontend'), or '' for the resource in general

Default: current_user_can( 'manage_options' ) — admin only.

Helper: unbk_settings_can_write( $group )

Example: Let Editors Change the Editor Settings Only

add_filter( 'unblock/settings/can_write', function( $allowed, $group ) {

    if ( 'admin' === $group && current_user_can( 'edit_others_posts' ) ) {
        return true;
    }

    return $allowed;

}, 10, 2 );

library/can_use

Filter whether the current user can browse and insert library patterns: the library button, the modal, and every read route.

Parameter	Type	Description
$allowed	bool	Whether the current user can use the library

Default: current_user_can( 'manage_options' ) — admin only.

Helper: unbk_library_can_use()

Example: Open the Library to Editors

add_filter( 'unblock/library/can_use', fn( $allowed ) => $allowed || current_user_can( 'edit_others_posts' ) );

Opening this gate alone inserts patterns unstyled

Inserting never requires CSS write access, so a user allowed here but refused by css/can_write inserts the blocks alone: existing selectors still link to them, and missing selectors, variables and at-rules are skipped. A pattern that brings its own classes then lands as bare markup, while the Styles badges in the detail view still count what would have been added.

Both gates default to manage_options, so this only bites once you open this one.

library/can_manage

Filter whether the current user can create, rename and delete libraries and categories, and save or delete patterns: every write route and the matching UI.

Parameter	Type	Description
$allowed	bool	Whether the current user can manage the library

Default: current_user_can( 'manage_options' ) — admin only.

Helper: unbk_library_can_manage()

Where the other library filters live

These two gates decide who uses the library. The filters that decide which libraries exist and who may pull a shared one live on the Library filters page.

Next steps

• Library filters — register a library source, authorize a shared pull
• AI filters — assistant and MCP permission gates, prompts, models
• Data filters — providers, meta, and expression extensions