You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are scenarios where the plugin can leave the project config in a state that prevents importing into another site.
It seems that if, for example, a matrix block type gets deleted, the corresponding labels in the project config do not get removed, even though the field layouts no longer exist.
This leaves the project config in a state, where if you apply it to a different environment, a DB error will be thrown because of non-nullable columns.
Thanks for reporting that, I'll of course fix it but Relabel doesn't even work for fields in a matrix. I don't reference fields that are in the field layout of matrix block types so I'm a little bit confused why deleting them should be a thing.
What I mean is: there are no corresponding labels for a matrix block type.
My bad, my then-context was just debugging a poject.yml file with a bunch of Matrix stuff. The same argument applies for a deleted entry-type, though where the field layout would get nuked.
Also, I'm not very smart when writing things on GitHub, so I should have clarified that it would not be the most common stumbling block for Relabel.
There are scenarios where the plugin can leave the project config in a state that prevents importing into another site.
It seems that if, for example, a matrix block type gets deleted, the corresponding labels in the project config do not get removed, even though the field layouts no longer exist.
This leaves the project config in a state, where if you apply it to a different environment, a DB error will be thrown because of non-nullable columns.
The easiest way to hotfix this is to check if any of these calls return null, and, if so, skipping the (re)label.
The text was updated successfully, but these errors were encountered: