Post Date Block: Offer better defaults

[apeatling]

What problem does this address?

The post date block currently has restricted defaults, and editing this means opening the code editor.

What is your proposed solution?

Add in some more default options in the dropdown. Going further allow extending this by the theme and/or pulling in the defaults from WordPress itself.

Hat tip @mtias

[ramonjd]

Related issues:

• Post Date: Block Enhancement Ideas #24957
• Post Date Style Customization  #25456

[mtias]

@kjellr @beafialho curious what you'd suggest here.

[kjellr]

I actually ended up using some non-standard dates in Twenty Twenty-Two by manually editing the block markup. 😄

Here are a number of our most frequently used date configs:

• February 8, 2022
• Feb 8, 2022
• Feb 8th
• 2.8.2022 (or 8.2.2022)
• 2/8/202 (or 8/2/2022)

I haven't added an exact timestamp to any theme recently, but I know that's helpful for some high-volume sites. So perhaps we could include something like this:

• Feb 8, 2022, 10:35 AM

As noted elsewhere, an x days ago option would be excellent too.

[ramonjd]

I've been looking into the moving (and static) parts of dates and trying to find the best place to start tackling this specific issue while keeping longer term possibilities open.

I've made a bunch of assumptions here, so will be very happy to be corrected on anything. 😄

For now they're notes. I'll come back and refine them and add some steps we could take to move forward.

Where the current default date formats come from

The date package provides the default formats and other date settings for our app.

		time: 'g: i a',
		date: 'F j, Y',
		datetime: 'F j, Y g: i a',
		datetimeAbbreviated: 'M j, Y g: i a',

WordPress Core "overwrites" these default settings in script-loader.php. Here we call the date package's method setSettings using PHP-rendered variables such as get_option( 'date_format' ) and other localized input.

It's also the reason why, when we select a date format in WordPress General Settings, the date format is available an an option in the Post Date block.

This means that, no matter how much we extend the default settings in Gutenberg, the WordPress Core inline script will overwrite them.

In the Post Date Block and potentially elsewhere, we grab the date settings via __experimentalGetSettings() and use the formats in our select box.

Adding new date formats to Post Date

Firstly, it's important to note that the property names in the date package have corresponding type definitions, so we cannot add new formats without causing compile errors. Any new ones we add would need their own type definitions.

Unless there's a good reason to expect specific property names, I think we should refactor the date package's types to remove the explicit property names.

As an initial step to achieve the minimum for this PR, we'd add the new formats in the Post Date block, and completely bypass the date package. This would work, but would mean that we'd have a bespoke set of date formats out there so I'd say it's not sustainable.

Ideally we'd add our new formats to the WordPress Core overrides, and also add them to the date package.

It seems more robust to have the formats available across the editor, especially if we want to use the formats across the Gutenberg app. The best example (there are without doubt others) I could find is the Latest Comments Block, which outputs the dates using get_option( 'date_format' ).

This option is the value selected in General Settings.

And can, and I'd say usually is, different from the Post Date format.

Longer term possibilities/ideas

In the future, we might like to allow theme authors to extend the date format list with additional formats.

Some ideas to achieve this:

• Apply a filter in WordPress Core where we add the date JS via $scripts->add_inline_script so we can update the formats (or any settings) using add_filter.
• We could allow theme authors to add their own formats via theme.json? ”settings.date.formats = [ ‘Y-m-d’, ‘m/d/Y’, ‘d/m/Y’ ] We would have to check them before parsing? We could then get them by useSetting( ‘date.formats’ );
• Following on from above, might like to return date formats and other date-related settings from the settings endpoint as discussed in Latest posts: i18n date by Soean · Pull Request #7996 · WordPress/gutenberg · GitHub

Some more related, but possibilty even longer term tasks:

• Gutenberg could offer the same default date and time formats as WordPress General settings by tapping into the date_formats hook.
• Long term we could also create a reusable WYSIWYG component that helps users format a date with editing field and preview. Props to @andrewserong
• Relative dates. Moment.js has this functionality, though PHP doesn’t have a relative date built in. WordPress has human_time_diff() | Function | WordPress Developer Resources, human_time_diff( $the_post_date ); outputs something like but it doesn’t output the adverb “ago” and therefore could be troublesome to translate for some languages. Still worth a look.

[apeatling]

As an initial step to achieve the minimum for this PR, we'd add the new formats in the Post Date block, and completely bypass the date package. This would work, but would mean that we'd have a bespoke set of date formats out there so I'd say it's not sustainable.

@ramonjd Did you do this as an initial step? Should we keep this moving forward with some of your suggestions above?

[ramonjd]

@ramonjd Did you do this as an initial step? Should we keep this moving forward with some of your suggestions above?

Thanks for the ping. No I haven't yet returned to this one yet (I want to!), but I think it would be good to look at extending the WordPress core overrides.

[noisysocks]

I find it confusing that the first two options in the dropdown come from the site's Date Format and Time Format settings but that there's no indication of that.

It's also weird that, because we store the format (e.g. F j, Y g:i a) in the Post Date block attributes, changing the site's Date Format or Time Format settings doesn't update any existing Post Date blocks, which is what happens in classic themes.

I think the Post Date block should offer the user the choice of using the site's Date Format setting or one of a handful of formats that we suggest based on the user's locale.

So in other words the dropdown would look like something like this:

If Site default is selected then updating Date Format in Settings → General would update what's shown on the frontend.

If Custom is selected then a text field appears which lets the user type in a date format.

[ramonjd]

Thanks for looking at this @noisysocks

offer the user the choice of using the site's Date Format setting or one of a handful of formats that we suggest based on the user's locale.

I like the idea of integrating the currently-selected site date format into the list

If Custom is selected then a text field appears which lets the user type in a date format.

I hacked together something for this custom date demo and seem to recall it didn't take long at all:

#25456 (comment)

It's also weird that, because we store the format (e.g. F j, Y g:i a) in the Post Date block attributes, changing the site's Date Format or Time Format settings doesn't update any existing Post Date blocks

Good spotting. That's also something I'd have expected to happen. It'd be awesome be able to offer the ability to standardize the dates.

Do you think we should extend the same functionality for all blocks that display a date?

The Latest Comments Block pulls get_option( 'date_format' ), so the site's Date Format setting, and is currently not editable.

[noisysocks]

Do you think we should extend the same functionality for all blocks that display a date?

Yeah definitely.

The Latest Comments Block pulls get_option( 'date_format' ), so the site's Date Format setting, and is currently not editable.

Probably we can leave Latest Comments how it is, since that block is on its way out in favour of Comments Query Loop. I'd say we should mirror whatever we do for the Post Date block to the Comment Date block, though.

[noisysocks]

I started implementing what I described above in #39209. Let me know if you think it's a good idea and I'll polish it up!

[mtias]

changing the site's Date Format or Time Format settings doesn't update any existing Post Date blocks

Yep, this is wrong. If the block doesn't serialize a specific format descriptor we should fallback to what the site has defined globally wherever we display dates. That should be clear in the control we offer in the UI as well.

[jasmussen]

Relative dates.

I'd echo @ramonjd's wishlist item here, it'd be nice with a toggle to convert whatever format chosen to be relative for at least 7 days ("Just now", "10m ago", "3h ago", "2 days ago", etc.)

[mtias]

Relative date can be nice, but let's keep it as a separate thing from this issue :)

[cdils]

Was a separate ticket ever created for the relative date feature? +1 for that as a native option.

[ramonjd]

Was a separate ticket ever created for the relative date feature? +1 for that as a native option.

@cdils I can't find an issue. Would you have time to create one? 🙏🏻

[cdils]

@ramonjd Done. :)

[mtias]

Thanks for the follow up :)