Add block bindings support: core/post-date:isLink

[JDeepD]

Enable block bindings for the core/post-date block's isLink attribute

Editor-side, the Attributes panel was previously hidden entirely for core/post-date to prevent the datetime attribute from being bound to incompatible sources (#72712). Replaced that all-or-nothing block-level hiding with a per-attribute map so the panel can expose isLink while keeping datetime hidden (the latter remains managed through the block's variations). Resetting the panel now only clears the visible bindings, leaving the variation-managed datetime binding intact.

Server-side, register isLink as a supported attribute through the block_bindings_supported_attributes filter. The
block's existing render callback already wraps the date in a link based on isLink, so no render changes are needed.

What?

Closes #78851 (See for the core/post-date block)

Enables block bindings for the core/post-date block's isLink attribute. This block already supported binding its datetime attribute; this PR adds isLink and unhides the bindings "Attributes" panel for the block, while keeping datetime out of that panel.

Why?

For core/post-date, datetime was already supported; isLink is the remaining attribute on the audit list.

The Attributes panel was previously hidden entirely for core/post-date (#72712) to prevent its datetime attribute from being bound to incompatible (non-date) sources, which would break the block. That all-or-nothing approach also prevented exposing any other attribute, like isLink. This PR replaces it with a finer-grained mechanism so isLink can be exposed safely while datetime stays hidden.

How?

Editor-side:

• Removed core/post-date from the panel's hasSupport blocklist so the Attributes panel renders for the block again.
• Introduced a per-attribute HIDDEN_BLOCK_BINDINGS_PANEL_ATTRIBUTES map that keeps datetime hidden from the panel (it remains managed through the block's variations, where it's safely bound to core/post-data), while exposing isLink.
• Scoped resetAll so it only clears the visible bindings, leaving the variation-managed datetime binding intact.

Server-side:

• Registered isLink as a supported attribute via the block_bindings_supported_attributes filter. The block's existing render callback already wraps the date in a link based on isLink, so no render changes are needed.

Testing Instructions

A binding source exposing a boolean field is needed to connect isLink (it's a boolean attribute). The quickest way is to register a boolean post-meta field:

add_action( 'init', function () {
    register_post_meta( 'post', 'is_link_field', array(
        'type'         => 'boolean',
        'single'       => true,
        'show_in_rest' => true,
        'default'      => true,
    ) );
} );

1. Create or edit a Post.
2. Insert a Post Date block and select it.
3. Open the Settings sidebar and confirm the Attributes panel is now shown.
4. Confirm the panel lists isLink but does not list datetime.
5. Connect isLink to the is_link_field custom field.
6. View the post on the frontend: with the meta value true, the date is wrapped in a link to the post; set it to false and the date renders as plain text.
   • The meta values, for testing purposes, can be changed using the CLI:
   • npm run wp-env run cli wp post meta update <POST_ID> is_link_field 1
   • npm run wp-env run cli wp post meta update <POST_ID> is_link_field 0

Testing Instructions for Keyboard

1. Insert a Post Date block and move focus to it.
2. Open the Settings sidebar (Ctrl/Cmd + Shift + ,).
3. Tab to the Attributes panel and confirm isLink is reachable and operable via keyboard (Enter/Space to open the menu, arrow keys to navigate sources/fields).
4. Confirm datetime is not present in the panel.

Screenshots or screencast

Before	After

Use of AI Tools

• AI tooling (Claude Opus4.8, Gemini 3.1 Pro) was used to investigate the existing block bindings architecture, code completions and improve test coverage.
• All changes are reviewed and tested by me.

[github-actions]

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Required label: Any label starting with [Type].
• Labels found: .

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

[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: JDeepD <jdeep@git.wordpress.org>
Co-authored-by: kushagra-goyal-14 <kush123@git.wordpress.org>
Co-authored-by: cbravobernal <cbravobernal@git.wordpress.org>

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

[github-actions]

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @JDeepD! In case you missed it, we'd love to have you join us in our Slack community.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.