## Summary
Bricks 2.3.7 fails to generate CSS for certain global classes due to an **array index misalignment** in the `generate_global_classes()` method. The root cause is that the `bricks_global_classes` option array contains a non-class entry at index 0 (`variables` and `categories`), which causes `array_column()` to skip it and return incorrect indices. Subsequent `array_search()` calls return wrong indices, leading to CSS generation using the wrong class settings or skipping classes entirely.
-–
## Environment
| Item | Value |
|------|-------|
| Bricks Version | 2.3.7 (latest) |
| WordPress | 7.0 |
| PHP | 8.4.21 |
| Theme | Bricks Child Theme 1.1 |
-–
## Steps to Reproduce
1. Create multiple global classes in Bricks with different style settings
2. Apply these classes to various elements on a page
3. Save the page and view the frontend
4. Inspect the generated CSS (in `<style id="bricks-frontend-inline-inline-css">`)
5. Observe that some classes have CSS rules while others do not, despite having settings defined
-–
## Root Cause Analysis
### The Bug Location
**File:** `wp-content/themes/bricks/includes/assets.php`
**Method:** `Assets::generate_global_classes()`
**Lines:** ~1063-1066
### The Problematic Code
```php
$global_classes = Database::$global_data[‘globalClasses’];
// …
foreach ( self::$global_classes_elements as $global_class_id => $element_names ) {
$global_class_index = array_search( $global_class_id, array_column( $global_classes, 'id' ) );
$global_class = ! empty( $global_classes\[ $global_class_index \] ) ? $global_classes\[ $global_class_index \] : false;
if ( ! $global_class ) {
continue;
}
*// ...*
}
```
### Why It Fails
The `bricks_global_classes` option is stored as a numerically-indexed array where:
- **Index 0** contains `[‘variables’ => […], ‘categories’ => […]]` (NOT a class definition)
- **Index 1+** contain actual class definitions with `id`, `name`, `settings`, etc.
When `array_column($global_classes, ‘id’)` is called:
1. Index 0 has no `id` key → **skipped by array_column**
2. All subsequent entries are shifted up by one position
3. `array_search()` returns an index that is **1 less than the actual array index**
4. The wrong class definition is retrieved
### Example
```php
// Actual database structure:
$global_classes = [
0 => \['variables' => \[...\], 'categories' => \[...\]\], *// No 'id' key*
1 => \['id' => 'gjrnud', 'name' => 'c-hero-v1__ttl', 'settings' => \[...\]\],
2 => \['id' => 'hfgzrq', 'name' => 'c-hero-v1__l-inner', 'settings' => \[...\]\],
3 => \['id' => 'pihzes', 'name' => 'c-hero-v1__l-wrap', 'settings' => \[...\]\],
];
// array_column result (index 0 is skipped):
// [0 => ‘gjrnud’, 1 => ‘hfgzrq’, 2 => ‘pihzes’]
// When searching for ‘pihzes’:
$index = array_search(‘pihzes’, array_column($global_classes, ‘id’));
// Returns: 2 (WRONG - should be 3)
$global_class = $global_classes[2];
// Returns: c-hero-v1__l-inner (WRONG - should be c-hero-v1__l-wrap)
```
### Impact
- **Classes with empty settings** get matched to the wrong class definition, resulting in no CSS output
- **Classes with mismatched controls** (e.g., accordion-nested class with button controls) fail to generate CSS because the retrieved settings don’t match the element type
- The bug affects approximately **21 out of 93 global classes** on a typical site
-–
## Evidence
### Database Inspection
```php
$global_classes = get_option(‘bricks_global_classes’);
// Index 0 is NOT a class
echo $global_classes[0];
// [‘variables’ => […], ‘categories’ => […]]
// Actual classes start at index 1
echo $global_classes[1][‘name’];
// “c-hero-v1__ttl”
```
### Frontend CSS Verification
- Total custom classes in HTML: **93**
- Classes with CSS rules generated: **73**
- Classes missing CSS rules: **21**
The 21 missing classes all correspond to entries where the index misalignment causes either:
1. Wrong class settings to be used (control mismatch → no CSS)
2. Empty settings to be retrieved (no CSS generated)
-–
## Suggested Fix
### Option 1: Filter out non-class entries before array_column
```php
$global_classes = Database::$global_data[‘globalClasses’];
// Filter to only entries that have an ‘id’ key (actual classes)
$class_entries = array_filter($global_classes, function($item) {
return is_array($item) && isset($item\['id'\]);
});
// Re-index the array
$class_entries = array_values($class_entries);
// Now array_column will have correct indices
$global_class_index = array_search($global_class_id, array_column($class_entries, ‘id’));
$global_class = ! empty($class_entries[$global_class_index]) ? $class_entries[$global_class_index] : false;
```
### Option 2: Use a lookup array with ID as key
```php
$global_classes = Database::$global_data[‘globalClasses’];
// Build a lookup array: id => class_data
$classes_by_id = [];
foreach ($global_classes as $class_data) {
if (is_array($class_data) && isset($class_data\['id'\])) {
$classes_by_id\[$class_data\['id'\]\] = $class_data;
}
}
// Direct lookup instead of array_search
$global_class = $classes_by_id[$global_class_id] ?? false;
```
### Option 3: Fix the data storage
Ensure that `bricks_global_classes` only stores actual class definitions, and move `variables`/`categories` to a separate option key.
-–
## Additional Notes
- This bug is **not visible in the Bricks editor** because the editor uses a different code path to retrieve class settings
- The bug only affects **frontend CSS generation**
- Clearing CSS cache does not fix the issue because the root cause is in the data retrieval logic
- The bug affects **all sites** where `bricks_global_classes` has the mixed structure with `variables`/`categories` at index 0
-–
## Attachments
- [ ] Screenshot of database showing index 0 structure
- [ ] Screenshot of frontend showing missing CSS for specific classes
- [ ] Minimal reproduction steps
-–
## Contact
Site: https://yiwnkxyo6n.onrocket.site
Bricks Version: 2.3.7
Report Date: 2026-06-12