Add filter to disable PostAuthor

[mkaz]

Description

Adds a filter to the PostAuthor component which allows to override with a custom component.

How has this been tested?

• Confirm the author field shows fine before/after apply the patch

• In the plugin or theme that wants to override the component, use the following JavaScript code, remember to include 'wp-hooks', 'wp-element' in your enqueue dependency array.

var MyComponent = wp.element.createElement( 'div', {}, 'My Authors Content' );
wp.hooks.addFilter( 'editor.PostAuthor', 'myplugin', function() { return MyComponent; } );

• Confirm the Author box no longer displays, instead you should see "My Authors Content"

Types of changes

This extends gutenberg with the editor.PostAuthor filter giving developers a hook to control the component for PostAuthor.

Checklist:

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

[georgeh]

Tested and confirmed that I was able to remove the see the author dropdown, and that adding the filter in the documentation removed the input.

[chrisvanpatten]

It'd be nice to get some direction on whether it's worth filtering just the hiding of the box, vs. going a step further and making the component fully filterable so you can replace it entirely. Interesting idea though; definitely can see how it'd be useful to make this more flexible (Co-Authors Plus could benefit, for instance)

[mkaz]

@chrisvanpatten Co-Authors-Plus is exactly the use case, their quick fix was this PR Automattic/Co-Authors-Plus#630 which is far from ideal.

My thought was that a multiple author plugin stores data in a different way, that it is beyond what the current component does. I suppose a new component provided by the plugin could handle the data the same way it would if it implemented as a sidebar module.

I'm open to the idea of a filter that allows replacing <PostAuthor/> with something like <CoAuthorPlus/> if that could work

[mkaz]

@chrisvanpatten @mtias - updated with a different approach using a full component passed in to filter to switch it out. I welcome feedback.

For the CoAuthorsPlus use case, it will require them to fully embrace Gutenberg and write a component to integrate. However, this seems like the much better and more flexible path to take.

[gziolo]

We should mirror the solution used in other places and wrap PostAuthor component with withFilter HOC as it is always used with PostAuthorCheck anyways. See: https://github.com/WordPress/gutenberg/blob/master/packages/edit-post/src/components/sidebar/post-author/index.js#L9.

See PostFeaturedImage as an example: https://github.com/WordPress/gutenberg/blob/master/packages/editor/src/components/post-featured-image/index.js#L146

[gziolo]

See also the first part of README file for PostFeaturedImage in @wordpress/editor to check how it can be used in action: https://github.com/WordPress/gutenberg/blob/master/packages/editor/src/components/post-featured-image/README.md

[mkaz]

Thanks @gziolo so much better (and easier).

I was pointed to PostFeatureImage as an example to look at but started off in the wrong direction, I looked at just this piece: https://github.com/WordPress/gutenberg/blob/master/packages/editor/src/components/post-featured-image/index.js#L35

Updated and included a readme for the component documenting how to extend it properly.

[chrisvanpatten]

The docs look good to me!

[gziolo]

It looks good, thanks for updating 👍

[youknowriad]

Like we discussed in previous #core-js chats, we should resist adding new filters/actions.
An alternative here would be to build a custom edit-post module.

[gziolo]

It is part of the Post & Status panel, so it had to be re-created from scratch. I think we should introduce all missing filters for the elements we put in the sidebar for backward compatibility and consistency. However, we should stop doing it in other places unless there is a really good reason to do so. I can't think of any at the moment :)