{content block="some value with whitespaces"} Problem
Posted: Fri Sep 10, 2010 2:10 pm
Hello there,
i just noticed a strange behavior when whitespaces are in the param "block".
I personally never use whitespaces in that param since it should be more handled like a varname instead of a label (IMHO).
But other users might do that.
The CMSms core replaces whitespaces in the param "block" by underscores before saving the block in the database.
So when using this in the template:
{content block="some value with whitespaces"}
the content of that block will be stored in the content_props table with propname "some_value_with_whitespaces".
When showing the block in the frontend the {content} tag also replaces the whitespaces of the param "block" by underscores and then gets the content of that block. That means it looks for a content property named "some_value_with_whitespaces".
Also the {content_image} tag does.
Everything fine.
When creating the GBFilePicker module that supports the {content_module} tag i realised some issues of the core.
1st: All blocks that uses whitespaces in the param "block" are stored twice in the db.
One of propname with replaced whitespaces and correct content
and one of propname with witespaces but without content.
2nd: The {content_module} tag passes the param "block" without replacing whitespaces.
So modules will create input fields with name and id attributes that may contain whitespaces
what is not good. They need to replace the whitespaces again.
This is no big problem but just something that can be avoided.
3rd: The {content_module} tag does not replace the whitespaces in frontend anyway.
It trys to get a content property that is named exactly like it was entered in the param "block".
That means it searches for "some value with whitespaces".
But this cannot be found or an empty value is stored.
Solution atm is to never use whitespaces in param block.
To label your blocks use the param "label".
i just noticed a strange behavior when whitespaces are in the param "block".
I personally never use whitespaces in that param since it should be more handled like a varname instead of a label (IMHO).
But other users might do that.
The CMSms core replaces whitespaces in the param "block" by underscores before saving the block in the database.
So when using this in the template:
{content block="some value with whitespaces"}
the content of that block will be stored in the content_props table with propname "some_value_with_whitespaces".
When showing the block in the frontend the {content} tag also replaces the whitespaces of the param "block" by underscores and then gets the content of that block. That means it looks for a content property named "some_value_with_whitespaces".
Also the {content_image} tag does.
Everything fine.
When creating the GBFilePicker module that supports the {content_module} tag i realised some issues of the core.
1st: All blocks that uses whitespaces in the param "block" are stored twice in the db.
One of propname with replaced whitespaces and correct content
and one of propname with witespaces but without content.
2nd: The {content_module} tag passes the param "block" without replacing whitespaces.
So modules will create input fields with name and id attributes that may contain whitespaces
what is not good. They need to replace the whitespaces again.
This is no big problem but just something that can be avoided.
3rd: The {content_module} tag does not replace the whitespaces in frontend anyway.
It trys to get a content property that is named exactly like it was entered in the param "block".
That means it searches for "some value with whitespaces".
But this cannot be found or an empty value is stored.
Solution atm is to never use whitespaces in param block.
To label your blocks use the param "label".