Block installs itself in 'other'
Permalink Browser Info Environment
Our company uses Block Designer in Concrete5.8 and we use version control through Subversion/SVN.
I have a testsite where I've created a block and I set it to be part of the 'Basic' block type set.
But on the live version of this site (which is a SVN checkout of the same repository) the block installed itself as part of the 'Other' block type.
Why is that?
How can we set this block to be part of the 'Basic' set?
NB: Our testsite has Blockdesigner as a package, but our Live site doesn't, because we don't want customers to be able to change blocks.
I have a testsite where I've created a block and I set it to be part of the 'Basic' block type set.
But on the live version of this site (which is a SVN checkout of the same repository) the block installed itself as part of the 'Other' block type.
Why is that?
How can we set this block to be part of the 'Basic' set?
NB: Our testsite has Blockdesigner as a package, but our Live site doesn't, because we don't want customers to be able to change blocks.
Type: | Discussion |
---|---|
Status: | Resolved |
Thanks,
but this may be a bug?: I made numerous multiple blocks in the testsite, and they all installed perfectly in the correct interface categories, no problem there.
The Live site has all those initial blocks in 'basic' just like I picked originally from within Blockdesigner.
But Now that I've added a new block, aftyer SVN version update, this one doesn't seem to get into the right place - perhaps because the Live site doesn't have Blockdesigner as a package?
but this may be a bug?: I made numerous multiple blocks in the testsite, and they all installed perfectly in the correct interface categories, no problem there.
The Live site has all those initial blocks in 'basic' just like I picked originally from within Blockdesigner.
But Now that I've added a new block, aftyer SVN version update, this one doesn't seem to get into the right place - perhaps because the Live site doesn't have Blockdesigner as a package?
Uhm.. shouldn't make a difference. Perhaps take a look if the variable is set in the controller and if so, what the value is. And then check if a set with that handle does exist. If a block is installed and the set can not be found, they will be automatically go into "Other". So it may be values are set that are not available. Then it goes into "Other". So not sure what is happening here. Shouldn't matter at all if Block Designer is available or not.
We did somethig else: a change in the database of the Live site.
There we added entries in the BlockTypeSetBlockTypes - and set their ID's to Basic (1) id.
There we added entries in the BlockTypeSetBlockTypes - and set their ID's to Basic (1) id.
That's an option too if you're comfortable with adding (or changing) database entries! For block types created in the future, you can use the field in the form upon creating the block. That should normally work.
Kind regards,
Ramon
Kind regards,
Ramon
Under the "Interface" tab upon creating a block within Block Designer, you see a "Default block type set" field. In there, you can enter the handle of the set it should install into. By default, everything will go into "Other" if you don't enter anything in there. If you want to have them in "basics", you enter that in there. Because other Add-Ons can make block type sets and you can do too, it's not a "simple select".
You can also open up your controller.php file of the Block Type and look for this:
protected $btDefaultSet = 'your_set';
If the variable ($btDefaultSet) does not exist, you can add it (and change 'your_set' to whatever handle your set has - 'basics' in your example).
Kind regards,
Ramon