Use case:

  1. Developer create a content type Article with field 'image', 'tags' and 'body' in his dev environment.
  2. Developer export the configuration.
  3. Developer import the configuration into the production site.
  4. Developer remove the field image from the a content type Article dev environment.
  5. Developer export the configuration.
  6. Developer import the configuration into the production site.

At the end we have, in the Staging Area a Configuration of node.field_image.article but this file is not in the DataStore because it was removed in the step 5.

At difference of features module, we are currently able to see when a config file was deleted. The main issue is, what to do, should we provide a config-remove-missing command? Or this should be done automatically after the config-import.

Also, there is another issue. For example, if user make a backup of a Content Type of the production server, this configuration will be available in the staging area, but not in the DataStore, and in this case, the config shouldn't be removed.

Maybe a posible solution is to play with different values for the status of the configs in the Staging Area.

Comments

dragonwize’s picture

dragonwize CreditAttribution: dragonwize commented

I may not understand the proposed issues you are describing but let me try.

At the end of the day what is in files should never matter. The config is owned by the site which means that it is in the activestore(database) and that is all that matters.

The files are only to save that config to disk so that it can be committed to source code to transfer to another environment or downloaded to copy to a different site. But once that is done, the system doesn't care because it always uses the activestore.

dagmar’s picture

dagmar
Primary language Spanish
Location Argentina
CreditAttribution: dagmar commented
Title: [META] Define what to do when Config Files are removed » [META] Define how to delete Configurations

I see. I think the issue title is wrong. What we should discuss is how to 'remove' configurations

johnnydarkko’s picture

johnnydarkko CreditAttribution: johnnydarkko commented

Given the case above, is this the proper way to handle removing fields for now?

  1. Delete the field.node.field_image.article.inc file on dev
  2. Remove field from article node type on dev
  3. Delete the field.node.field_image.article.inc file on production
  4. Remove field from article node type on production

Is the eventual goal to remove field.node.field_image.article.inc on prod and have it automagically remove the field on production?

johnnydarkko’s picture

johnnydarkko CreditAttribution: johnnydarkko commented
Issue summary: View changes

Updated issue summary.

Daniel Wentsch’s picture

Daniel Wentsch CreditAttribution: Daniel Wentsch commented
Issue summary: View changes

I'm looking for an answer to the exact same problem. E.g. when deploying a content type from dev to production I wonder how to deal with removed fields.

GDrupal’s picture

GDrupal CreditAttribution: GDrupal commented

@Daniel Wentsch we are still missing a path to deal with this in the configuration workflow. If it helps what we are doing in other projects it's to create a hook_update dealing with the removing of the fields, and since the deploys in most cases run a db update then a "config sync / import" it's all in good shape.

Daniel Wentsch’s picture

Daniel Wentsch CreditAttribution: Daniel Wentsch commented

Hi and thanks for answering.
I know hook_update only from writing modules to mess around with db records on install.

So do I get you right that your write a module that implements hook_update and keep that module up to date with database changes?

Or don't you use the Fields UI (for examle) at all and define all your configuration within modules? So can I compare that workflow to writing migrations in Rails?

Would be glad to hear about how other people deal with that issue.

Cheers,
Daniel

Daniel Wentsch’s picture

Daniel Wentsch CreditAttribution: Daniel Wentsch commented

For anybody asking him/herself the same question as I did in #6, here's a very helpful article on writing your own deloyment modules which implement hook_update_N to keep track of configuration changes: http://befused.com/drupal/site-deployment-module

Which brings me to the next question: based on which criteria do I decide, which changes to track with hook_update_N and what to track with Configuration Management?

ivansf’s picture

ivansf CreditAttribution: ivansf commented

This is a very important topic and the module is lacking in there. In simple terms, the module should see which fields were removed in the configuration file and delete the field and instances of it accordingly. It sounds easier than it is.

A hook_update could do a lot of this but if it all stays in configuration management it would be much better.

bisonbleu’s picture

bisonbleu CreditAttribution: bisonbleu commented
Related issues: +#2486099: Deleted field in Site-A is not deleted in Site-B after migration...

I have the same issue.

I'm using the Migrate workflow (tab) to quickly test new dev configurations in production.

But unlike @GDrupal's use case in #5 which rightly assumes a DB update, there is no database update in the Migrate workflow: fields deleted in Site-A remain in Site-B after importing the configuration tar file.

For this reason alone, it would definitely make sense to find an appropriate way of dealing with deleted fields.