Bugfix/16087 singles and entry types

[i-just]

Description

Issue 1:
When saving a single section where the entry types were changed, the existing entry was deleted, and a new one was created in its place and disabled.

This happened if you had one entry type assigned to your single and replaced it with another entry type, and also if you had a single with two entry types, the entry was created for the first entry type on that list, you then removed that first entry type and saved the section. In both of those scenarios, the old single entry would be deleted, along with its content and a new one (with a different ID) would be created and set as disabled.

Solution:
When ensuring a single entry, if we can’t find the entry by section and type, do another search without the type. If this time, the entry was found, assign the first new entry type and carry on as normal. This way, the old entry is not deleted, and the content from the old entry is preserved (if e.g. old and new types have some of the same fields).

Issue 2:
When running the entry-types/merge command to merge an entry type used by a single with another entry type and persisting the other entry type, the content of the single entry is lost (even if both entry types use the same fields with the same handles). (Content of entries of any other section type is preserved.)

This happened because when we’re done applying project config changes for a single, the single entry already has the typeId changed to the persisting entry type, and so this query was not finding the single entry and therefore wasn't re-writing the content.

Solution:
When running the BaseEntryTypeMergeMigration, also query for the single entries by the persisting entry type id.

Issue 3:
When deploying changes from the entry-types/merge command to other environments, singles could get duplicated if their entry type changed.

This happened because when applying project config changes, the entry with the old entry type was deleted, and then a new one was created with the new entry type. This was followed by the old entry type being restored.

Solution:
When ensuring a single entry, also look through the trashed entries that were deleted with an entry type. As with the solution for the first issue, if one is found, update its entry type.
When running the BaseEntryTypeMergeMigration, run the content updates and restore separately for the singles and account for the fact that the single entry will already have the persisting entry type.

Related issues

#16087

[brandonkelly]

Oops, referenced the wrong “fixed” issue # in 8c29e20

[ul8]

I've just run into all of these issues in a Craft 5 migration, hope this gets released soon :)