Documentation suggests that the File-based configuration workflow is usable - and various references suggest using it - including settings.php itself.
However, it is broken, because modules / themes are not actually installed when enabled using this workflow, as config-import is not (and cannot) be run (because there is no config to import - it's already there, on disk). This means that although modules are enabled in config, they their hook_schema() and hook_install() hooks are not run, and chaos ensues.
simple_sitemapdrush -y updb; drush cr;
Module should be enabled, schema present and install hooks run.
Drupal admin UI records module as enabled.
drush pm-list records module as not installed.
Database schema is missing from db.
drush pm-uninstall modulename (which removes the config entries from disk)
drush en modulename
drush config-refresh command which compares the current file config with a previous snapshot, and runs equivalent steps from _drush_config_import() - in particular ConfigImporter->processExtensions()
It's a pity to lose file-based config - because these workflows (not using the database at all for config locally) are brilliant for development, and cut down on potential config-export/import mistakes - as well as clearly exposing what's changing.
Comments
Comment #2
greg boggsWhen you use file-based configuration management, you must still import the configuration from the sync folder to the active folder so that it's used. I don't see that step in your above notes.
Yes, it would be an ideal workflow (and the workflow that WordPress has) to be able to use file-based configuration without the extra import step. But, the current implementation requires the import step even with file-based configuration storage because the import step is what creates the database tables.
Essentially, the current implementation gives you is the ability to automatically export configuration on form save. Ideally, additional code could be written to make importing unneeded, but that code doesn't exist as far as I know.
Comment #3
schnitzel commentedI think they actually overwrites the files in "CONFIG_ACTIVE_DIRECTORY", which in my understanding makes sense if you switch to the File system based workflow, because without being able to overwrite the "CONFIG_ACTIVE_DIRECTORY" directory directly what does the "File system based workflow" bring you compared to the Database Workflow?
Comment #4
greg boggsCurrently, what file-based configuration gets you is that configuration is automatically exported on form save.
This means that "drush cex" is an unneeded step that happens automatically. When site building with database workflow, you have to type this hundreds of times to build a site, and it's never quite clear if it's been run. So, it's a nice win that prevents you from losing work.
In an ideal world, one could go without "drush cim" as well which would be a huge win. But, for that, someone would have to move the database schema creation code from config import into the configuration verification step.
Comment #5
SimonPhillips commentedAha!
Thanks, I hadn't appreciated the difference between active and sync. Schnitzel is absolutely right - we'd adopted this workflow precisely to avoid our developers needing to drush cex and drush cim - and clearly it would be a great end goal to solve this properly with it handled in config validation as you say.
I have amended the documentation (and title of this issue) to make this clear.
Comment #6
mcrittenden commentedComment #7
greg boggsSince this thread is awake again, The key step in file-based workflow is to make sure that you *do not* use the same folder for sync and active. They *must* be two different folders. And, you must import and export between those two folders. If you do that, everything works as designed.
If you want to automate this without needing to run drush commands, use config suite: https://www.drupal.org/project/config_suite
When I get some time, I'll add an error check to config suite to warn you when you have used the same sync/active folder.
Comment #11
quietone commented#2 pointed out the solution and it was confirmed in #5. So, there is no bug here, it is actually a support request and one that was resolved 5 years ago.
Thanks
Comment #12
greg boggsFor clarity, this issue is won't fix. The import step is still required and it's even more important now than it was 5 years ago.