Date block: Allow connecting to Block Bindings #70585
Merged
+719
−144
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ockham
added
[Type] Experimental
|
Size Change: +308 B (+0.02%) Total Size: 1.89 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in 8f77685. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/16351551233
|
ockham
force-pushed
the
try/date-block-with-block-bindings
branch
2 times, most recently
from
75013ae to
81964e1
Compare
ockham
commented
Jul 16, 2025
Comment on lines
68
to
80
| const { __unstableMarkNextChangeAsNotPersistent } = | ||
| useDispatch( blockEditorStore ); | ||
|
|
||
| // We need to set the date to a default value upon first loading | ||
| // to discern the block from its legacy version (which would default | ||
| // to the containing post's publish date). | ||
| useEffect( () => { | ||
| if ( date === undefined ) { | ||
| __unstableMarkNextChangeAsNotPersistent(); | ||
| setAttributes( { date: new Date() } ); | ||
| } | ||
| }, [ date ] ); | ||
|
|
There was a problem hiding this comment.
This is largely inspired by #43112.
ockham
commented
Jul 22, 2025
| @@ -623,7 +623,7 @@ Display the publish date for an entry such as a post or page. ([Source](https:// | |||
| - **Name:** core/post-date | |||
| - **Category:** theme | |||
| - **Supports:** color (background, gradients, link, text), interactivity (clientNavigation), spacing (margin, padding), typography (fontSize, lineHeight), ~~html~~ | |||
| - **Attributes:** displayType, format, isLink, textAlign | |||
| - **Attributes:** datetime, format, isLink, textAlign | |||
There was a problem hiding this comment.
Using datetime (rather than just date) as the block can still be bound to the post's publish date, which is really a timestamp that includes the time (and can be set from the block toolbar's "pencil" icon via a DateTimePicker).
ockham
force-pushed
the
try/date-block-with-block-bindings
branch
from
07f1d7d to
fa2edfb
Compare
ockham
requested review from
spacedmonkey,
ellatrix,
ajitbohra,
fabiankaegy,
juanmaguitar and
ndiego
as code owners
|
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 If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
ockham
changed the title
|
The PR works as expected. Is adding a new source, that will appear on the UI along with Post Meta. Is that expected? According to the UI, we did it to show different sources that way, so my opinion is that it is, indeed. 
|
| if ( get_the_modified_date( 'Ymdhi', $post_id ) > get_the_date( 'Ymdhi', $post_id ) ) { | ||
| return esc_attr( get_the_modified_date( 'c', $post_id ) ); | ||
| } else { | ||
| return ''; |
There was a problem hiding this comment.
Will an empty string cause some confusion to the user?
There was a problem hiding this comment.
Possibly. But I needed to keep this for backwards-compatibility with the block's previous behavior for the "Modified Date" variation.
I don't love it 100%, but there didn't seem to be a compelling argument against it, so I kept it this way 🤷♂️
| @@ -7,6 +7,9 @@ | |||
| "description": "Display the publish date for an entry such as a post or page.", | |||
| "textdomain": "default", | |||
| "attributes": { | |||
| "datetime": { | |||
| "type": "string" | |||
There was a problem hiding this comment.
Should we add role:content for a future reference to a binding?
There was a problem hiding this comment.
Yes, that sounds like a good idea 👍
cbravobernal
approved these changes
Jul 23, 2025
Yeah, my thinking was that information like a post's publish date and last modified date should be presented as part of a dedicated source. Eventually, that source could also expose information such as a post's title, author, etc. It's definitely distinct from post meta, which is typically used defined meta information. Post Data seemed like a fitting name for what we're exposing here. |
sirreal
reviewed
Jul 23, 2025
Co-authored-by: Mukesh Panchal <[email protected]>
ockham
force-pushed
the
try/date-block-with-block-bindings
branch
from
685800d to
bf2ecd5
Compare
|
I've pushed another commit to add the variations to the
|
21 tasks
gziolo
added
[Feature] Block bindings
[Type] Enhancement
gziolo
reviewed
Jul 29, 2025
Comment on lines
+44
to
+49
| label: 'Post Date', | ||
| value: entityDataValues?.date, | ||
| type: 'string', | ||
| }, | ||
| modified: { | ||
| label: 'Post Modified Date', |
There was a problem hiding this comment.
Both labels should be translatable.
There was a problem hiding this comment.
Oversight on my part! I'll address in a follow-up.
|
Excellent work refactoring the Date block in a way that allows to support custom dates, while offerring variations for the publish and modified dates directly wired to post data through Block Bindings. This is a great example of how flexible blocks could become when using proper APIs. What's the plan regarding the Post Data source and exposing other available fields like status, slug, author, featured media, etc? |
dmsnell
reviewed
Jul 29, 2025
There was a problem hiding this comment.
Noting here to call it out: we’re returning data that has been passed through esc_attr(), and this is extremely ambiguous because there’s no exit from this function directly to the browser.
I think we saw that there’s no current way to indicate where this data goes, but it would be good to ponder all of these and think of a way we could work in data-escaping and security into the design if we can.
This probably cannot happen from these functions either, simply because these functions do not exist in the right place in the pipeline to know what escaping needs there are.
Luckily esc_attr() and esc_html() happen to be the same function today in WordPress, but this doesn’t prevent the potential for data corruption via double-escaping.
|
|
||
| if ( 'modified' === $source_args['key'] ) { | ||
| // Only return the modified date if it is later than the publishing date. | ||
| if ( get_the_modified_date( 'Ymdhi', $post_id ) > get_the_date( 'Ymdhi', $post_id ) ) { |
There was a problem hiding this comment.
the U option seems like it would reliably compare without us needing to ensure that we get all the right date field formats in the string. It should return the seconds since Unix Epoch.
There was a problem hiding this comment.
Good point. This is pre-existing logic that I carried over, but I like yours much better.
We can start exposing those! I can file a PR to add a few more fields. |
I may need it too for Featured Image :-) |
adamsilverstein
pushed a commit
to adamsilverstein/gutenberg
that referenced
this pull request
Jul 31, 2025
Make the Date block accept a manually set date, i.e. independent of the current post's publish or last modified date. Retain the latter two options by introducing a new Block Bindings source called `core/post-data` that exposes those two dates. Update existing block variations of the Date block to continue to allow easy insertion of the "Post Date" and "Last Modified Date" variations of the block. Include code for back-compat in the block's PHP, and a block deprecation to update existing Date blocks to use the new Block Bindings-based approach. --------- Co-authored-by: Mukesh Panchal <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
Make the Date block accept a manually set date, i.e. independent of the current post's publish or last modified date. Retain the latter two options by introducing a new Block Bindings source called
core/post-datathat exposes those two dates.Update existing block variations of the Date block to continue to allow easy insertion of the "Post Date" and "Last Modified Date" variations of the block.
Include code for back-compat in the block's PHP, and a block deprecation to update existing Date blocks to use the new Block Bindings-based approach.
Why?
Various reasons: The block already supports the publish date of the post, and the "last modified" date. It's a natural extension to connect it to other data sources. One real-world example that inspired this PR was e.g. a director's website with a
filmCPT that had the movie's release as one meta field.How?
In order to connect the block to Block Bindings, we need an explicit date attribute for Block Bindings to connect to.
Problem(s) to solve
Prior to this PR, the block used the
__experimentalPublishDateTimePickerto set the post (publish) date and time, as that date picker also allows setting the time. For back-compat, it might be easiest to continue storing date and time in all cases; for that, we should probably rename the newly introduced attribute todatetime.Testing Instructions
Start by testing backwards compatibility:
On the
trunkbranch, create a new post, and insert the "Date" block, and "Modified Date" blocks.Check the code editor; the markup should look like this:
Go back to the visual editor. Set the post's publish date to an earlier date (e.g. yesterday).
Publish the post and view it on the frontend. It should look something like this:
Now switch to this PR's branch, rebuild Gutenberg, and reload the page on the frontend. Verify that the blocks still look the same as before.
Go back to the editor and reload it. Make a small change (e.g. add a new paragraph with a few characters), and switch to the Code Editor. Verify that the blocks have been updated by a block migration. They are now using Block Bindings:
Go back to the Visual Editor. Observe that the first block is now called "Post Date". Save the post again. Once again, view it on the frontend, and verify that it still looks the same as before.
Go back to the editor once more. Insert a "Date" block. In the block's toolbar, use the pencil icon to set an arbitrary date. Save the block, view the post on the frontend, and verify that all three blocks render as expected.
Finally, open a template in the Site Editor that contains a query loop with Post Date blocks. Verify that the block instances work fine there as well.
Screenshots or screencast
Before
Date (i.e. post publish date) and Modified Date blocks:
After
Post Date (i.e. post publish date), Modified Date, and "generic" Date block (that can be used to format a manually entered date):
Note that the Post Date block changes upon publish -- this is because the post wasn't previously published, so clicking "Publish" sets the post publish date, and the block reflects it.