If you are developing a package containing one or more blocks, you may have found yourself wondering why on Earth your block is not installing with the package. Your package’s controller code may be perfectly fine and no error messages are given, but yet the blocks are not installed. Furthermore, your block’s code may also be completely correct and valid. If this is the case, then you are the victim of what seems to be a very silly bug in concrete5.

Let us first ensure that your package controller’s code is correct. It should look something like the below.

public function install() {
	$pkg = parent::install();
	BlockType::installBlockTypeFromPackage('block_handle', $pkg);
}

Now the catch is that your block’s db.xml file must contain at least two fields in the block’s table. As you probably know, your block type’s table should have a column named bID. What if you do not need to store any information about your block? In that case it would seem logical to only have the bID column in the table. As it turns out, that is not an option.

For unknown reasons, there must be at least two fields in the table – even if you do not use one of them at all. While the column then seems completely redundant, it is necessary, because otherwise concrete5 will refuse to install your block. It will not give you any error message, so figuring out why your block is not installing can be a very daunting task.

The solution is simple; simply add another field to your block type’s table. It does not have to be used in any way and the name and type does not matter. The structure below would solve the problem.

<?xml version="1.0"?>
<schema version="0.3">
    <table name="btMyBlock">
        <field name="bID" type="I">
            <key />
            <unsigned />
        </field>

        <field name="dummy" type="I"></field>
    </table>
</schema>

Reinstall your package and your block should now be installed successfully and be ready for use.