Incompatible after upgraded from Page8's plugin

[wei2go]

Question

I assume that I wouldn't need to do anything after upgrading from Page 8's many to many plugin, but I got errors in the CP like this on all the many to many fields: Unable to find component class 'Page8\ManyToMany\fields\ManyToManyField'. I wonder what I did wrong.

I didn't run composer require verbb/many-to-many && composer remove page-8/craft-manytomany, but I remove page-8/craft-manytomany and specify "verbb/many-to-many": "2.0.0" in composer.json, and run composer install (without composer.lock) together with Craft & bunches of other plugins I want to update. I assume this is the same as running composer require and composer remove as you suggested.

It would be great if you can advise.

Additional context

PHP version 8.1.9
Craft edition & version Craft Pro 3.7.61

[engram-design]

Should be fixed in 2.0.1

[wei2go]

Hi @engram-design ,

Thanks for looking into it so quickly.

It still doesn't migrate correctly though. The field warning (e.g. Unable to find component class 'Page8\ManyToMany\fields\ManyToManyField') is gone, but the field settings (i.e. Linked Section and Associated Field) are not migrated over. They are both set to the first option in the dropdown, and the Many to Many fields in the existing elements are all empty.

[engram-design]

Hmmm, nothing should've changed on that front. But it's probably not a great move that both the Linked Section and Associated Field setting use the ID, instead if the UID, which it should be using to be compatible with project config.

I'll be making that change shortly, but it shouldn't have a bearing of your field.

Can you send through your field settings, before you've saved the field? In the fields database table, and the settings column.

[wei2go]

Hi @engram-design ,

Yeah tested again, and the same thing happened. See the settings below. Looks like out of 4 fields, only the last one saved incorrectly:

Before update:

{"source":{"value":"6","type":"section"},"singleField":"71"}
{"source":{"value":"18","type":"section"},"singleField":"71"}
{"source":{"value":"9","type":"section"},"singleField":"71"}
{"source":{"value":"4","type":"section"},"singleField":"93"}

After update:

{"singleField":"71","source":{"value":"6","type":"section"}}
{"singleField":"71","source":{"value":"18","type":"section"}}
{"singleField":"71","source":{"value":"9","type":"section"}}
{"singleField":"71","source":{"value":"8","type":"section"}}

[engram-design]

Strange. There is a section with the ID of 4 and a field with the ID of 93, correct?

As I've mentioned, referring to things via their ID, isn't great because the way project config applies doesn't mean that the IDs will always be the same, which is why I issued that fix to migrate fields to use their UIDs instead.

[wei2go]

Yup, it's supposed to be section ID 4 and field ID 93.

It doesn't look like the UID changes have been released yet. But even with that, the issue persist, as the first migration script m221130_000000_verbb_migration already migrates the field settings incorrectly.

Anyway, the issue can be fixed by manually update the field settings. Will do for now.

[engram-design]

You're right, I'd not pushed that change! See 2.0.2.

The migration does re-apply your project config settings (so we can change the namespace for the field type), so unless that's somehow different to what's in your database, I don't see how that could change.

It also could be an issue that you might've done the updates before the initial m221130_000000_verbb_migration migration was run, which might've messed things up.

Regardless, will keep this open for now.