Skip to content

Bugfix/16087 singles and entry types#16102

Merged
brandonkelly merged 6 commits into5.xfrom
bugfix/16087-singles-and-entry-types
Nov 18, 2024
Merged

Bugfix/16087 singles and entry types#16102
brandonkelly merged 6 commits into5.xfrom
bugfix/16087-singles-and-entry-types

Conversation

@i-just
Copy link
Copy Markdown
Contributor

@i-just i-just commented Nov 13, 2024

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

@i-just i-just marked this pull request as ready for review November 13, 2024 13:33
@i-just i-just requested a review from brandonkelly November 13, 2024 13:33
Comment thread src/services/Entries.php
@brandonkelly
Copy link
Copy Markdown
Member

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

@ul8
Copy link
Copy Markdown
Contributor

ul8 commented Nov 18, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants