Add server side registration to fix translation

[cbravobernal]

Add server-side registration so we can fix Comment Query Loop title and description not being translated.

More info on the issue.

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

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[github-actions]

Hi @c4rl0sbr4v0! 👋

Thank you for your contribution to WordPress! 💖

It looks like this is your first pull request to wordpress-develop. Here are a few things to be aware of that may help you out!

No one monitors this repository for new pull requests. Pull requests must be attached to a Trac ticket to be considered for inclusion in WordPress Core. To attach a pull request to a Trac ticket, please include the ticket's full URL in your pull request description.

Pull requests are never merged on GitHub. The WordPress codebase continues to be managed through the SVN repository that this GitHub repository mirrors. Please feel free to open pull requests to work on any contribution you are making.

More information about how GitHub pull requests can be used to contribute to WordPress can be found in this blog post.

Please include automated tests. Including tests in your pull request is one way to help your patch be considered faster. To learn about WordPress' test suites, visit the Automated Testing page in the handbook.

If you have not had a chance, please review the Contribute with Code page in the WordPress Core Handbook.

The Developer Hub also documents the various coding standards that are followed:

• PHP Coding Standards
• CSS Coding Standards
• HTML Coding Standards
• JavaScript Coding Standards
• Accessibility Coding Standards
• Inline Documentation Standards

Thank you,
The WordPress Project

[ockham]

Let's maybe add a note somewhere in these comments why we need this file (with a reference to this PR or the discussion in WordPress/gutenberg#41292), as it might otherwise be very tempting to remove it 😬

[ockham]

Confirming that I see the block title translated:

Edit: Compare to trunk:

[ockham]

Thanks, LGTM!

A lot of unit tests are failing, but those seem unrelated to me (?)

[cbravobernal]

A lot of unit tests are failing, but those seem unrelated to me (?)

I'm checking and running on local. Anyway, here there are not reviews-merges, they are done in Trac 😄

[ockham]

I had another look at the unit tests.

All 18 failures are actually the same (although they happen in different locations):

Unexpected incorrect usage notice for WP_Block_Type_Registry::register
Failed asserting that an array is empty.

I had one idea -- maybe we are doing something wrong when registering the block.

Turns out that the PHP for individual blocks is synced from Gutenberg via npm packages (see e.g. 619693e an example).

So basically, we don't really edit src/wp-includes/blocks/my-block.php directly; instead, we:

1. make the changes in Gutenberg to packages/block-library/src/my-block/index.php,
2. publish a new npm version of @wordpress/block-library with those changes, and
3. file a PR against wordpress-develop with a version bump for @wordpress/block-library accordingly. Judging from 619693e, I think that the version bump is generated by running npm run sync-gutenberg-packages

I'm not 100% sure this is the reason for the unit test failure, but it might be. Regardless, it seems to be how block changes need to be made 😅 (And yeah, if wonder if this is documented anywhere.)

[ockham]

I'm not 100% sure this is the reason for the unit test failure, but it might be. Regardless, it seems to be how block changes need to be made 😅

I realize that this might be tricky since we've already changed the directory name to comments in Gutenberg 😕

But here's another thought -- unit tests are specifically complaining about an "incorrect usage notice for WP_Block_Type_Registry::register). So maybe we can at least observe those locally (either when running unit tests, or maybe when running wordpress-develop's development instance).

[ockham]

I managed to track down the incorrect usage notice that's being triggered; it's this:

Block type "core/comments-query-loop" is already registered.

[ockham]

I think that error makes sense; after all, the Comments Query Loop block has already been registered prior to this PR. So now we have to find where that was happening and probably disable it.

[ockham]

I tried grepping for other occurrences of comments-query loop and found this:

wordpress-develop/tools/webpack/blocks.js

Line 92 in a5b555a

'comments-query-loop',

I think this is a likely candidate -- some Webpack plugin that gets information about all static and dynamic blocks, separately.

So I tried moving comments-query-loop from the static to the dynamic section

diff --git a/tools/webpack/blocks.js b/tools/webpack/blocks.js
index 3250df5bbf..05b50d5e4d 100644
--- a/tools/webpack/blocks.js
+++ b/tools/webpack/blocks.js
@@ -38,6 +38,7 @@ module.exports = function( env = { environment: 'production', watch: false, buil
                'comments-pagination-next',
                'comments-pagination-numbers',
                'comments-pagination-previous',
+               'comments-query-loop',
                'cover',
                'file',
                'gallery',
@@ -89,7 +90,6 @@ module.exports = function( env = { environment: 'production', watch: false, buil
                'code',
                'column',
                'columns',
-               'comments-query-loop',
                'embed',
                'freeform',
                'group',

I then ran npm run build, which unfortunately failed:

Running "webpack:prod" (webpack) task
ERROR in unable to locate 'wordpress-develop/node_modules/@wordpress/block-library/src/comments-query-loop/index.php' glob

webpack compiled with 1 error

Which makes sense, since the @wordpress/block-library package doesn't have a comments-query-loop folder (but a comments one, per our rename) 😕

I wonder if we'll have to do an npm release with that rename reverted 😕

cc/ npm expert in residence @gziolo

[gziolo]

We forgot to list the block here:

wordpress-develop/src/wp-includes/blocks/index.php

Lines 77 to 114 in a5b555a

	function register_core_block_types_from_metadata() {
	$block_folders = array(
	'audio',
	'button',
	'buttons',
	'code',
	'column',
	'columns',
	'embed',
	'freeform',
	'group',
	'heading',
	'html',
	'list',
	'media-text',
	'missing',
	'more',
	'nextpage',
	'paragraph',
	'preformatted',
	'pullquote',
	'quote',
	'separator',
	'social-links',
	'spacer',
	'table',
	'text-columns',
	'verse',
	'video',
	);
	foreach ( $block_folders as $block_folder ) {
	register_block_type(
	ABSPATH . WPINC . '/blocks/' . $block_folder
	);
	}
	}
	add_action( 'init', 'register_core_block_types_from_metadata' );

@adamziel has a patch that is nearly ready to land that automates the whole process to avoid future mistakes:

#2647

For the 6.0.1 release, we will need a manual patch in the 6.0 branch that just adds the name of the block to the list.

[cbravobernal]

Closed in favor of #2921

[SergeyBiryukov]

All 18 failures are actually the same (although they happen in different locations):

Unexpected incorrect usage notice for WP_Block_Type_Registry::register
Failed asserting that an array is empty.

I had one idea -- maybe we are doing something wrong when registering the block.
...
I managed to track down the incorrect usage notice that's being triggered; it's this:

Block type "core/comments-query-loop" is already registered.

Just to follow up on this, I've committed a change to the test suite in r53637 to always include the actual _doing_it_wrong() message or deprecation notice in the output if one is encountered, which should hopefully make it easier to track down issues like this in the future 🙂