get_post_galleries() should return gallery blocks

[pento]

Originally reported here: ​https://github.com/WordPress/gutenberg/issues/5797

Galleries in Gutenberg don't use the [gallery] shortcode, so aren't returned by get_post_galleries(). This function should check for gallery blocks, too.

[pento]

Currently block on ​https://github.com/WordPress/gutenberg/issues/8193.

[Takahashi_Fumiki]

Add gutenberg block parser for get_post_galleries

[Takahashi_Fumiki]

I added a patch above.

• Avoid quick return with checking shortcode existence.
• Add gut block parser.

Questions

• I think this needs new tests because no test case for block format strings.
• if $html attribute is true, simply added block content html. But this output html is apparently different from former shortcode empowered gallery html.
• I'm afraid that there might be php gutenberg parser in core.

[birgire]

@Takahashi_Fumiki

Thanks for the patch.

When I add a gallery I get something like this:

<!-- wp:gallery -->
<ul class="wp-block-gallery columns-3 is-cropped">
	<li class="blocks-gallery-item">
		<figure>
			<img src="https://example.com/wp-content/uploads/2018/11/image.jpg" alt="" data-id="123" data-link="https://example.com/testing/image/" class="wp-image-123"/>
			<figcaption>Test image.</figcaption>
		</figure>
	</li>
        <li>...cut...</li>
        <li>...cut...</li>
</ul>
<!-- /wp:gallery -->

So I assume the task here is to support this format in get_post_galleries() ?

---

I noticed in 43826.patch​ the following:

if ( false !== strpos( $post->post_content, '<!-- wp:gallery' ) ) {

We can instead use the has_block() function to check for the gallery block, e.g.:

if ( has_block( 'gallery', $post->post_content ) ) {

There's also the parse_blocks(), that might help to get the innerHTML of the core/gallery block names, instead of using:

 if ( preg_match_all( '/<!-- wp:gallery([^>]*)-->(.*?)<!-- \/wp:gallery -->/s', $post->post_content, $blocks, PREG_SET_ORDER ) ) {

Adding tests for the block format string cases (like above) sounds good.

Here are the current get_post_galleries() tests that would be helpful:

https://core.trac.wordpress.org/browser/tags/4.9.8/tests/phpunit/tests/media.php

[pento]

Thank you for the patch, @Takahashi_Fumiki!

There's actually already a block parser in Core, as @birgire mentioned.

Before continuing, however, it's worth noting that the Gallery Block format will be changed before 5.0 (​GB11212) to store the image data in the block attibutes, which will make it available in the parse_blocks() output.

[tellyworth]

attachment:43826.2.diff​ uses parse_blocks() to crudely parse gallery blocks and include the corresponding images in get_post_galleries() and related functions. Unit tests are included.

Currently it still relies on regexes to grab the <img src=".."> values from the gallery block's innerHtml. That could be improved when GB11212 lands, as @pento suggests.

Please note that I have only tested this with phpunit tests. I probably missed and/or broke something as well.

[birgire]

@tellyworth thanks for the updated patch and tests in 43826.2.diff​

Few suggestions for the tests:

It would be nice to have a test case for a content containing both gallery shortcode and a gallery block.

I also wonder if we need more coverage for the $html = false input argument.

We could add @group blocks to the descriptions of the test methods:

• test_block_inner_post_gallery_images()
• test_block_post_gallery_images()
• test_block_post_galleries().

It seems we can reduce some code by combining the two foreach loops with range 1 to 3 and 4 to 6 into a single foreach loop with range 1 to 6. (same for the older test cases).

But it seems benificial to move all the tests for get_post_galleries() under it's own test class, e.g. /tests/phpunit/tests/media/getPostGalleries.php.

Then we could share the fixtures to avoid duplication.

[tellyworth]

attachment:43826.3.diff​ improves the tests as per @birgire's suggestions, specifically:

• @group blocks added to block tests
• Added test_mixed_post_gallery_images() to cover mixed shortcode/block case
• Shortened the tests using single ranges (also for some older tests)

Re $html = false, it seems like all of the tests cover these cases currently; it's true that is not covered. I'll look at adding those next.

Has anyone tested this manually?

[tellyworth]

attachment:43826.4.diff​ makes further improvements:

• It now supports json attributes in the gallery block, as per ​https://github.com/WordPress/gutenberg/pull/11973
• Added test_block_post_gallery_images_json to cover the <!-- wp:gallery {"ids":1,2,3} --> case
• Added test_mixed_post_galleries to better cover the $html=false parameter for both shortcodes and blocks (with json)

Couple of things to point out for further discussion:

1. This continues to support gallery blocks that don't contain the json blob, by extracting img srcs from innerHtml. Should it?
2. For blocks, get_post_galleries( ..., false ); will now include block attributes in the returned array, in much the same way that it does for shortcodes (see test_mixed_post_galleries for details). I've made sure the ids in the return array is a string, same as for shortcodes. However it's likely that other values in the json blob won't quite match what would be returned from a shortcode, so code that relies on get_post_galleries( ..., false ) might be surprised by the results. What's that going to break?

I've really only unit tested this, as I don't have a good understanding of real world use cases for these functions.

[antpb]

We should move this to a future milestone as there are still some things to discuss and agree on. Changing the same function to produce different results may not be the best path forward.

One other thing to add, since we are moving this from 5.0, is that the classic-block has the ability to add a gallery with no ids defined. We may want some documentation around that for users that are expecting to use it. New galleries should be accessed like any other block on the server instead of forcing get_post_galleries() to match. I do think later we should support get_post_galleries() but we will need to do it at a later time.

[birgire]

To better understand the usage of "get_post_galleries" in plugins and themes:

There are currently 81 matches in 40 plugins in the plugin directory:

​https://wpdirectory.net/search/01CWVNTY847CDMRPSX4J899RSY

and 170 matches in 91 themes in the theme directory:

​https://wpdirectory.net/search/01CWVPA933JVWHT2HPZVD0S7ZC

[tellyworth]

Thanks for those references @birgire. I reviewed the twenty* themes and usage in all of the plugins with > 0 installs, and it looks promising. Most calls use ids only. A few use type or size if present.

I can see no indication there is a common usage idiom that would be tripped up by unexpected keys in the output. Just in case though, that's trivially dealt with by only including ids in the block return.

[tellyworth]

attachment:43826.5.diff​ iterates on the previous patch with two changes:

• Only ids is included in the block attributes returned by get_post_galleries()
• test_mixed_post_galleries_data tests the behaviour of attributes returned from both shortcode and block galleries

I think that should address the compatibility concern as described in comment:12.

[desrosj]

43826.5.diff​ is currently not applying to trunk for me. Can someone refresh this, please? Would love to see this fixed in 5.0.3.

[audrasjb]

patch refreshed

[audrasjb]

@desrosj I tried to refresh that patch

[desrosj]

43826.6.diff​ had some missing closing curly braces in the unit tests that was causing some fatal errors. 43826.diff​ should be a clean refresh against trunk. Working to review now.

[desrosj]

Going to punt this. Still working through a review. If there is time before the 5.0.3 RC to finish, it can be moved back.

[pento]

Let's leave it for 5.1. @desrosj: Can you finish reviewing it and commit when ready?

[pento]

Converting this to a task. We can land it early during the beta period.

[desrosj]

There were some questions when going through this one in Slack recently:

• Does this have the potential of breaking anything that is using this function _not_ expecting Gutenberg galleries?
• We would need to know if the content includes Gutenberg blocks, not if the site currently supports it, as those may be separate things.

@tellyworth do you need any help testing this? I didn't want to double efforts working on this one.

[celloexpressions]

get_post_gallery_images() and get_post_gallery() also call get_post_galleries(). Usage of these higher-level functions may be more common than 11 indicates. get_post_gallery_images() returns the image srcs, and this should continue working with new blocks so that themes don't have to rely on their own logic to locate classic and block galleries in content.

As long as the returned data format/contents matches classic galleries, themes and plugins would expect this to work equally for classic and block-based galleries. A very common usage is to show gallery excerpts in theme archive views; these are often created by gathering data with this function, then reformatting a custom gallery excerpt with custom markup. It is not tenable to use a different function for block galleries unless all existing content is migrated to gallery blocks, since this usage needs to apply to pre- and post-5.0 galleries equally.

43826.diff​ appears correct to me; however, I have not tested it.

[pento]

Still needs more testing, punting to 5.2.

[dway]

Hello, any update on this ?

[JeffPaul]

Per today's bugscrub, we're punting this as not enough time remains to get this into 5.2. Given the minimal movement during the 5.2 release cycle, I'm punting this to Future Release so that we consciously milestone this for a numbered release when we're ready to take it on.

[russhylov]

WP 5.2.2
All this functions ( get_post_gallery, get_post_galleries, get_post_galleries_images, get_attached_media) return empty array or false because post_parent cell is stays 0 when wp_post gets new record or the existing post is edited.

[russhylov]

Hi all.
Have temporarity solution.

When we insert new gallery into the post content, html view of gallery block look at this
<!-- wp:gallery {"ids":[909,917,916,915,914,913,912,911,910],"linkTo":"media"} -->
<ul class="wp-block-gallery columns-3 is-cropped">....
All of we need its IDs of attachment posts.

If we add to custom meta of post ids block (only numbers in []) with caption "gallery", then we can get custom metadata of the post and get IDs of attachments post which needed.
So, in our script we can get ids of attachments type post and show needed images

<?php

foreach ($posts as $post) {  
    $meta = get_post_meta($post->ID, 'gallery');
    $ids= explode(',', $meta[0]);
    foreach ($ids as $id) { 
      $atp_meta = get_post_meta($id);
      echo "<pre>";
        echo dirname($atp_meta['_wp_attached_file'][0])."<br>";  //  get the upload directory for needed images.  
        var_export(unserialize($atp_meta['_wp_attachment_metadata'][0])); // get array of all intermediate images.
      echo "</pre>";
    }
  }

Done. Profit :)

[lynk]

Will this be fixed add some point? There should be a note in the codex that these functions are currently broken.

[celloexpressions]

This needs to be fixed. The onus of backwards compatibility should be on core, not themes. And many themes have not taken temporary steps to address this issue. This pushes the work to users, who must rely on the classic editor or insert galleries in classic blocks within the block editor. With dozens of uses in dozens of themes and plugins, there are at minimum hundreds or thousands of people impacted by this breakage.

### Description
Currently the get_post_galleries method will only handle gallery shortcodes. A trac ticket has been open for some time to rectify this, and in the meantime a new version of the gallery block is about to be released which uses innerblocks, so the diffs on this ticket will no longer be sufficient.

This PR adds support for both versions of the gallery block

### To test:

• Check out this PR to local wp dev env along with the latest version of the gutenberg plugin
• Add a theme that makes use of the get_post_galleries method, eg. ​Arbutus
• Add several posts using the Gallery post type - add a short code, gallery block, and v2 gallery block (turn on gallery experiment to add a v2 block)
• The the homepage of the site and check that all 3 galleries display as expected

Trac ticket: https://core.trac.wordpress.org/ticket/43826

[glendaviesnz]

Since this was last looked at we now have a new version of the Gallery block that is about to be released that uses innerBlocks. I have created a PR (​https://github.com/WordPress/wordpress-develop/pull/1783) that refactors the get_post_galleries method to account for both these formats, and also splits some of the parsing out to separated methods as the nesting was getting a bit deep/complex to account for a second block format.

Once there is agreement on the way forward with this I will add some additional unit tests

This is an alternative to #1783 - it makes for a much longer and harder to grok get_post_galleries method, but avoids adding extra methods to global namespace.

### Description
Currently the get_post_galleries method will only handle gallery shortcodes. A trac ticket has been open for some time to rectify this, and in the meantime a new version of the gallery block is about to be released which uses innerblocks, so the diffs on this ticket will no longer be sufficient.

This PR adds support for both versions of the gallery block

### To test:

• Check out this PR to local wp dev env along with the latest version of the gutenberg plugin
• Add a theme that makes use of the get_post_galleries method, eg. ​Arbutus
• Add several posts using the Gallery post type - add a short code, gallery block, and v2 gallery block (turn on gallery experiment to add a v2 block)
• The the homepage of the site and check that all 3 galleries display as expected

Trac ticket: https://core.trac.wordpress.org/ticket/43826

Closed in favour of ​https://github.com/WordPress/wordpress-develop/pull/1788

This is testing well for me.

I tried with Classic Block/short code, v1, v2 galleries

Before

After

[hellofromTonya]

In talking with @glendaviesnz, PR 1788 is needed:

to update an existing method to cope with the new gallery block format that will be merged from gutenberg into core

the method has never worked with gallery blocks anyway, but this fix will make it work for both old and new gutenberg gallery block formats

See ​Gutenberg issue 35907 for context and more details.

Moving this ticket into 5.9 and self-assigning for test and review.

Have added initial unit tests - still need to add some tests for the new gallery format

Galleries in Gutenberg don't use the [gallery] shortcode, so aren't returned by get_post_galleries().

This change makes get_post_galleries() also check for Gallery blocks and return them.

Trac ticket: https://core.trac.wordpress.org/ticket/43826

[glendaviesnz]

To test ​https://github.com/WordPress/wordpress-develop/pull/1788:

Apply the patch to a 5.9 build in local wp dev env

• 5.9 includes the version of Gutenberg needed (11.9) so no need for plugin

• Install the Arbutus theme ​https://wordpress.org/themes/arbutus/ and activate it

• Add a gallery post (post type can be set in editor right settings panel) with v1 version of the gallery blocks - to do this set the use_balanceTags option to 1, eg. wp option set use_balanceTags 1. With this set add a new post of type Gallery, add a gallery block to it and check that it is v1 block - you can tell by clicking on an image in the gallery and seeing that it is the move icons within the image

• Once you have a gallery post with a v1 gallery block set wp option set use_balanceTags 0 and add a new gallery post with a v2 gallery block - you can tell it is v2 by selecting an individual image and it will have its own block tool bar with image editing, duotone, etc

• Add a third gallery post with a gallery short code. You can do this by adding a Classic block, and using the media option in the classic block toolbar to add a gallery

• Visit the site homepage and all three types of gallery should display a gallery excerpt as below:

Without the patch applied only the classic and v1 block will display the gallery excerpt in the home page. The v1 block only displays because Arbutus has a fallback that parses the v1 blocks when get_post_galleries fails to return anything.

This tested well for me on a site running the Arbutus theme which uses get_post_galleries to generate gallery excerpts. This updated call worked for a v1 and v2 gallery block, a gallery blocked nested 2 deep in group blocks, and also for a short code gallery:

LGTM once the failing tests are sorted.

Closing in preference to PR #1864.

[hellofromTonya]

​PR 1864 is ready for commit. It handles both v1 and v2 gallery block. Performance has been considered, analyzed, and tuned.

There are holdups with getting the migration from v1 to v2 gallery block content working (​see GB PR 36191. Per @glendaviesnz,

This hold up has been brought about by the need to block access to sites that have use_balanceTags enabled, but are running WordPress versions < 5.9, and complications with trying to set a flag to alert for the presence of the use_BalanceTags at a point in desktop and mobile before gallery deprecations run.

The migration testing work should not affect the v2 structure which is handled in this ticket and the patch.

If by RC the v2 gallery block is reverted (removed from core), then this ticket's patch can be revisited to determine if the v2 portion should also be reverted.

As today is 5.9 Beta 1, marking this commit.

[dway]

Nice work, thx !

[hellofromTonya]

Preparing the commit.

[hellofromTonya]

In 52190:

Media: Add support for v1 and v2 gallery block in get_post_galleries().

The get_post_galleries() function only handled galleries from the [gallery] shortcode. It did not process gallery blocks.

Introducing v1 and v2 gallery block support in get_post_galleries() including support for innerblock nesting.

There are no changes to how the function is called. It detects if the post content has one or more gallery blocks. If detected, it parses the blocks and then processes to add each gallery block's HTML to the array of galleries before being passed through the filter and returned.

Includes integration tests.

Follow-up to [24682], [43309], [48262], [52042].

Props glendaviesnz, costdev, antpb, audrasjb, birgire, celloexpressions, desrosj, hellofromTonya, jeffpaul, lynk, pento, ramonopoly, russhylov, takahashi_fumiki, tellyworth.
Fixes #43826.

Committed via changeset https://core.trac.wordpress.org/changeset/52190.

[hellofromTonya]

Gallery block support (for v1 and v2) has arrived in get_post_galleries(). Thank you everyone for your contributions! This will ship with 5.9. Cheers

Marking for dev-note and docs update.