Now that we’ve got the form template working for adding the block type, let’s try saving it and see what happens. I’ll upload a custom image into the file manager, check the checkbox and provide a custom page header.
Now click Add.
This is promising. We’re getting the proper view template (which, remember, said “Hello World” like the other templates), and we’re not seeing any errors. Let’s check the database:
Also good. We have a row in the btDreamrsPageHeader title with the block ID of the block that we added, and our custom data (the file ID of the background image, the custom page header title, and the boolean overridePageName.)
There is one little snag, however. If we uncheck the checkbox and save the block, our changes to this setting won’t take effect. Why? Because our the value of the overridePageName field won’t be within the POST request, and so Concrete CMS won’t even attempt to update the column. Let’s fix this by subclassing the save() method of the block controller, and handling this specific case:
public function save($data)
{
$data['overridePageName'] = !empty($data['overridePageName']) ? 1 : 0;
return parent::save($data);
}
That should fix that problem. Now when you uncheck overridePageName your changes will save properly, because the falsy 0 value will still be contained in the request.
This is great -- we have the block saving and it we didn’t have to write much custom code for it! That’s one of the best parts about Concrete custom block type development; if your blocks are reasonably simple, you won’t have to implement a save() method in the block controller at all. The POST request is inspected and, if your fields match variables in the post request, they will be saved automatically.