I'am a bit helpless at the moment, because my project staging workflow using project.yaml stopped working and a) I don't know why and b) have no clue if I can solve it.
Problem: Until some days ago my staging worked like that:
1.) We are 3 developers working in our office, sharing the craft db on a central mysql. Dev User files were synced using an internal dropbox. When we wanted to bring our Craft DB changes to the QS machine, we enabled projectConfig, craft wrote a project.yaml, we pushed it to our repo and the QS installation of Craft took the project yaml and imported them. This worked great.
2.) Now this stopped working. We had a couple of new globals, fields, etc. but they were not taken over to QS
3.) When I look into my database I can see the fields, globals etc. in the corresponding tables (looking good). But when I look at the config column in the info table, the settings there do not match my database. e.g. I found the same fields and fieldgroups with different UIDs duplicated in there. So I know there is something wrong here, but I do not know what. And I also know that my project.yaml is the same as my config column so maybe this is the reason, why my QS installation does not take over any recent changes to my project db structure.
So my questions are rather general: - Can this problem be solved? - Can the config column in the info be rewritten according to the real existing structure on the source Craft installation? - Can a broken Craft database in some way be repaired?
My problem is that we already have some (not too much tough) customer content in the QS system and unless I want to manually recreate the Craft installation I would definitely prefer a way of repairing it.
Thanks, Matthias
