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

https://github.com/user-attachments/assets/0b8bde8b-b032-44bc-b3da-03b04f8cc441

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

[github-actions[bot]]

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: 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.