Gutenberg: un/register_pattern() function names violate WordPress naming guidelines

[JJJ]

Describe the bug

Introduced in #21074, the new register_pattern() and unregister_pattern() function names violate the WordPress function naming guidelines.

Emphasis mine:

let the code be unambiguous and self-documenting.

Expected behavior

I expect for PHP functions intended to be merged into WordPress to follow the naming guidelines. A "pattern" could be related to anything, and does not provide enough information alone to inform developers _what kind_ of pattern is being registered.

Is it for permalinks? Some other regular expression? Is it a background pattern?

Editor version (please complete the following information):

• WordPress version: Any
• Does the website has Gutenberg plugin installed, or is it using the block editor that comes by default? Gutenberg plugin
• If the Gutenberg plugin is installed, which version is it? Latest

Desktop (please complete the following information):

• OS: Any
• Browser: Any
• Version: Any

Smartphone (please complete the following information):

• Device: Any
• OS: Any
• Browser: Any
• Version: Any

Additional context

I was directed by @youknowriad to create a new issue to re-open discussion regarding these function names.

Make Post

Developer docs

The argument against renaming these functions seems to be one of parity with the name of the feature inside of Gutenberg. This argument comes from contributors who have a deep understanding of what they have envisioned a "pattern" to be.

This perspective fails to take into account preexisting patterns in WordPress itself and the thousands of plugins already in existence. Deeply considering permalinks for a moment, registering custom post types and taxonomies interact with complex regular expression patterns, which do pattern matching to identify what content to render from the database to the browser.

Something like permalink patterns have existed in WordPress for over 10 years, amongst several other APIs that use regular expressions or other "pattern" like paradigms. It is safe to speculate that function names such as register_permalink_pattern() would make more sense than register_pattern() within that context, hence the same goes for Block Patterns.

I believe these function names need to be promptly reconsidered before too many people start using them in their own code.

Thank you for your kind consideration. 💙

[JJJ]

A colleague reminded me that register_block_type() and register_block_style() already exist as PHP functions in WordPress.

Without _block_ as a descriptor, the function names would fail to follow the already established function naming _pattern_ in WordPress.

Omitting it here and now is a consistency break. A function named register() would not immediately be recognized as being for Blocks, similar to register_style() or register_type() or register_pattern() not being related to Blocks unless it includes it in the function name.

[youknowriad]

here my own reasoning

A colleague reminded me that register_block_type() and register_block_style() already exist as PHP functions in WordPress.

These are block specific settings, "patterns" are not, they are more "HTML" composed of blocks (or not)

We're going to refer to these was "Patterns" in the UI, I find it confusing to have a name for the UI and a different name for the APIs.

I'm open to change though.

cc @WordPress/gutenberg-core for more thoughts

[swissspidy]

What about register_ui_pattern or register_block_pattern or something? The current name is indeed ambiguous IMO. If I'd encounter register_pattern anywhere in the code refernece, I'd have no clue what it's about.

[mtias]

I'd be fine with register_block_pattern or register_design_pattern even if in the UI (which has more context than a function name) we show it just as "pattern".

[JJJ]

they are more "HTML" composed of blocks (or not)

Can you help educate me on the or-not part? What part(s) of a UI Pattern inside of Gutenberg are not blocks? Are there future plans to move away from blocks?

[youknowriad]

@JJJ there's no intention of moving away from blocks. I was just referring to the fact that patterns are defined as HTML parsed as blocks for edition, but that HTML can contain anything.