Fix author information leakage by author blocks for Custom Post Types without author support & display notice to user

[sarthaknagoshe2002]

fixes: #65816

What?

This PR updates the behavior of author blocks to ensure they do not render when the post belongs to a Custom Post Type (CPT) that does not explicitly declare support for the author feature.

Why?

Author blocks displaying on CPTs without declared author support is inconsistent with WordPress behavior.
This can lead to unintentional data exposure, as WordPress still saves author information to the database even when it is not intended to be visible.
Ensures better security, consistency, and adherence to user expectations for CPTs.

How?

• Added a conditional check in the rendering logic of the author blocks to verify if the CPT supports the author feature.
• If the feature is unsupported, a message is displayed in the editor notifying users that the block will not render on the frontend.
• Updated the frontend output to prevent leaking author information when the CPT does not support authors.

Testing Instructions

Reproduction:-

1. Create a Custom Post Type (CPT) without declaring support for the author feature:

add_action( 'init', function() {
    register_post_type( 'custom-post', array(
        'public' => true,
        'supports' => array( 'title', 'editor', 'custom-fields' ),
    ) );
} );

2. Add a post to the newly created CPT.
3. Add an author-related block (e.g., Post Author) in the block editor for that CPT post.
4. View the post on the frontend.

Expected Outcome:-

1. In the Editor:

   • A message is displayed informing users that the author block will not render because the CPT does not support the author feature.

2. On the Frontend:

   • The author block does not render, and no author information is displayed.

Screenshots or screencast

author.blocks.mov

The suggestion given by @dhruvang21 is also used in this PR from the comment

[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: sarthaknagoshe2002 <sarthaknagoshe2002@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: fabiankaegy <fabiankaegy@git.wordpress.org>
Co-authored-by: jameskoster <jameskoster@git.wordpress.org>
Co-authored-by: dhruvang21 <dhruvang21@git.wordpress.org>
Co-authored-by: groenroos <groenroos@git.wordpress.org>

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

[Mamaduka]

Thanks for contributing, @sarthaknagoshe2002!

I'm unsure if we need to modify the block's edit components. People with access to the editors can also access details about post type author.

If it's decided to display a notice in edit components, it should probably be a part of rendered content and not an editor notice.

cc @WordPress/gutenberg-design

[sarthaknagoshe2002]

If it's decided to display a notice in edit components, it should probably be a part of rendered content and not an editor notice.

@Mamaduka Can you elaborate more on this?

[Mamaduka]

The blocks could render static text/warning in the editor when the post type doesn't support authors. But as I mentioned, I'm unsure if that warning makes sense in the editor context.

Rought Example

[sarthaknagoshe2002]

@Mamaduka I have implemented your suggestion now.
In future if we conclude that the warning makes sense in the editor context then we can proceed with the merge.

Screenshot

[sarthaknagoshe2002]

I believe that the warning definitely makes sense in the editor context since displaying warnings/errors on the frontend doesn't seem appropriate.

Also, as you suggested static warning makes sense too.

[sarthaknagoshe2002]

@Mamaduka Any updates on how we should proceed with this PR?

[Mamaduka]

@sarthaknagoshe2002, I left a couple of suggestions. Still looking for design feedback before final approval.

P.S. There's also a proposal to deprecate Post Author block - #53427, but the information leaking issue also applies to deprecated blocks.

[jameskoster]

If it's decided to display a notice in edit components, it should probably be a part of rendered content and not an editor notice.

I agree with this, assuming you mean these inline warning notices (obviously with a different message):

Something like:

This post type ($post_type) does not support Authors. [Remove block]

Additionally, should those blocks be hidden in the Inserter when editing a template associated with a post type that doesn't support them?

[Mamaduka]

Thanks, @jameskoster!

Yes, the block editor warning component can work in this case.

Additionally, should those blocks be hidden in the Inserter when editing a template associated with a post type that doesn't support them?

Generally, a template-aware inserter would be cool, but hiding blocks without context as to why they're hidden can be confusing.

[sarthaknagoshe2002]

@fabiankaegy @Mamaduka I’ve addressed the feedback.

@jameskoster I’ve updated the message to This post type ($post_type) does not support Authors. However, I’m unsure how to implement the [Remove block] functionality. Could you please guide me on this?

[jameskoster]

I'm not actually sure myself, sorry. Maybe @Mamaduka knows 🤞

[fabiankaegy]

@sarthaknagoshe2002 you can remove a block like so:

const BlockEdit = (props) => {
    const { clientId } = props;
    const { removeBlock } = useDispatch( blockEditorStore );
    
    return (
        <Button onClick={() => removeBlock(clientId)} isDestructive>Remove</Button>
    );
}

[Mamaduka]

I think there's no need to use the warning component and separate the removal action. Why?

• The severity of missing author support is negligible. It won't break or affect anything on the front end. You don't need the Waning component to grab the user's attention.
• Users can use toolbar options to remove the block.

@sarthaknagoshe2002 left minor suggestions regarding translation comments and string. After that, I think we're good to merge.

Screenshot

[Mamaduka]

@fabiankaegy, the block editor component will receive the onRemove callback via props. But as I mentioned in my previous comment, I think there's no need to implement it.

gutenberg/packages/block-editor/src/components/block-list/block.js

Line 126 in 3159fa2

onRemove={ canRemove ? onRemove : undefined }

[fabiankaegy]

@fabiankaegy, the block editor component will receive the onRemove callback via props. But as I mentioned in my previous comment, I think there's no need to implement it.

gutenberg/packages/block-editor/src/components/block-list/block.js

Line 126 in 3159fa2

onRemove={ canRemove ? onRemove : undefined }

🤯 very good to know thank you :)

[sarthaknagoshe2002]

@Mamaduka I’ve addressed the changes, and I believe this is now ready to be merged.