[3.5.x-dev]: Duplicate fields, globalsets created with same handles

[timkelty]

On a particular project, I've been on 3.5.x-dev for a bit, so this could well just be an artifact of that and not a real issue, but I wanted to bring it up in case anyone else has experienced it.

At some point, I've ended up with both some duplicate fields, and some duplicate global sets.

In the case of the fields, they seemed to be total dupes (including the handle, which is the biggest problem).
For global sets, the dupes seem to just be the name and handle, with an empty fieldset.

Of course, I can't just delete the dupes, because they somehow were created with the same handles. So if I do, I get errors because the other field is still looking for those tables/columns associated with the handle.

My quick hack around this was to:

• change the handles of both the real and dupe (myHandle_good, myHandle_bad)
• project-config/apply
• delete myHandle_bad field
• rename myHandle_good field back to myHandle

[brandonkelly]

Do you know how it happened in the first place? Maybe duplicate files added in the config/project/ folder?

[timkelty]

@brandonkelly unfortunately I don't…could have been a bad git merge, etc…I was just writing it off but then figured I'd post an issue when I saw it crop up again with global sets.

I'll keep an eye out and see if I can track down the sequence of events if it happens again.

[brandonkelly]

Alright, will close for the time being. Let us know if you figure out how to reproduce.

[joshuabaker]

Just encountered this issue. Erasing the fields causes everything to explode.

Shouldn’t this be impossible? I thought handles were unique keys.

[brandonkelly]

@joshuabaker it’s not allowed from a validation perspective, but still technically possible to get there if you were to manually add two fields with the same handle via the project config. Perhaps the duplicate fields were created on two separate environments, and then merged together via Git?

[joshuabaker]

Thanks, @brandonkelly. Apparently nobody else added anything, but I think you’re probably right. Any chance we could switch this to a FR to introduce validation with project config?

[brandonkelly]

Once the data is in the project config, it’s passed the point of validation as far as Craft is concerned. (Same with data that’s already in the database).

You should be able to fix it by deleting the duplicate fields, however there’s a good chance that the duplicates are sharing content table columns with each other, and deleting a duplicate will result in that column getting deleted. So I’d suggest doing the following:

1. Make a backup of just the content table.
2. Delete the duplicate fields.
3. Restore the backup.

If the duplicate fields have already been pushed to other environments (e.g. production), then do the following for each of them:

1. Make sure the other environment is fully up-to-date with any project config changes besides the duplicate field deletions.
2. Make a backup of the content table.
3. Push & apply the field deletion project config change.
4. Restore the backup.

Going to make this better in Craft 4 though, by starting to include a portion of fields’ UIDs in their column names, so there’s no ambiguity (see #6922).

[joshuabaker]

Thanks for the thorough response, @brandonkelly. 🙏