Two related bugs with Bricks Builder integration

Bug 1: Cache scan crashes with 500 when _cssGlobalClasses is a string

Endpoint: /wp-json/windpress/v1/admin/settings/cache/providers/scan

Error:

array_map(): Argument #2 ($array) must be of type array, string given

Location: src/Integration/Bricks/Compile.php → transform_meta_value()

Root cause: Bricks sometimes stores _cssGlobalClasses as a plain string (e.g., "nturjc") instead of an array (["nturjc"]) in post meta. This happens when pasting HTML or importing templates. transform_meta_value() calls array_map() on this field without type checking.

Fix:

if (array_key_exists('_cssGlobalClasses', $node['settings'])) {
    $classes = $node['settings']['_cssGlobalClasses'];
    if (is_string($classes)) {
        $classes = [$classes];
    }
    if (is_array($classes)) {
        $meta_value[$key]['settings']['_cssGlobalClasses'] = array_map(
            fn($class) => array_key_exists($class, $this->global_classes_index)
                ? $this->global_classes_index[$class]
                : $class,
            $classes
        );
    }
}

Important: Only _cssGlobalClasses should be cast to array. _cssClasses is a string by design in Bricks — do NOT wrap it in an array or the Bricks editor canvas will render empty (elements exist in the structure panel but nothing shows on canvas).

Bug 2: Bricks global class names are not scanned for Tailwind classes

Scenario: In Bricks, users create global classes with Tailwind utility names (e.g., a global class named bg-gray-950/90). These classes are stored in bricks_global_classes option and referenced by ID in each element's _cssGlobalClasses.

What happens during scan:

1. transform_meta_value() replaces the global class ID (e.g., upjzfr) with the class name (e.g., bg-gray-950/90)
2. But it puts this name back into _cssGlobalClasses property of the node settings
3. The WindPress scanner/oxide-parser extracts Tailwind classes from the content of each node, not from the _cssGlobalClasses property values
4. Result: the Tailwind class bg-gray-950/90 is never sent to the compiler, so it's missing from the generated CSS cache

Impact: Any Tailwind class used as a Bricks global class name works in the editor (Play CDN mode) but is missing in the frontend cached CSS. This is a very common workflow — Bricks users routinely name global classes with Tailwind utilities.

Workaround (mu-plugin): We registered an additional cache provider that extracts all global class names and feeds them to WindPress as scannable content:

add_filter('f!windpress/core/cache:compile.providers', function($providers) {
    $providers[] = [
        'id' => 'bricks-global-classes-names',
        'name' => 'Bricks Global Class Names',
        'description' => 'Extracts Tailwind classes from Bricks global class names',
        'callback' => function($metadata) {
            if (!defined('BRICKS_VERSION')) return ['metadata' => ['next_batch' => false], 'contents' => []];
            $global_classes = get_option(BRICKS_DB_GLOBAL_CLASSES, []);
            $class_names = [];
            foreach ($global_classes as $gc) {
                if (!empty($gc['name'])) {
                    $class_names[] = $gc['name'];
                }
            }
            return [
                'metadata' => ['next_batch' => false, 'total_batches' => false],
                'contents' => [
                    ['name' => 'bricks_global_class_names',
                     'content' => '<div class="' . esc_attr(implode(' ', $class_names)) . '"></div>']
                ]
            ];
        },
        'enabled' => true,
        'type' => 'custom',
    ];
    return $providers;
}, 20);

Suggested proper fix: In Compile.php, after transform_meta_value() replaces the global class IDs with names, also include these names as scannable class strings in the output content, so the Tailwind compiler picks them up.

Environment

• WordPress 6.9.4
• PHP 8.3.6
• Bricks Builder (latest)
• WindPress 3.3.78
• Ubuntu 24.04 / Plesk