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?
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.
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.
I'm also now getting a 403 when trying to access admin/reports/updates - it seems to be Backdrop generated but there is nothing in the Recent Log messages other than my login as admin...
Since this is still possibly Cloudflare related I'll post here:
I'm now experiencing what I think is caching issue - since installing Bee I've run bee cc all, bee cron, bee mm 1, then,...
My thanks to you both... I understand now that Bee is not a module but a stand alone utility.
I've installed it and see that it is similar to Drush which I have used before. I'll now...
@ian Let's try to stay on the rails here. As the project page, https://backdropcms.org/project/bee, says: "Bee is a command line utility for Backdrop CMS." It is equivalent to drush. It is not...
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.