Auto-merge Custom Field Name #17672
-
Hey, I'm finally updating our Craft 4 site to Craft 5 (I know, shame on me). I followed the guide and was able to successfully make the update (as well as update a custom plugin). After the migration, I now have well over 200 fields and I'm looking to merge those together to be as efficient as possible. When I run
In this situation, I MUST choose between one of the 6 field slugs above. Custom Field Name SelectionI'd like to propose the ability to choose a field name that isn't listed in the identical fields. For instance, in this situation if I was starting a Craft 5 project from scratch, I'd probably call this base field something general like It seems as though I can select one to persist, and then go update it after the merge. But it'd be nice to cut that out of the process. Just a thought. Thank you for this! |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
The prompt isn’t asking which handle should persist – in fact, all of your field layouts that are currently using the merged fields will retain their existing handles, thanks to field layouts’ ability to override field handles in Craft 5. It’s asking which field should persist. That could be important depending on the site. E.g. if Field A is used in 100 layouts and Field B is only used in two layouts, you’d probably want Field A to persist, so the command and generated content migration have a lot less work to do – as they will only be updating two field layouts instead of 100. You can certainly go back and rename the persisting field’s handle after the fact if you want, but that’s not really a concern of this CLI command. |
Beta Was this translation helpful? Give feedback.
The prompt isn’t asking which handle should persist – in fact, all of your field layouts that are currently using the merged fields will retain their existing handles, thanks to field layouts’ ability to override field handles in Craft 5.
It’s asking which field should persist. That could be important depending on the site. E.g. if Field A is used in 100 layouts and Field B is only used in two layouts, you’d probably want Field A to persist, so the command and generated content migration have a lot less work to do – as they will only be updating two field layouts instead of 100.
You can certainly go back and rename the persisting field’s handle after the fact if you want, but that’s not r…