System Filters

This page documents filters for plugin options, filesystem access, and settings REST permissions.

Filter	Description
unblock/defaults/options	Default plugin options
unblock/filesystem	Filesystem access control
unblock/settings/can_read	Read permission for the settings REST endpoint
unblock/settings/can_write	Write permission for the settings REST endpoint

defaults/options

Modify default plugin option values before they are merged with saved options.

Parameter	Type	Description
$defaults	array	Default options

Example: Set Default Value

add_filter( 'unblock/defaults/options', function( $defaults ) {

    $defaults['my_option'] = 'custom_value';

    return $defaults;

} );

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;

} );

settings/can_read

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

Parameter	Type	Description
$allowed	bool	Whether the current user can read settings
$request	WP_REST_Request	The REST request

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

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.

settings/can_write

Filter the write permission for the unblock/v1/settings REST endpoint. Writes mutate the global selectors, variables, and at-rules registries.

Parameter	Type	Description
$allowed	bool	Whether the current user can write settings
$request	WP_REST_Request	The REST request

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

Example: Grant Write Access to Editors

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

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

    return $allowed;

}, 10, 2 );

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: 'settings' }). That check inspects the REST OPTIONS Allow header, which reflects this filter — so granting write access here automatically reveals the corresponding UI.

Next steps

• Data filters — providers, meta, and expression extensions
• Assets filters — CSS inlining threshold