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 1 day 4 hours ago by Dominique (In Info Veritas) in Requests and Feedback
Posted 3 days 16 hours ago by (echo) in How-To and Troubleshooting
Posted 3 days 18 hours ago by (leeksoup) in How-To and Troubleshooting
Posted 3 days 20 hours ago by (colbyat) in How-To and Troubleshooting
Posted 4 days 18 hours ago by Dragon Drop (drop) in Weekly Meetings
Recent comments
Slight improvement to @argiepiano's procedure. Again for PR 4690, it would be: Using shell access, go to the Backdrop doc root. Run this command to get the diff file...
Workflow for core update with fixes that are not yet in core
This issue is seeing some progress, but there are some questions that might benefit from a UX discussion. https://github.com/backdrop/backdrop-issues/issues/2894
Apr 18th Weekly Meetings
Related from D7 - User picture is deleted after calls to user_save()
Editing user profile, results in user picture disappearing
Here is a topic for the next Design/UX meeting. Just needs a little discussion to push it along. https://github.com/backdrop/backdrop-issues/issues/4961 I need feedback on this one...
Apr 18th Weekly Meetings
@argiepiano, thanks for the procedure. I actually meant that I needed to update Backdrop because my site is still at 1.27.0 and 1.27.1 has been released. And then I wanted to add 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.