Posted by brad.bulger on Tue, Feb 19, 2019 - 8:27am

I just was trying to do an update on the production version of a site, pulling the code and replacing the database with a copy of the development db. The changes were pretty extensive - new modules, fields deleted and recreated as new field types, content types added, changed, and removed, etc. I'm using the dev-active / prod-active mirror config setup - dev-active is live on dev site, prod-active on prod site.

I found I had to manually make the prod-active config directory a copy of the dev-active config before loading the new database. I was unable to import changes. It would not change the existing fields, and it kept failing during import on settings files for new modules.

Does that sound normal? I thought I remembered it not being so much trouble, but I probably never made as many changes before.

Most helpful answers

I think that's what I had to

I think that's what I had to do in the end. I haven't any similar problems since but I haven't made changes nearly as extensive, so.

Comments

Tue, Feb 19, 2019 - 2:25pm by brad.bulger

Additionally, it turned out that I had to completely delete all the config files and drop the database tables for the field that changed from a text list field to a term reference. I could not delete it through the UI, nor change its widget from a select list to checkboxes. The instance array that was given to the various field module function was missing expected information, like entity_type.

I have custom module code that modifies that field by name in displaying the node form, I wouldn't think that was relevant but I could be wrong. I don't otherwise understand what the problem was. But it was somehow related to a clash of config files.

Thu, Oct 17, 2019 - 12:18am by stpaultim

I was just trying to move the config files and database from an existing site into a new site, after running the installation process on the new site and starting with a fresh install. My plan was to use backup and migrate to import the database and then use the Backdrop UI to import the config files. 

That doesn't seem to work, I get numerous errors. 

I think in this situation where you are moving the config and database together, it's better to:

1) Simply import the database into the new site 
2) Directly replace all the config files in the active directory for the new site with copies from the active config file in the old site. 

Does this sound right? Is there a better way?

This worked for me, I just don't know if there is a better path. 

Thu, Oct 17, 2019 - 11:17am by brad.bulger

I think that's what I had to do in the end. I haven't any similar problems since but I haven't made changes nearly as extensive, so.

Mon, Oct 21, 2019 - 2:17pm by brad.bulger

Just today, I created a new field in a content type on my local site. I imported a copy of the live site database into the local installation. It gives me a fatal error saying that the table for the new field doesn't exist. But the config import option is to remove the field.

I think the problem is that I'm using the dev/prod config directory switch setup, where dev is the active directory on local and prod the active directory on the live site. So that what it sees as "incoming" on the local site are the unchanged config files from the live site. There's no provision for "make this database match the schema my current active config files describe".

Mon, Oct 21, 2019 - 3:13pm by stpaultim

We do need better documentation for moving config and databases around. 

I don't know if this is helpful, but I think I understand, why you are having the problem. If you create a new field, two things happen - the config file is generated as well as a database table.

If you do this in your local environment, you should be able to import that config file into your LIVE environment and the necessary table will be created at the same time, bringing both environments into sync. 

But, you can not import the live database into your local environment, because you will overwrite the table that has already been generated - and create a conflict with that configuration.

If you try to import config into your local site, you are trying to import the OLD config from before you create the field - so yes, it will try to delete the field instead of adding it. 

After creating the field locally, you could first import the config file for the field to your live site, which will then create the table. Once you have created the table on your live site, you should be able to import the live database into your local site without problem (unless there are other things going on).

I don't think that this has anything to do with how your config files are set up, unless you are using GIT to move your config from one location to another, in which case it might be a problem.

Tue, Oct 22, 2019 - 9:08am by brad.bulger

This matches what I saw. It sort of does relate to the config setup, in that I was able to make it work by swapping the config directory from the local site that contained the new field with the config directory from the live site that did not contain the new field. Essentially, temporarily change my local environment to match the production setup. At that point, the import of the new field config worked fine, as you say. Once the changes were imported, the config directories had the same content, so I was able to reverse the swap and restore everything to its normal state.

I do use git to manage the config files, and apart from making sure to undo the file deletions after config sync, it usually works quite nicely. Much less fiddling around than I did with the Features module - in normal circumstances, at least.