[5.x]: Merged fields are not properly merged or deleted

[nathansnelgrove]

What happened?

Description

Just upgraded to Craft 5 on a client project. Huge multisite project, hundreds of fields. I had a lot of fields I could quickly merge that existed in matrixes and SuperTables before. I followed the instructions as per the upgrade docs, and I did this a couple different times with different DDEV and remote staging environments to make sure I wasn't missing anything.

Once I merged the fields, the merged fields do not delete. Here's an example below, where many redundant fields are still listed:

Furthermore, the fields are not actually merged properly in the content. Below is a screenshot of a matrix. Each block in the matrix is an Internal Link, but instead of referring to the now-merged internalLink, this content is still internalLink2. To fix this, I have to manually replace each of these fields with the merged internalLink field and re-add my content.

Steps to reproduce

1. Update Craft CMS from 4.X to 5.X with PHP 8.3 (my only non-stock change) and MySQL 8.0.
2. Merge dozens of duplicate fields previously using the craft fields/auto-merge command.

Expected behavior

I expect fields that are merged to be completely removed from the Fields screen, and their instances within content to be updated.

Actual behavior

Fields that are merged say they are used 0 times, remain in the Fields screen, and their instances do not update.

Craft CMS version

5.5.2

PHP version

8.3.14

Operating system and version

No response

Database type and version

MySQL 8.0

Image driver and version

No response

Installed plugins and versions

• "craftcms/aws-s3": "^2.2.0",

• "craftcms/ckeditor": "^4.4.0",
  

• "craftcms/feed-me": "^6.5.0",
  

• "craftcms/mailgun": "^3.1.0",
  

• "craftcms/redactor": "^4.2.0",
  

• "craftpulse/craft-colour-swatches": "^5.1.0",
  

• "doublesecretagency/craft-googlemaps": "^5.0.3",
  

• "nystudio107/craft-cookies": "^5.0.0",
  

• "nystudio107/craft-imageoptimize": "^5.0.3",
  

• "nystudio107/craft-retour": "^5.0.3",
  

• "nystudio107/craft-seomatic": "^5.1.7",
  

• "nystudio107/craft-typogrify": "^5.0.1",
  

• "ostark/craft-async-queue": "^4.0.0",
  

• "solspace/craft-freeform": "^5.7.2",
  

• "verbb/field-manager": "^4.0.3",
  

• "verbb/formie": "^3.0.12",
  

• "verbb/super-table": "^4.0.2",
  

• "vlucas/phpdotenv": "^3.4.0",
  

• "wrav/oembed": "^3.1.1"
  

[nathansnelgrove]

Oh! One other thing worth mentioning: I can't delete fields with no usages. When I click the delete button, then attempt to delete the field, absolutely nothing happens, even though the site says it's deleted the field.

[i-just]

Hi, thanks for reaching out! Could you send your composer.json, composer.lock and database export from before and after running the fields/auto-merge command (but before any manual changes you might have done) to [email protected] and point out the control panel link to where the second screenshot comes from so we can try to reproduce and dig deeper?

[nathansnelgrove]

Thanks for getting back to me! I did not make database exports before the fields/auto-merge command. Obviously, I need to give this another go and see if I can re-reproduce the issue still, so that's on my todo list for the week. I'll make multiple database exports and send them your way if I manage to reproduce the problem. Thank you!

[LinneaHarts]

I am having this problem too. I am creating migrations, deploying them, and when they run they do not delete the merged fields even though it says it ran the migration, and all the guids match in the environment. This has cost me many hours and I'm having to merge fields in production.

I am using fields/merge and merging individual fields because the auto-merge doesn't really do what I'm looking for

[i-just]

The field deletion is handled by the project config being applied. @LinneaHarts, when you deploy your fields/auto-merge changes and run craft up, do you see the field removal listed in the output?

[nathansnelgrove]

I have managed to re-reproduce this. I am going to send the SQL files and the Composer files over as requested, but wanted to quickly add a few more notes in case somebody else in the community is experiencing this:

1. I wonder if this has to do with SuperTable, which I have a lot of fields (now entry types) created in?
2. Fields are merged, but the merged fields are now not deleted. To use one example: because of the amount of externalLink fields I had inside Matrix elements of SuperTable elements, I have fields like externalLink10. externalLink10 has been merged with externalLink, but is still visible inside Fields in Craft. It just says "No uses." There is also an entry type called externalLink10. I merged it with an entry type called externalLink, but that obviously has the same name as the field externalLink. Renaming either the field or the entry type does not let me delete redundant fields.
3. Attempting to delete a field results in a success message ("The field has been deleted"), but the field is still available.

Unfortunately, this makes the Craft update impossible for me right now, even though both the client and I would love to do it.

[LinneaHarts]

I'm using fields/merge not auto merge.

When I deploy it says the migrationos have run, but the fields are neither merged nor deleted.

[nathansnelgrove]

I got a lot of help from Tommy at support, who got a few database dumps from me and did some experimentation on his end. A clean install solved it for me. Still kind of a mystery what caused it, though.

[LinneaHarts]

@nathansnelgrove does that mean you deleted your vendor directory and reinstalled? or something else? And was this happening for you on deploy? My merges are working on one server, but not if I copy the migration to another server, even if the database is identical.

[nathansnelgrove]

@LinneaHarts it means I set up a whole new Docker container and did a clean install of Craft 5 without an existing database. Then imported the DB and migrated it from there to Craft 5. I have not migrated to staging or production yet; I'm still replacing all the old Supertable field groups I had before with generic field types.

[LinneaHarts]

Thanks @nathansnelgrove ! Yeah, sounds like a somewhat different problem than I'm having. @i-just should I open a new issue?

[i-just]

@LinneaHarts, it would be best if you could send your composer.json, composer.lock and database export from before and after running the fields/merge command to [email protected] and point out which fields you run the command on where the changes were not deploying as you’d expect them to.