Hi!
When I need to read a true or false in my condition I need to use a String input with | json_encode to make it read the actual boolean value. Is there a reason why there is not a dedicated Boolean type in the dynamic input selector that lets you select True or False?
Hey @100leiden,
The absence of a dedicated Boolean type in the Cornerstone/Pro Condition selector is primarily due to the Unified Input System and the flexibility required for Dynamic Content.
Here are the specific reasons why it currently works this way:
The “Value” field in conditions is designed as a polymorphic text input. This allows it to serve multiple purposes:
{{dc:post:id}}.If this field were converted into a dedicated Boolean Toggle (True/False switch), it would become technically difficult to allow the injection of Dynamic Content strings into that same field. Keeping it a text input ensures you can always use Dynamic Content on both sides of the equation.
json_encode is the Current SolutionWhen you use | json_encode, you are forcing the Dynamic Content to return the literal string "true" or "false". Since the UI input is also a string, "true" === "true" evaluates correctly.
You might notice there is a dedicated Number type. This exists because numbers can be safely normalized using floatval() before compariso.
Booleans are harder to normalize automatically because values like "0", "false", "", and null can all be interpreted differently depending on the context, leading to potential “false positives” in your logic.
Hey Christian!
Thanks for the explanation. It makes sense now.
It somehow felt a bit off when I use raw boolean values inside the parameter json and the need to convert it to string before comparing. What is your advice in this situation? Should I keep the raw boolean values inside the parameters of my component, or should I start with a string “true”/“false” from the start to avoid using | json_encode in the conditions?
Hey @100leiden,
I’d recommend to keep the raw boolean values because while it requires that extra step in the Condition UI, sticking with raw booleans is the better architectural choice for several reasons. Here is the advice on why you should stay the course and how to make it feel less “off”:
If you define your parameters using raw booleans (e.g., true or false), Cornerstone automatically maps them to the Toggle control in the Inspector.
"true"/"false"): The Inspector might default to a text input or a dropdown. To get a toggle, you would have to manually configure the control and possibly add logic to map those strings back to a “checked” state, which adds more complexity than it saves.Keeping values as booleans makes your component’s JSON data “Type Correct.” If Themeco ever updates the Condition engine to include a native Boolean selector, your components will be ready for it immediately. If you use strings, you’ll have “stale” data types that don’t match the logic they represent.
If the | json_encode syntax feels too verbose, an alternative is to use 1 and 0 as your raw values in the JSON.
{{dc:p:my_bool}} is 1). This is often cleaner to read.If you find yourself doing a lot of boolean comparisons, you can use a filter to make the Condition more readable. Instead of json_encode, you can do:
{{dc:p:is_active ? 'active' : 'hidden'}}
Then your condition becomes:
String -> {{dc:p:is_active ? 'active' : 'hidden'}} -> is -> active.
This often feels more “semantic” and easier to read when looking at a long list of conditions.
Hope that helps.
Thanks for the deep dive.
I think keeping it raw and using json_encode will work perfectly for now.
Do you think its possible to add a checkbox inside the condition/dynamic UI selector that auto adds | json_encode automatically? Because typing it everytime seems to waste time and frustration and also my team/company is not aware of that function, they can work with the UI, but when something like | json_encode is needed to output the raw values it needs an “expert” action. I also use it to show what is inside my looper array to avoid just seeing “Array”. So in some cases it’s needed to type it many times a day.
What you do think?
Hey @100leiden,
Yes, a checkbox (represented as a “Toggle” switch in Cornerstone) is absolutely possible to add but with custom coding which we’ll provide some guidance but we cannot provide further support. In Cornerstone’s UI system, checkboxes are registered using the 'type' => 'toggle' control.
By adding a toggle control with the key 'json' to your dynamic content fields, a clean on/off switch will appear in the builder UI. When checked, it automatically appends json="true" to the dynamic content tag (e.g., {{dc:param:my_param json="true"}}).
To make this work seamlessly, you register the toggle control in the UI and add a small backend filter to process it:
The UI Toggle Control (PHP Filter):
add_filter( 'cs_dynamic_content_ui', function( $ui ) {
$json_toggle = array(
'key' => 'json',
'type' => 'toggle',
'label' => __( 'Output as JSON', 'cornerstone' ),
'default' => false,
);
foreach ( $ui['fields'] as $key => $field ) {
$ui['fields'][$key]['controls'][] = $json_toggle;
}
return $ui;
});
The Backend Processor (PHP Filter):
add_filter( 'cs_dynamic_content_string_result', function( $result, $args ) {
if ( ! empty( $args['json'] ) && $args['json'] === 'true' ) {
return json_encode( $result );
}
return $result;
}, 10, 2 );
Implementing the above will theoretically allow your team to simply turn on an “Output as JSON” switch in the UI, completely eliminating the need to manually type | json_encode or work with raw text filters.
Please just note that we cannot provide further support for this or any issues resulting from the use of custom codes. For this, we recommend our One service.
You are amazing!
I will pick this up and see where it takes me.
Thank you very much!
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.