Serendipity Forums

I just wondered to see Bulletproof using boolean vars as string.
Is there is anything bad setting $template_option vars to real booleans?

Timbalu wrote:I just wondered to see Bulletproof using boolean vars as string.
Is there is anything bad setting $template_option vars to real booleans?

Huh? There are two template options which are strings – addthisaccount and sidenav_sidebar_title. What do you mean?

YL

No I dont mean strings. I really meant the booleans. Just as an example: there are lots of them.
Type is set to boolean, but it's value is set to 'true', which is a string. If you need to check this value in the tpls, you have to check {if $template_option.footercategories == 'true'}. A real boolean could be checked by {if $template_option.footercategories}. I wondered why this was kind of necessary or overseen all the years.
Btw., the option table stores them as they are by value, booleans like 1/, strings as 'true/false'.

Timbalu wrote:I wondered why this was kind of necessary or overseen all the years.

I remember these originally being strings and us switching them to boolean to save some … erm … bytes? I wasn't even aware that this was the wrong usage of the boolean type, so it was probably a combination of us now knowing better and the "real" coders not checking on us.

Can you give us a code example of how it's properly to be used in config.inc.php and .tpl files?

YL

Thats easy..., do not use quotes in case of booleans Boolean true is 1, false is not set, so smarty can handle {if $foo} same as {if $foo === true}, {if !$foo} same as {if $foo === false}, but not {if $foo == 'true'} any more.
I dont think bulletproof needs to be changed because of that, I only noticed this by my own template, based on BP. Maybe its just worth to know for future versions.

Timbalu wrote:Maybe its just worth to know for future versions.

Yes, that's what I was thinking about – future template rather than versions. Thanks for clearing it up.

YL

I'm nearly certain {if $template_option.footercategories} works too.

Timbalu wrote:Btw., the option table stores them as they are by value, booleans like 1/, strings as 'true/false'.

Back to start! I am sorry to say, this is not true (seeing only the template_config array). I now discovered booleans are set there to true or false as text. And as the template_loaded_config array, which is build by the option table values, is the one assigning those vars (somewhere) to smarty, these vars are strings in our templates, which is different to core or plugin assigned vars mostly carrying real booleans.

Garvin, is there a way to proceed with real booleans here, like get the template_loaded_config array parsed by the serendipity_db_bool() function, or have I to revert my changes?

Hi!

I thought that there should be a handler that converted boolean types using serendipity_db_bool() for template variables as well, just for plugin variables. I haven't checked, but if that is not the case, the core code should be changed to use serendipity_db_bool() on those conf items that have 'boolean' set as their type.

Regard,s
Garvin

The type boolean is not available, since we are talking about the serendipity_loadThemeOptions() returning the option table $template_vars array. As a very hacky workaround I did this. Hopefully it can be done better.

There still is the issue with the delay (of another reload) - even in this case - between $template_config (the real configs array) and $template_loaded_config (the options table array), which is bad to be left. This only produces confusion by none advanced users until they learned to submit twice.

This will break theme compatibility, so we need some sort of $bc_bool=false mode as function parameter.
If we do not have this, bulletproof and all other themes using == 'true/false' will not work as they did before.