dgrigg / craft-migration-assistant

Migration Manager for Craft CMS
Other
27 stars 10 forks source link

Craft 3.1 UID migration failure #5

Closed my2ter closed 5 years ago

my2ter commented 5 years ago

Hi,

This is a combined error with https://plugins.craftcms.com/entriessubset and Craft new UID solution. The problem is due to how Craft uses UID now for searching sections.

To reproduce:

When generating the migration it will end up with something like the below JSON in the field settings:

{"entryTypes":["22"],"userGroups":null,"users":null,"sources":["section:5e00baaa-9030-4d63-ab93-d4e376fc4905"],"source":null,"targetSiteId":null,"viewMode":null,"limit":"1","selectionLabel":"My label","localizeRelations":false}

Expected:

Result:

Why? When you run the migration it creates a section with a different UID (Thanks to Craft...) and that field is now pointing to a non existent UID

I think this highlight a bigger issue for your migration plugin though, you shouldn't rely on the UID in your migrations as this is always going to be random when running migrations from start. Sure it works if you have an app that run migrations one after the other, but if you've got a dev team that needs to work from scratch it will always fail - which is the point of migrations, you should be able to up and down at will and always end up in the same state. (I know Craft makes it harder...)

What I'm gonna do is alter the migration programatically to search for the section first, grab the UID and inject it in the JSON text field. But would be nice to not have to do that. ;)

Hope it makes sense. Cheers

dgrigg commented 5 years ago

@my2ter try using the events, https://github.com/dgrigg/craft-migration-assistant#using-events to grab the data on the way out/in to manipulate it before the migration runs. With complex custom field types that's the best way to handle those situations since we can't plan/support every type of field.

my2ter commented 5 years ago

@dgrigg

I don't think the event is necessary - as said I can just search for the section before running the migration - but good to know. I agree you can't support every custom fields and my example was only showcasing the problem, which is not about custom field but Craft UIDs.

For a migration to work you need to base it on a unique ID that never changes, Craft UID aren't like that because at a creation time the same section will have different UID on different systems... Handles on the other hand are probably the best solution, or as it was before using database ID.

Happy for you to close this issue, I can work around with my solution, but I still think your migration shouldn't be using the UID ;) If I have time I can try to make a PR...

Thanks for taking the time to reply though.

dgrigg commented 5 years ago

@my2ter the event route is handy if you need to modify migrations on an ongoing basis. For one and done, manual is probably the best option.

Regarding the migrations and ids/uids the migration assistant does not rely on them. It uses handles and slugs (depending on the entity being migrated) which are more likely to remain consistent between environments. We do export the UID but only for data integrity purposes not for lookup and matching when running migrations.