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 week 19 min ago by (stpaultim) in How-To and Troubleshooting
Posted 1 week 1 day ago by (stpaultim) in Weekly Meetings
Posted 1 week 2 days ago by (NormPlum) in Other
Posted 1 week 3 days ago by (NumerousHats) in How-To and Troubleshooting
Posted 1 week 3 days ago by (gwolf) in Other
Recent comments
Tried and successfully applied DrAlbany's method with the form https://www.drupal.org/sandbox/grobot/2105379stickman hook. I also encountered the same situation. Thanks DrAlbany
Ubercart - Auto increment SKU
Since before migration you need to prepare the Drupal site - disabling and removing all modules, disabling themes, as part of the preparation you can clear the cache and logs, delete the search...
Trimming the size of my database for D2B_migrate not to error out (Request Entity Too Large / 504 Gateway Time-out)
QuickTabs is now available!!! But does not work as expected, already reported (https://github.com/backdrop-contrib/quicktabs/issues/14). Maybe an alternative solution using Views...
Quick Tabs (or method to simulate)
Great, I just accessed the report here: https://github.com/backdrop-contrib/quicktabs/issues/14 geometry dash
Quick Tabs (or method to simulate)
SKU = Stock Control Unit... meaning an easy way to identify stock... Depending on the type of stock item you have, would dictate the SKU. So, for example, in the IT industry,...
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.