It looks like Deploy has not been ported. Does the file-based config mean that people just copy the database and uploaded files to the same folder when the time comes to move staged content live?
Recent topics
Posted 18 hours 21 min ago by (Matt75) in How-To and Troubleshooting
Posted 2 days 14 hours ago by (rt-9988) in How-To and Troubleshooting
Posted 3 days 22 min ago by (dd123) in How-To and Troubleshooting
Posted 5 days 15 hours ago by (Coffee70) in How-To and Troubleshooting
Posted 6 days 4 hours ago by (willowf) in How-To and Troubleshooting
Recent comments
Hi I added the 2 additional settings in settings.php, did a restart - and the error disappeared! Thanks for the support! (but the issues with the conversion still remain .....
Problem with utf8mb4 Format when importing database
With JQuery, simple and fast. Or put all possible links in one menu, and hide unnecessary with CSS mediaquery.
Different primary menus depending on the viewport size?
I wonder if what is happening here is the default database settings are for utf8mb4 if the database server supports it. In settings.php or settings.local.php if that's where you put your...
Problem with utf8mb4 Format when importing database
I've not done this with a menu before but something similar with different Views presentation blocks for different resolutions (i.e. not just responsive but a different presentation method...
Different primary menus depending on the viewport size?
Thank you for all your help. In the meantime I just edited the export db-file and removed the top line with the sandbox comment. --> Still the same issue. I exported also with the...
Comments
There are different ways the config can be handled, but one of the simplest is to export the config via the UI on staging and import via the UI on live.
Or copy the config_*/active files on staging to config_*/staging on live. Then sync in the UI.
There's a long discussion here on various approaches https://github.com/backdrop/backdrop-issues/issues/855.
Content is a different issue. If you don't need to save anything on live just replace everything.
In theory, you face the same issues with Backdrop CMS that you would with Drupal 7 in terms of deploying content from test to live. I've always heard, that neither system was built with this in mind. There is a built-in assumption that you are creating content in your live environment.
To get around this limitation in Drupal 7, people have come up with many work-arounds or solutions. The Deploy module is new to me. I've used the Node Export module before. I've also told clients that if they want to stage content on 'test' they need to not make any changes on 'production' site during this time and then we simply push the entire database from 'test' to 'production.'
I wonder if you might also use something like the Feeds module for this (not a very user friendly solution). But, there is a version of the Feeds module for Backdrop CMS.
If you provide more information about your workflow and/or your need for a content staging area, we might be able to provide more suggestions. I suspect that until now, most Backdrop CMS users tend to create content directly on their production sites.
I believe that one of the new features that is coming soon (or already exists) to Drupal 8 is the ability to stage content directly on your production site. On your production site, you will have two versions of content, the actual live content and a draft version of the entire site. I don't know that anything like that is in the works for Backdrop yet.
Config management in Backdrop means that we have taken most configuration out of the database and can deploy configuration directly from staging to production through the UI and commit config to git. Backdrop CMS stores configuration in JSON files. But, there are some limitations on that.