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?
Weekly office hours
Bring your questions to our weekly virtual office hours, every Wednesday. Everyone is welcome.
Recent topics
Posted 2 weeks 1 day ago by Francis Greaves (themetman) in How-To and Troubleshooting
Posted 3 weeks 7 hours ago by Francis Greaves (themetman) in How-To and Troubleshooting
Posted 1 month 24 min ago by (izmeez) in How-To and Troubleshooting
Posted 1 month 1 day ago by (izmeez) in How-To and Troubleshooting
Posted 1 month 1 day ago by (ian) in How-To and Troubleshooting
Recent comments
well @herb I cannot believe it, but the webform module was there in modules on the disc, but missing in the listed modules, so I delete the module folder, and downloaded it again. Then...
My Webform Worksheets have disappeared
The only thing I can think of is to make sure Webform module is enabled and that the content type that needs to contain the webforms has Webform enabled for it. Edit the content type and make...
My Webform Worksheets have disappeared
@yorkshirepudding, In the end I fixed it by deleting the config/active folder contents, copying the config/staging/ files into config/active, importing the database again and clearing the caches...
Importing the staged config throws an error: another field with the same name already exists
Thanks, I have to go out now, I will try later on and report back
Importing the staged config throws an error: another field with the same name already exists
Hi Francis. Yes, what config do you have in staging for it? You might have configs like: field.field.field_video_embed field.instance.node.page....
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.