Description
The Off Canvas Trigger block inside an Advanced Header has color and background-color settings that apply correctly in the block editor preview but are ignored on the frontend. Inline <style> rules generated by Kadence Blocks for the trigger are output in the page <head>, but the plugin's static stylesheet style-blocks-header.css is enqueued after them. Because both rule sets have equal specificity, the static stylesheet wins by cascade order and the user's settings are silently overridden.
Steps to reproduce
- Install Kadence Theme + Kadence Blocks 3.6.7 on a clean WordPress install
- Go to Kadence → Headers and create a new Advanced Header
- Add an Off Canvas Trigger block to the header
- In the block's sidebar, set Trigger Colors → Normal to a non-default value (e.g.
#ffffff)
- Optionally set a non-default background color
- Publish the header
- Enable it via Appearance → Customize → Header → Use Block Header and select the new header
- View any page on the frontend (with all caching/minification disabled to rule out interference)
Expected behaviour
The trigger icon color and background-color match the values set in the block sidebar.
Actual behaviour
The trigger renders in the default color (black) and the background-color setting is ignored entirely. The block editor preview shows the correct colors, confirming the settings save and serialize fine.
Root cause (per browser inspection)
Viewing page source on the frontend:
- The inline
<style> block containing the user's per-block rules is printed near the top of <head>.
wp-content/plugins/kadence-blocks/dist/style-blocks-header.css?ver=3.6.7 is enqueued and loaded after the inline styles.- The static stylesheet contains rules targeting the same trigger elements with equal CSS specificity.
- Per the CSS cascade, equal-specificity rules declared later win — so the static defaults override the user's settings.
The per-block customizations cannot beat the plugin's own defaults without !important or a higher-specificity selector being introduced somewhere.
Suggested fix
Any one of the following would resolve it:
- Enqueue
style-blocks-header.css early enough (e.g. via a higher priority on the wp_enqueue_scripts hook) that it loads before per-block inline styles.
- Output the per-block inline CSS via
wp_add_inline_style() attached to the kadence-blocks-header handle so WordPress automatically places it after the stylesheet.
- Increase specificity of the inline rules — e.g. prefix selectors with the block's unique wrapper class — so they beat the static defaults regardless of source order.
The second option is probably the cleanest since it's the standard WordPress pattern for this exact problem.
Workaround
Adding equivalent rules to Appearance → Customize → Additional CSS works because Customizer CSS is output later than any plugin stylesheet. This isn't an acceptable long-term solution because it requires every Kadence user to manually re-implement settings the UI claims to control.
Environment
- Kadence Blocks: 3.6.7
- Kadence Theme: 1.4.5
- WordPress: 6.9.4
- PHP: 8.4.19
- Browser tested: Chrome 147.0.7727.138
- Tested with caching/minification disabled: yes — issue persists on a request to a fresh URL with no caching layer (also reproduces with WP-Optimize Minify both enabled and disabled, confirming the minifier is not the cause)
Notes
The rules in style-blocks-header.css could be observed loading after the inline overrides on a live staging site (URL available on request if helpful for the maintainer team).
Description
The Off Canvas Trigger block inside an Advanced Header has color and background-color settings that apply correctly in the block editor preview but are ignored on the frontend. Inline
<style>rules generated by Kadence Blocks for the trigger are output in the page<head>, but the plugin's static stylesheetstyle-blocks-header.cssis enqueued after them. Because both rule sets have equal specificity, the static stylesheet wins by cascade order and the user's settings are silently overridden.Steps to reproduce
#ffffff)Expected behaviour
The trigger icon color and background-color match the values set in the block sidebar.
Actual behaviour
The trigger renders in the default color (black) and the background-color setting is ignored entirely. The block editor preview shows the correct colors, confirming the settings save and serialize fine.
Root cause (per browser inspection)
Viewing page source on the frontend:
<style>block containing the user's per-block rules is printed near the top of<head>.wp-content/plugins/kadence-blocks/dist/style-blocks-header.css?ver=3.6.7is enqueued and loaded after the inline styles.The per-block customizations cannot beat the plugin's own defaults without
!importantor a higher-specificity selector being introduced somewhere.Suggested fix
Any one of the following would resolve it:
style-blocks-header.cssearly enough (e.g. via a higher priority on thewp_enqueue_scriptshook) that it loads before per-block inline styles.wp_add_inline_style()attached to thekadence-blocks-headerhandle so WordPress automatically places it after the stylesheet.The second option is probably the cleanest since it's the standard WordPress pattern for this exact problem.
Workaround
Adding equivalent rules to Appearance → Customize → Additional CSS works because Customizer CSS is output later than any plugin stylesheet. This isn't an acceptable long-term solution because it requires every Kadence user to manually re-implement settings the UI claims to control.
Environment
Notes
The rules in
style-blocks-header.csscould be observed loading after the inline overrides on a live staging site (URL available on request if helpful for the maintainer team).