Browser: Chrome 110
OS: macOS
URL: N/A
Video: N/A
Hi Bricks team,
I’m reporting a separate component-import issue that I encountered while working around the already acknowledged Manage import permission bug.
I understand that the permission issue has been reproduced and added to your task tracker. This post is not another report of that same issue.
For context, Execute Code is enabled for both my individual user and the Administrator user role, but affected bundles still encounter the permission error. That is the only reason I switched to importing through the Components panel.
Unfortunately, that alternative import route appears to silently change component property data types.
What happens
The component JSON supplied for import contains proper boolean values:
"default": true,
"multiple": false,
"replace": true
However, the saved component definitions on the destination contain strings:
"default": "true",
"multiple": "false",
"replace": "true"
The import reports success, but some component controls no longer work correctly.
Concrete example: visibility toggles stop working
One component has a Hide color overlay toggle that defaults to enabled.
After importing through the Components panel, switching that toggle off does not reveal the overlay in either the builder or frontend.
Investigation found that the builder’s checkbox inversion logic uses:
true === this.instanceProperty?.default
The imported string "true" fails this comparison. This interferes with the handling that should save the native "off" value when disabling a true-default toggle.
Consequently, a toggle can appear disabled while the element remains hidden.
Apparent cause
In the installed Bricks 2.4.2 code, the Components-panel importer submits the parsed component data as nested form fields to bricks_upgrade_components.
The PHP handler reads $_POST['components'] and returns the component data without restoring the original boolean types. This appears to be where the conversion occurs.
Scope and verification
Comparing the source and destination component libraries found:
- Source: no mistyped values among 1,370 checked boolean property fields across 67 components.
- Destination: 429 mistyped fields across 18 components.
The audit covered toggle defaults and the multiple/replace property flags.
For comparison, a scoped component ZIP that could successfully pass through Manage → Import / Export preserved the proper boolean types. The overlay’s show/hide behavior then passed builder and frontend testing on the source site.
Expected behavior
Component imports should preserve JSON data types, and successful imports should not silently change how component properties behave.
Could you investigate this separately from the existing Manage permission issue? Together, these issues leave us with a blocked import route and an alternative route that can silently break component settings.
Also, what repair approach would you recommend for already affected components while preserving their IDs, existing instances, and instance overrides?
I can provide affected component exports and reproduction details privately.