Meta Box

Gutenberg Sidebar Media Upload Clash with image_advanced

Support › General › Gutenberg Sidebar Media Upload Clash with image_advancedResolved

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • June 19, 2019 at 11:03 PM #14998
    latlonglatlong
    Participant

    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:

    Upload clash demo

    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 image_advanced.

    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.

    June 20, 2019 at 2:45 PM #15010
    Anh TranAnh Tran
    Keymaster

    Hi @latlong,

    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.

    June 23, 2019 at 2:36 AM #15055
    latlonglatlong
    Participant

    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.

    Thanks!

    June 24, 2019 at 11:22 AM #15063
    Anh TranAnh Tran
    Keymaster

    I'm reviewing a fix on Github that you can try for now:

    https://github.com/wpmetabox/meta-box/pull/1316

    In my test, it seems to work well.

    June 25, 2019 at 8:54 PM #15090
    latlonglatlong
    Participant

    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

    June 26, 2019 at 3:07 PM #15100
    Anh TranAnh Tran
    Keymaster

    FYI, I've just merged the code into the master branch on Github. If you have time, please try it:

    http://github.com/wpmetabox/meta-box/

    June 27, 2019 at 10:29 AM #15125
    Anh TranAnh Tran
    Keymaster

    @latlong: There is an updated fix on this, can you try the latest version on Github?

    June 28, 2019 at 9:32 PM #15171
    latlonglatlong
    Participant

    Quick tests yesterday worked great! Giving it a bit more thorough QA today and tomorrow to confirm, but first checks look good

  • Author
    Posts
Viewing 8 posts - 1 through 8 (of 8 total)
  • You must be logged in to reply to this topic.