Admin name not showing when making a post

[itsonlybarney]

Not sure , if this has been reported, but when I'm posting a new post, because I have a number of contributors to the site, the only names in the Author list as those who are contributors, and the Administrator isn't present in the list.

I have attached a screenshot of the problem I'm finding, in the screenshot I'm logged in as the administrator, and attempting to edit a post prior to publishing the post as myself as the Author.

[itsonlybarney]

Screenshot of only contributors being shown as Author of the article

[foolswisdom]

ENV: trunk
Unable to reproduce on trunk r6256

itsonlybarney, thank you for participating in WordPress development!

In the future please provide reproduction steps and give your attachments a file name that suggests the issue it demostrates.

Is this an existing WordPress installation, or a new one? What version of WordPress did you set it up? Were you able to duplicate it in a testing environment? Clean install?

This sounds like a previously fixed issue, #2818. Marking as duplicate pending additional feedback.

[itsonlybarney]

I have created this using WP 2.3 with minimal plugins. I have also tried this on a same server with a different configuration path.

It is the same problem as 2818, but it still appears even in 2.3. Is there a work around/patch for it, or will it continue to plague WP?

[rob1n]

Not really "plaguing" IMO.

[MichaelH]

@itsonlybarney - The big question is, at what version was the admin user created? Was the blog installed at 2.3? If so, then I'd say the problem persists. If you upgraded from earlier versions then the problem could have been created at those versions. This problem has yet to be duplicated so devs can fix.

See these for more discussions and work-arounds:

*​http://wordpress.org/support/topic/105985

*​http://wordpress.org/support/topic/107612

*​http://wordpress.org/support/topic/118633

*​http://wordpress.org/support/topic/118963

*​http://wordpress.org/support/topic/138611

*​http://wordpress.org/support/topic/134410 (that last one is new 2.2.3 site)

[foolswisdom]

Closing as dup, pending answers to MichaelH's qeuestions.

WIP. Based on #5158.

Trac ticket: TBD

Rebased.

One more place to include block_hooks:

​https://github.com/WordPress/wordpress-develop/blob/943e2b95511794417d545ca06fa22c0167391267/src/wp-admin/includes/post.php#L2216-L2234

One more place to include block_hooks:

​https://github.com/WordPress/wordpress-develop/blob/943e2b95511794417d545ca06fa22c0167391267/src/wp-admin/includes/post.php#L2216-L2234

Thank you @gziolo!

[...] the key is the block name that can be anything that matches the pattern for the block name. If that helps we could include the pattern also for the name field:

​https://github.com/WordPress/wordpress-develop/blob/72de12010b0bd67f814e699705e709f3a125351e/src/wp-includes/rest-api/endpoints/class-wp-rest-block-types-controller.php#L478-L484

That reminded me of something else; maybe we can cross-reference the name field in the block_hooks schema definition? Would make it more semantic -- we'd basically state, "The keys in block_hooks are block names.".

I see there is custom logic for mapping blockHooks to block_hooks. I'd like to work on a follow-up to cover that part with unit tests. before case is covered indirectly by other values still could use some testing.

Ah yeah, that's a fair point; especially for the camelCase -> snake_case mappings.

One last bit of feedback is for the _doing_it_wrong logic. I like that there is additional security enforced. I'm wondering if we should move it to the WP_Block_Type class though, to cover also the case when someones registers the block with:

register_block_type( 'my-plugin/my-block', array(
    'block_hooks' => array(
        'my-plugin/my-block': 'first_child',
    ),
) );

FWIW, register_block_type actually calls register_block_type_from_metadata for block registration, so your example should already be covered: ​https://github.com/WordPress/wordpress-develop/blob/e005108fe18e6278f4e6dd0fec030e503fe0ff46/src/wp-includes/blocks.php#L584-L590

(We might want to add some unit test for this too, BTW 🤔 )

It also reminds me that in genera; there isn't that much sanitization present on the code for settings provided during block registration which I find a bit unforunate.

Yeah, good point!

Committed to Core in https://core.trac.wordpress.org/changeset/56587.

In ​https://github.com/WordPress/wordpress-develop/pull/5218 I added some refactorings discussed above:

• ​https://github.com/WordPress/wordpress-develop/pull/5203#discussion_r1326102815 - gutenberg text domain remove
• There is custom logic for mapping blockHooks to block_hooks when handling metadata. I covered that part in unit tests.
• One last bit of feedback was for the _doing_it_wrong logic. I moved the check to the WP_Block_Type class to cover also the case when someone registers the block with a regular register_block_type call without using metadata file.