We've uncovered an issue with Gutenberg media uploads clashing with the
image_advanced fields that is very similar to what was reported and diagnosed here: https://support.metabox.io/topic/error-with-image-advanced-in-gutenberg/
When uploading media from controls in the sidebar, the next instances of
image_advanced fields on the page have their values removed once an image is selected from another MediaUpload component.
While that previous ticket dealt with Gutenberg media uploads from within the editor, we're seeing the same behavior for media upload controls that exist within a block's "Inspector" sidebar. I've verified that we are testing with the latest MB version which contains the code solution described in that thread.
You can see it in acton in this demo gif:
In this demo, the "Product Images" panel below the editor is created with MetaBox and both the "Lifestyle Thumbnail Image" and "Studio Thumbnail Image" fields are
It seems like the Backbone media collections are not unique for MetaBox and Gutenberg so the 'removed' event is firing when the WordPress media select window is opened.
The sidebar media upload buttons are being added with the standard MediaUpload component
Happy to PM login information to a staging environment or provide any further debug details we can.
That's exactly the problem in the topic you mentioned above. The problem is media items (models) used in Gutenberg and our Backbone collection are shared (the WP's API does that). And Gutenberg clears the collection (which removes the items) when selecting another image (which is weird, since in the classic editor, it doesn't happen). I'm still looking for a fix.
Anything we can do to assist, let me know. It’s causing a few headaches on a live enterprise project, so we’re happy to fund some development time, devote dev time of our own (with guidance) or help with testing if we can be useful.
I'm reviewing a fix on Github that you can try for now:
In my test, it seems to work well.
Gave this PR a test drive yesterday; unfortunately, it didn't change the behavior in our context. But we're going to spend some time on it this week and see if the approach taken in that solution can lead us to some success
FYI, I've just merged the code into the master branch on Github. If you have time, please try it:
@latlong: There is an updated fix on this, can you try the latest version on Github?
Quick tests yesterday worked great! Giving it a bit more thorough QA today and tomorrow to confirm, but first checks look good