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.

Type: Discussion
Status: Resolved
View Replies:
ramonleenders replied on at Permalink Reply
Hi there,

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,

jiropii replied on at Permalink Reply
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?
ramonleenders replied on at Permalink Reply
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.
jiropii replied on at Permalink Reply
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.
ramonleenders replied on at Permalink Reply
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,


concrete5 Environment Information

Concrete 5.8.1

Browser User-Agent String

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36

Hide Post Content

This will replace the post content with the message: "Content has been removed by an Administrator"

Hide Content

Request Refund

You have not specified a license for this support ticket. You must have a valid license assigned to a support ticket to request a refund.