Date block: Allow connecting to Block Bindings #70585
Conversation
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
| 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.
| - **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
ajitbohra,
ellatrix,
fabiankaegy,
juanmaguitar,
ndiego and
spacedmonkey
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. 
|
| "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 👍
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. |
gziolo
added
[Feature] Block bindings
[Type] Enhancement
| 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? |
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.
We can start exposing those! I can file a PR to add a few more fields. |
I may need it too for Featured Image :-) |
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]>
| $formatted_date = get_the_date( empty( $attributes['format'] ) ? '' : $attributes['format'], $post_ID ); | ||
| $formatted_date = gmdate( empty( $attributes['format'] ) ? get_option( 'date_format' ) : $attributes['format'], $post_timestamp ); |
|
👋 - I came across this PR and I think the block's description should change when we have a simple editable Also personally I found it a bit confusing that the |
That's a very good point 👍 We'll file a PR to make that change.
Not sure I'm 100% following; can you rephrase? FWIW, if the "default" block variation is used, the date picker allows setting a custom date; it won't change the publish date. If the "Post Date" variation is used, the date picker will update the publish date. (The idea being that the |
I'll try 😄 . Below, when I'm referring to the So, what confused me a bit is that using the same UI can perform different actions per variation:
So, after testing the generic date variation where I set a random date and it rendered that, when I tried to do the same with Hope I clarified.. |
|
Gotcha. That is indeed the behavior we wanted to implement. I understand it can be unexpected at first, but as more and more blocks and block attributes are being supported by Block Bindings, this pattern is becoming more widespread. For example, it's also possible to connect an Image block's The indication we have right now in the UI is the purple border around a block that's connected to a Block Bindings source (and the purple background behind the block icon). Additionally, the date picker says "Publish Date" when the block is connected to the publish date (instead of just "Date" when it allows setting a custom date), but that's admittedly rather subtle.
Do you think this should be made more clear in the UI? Should we get some input from designers on this? |
|
Thanks for elaborating @ockham. No, I think it's fine. I was playing around with the block fast it seems and missed the details, that are actually there. |
|
I believe this PR requires a I created a PR for Query Loop variations, but there might be cases in the wild for example when registering a post type with a template that includes this block. |
8 participants
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.