Photograu Blog

OK, Mr Pink there’s two way you can do this

1. My way: GUI tools 
2. The Highway: Command Line Drush & Git

First and foremost, remember D8 config management is set to know it’s working on the same site, only FEATURES are used to export modules to other sites.  Drupal configs look for the Universally Unique IDentifier (UUID) in the system.site configuration to match to know it’s syincing up the right junk.

 

sauce

1. Number 1:  what is the Configuration Sync Directory?
   1. It’s an import dropfolder for config files
   2. defaults to /sites/default/files/config_UNIQUEHASH
      1. has folder /sync
         1. has it own hidden its own hidden .htaccess
   3. Change location for sync directory
      1. make new directory
      2. Probably want to copy dat readme file
      3. in settings.php
         1. update $config_directories[‘sync’] variable
         2. relative to Drupal Root
2. Source

Configuration Sync Directory Setup

Setting up Git in GoDaddy..

1. D8 configuration is different, in that it is meant to capture the whole site from local>dev>stage>prod, instead of configuration changes captured in Features and encapsulated in individually importable modules, as in D7.
2. That said, Features would still be employed for exporting a chunk o code / config for use in ANOTHER site, but once  the feature is imported, it all is a part of the site and managed though the core config management
3. Configuration may be overridden on a particular environment through the $config array in a *.settings.php
4. All feature/module default configurations are stored in YAML files that are dragged around as part of the config deployment.
5. Config syncing (ie Stage>Prod) scenarios and solutions:
   1. Scenario 1: Configuration not managed at all.
   2. Scenario 2: Configuration sync directory in use, but sometimes configuration on the live site is edited: set up a local development instance, make and test your configuration changes there, export your configuration to files in your config sync directory, and finally use command-line tools like Git and Drush to deploy and import changes to the live site
   3. Scenario 3: Configuration changes are always made and tested on non-production instance(s) and then deployed to live: set up a strict workflow policy
   4. If you’re the one and only site admin and developer… learn how to use both GUI and command-line tools to manage and move your site’s configuration between instances.
   5. If you’re working on a team…