Hi,

We've just taken on a Silverstripe 3.2 website, so finding our feet with some fairly basic CMS development tweaks.

We added a simple checkbox to an existing form using the following methods:

• Added CheckboxField::create('IsGuestBlogger','Guest Blogger'), to existing $fields->addFieldsToTab() call
  
• Added a tinyint(1) field into the relevant mysql database field
  
• Relaoaded the form, checked the checkbox and saved ... new field's data was not saved
  
• Realised we needed to add 'IsGuestBlogger' => 'Boolean', to private static $db array()
  
• Checked the box, saved the form, data not saved
  
• Read somewhere about running domain.com/build?flush=1, so tried that
  
• Check the box, saved the form, all forms disappear and can't load anything from the CMS menu
  
• Refresh the browser page and all forms come back
  
• Navigate to the page we're working on to see the new checkbox field data has been saved
  

So, we've added a field and the data is getting saved, but totally broken the CMS. Can someone explain where we are going wrong?

Thanks,

Paul.

[edited: to correct 'public static $db array()' to 'private static $db array()']

Looks like all I was doing wrong was using domain.com/build?flush=1 rather than domain.com/dev/build

Also now understand that flush=1 can be used on any URL to flush the cache, has nothing to do with db rebuild.

Unless it was a typo, "public static $db" ought to be a private static. This has been the case since SilverStripe 3.1. The site and form may work if the database already has the fields (it sounds like you manually added the field in mysql directly), but future edits of $db and other config variables won't be picked up. See https://docs.silverstripe.org/en/3.4/developer_guides/configuration/configuration/ and https://docs.silverstripe.org/en/3.4/changelogs/3.1.0/#upgrading

Thanks for the response Fred :)

Yeah, that was a typo/mistake, I was using 'private static' and have amended the previous post to reflect that.

Realise now that SilverStripe builds the database from the $db arrays so will not be touching the database schema directly from now on.

Thanks, Paul.