Add generic has_blocks function

[obenland]

See #4418.

Description

Merges gutenberg_post_has_blocks() and gutenberg_content_has_blocks(), resulting in a template function that can be used context-independently.
It accepts a content string, a post object, or post ID, and default to the current post if none of those are given. Make this part of the API behave close to existing WordPress template functions.

It's my first Gutenberg PR, so I'd love to get feedback on this, especially around a better phpunit setup potentially?

How has this been tested?

I added unit tests and ran those, as well as navigating around post and page edit screens.

Types of changes

• Introduces has_blocks().
• Deprecates gutenberg_post_has_blocks() and gutenberg_content_has_blocks().
• Replaces existing uses of gutenberg_post_has_blocks() and gutenberg_content_has_blocks().
• Adds PHP unit tests for has_blocks().

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.

[mtias]

It has been brought up the potential for conflicts with function names. We might need to prefix with wp_ here. But then the name can be seen as misleading "WordPress has blocks" (well, of course it does!).

Do we have similar functions in core that we should model after?

[andreilupu]

In core, I can think of has_shortcode has_excerpt has_category or has_custom_logo.

Functions implemented with wp_* seem to be related to actions like wp_{action}_{object} like wp_get_nav_menu or wp_get_attachment_{meta}.

I would vote for wp_ prefix just to make a difference from PHP native functions like is_string is_readable file_exists.

Anyway, I'm also thinking about this topic in #8340, and I would love to follow the decision here. In that case, I was thinking about a formula like wp_{who}_has_{what} for example:

• wp_post_has_block where the $post parameter can be defaulted for $post global as many WordPress functions do
• wp_content_has_block Utility to quickly search for a block in a piece of content (maybe widgets content or excerpts.)

Aside: And I don't even want to think about the fact that there may be a semantic difference between block and block_type.

[aduth]

Chiming in with my own thoughts:

• Consistency is important. If there's already has_shortcode, has_excerpt, etc. the thought of introducing wp_has_blocks is worrying merely in that it breaks convention and therefore expectations of the developer.
  • On point of consistency, I'm a bit disappointed to see that has_shortcode accepts a string while has_excerpt accepts a post object. And then this function here accepts either / or 😬
• Conflicts could occur, but the plugin handbook already prescribes recommendations to avoid naming conflicts
• Recent additions have been introduced without prefix, e.g. register_rest_route
• Whatever decision is made should probably be made and adopted universally, so that this discussion doesn't come up on every addition of a new core function 😆

[mtias]

Yes, we should probably move this chat to the umbrella issue, as that was the point of it, to avoid repeating similar conversations in multiple PRs :D

[aduth]

Aforementioned issue: #8352

[aduth]

Given #8352 (comment) and linked discussion in Slack meeting, I'm inclined to think this should remain has_blocks as proposed, for consistency with existing comparable WordPress function names.

[aduth]

Is this the same as #8340 ?

[obenland]

Is this the same as #8340 ?

For posterity since it was already answered in #8340 (comment), this one is about a generic has_blocks() while #8340 checks for a specific block.

[pento]

Nice work, thanks @obenland!

Because I wasn't online for core dev chat, I'll note here that has_blocks() is the correct name to use here. 🙂

[mtias]

🎉