Galleries with captioned images no longer function properly

[wlanowski]

Expected behavior:

• Galleries made with the WordPress app should work
• Galleries should be editable

Actual behavior:

• Gallery breaks after saving or publishing and is not editable in the app.
• In the browser, the gallery is displayed, but with display errors.
• In the browser editor, the gallery is displayed, but is not editable and the error "This block contains unexpected or invalid content." is displayed. Block recovery does not work.

Steps to reproduce the behavior:

1. Create a gallery with the WordPress app.
2. Caption at least one image in this gallery. The error does not occur if no image is captioned!
3. Save or Publish Post/Page

Tested on [device], Android [version], WPAndroid [version]:

Tested on a Samsung Galaxy A52, with Android 13, WordPress app version 21.3
Tested on 2 different WordPress instances with version 6.1.1

[wlanowski]

Similar error has occurred here before: #15819

[thehenrybyrd]

@wlanowski thanks for reporting this and pointing out the previous issue!

I wasn't able to reproduce in WP Android 21.4.
After adding a Gallery Block to a new post, I tried captioning one or several photos, using different punctuation in the captions, and captioning the whole gallery. In each case, after saving I was still able to edit and view the post in both app and browser. I also tried publishing vs saving a draft and wasn't able to get any errors.
Can you check whether you still find the same issue in WP Android 21.4?

The biggest difference I can see in our setup is that I'm still on Android 12.
@fluiddot do you know of any version differences that could be causing this issue? I can't think why that would be, but you'd have more technical insight.

[wlanowski]

I can not try 21.4 since 21.4 is not published in Google Play Store yet.

For Security Reasons i am unable to install APKs or Apps from other sources on my company device.
Nevertheless the issue is also there on iOS.

Maybe there are some errors with the Syntax. Here is the code of a post with one working gallery without any captions and a second not working gallery with a caption at the last picture. It looks strange for me. Do you see something strange here?

Link to GIST

[wlanowski]

As in the GIST showed, in the working galery there are only <img> and <figures> while in the not working gallery each gallery item is part of a <li>-Element within an gallery-grid build with an <ul>element. There are some differences between the two galleries, such like classes in the elements, although they are build in the same post with the same application.

[derekblank]

It looks like this is an issue relating to the Gallery v1 and v2 block HTML. As @wlanowski referenced in the gist, the working gallery HTML without captions is using Gallery block v2 syntax (figure + image):

<!-- wp:gallery {"linkTo":"none"} -->
<figure class="wp-block-gallery has-nested-images columns-default is-cropped">
    <!-- wp:image {"id":3326,"sizeSlug":"large","linkDestination":"none"} -->
    <figure class="wp-block-image size-large"><img
            src="https://****.files.wordpress.com/2022/05/image.jpg?w=1024" alt="" class="wp-image-3326" />
    </figure>
    <!-- /wp:image -->
</figure>
<!-- /wp:gallery -->

And the non-working gallery with captions is using Gallery block v1 syntax (figure + ul + li + image):

<!-- wp:gallery {"ids":[38],"linkTo":"none"} -->
<figure class="wp-block-gallery columns-1 is-cropped">
    <ul class="blocks-gallery-grid">
        <li class="blocks-gallery-item">
            <figure><img src="http://localhost:8888/wp-content/uploads/2022/06/265-5000x5000-1-scaled.jpeg" data-id="38"
                    class="wp-image-38" /></figure>
        </li>
    </ul>
</figure>
<!-- /wp:gallery -->

Support for the v1 Gallery syntax was re-introduced in WordPress/gutenberg#41533, and released in app version 20.1. My understanding is that the Gallery v1 syntax should still work in the native editor, however. The issue may be that something in the editor settings (on either app or web) is causing the Gallery block to mix the v1 and v2 syntaxes in an unknown circumstance, possibly related to captions, or the version of WordPress itself.

I can continue further, but at this point I want to pause to get a second opinion. @fluiddot -- are you aware of any reason why using Gallery captions (vs. no captions) would invoke the Gallery v1 syntax (or the __unstableGalleryWithImageBlocks flag) in the app editor? It appears to be possible based on the HTML in the gist provided. Or could it be related to the version of WordPress itself having been upgraded from 5.9 to 6.1.1, as referenced in this comment? FWIW, I was not able to reproduce the issue (or non-working HTML syntax) on either v20.3 or v20.4 on WordPress 6.1.1, using both captions and no captions within the Gallery block.

[fluiddot]

I think you hit the point @derekblank with the two versions of the Gallery block being the issue here. Version 2 of the Gallery block uses Image blocks (<!-- wp:image --> HTML tag) as the inner children of the Gallery block (<!-- wp:gallery --> HTML tag), where Version 1 uses li and figure+ image for the images.

I followed the steps to reproduce the behavior in a self-hosted site with WordPress 6.1.1 and couldn't reproduce the issue. I added a Gallery block, but captioning some images in this gallery and saving the post didn't make the format of the Gallery block change. Same as the results shared in this comment by @thehenrybyrd .

@wlanowski If the Gallery block is being added to a site with WordPress 6.1.1, the HTML code generated for the Gallery block should have the Version 2 format, like the one you shared in the example of the first Gallery without captions.

Just to confirm, @wlanowski could you double-check that the Gallery block format changes after captioning an image? It would be very helpful if you can copy the HTML generated once you add the Gallery and then once you caption any of the images. This way we can compare the HTML code and see if there are any modifications in the format. Thanks!

[wlanowski]

Update: The issue is still there with WP Android version 21.4, which is released today

@fluiddot If I create a gallery with images and don't label an image, a gallery with v2 code comes out.

When I create a gallery of images and label at least one image, a gallery comes out with v1 code and the gallery becomes uneditable and has display errors.

If I edit an already created and saved v2 gallery, it remains a working v2 gallery. However, when I caption an image in this gallery, the gallery is converted to a v1 gallery on save and the errors occur.

However, the phenomenon only occurs when using the iOS and Android apps! When editing and creating galleries with the browser, everything works smoothly.

Here is the page report of the website in question: GIST. The error occurs with me but also on other websites.

I additionally created a post for you, with one working v2 gallery and one notworking v1 gallery with a caption: LINK / Wordpress-Code in Editor / HTML-Code (GIST)

[fluiddot]

Thank you so much @wlanowski for checking my comment and helping us to debug the problem 🙇 .

I followed the steps to reproduce the behavior in a self-hosted site with WordPress 6.1.1 and couldn't reproduce the issue. I added a Gallery block, but captioning some images in this gallery and saving the post didn't make the format of the Gallery block change.

I performed another test on a self-hosted site without the Gutenberg plugin and noticed that the Gallery block is created with the V1 format. Captioning some images and saving a post results in breaking the block, as described in the issue.

@fluiddot If I create a gallery with images and don't label an image, a gallery with v2 code comes out.

When I create a gallery of images and label at least one image, a gallery comes out with v1 code and the gallery becomes uneditable and has display errors.

It's still unclear to me what might be causing the Gallery block to change from V2 and V1 when captioning an image. In my case, I couldn't reproduce this specific case.

---

Having a site with WordPress 5.9 or greater (e.g. version 6.1.1) should make the app to use Gallery block V2, which as far as I tested, this is not happening for the case of using a self-hosted site without the Gutenberg plugin installed. We'll investigate this issue further and figure out how to address it.

@wlanowski I noticed per the page report you shared here, that your site doesn't have the Gutenberg plugin installed. While we work on a fix, you might consider installing it as this should address the issue you are experiencing. Thanks for your help 🙇 !

[wlanowski]

@wlanowski I noticed per the page report you shared here, that your site doesn't have the Gutenberg plugin installed. While we work on a fix, you might consider installing it as this should address the issue you are experiencing. Thanks for your help 🙇 !

Oh! With the Gutenberg Plugin installed, the error does not occur anymore!! I tested it successfully. But why??

[fluiddot]

@wlanowski I noticed per the page report you shared here, that your site doesn't have the Gutenberg plugin installed. While we work on a fix, you might consider installing it as this should address the issue you are experiencing. Thanks for your help 🙇 !

Oh! With the Gutenberg Plugin installed, the error does not occur anymore!! I tested it successfully. But why??

The reason for this is that the Gutenberg Plugin is used by the app to determine which version of the Gallery block should be used. By default, if the Gutenberg Plugin is not installed, the app uses the V1. However, this is no longer applicable because, in newer versions of WordPress, the default behavior is to use V2. We'll explore options to fix this issue in the app.

[mkevins]

The reason for this is that the Gutenberg Plugin is used by the app to determine which version of the Gallery block should be used. By default, if the Gutenberg Plugin is not installed, the app uses the V1. However, this is no longer applicable because, in newer versions of WordPress, the default behavior is to use V2. We'll explore options to fix this issue in the app.

Thanks for investigating this @fluiddot and @derekblank !

I think this is indeed the reason, though I'm still a bit confused how this relates to the caption (except to note that the caption has a different appearance in the v1 gallery images: overlayed). 🤔

I have debugged the scenario on a test site where the Gutenberg plugin is deactivated, and it seems that the editor settings endpoint response with a 404, and the editor theme endpoint is queried as a fallback when the plugin is not active. This is normal, afaik, but the response omits the galleryWithImageBlocks flag within the theme_supports. Since the response is parsed via Gson, and the model for the response has this field declared as non-optional, an omitted value is being coerced to false.

I have opened a PR which declares this parameter as optional. This allows us to distinguish between false and omitted (i.e. null), so we can coerce more gracefully depending on the site's core WP version. This should, in theory, still honor any edge case where WP version is 5.9+, but Gutenberg plugin is manually set to a pre-gallery-v2 version (maybe a rare case, but perhaps possible in some situation where an outdated deprecated theme is still in use 🤷‍♂️ ).

[fluiddot]

I think this is indeed the reason, though I'm still a bit confused how this relates to the caption (except to note that the caption has a different appearance in the v1 gallery images: overlayed). 🤔

I think the caption issue is just a symptom, probably the description of the issue doesn't accurately reflect the cause of the issue. For reference, I elaborated further on the cause on WordPress/gutenberg#47782.

I have debugged the scenario on a test site where the Gutenberg plugin is deactivated, and it seems that the editor settings endpoint response with a 404, and the editor theme endpoint is queried as a fallback when the plugin is not active. This is normal, afaik, but the response omits the galleryWithImageBlocks flag within the theme_supports. Since the response is parsed via Gson, and the model for the response has this field declared as non-optional, an omitted value is being coerced to false.

Ah, good catch. Thanks @mkevins for investigating and sharing the results 🙇 .

I have opened a PR which declares this parameter as optional. This allows us to distinguish between false and omitted (i.e. null), so we can coerce more gracefully depending on the site's core WP version. This should, in theory, still honor any edge case where WP version is 5.9+, but Gutenberg plugin is manually set to a pre-gallery-v2 version (maybe a rare case, but perhaps possible in some situation where an outdated deprecated theme is still in use 🤷‍♂️ ).

Great, this way we'll cover all cases 🙂.

[mkevins]

Great, this way we'll cover all cases

Yep! Thanks for reviewing and linking up the "duplicate" issues.

As a bonus, I set up a Jurassic Ninja site w/ the WP Downgrade plugin, and set WordPress core version to 5.9, and then I manually installed Gutenberg plugin v11.8.3, leaving the v2 ("Gallery block experiment") box unticked on the experiments page. In this scenario, galleries created on web are in the v1 format.

Testing this with the fix results in a v1 experience on mobile, and the issue is averted (caveat is that the editor settings must be fetched at least once prior to loading the content in question, e.g. by opening a different post, or creating a new one).

[mkevins]

Update: In the scenario described above (Gutenberg plugin v11.8.3 on WordPress code version 5.9), everything was working smoothly with v1 galleries (also confirmed that the editor_session_start event has property "unstable_gallery_with_image_blocks": false). However, when I add a caption to an image in the gallery (on mobile or on web), it presents the error "Problem displaying block". When I tap to attempt block recovery, the gallery retains the image, but loses the caption. It also seems to add an empty image. So perhaps there is indeed some additional issue with captions that can be encountered in these edge case scenarios 🤔

[wlanowski]

Update: In the scenario described above (Gutenberg plugin v11.8.3 on WordPress code version 5.9), everything was working smoothly with v1 galleries (also confirmed that the editor_session_start event has property "unstable_gallery_with_image_blocks": false). However, when I add a caption to an image in the gallery (on mobile or on web), it presents the error "Problem displaying block". When I tap to attempt block recovery, the gallery retains the image, but loses the caption. It also seems to add an empty image. So perhaps there is indeed some additional issue with captions that can be encountered in these edge case scenarios 🤔

Yes, I had the same issue... Only after adding a caption to at least one image, the error occurs.

But is it fixed in current versions? Is this issue ready for closing?

[mkevins]

But is it fixed in current versions?

This should be resolved when using the latest versions (of WordPress, as well as the Gutenberg plugin).

Is this issue ready for closing?

Good question. The "edge" case described above is, imo, a valid scenario, though it's hard to say how frequently this will be encountered. If re-opened, I'd think it would be pretty low priority, unless this turns out to be more common than expected.

I did a little more debugging, and it looks like the validation issue I encountered is:

Block validation: Expected attribute `class` of value `wp-block-gallery columns-2 is-cropped columns-1`, saw `wp-block-gallery columns-1 is-cropped`.

and this was on a gallery with only one image, so the columns-2 part is a bit suspicious to me.

[mkevins]

Some additional debugging info which might help in tracking down the root cause:

Content generated by `save` function:

<figure class="wp-block-gallery columns-2 is-cropped columns-1"><ul class="blocks-gallery-grid"><li class="blocks-gallery-item"><figure><img src="https://insufficient-octopus.jurassic.ninja/wp-content/uploads/2023/05/Phalacrocorax_carbo_Egretta_garzetta_and_Mareca_streper
a_in_Taudha_Lake.jpg" alt="" data-id="9" data-full-url="https://insufficient-octopus.jurassic.ninja/wp-content/uploads/2023/05/Phalacrocorax_carbo_Egretta_garzetta_and_Mareca_strepera_in_Taudha_Lake.jpg" data-link="https://insufficient-octopus.jurassic.ninja/?attachment_i
d=9" class="wp-image-9"/></figure></li><li class="blocks-gallery-item"><figure><img/></figure></li></ul></figure>

Content retrieved from post body:

<figure class="wp-block-gallery columns-1 is-cropped"><ul class="blocks-gallery-grid"><li class="blocks-gallery-item"><figure><img src="https://insufficient-octopus.jurassic.ninja/wp-content/uploads/2023/05/Phalacrocorax_carbo_Egretta_garzetta_and_Mareca_strepera_in_Taudh
a_Lake.jpg" alt="" data-id="9" data-full-url="https://insufficient-octopus.jurassic.ninja/wp-content/uploads/2023/05/Phalacrocorax_carbo_Egretta_garzetta_and_Mareca_strepera_in_Taudha_Lake.jpg" data-link="https://insufficient-octopus.jurassic.ninja/?attachment_id=9" class
="wp-image-9"/><figcaption class="blocks-gallery-item wp-element-caption">test caption!</figcaption></figure></li></ul></figure>

Notice the extra <li class="blocks-gallery-item"><figure><img/></figure></li> added at the end in the save function version. Somehow, it seems that an empty gallery image is being generated when a caption is present. 🤔

[fluiddot]

@mkevins Oh, good catch, I also managed to reproduce the issue using WordPress 5.9.7 and Gutenberg 14.7.3. If in the web version, I create a Gallery and set any caption to the images, when opening that post in the app, it results in a block error. I'm encountering the same error when using WordPress 5.8 and Gutenberg 13.6.0.

I'm wondering if there's a difference in the implementation of Gallery v1 between the web and native that produces this error. @derekblank since you've been working on the fix, could you take a deeper look? Thanks!

In any case, I agree this issue at least for Gallery v1 can't be marked as closed so I'm reopening it.

[derekblank]

The core issue appears to be due to the wrong selector being used for a Gallery block v1 caption. When a caption is added to an image in a v1 Gallery, the caption's class selector is blocks-gallery-item, which causes the caption to be interpreted as a second gallery item on mobile, as blocks-gallery-item is the selector for gallery items. The caption's class name should be blocks-gallery-item__caption, which correctly attributes the caption as a caption when parsed, and also matches the web behavior for the v1 Gallery block.

@mkevins and I isolated a fix for the captions issue that makes this change, and can be tested in this PR:

• [RNMobile] Fix Gallery v1 caption selector WordPress/gutenberg#51076

[fluiddot]

Now that WordPress/gutenberg#51076 is merged we can close the issue. Note that, as I shared here, this issue is likely to keep happening in the web version.