A page attributes panel slot now exists

[philwp]

What?

Adding a Slot on the Page Attributes Panel

Why?

This resolves #31888 and allows plugin authors to extend that panel with additional information.

How?

Added a new Slot PluginPageAttributesPanel which adds a new panelRow below the panel items from core. This is essentially mimicking the behavior provided by the page_attributes_misc_attributes hook.

Testing Instructions

1. Register a plugin

const MyPageAttributes = () => {
    return (
        <PluginPageAttributesPanel className="different">
			<p>
				{ __(
					'Add some page attributes',
					'gutenberg-slot-fill-system'
				) }
			</p>
		</PluginPageAttributesPanel>
    );
}
// Register the plugin.
registerPlugin( 'my-page-attributes', { render: MyPageAttributes } );

2. See that it appears in the page attributes panel in the editor while editing a page.

Testing Instructions for Keyboard

Screenshots or screencast

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: philwp <philwebs@git.wordpress.org>
Co-authored-by: colorful-tones <colorful-tones@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: youknowriad <youknowriad@git.wordpress.org>
Co-authored-by: fabiankaegy <fabiankaegy@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[colorful-tones]

"Phil's Fill" love it! 😆

[Mamaduka]

Thanks for contributing, @philwp!

Do you mind rebasing your branch on top of the latest trunk and resolving the merge conflict?

[youknowriad]

Thanks for the work here.

I think this raises the question about whether or not we want these panels to be extended like that or instead removed and replaced. Personally I lean towards "removed and replaced" instead because the extension point here is not clear. What happens if we redesign the panel, if we move it elsewhere...

[philwp]

@youknowriad

I think this raises the question about whether or not we want these panels to be extended like that or instead removed and replaced

My question would be why not both? Allowing a user to remove the entire panel does make sense, but if a user wants to extend that panel, it would be better to allow them to just extend the existing panel.

[youknowriad]

My question would be why not both? Allowing a user to remove the entire panel does make sense, but if a user wants to extend that panel, it would be better to allow them to just extend the existing panel.

@philwp mostly because a slot is not a very good extensibility API in random components like that. It's like a placeholder for random things, if the design of said components changes or we decide to split it into multiple places/fields... it becomes kind of useless or breaks. In other words, I'm not sure a slot with small components like that is a good forward compatible API. It happened in the past already that we introduce slots in places like that and regret them. (PostExcerpt comes to mind)