Saving blocks does not work in SilverStripe 3.1.16 about silverstripe-blocks HOT 2 CLOSED

I think the only explanation for this is that at some point you must have been using a slightly old version of the blocks module that still had the "Name" DB field. Otherwise SilverStripe would not be trying to write to that table column. Perhaps your blocks module was also updated when updating framework/cms composer dependencies? Or a dev/build was required? I can't see any reason why this error would occur on 3.1 so will close for now.

from silverstripe-blocks.

Just for record to this old issue: Now when I returned to the project where I use this module, I spent a few hours scratching my head with this (as I don't like to solve it by upgrading SilverStripe before I find out the real cause behind a bug in order to prevent it in the future).

All code was correct and my version of the blocks module was not outdated. Instead, the problem was in the database structure. I checked the structure and saw the old Name column in the Block table. I removed the column from the table, tried saving again a new Block in the CMS, and ran into the same error message again, but this time with a different column name. So I proceeded to remove columns one by one until the saving started to work.

These are the columns I removed: Name, Header, Content, Link, VideoURL, Template and Active

So my conclusion is that your module works flawlessly, but there is a bug in the Versioned class (and I guess they fixed it in SS 3.2). Any column that existed in the Block table were used in the INSERT INTO Block_versions query without first ensuring that the column actually exist in Block_versions too. As those columns did not exist, the saving process failed.

So anybody still using SS 3.1 can run into this problem by first installing an old version of this module and then upgrading the module to the current version. The upgraded module itself does nothing bad, it just abandons columns and implements a support for Versioned, which naturally will not create the obsolete columns into the Block_versions table. Problem solved :).

Thank you @sheadawson for pointing me to the right direction! :)

from silverstripe-blocks.