**Environment**
- WordPress 7.0 (happened as well with 6.9.4)
- Bricks Builder 2.3.5
- Meta Box 5.12.0
- Meta Box AIO 3.7.1 (includes MB Settings Page)
**Description**
I've been tearing my hair out for the past few days
I have a Settings Page (slug: reglages-generaux-site) with a radio field (sub_header_display_radio) with two options: show and hide.
The value is correctly stored in the database as a serialized string — confirmed via direct SQL query:
SELECT option_value FROM wp_options WHERE option_name = 'reglages-generaux-site'
→ "sub_header_display_radio";s:8:"show" (or "hide" depending of the settings)
**The problem**
get_option( 'reglages-generaux-site' ) and rwmb_meta() both return the correct value ("show" or "hide") inside the **Bricks Builder editor**, but on the **front-end** (logged out or logged in as a non-admin), both consistently return string(1) "1" regardless of the actual saved value.
This issue only affects boolean-type fields (switch, checkbox, radio). All other field types on the same settings page return correct values on the front-end.
**Steps to reproduce**
1. Create a Settings Page with a radio field (two options)
2. Save a value from the settings page admin UI
3. Read the value with get_option() or rwmb_meta() on the front-end
4. The returned value is "1" instead of the actual option key
**Expected behavior**
get_option() and rwmb_meta() should return the saved option key ("show" or "hide") consistently in all contexts.
**Actual behavior**
- In Bricks editor: returns correct value ("show" / "hide")
- On front-end: always returns "1"
**Additional note**
A direct SQL query bypassing all WordPress filters confirms the correct value is in the database. This suggests a WordPress filter (option_reglages-generaux-site or similar) may be transforming the value specifically in the front-end context, but I have not been able to identify its origin.
.
