fix(bricks): use official bricks/builder/color_palette filter for color injection - #92
Merged
jackgranatowski merged 4 commits intoMay 25, 2026
Conversation
…or injection The previous option_bricks_color_palette filter only fires when WordPress reads the DB option directly; Bricks fires its own bricks/builder/color_palette filter when assembling the builder color picker, bypassing get_option. Colors were never appearing in the builder because the wrong hook was used. The option_* filters are kept as fallbacks for REST/import/older Bricks paths.
…olor_palette
The bricks/builder/color_palette filter expects a flat array of {hex, rgb?}
objects (per Bricks Academy docs), not the {id, name, colors:[]} palette-group
shape used by the option. The previous fix wired the wrong callback to the
filter, so nothing appeared in the builder color picker.
Added inject_builder_colors() with the correct flat structure, using
var(--sf-color-*) references so swatches track the live theme via CSS
variable resolution in the editor iframe.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
✅ Files skipped from review due to trivial changes (3)
📝 WalkthroughWalkthroughAdds a new plugins_loaded initializer (slashed_bricks_data_init) that conditionally instantiates Bricks data managers (variables, classes, colors) early; slashed_bricks_init() is simplified to perform late enqueue/CSS setup. Class docblocks for the Bricks integrations are updated to document Bricks option-read timing and the managed/virtual inject-on-read / strip-on-save lifecycle. ChangesBricks integration bootstrap and docs
Sequence DiagramsequenceDiagram
participant WordPress
participant Slashed_Bricks_Data_Init
participant Slashed_Bricks_Variables
participant Slashed_Bricks_Classes
participant Slashed_Bricks_Colors
participant Slashed_Bricks_Init
participant Slashed_Bricks_Enqueue
WordPress->>Slashed_Bricks_Data_Init: plugins_loaded (priority 20)
Slashed_Bricks_Data_Init->>Slashed_Bricks_Variables: instantiate Variables manager
Slashed_Bricks_Data_Init->>Slashed_Bricks_Classes: instantiate Classes manager
Slashed_Bricks_Data_Init->>Slashed_Bricks_Colors: instantiate Colors manager
WordPress->>Slashed_Bricks_Init: after_setup_theme
Slashed_Bricks_Init->>Slashed_Bricks_Enqueue: instantiate Enqueue (late)
🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…p_theme
Root cause: Bricks' Database::__construct() reads bricks_global_variables,
bricks_global_classes, and bricks_color_palette via get_option() during theme
functions.php load — which happens AFTER plugins_loaded but BEFORE
after_setup_theme. Our option filters were registered in after_setup_theme,
so Bricks had already read and internally cached the options before our filters
were ever in place. Nothing appeared in any of the three managers.
Fix: split initialization into two phases.
- plugins_loaded (priority 20): instantiate Variables, Classes, Colors so their
option filters are registered before the theme loads and Bricks reads options.
- after_setup_theme: instantiate Enqueue only (needs theme + Bricks version check).
Also removes the bricks/builder/color_palette flat-swatch hook added in the
previous two commits. That filter cannot assign names to injected colors per
Bricks' own docs ("id and name are generated after it is applied"), making it
unsuitable for Color Manager integration. Named palette groups via the option
filter are the correct mechanism and now fire at the right time.
get_option('template') returns false when the option is absent; casting to
string and using strtolower() makes the Bricks check robust against missing
options and any case variation in the theme directory name.
jackgranatowski
deleted the
claude/bricks-auto-load-framework-assets-3STxk
branch
May 31, 2026 18:00
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The previous option_bricks_color_palette filter only fires when WordPress
reads the DB option directly; Bricks fires its own bricks/builder/color_palette
filter when assembling the builder color picker, bypassing get_option.
Colors were never appearing in the builder because the wrong hook was used.
The option_* filters are kept as fallbacks for REST/import/older Bricks paths.
Summary by CodeRabbit