Add prefix / suffix to Post Date block

[TimBHowe]

What?

Add prefix / suffix to Post Date block

Why?

#47738

The Post Date block doesn't let you add a prefix or suffix. You can manually add a text before the block but you are using the Last Modified Date and it is empty then the text you added will appear with no date output.

This would allow using 2 Post Date blocks on the same post, which may solve #46645 :

Published on : 2 Febuary 2023
Last Modified : 3 Febuary 2023

How?

This pull request adds an optional prefix / suffix to Post Date, the same way the Category block does (see PR #40559).

prefix date suffix

For instance :

Published on : 2 Febuary 2023

This would allow to use 2 Post Date blocks on the same post, which may solve #46645 :

Published on : 2 Febuary 2023
Last Modified : 3 Febuary 2023

Testing Instructions

1. Create a new blog post
2. Add a Post Date block with the "Display last modified date" toggle disabled
3. Enter a prefix. example "Posted On: "
4. Enter a suffix. example "."
5. Add a Post Date block with the "Display last modified date" toggle enabled
6. Enter a prefix. example "Updated On: "
7. Enter a suffix. example "."
8. Save the post and view the post. As it is a new post it should show the "Posted On: 'Date'." and Not the "Updated On: 'Date'." as they are the same.
9. Update the publish date to be in the past to trigger the Published and Last Modified date to be different. This will allow the Post Date block output to pass the follow statement. https://github.com/dsas/gutenberg/blob/5b95e96a90aac522c6df73349930144b89b53dfa/packages/block-library/src/post-date/index.php#L38
10. Save the post and view the post. It should show the "Posted On: 'Date'." and the "Updated On: 'Date'."
11. Party

Screenshots or screencast

[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: TimBHowe <[email protected]>
Co-authored-by: fabiankaegy <[email protected]>
Co-authored-by: cbravobernal <[email protected]>
Co-authored-by: youknowriad <[email protected]>
Co-authored-by: dmsnell <[email protected]>
Co-authored-by: jameskoster <[email protected]>
Co-authored-by: Marc-pi <[email protected]>
Co-authored-by: paaljoachim <[email protected]>
Co-authored-by: t-hamano <[email protected]>
Co-authored-by: noisysocks <[email protected]>

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, @TimBHowe! 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.

[fabiankaegy]

This works exactly like one would expect and the code looks good to me.

I personally think this is a very valuable enhancement. If you try to accomplish the same thing today in a block theme you would need to add a paragraph before / after the post date block. But that comes with the downside of the label still getting rendered when the block is not getting rendered. Like in the case when the modified date is the same as the publish date.

Having said all that I definitely am looking for additional reviews from the core maintainers.

One downside of the prefix / suffix always is internationalization. What may be a prefix in one language is a suffix in another language etc.

Pinging @WordPress/gutenberg-core for reviews :)

[cbravobernal]

I think prefix and suffix would need esc_html. A contributor user could add scripts there.

[fabiankaegy]

It would need to be wo_kses_post because the rich text string may contain formats such as bold / italics etc.

[TimBHowe]

Applied wp_kses_post to the Prefix and Suffix for the Post Date block output 4d1ca75

[cbravobernal]

Maybe we could achieve a similar solution in a future by using block bindings or bits (see #39831) instead of adding a prefix and a suffix. 🤔

Pinging @dmsnell or @SantosGuillamot get some opinions (if they are able to provide it, of course)

[youknowriad]

To be honest, this one feels weird to me. Not because it's not valuable but because it sets a precedent. Is this the only block where you would need a prefix/suffix.

There are two alternatives to this:

• Use a row block (possible today)
• Consider solving this using "bits" which I know @dmsnell is exploring.

[fabiankaegy]

@youknowriad thats not technically true. There are other blocks that already use this approach: https://github.com/WordPress/gutenberg/blob/trunk/packages/block-library/src/post-terms/edit.js

And the example you mention about using a row with a paragraph to achieve this is also sadly not really a good option. Like described above the issue there is that the modified date variation of the post data block doesn't render any output if the modified date is the same as the publish date. In that case the label you add via another block in a row before the post date still renders but the actual information doesn't render.

We have that same issue with block bindings. And block pattern overrides. Not all data always exists. And currently there are no solutions for possibly empty fields which should get omitted entirely.

Having said all that this doesn't mean I think this is the perfect approach. I'm not sure how to solve it. But the other solutions all have issues that this implementation here doesn't have.

[dmsnell]

Pinging @dmsnell or @SantosGuillamot get some opinions (if they are able to provide it, of course)

Thanks! Bits definitely are going to solve this need, as the current system is overly cumbersome and inconvenient. Working on a Make proposal as we speak, but it won't be here in WordPress 6.6 for sure.

[youknowriad]

@fabiankaegy How would you achieve this design?

Like described above the issue there is that the modified date variation of the post data block doesn't render any output if the modified date is the same as the publish date.

The solution in this PR is a bit misguided if this is the main argument for us because it achieves the result for a very small set of designs.

I agree that this is a gap in our APIs and code but don't you think something like the Block visibility plugin would be a better approach for this kind of use-cases?

[fabiankaegy]

@youknowriad yeah that is exactly why I didn't approve the PR but instead pinged the room. I don't think it is the right solution because it doesn't allow for these kinds of layouts without custom CSS.

But I did want to raise it because it is a clear gap that I am seeing in many projects. And currently my solution on those projects is essentially adding a prefix via the render block filter in PHP.

I think this PR showcases the gap in our current API well and I think it is a problem worth looking into :)

[jameskoster]

Potentially related: #61508

[Marc-pi]

Hello, i faced this situation this week on some projects, but it's a daily need.
Here are the workarounds i used

1/ About prefix, i use a csss solution, just for the pleasure to test if it still works :-)
indeed we can play with a php filter on the block rendering

.datepubli::before {
  content: "Publié le ";
    }

.datemodif::before {
  content: "| Edité le ";
    }

2/ Hide Created when Edited is available

• Not everyone will want such a behavior
• I quickly fixed this with the Nick's Block Visilbility plugin
• I did not investigate how the modified date is stored,
  but if it's in a dedicated value, the case, would be nice to have a checkbox "don't render if empty", like the Phi's MFB plugin is doing

3/ About internationalization, i fixed this with the Block Visiblity plugin also, and another css class (see 1/ via a dedicated class per locale)

• Perhaps we have to wait Phase 4 to know how to improve this...
• For the short term, Nick's plugin does not recognize the localized content at least from Polylang (ex: categories) so we are not able to filter by category (filtering by URL is the workaround solution), but that's another story :-) Will push the need in his plugin forum.

Hope my feedback helps :-)

[TimBHowe]

I created an alternative solution to also review.
It seem the options are...

1. Add Prefix/Suffix
2. Always show Post Date blocks when using Last Modified Date
3. Wait for Gutenberg Bits solution.
4. Be there a 4th option....?

Hopefully this help, and let me know if there is anything else I can do to contribute

[paaljoachim]

This is the third block I believe that needs the prefix / suffix.
The PR James linked to above:
Potentially related: #61508

All of these should be handled in a similar way.

[paaljoachim]

@vipul0425 and @t-hamano

[t-hamano]

Does anyone know where there is a search/discussion going on about "Bits"? I remember seeing it but couldn't track it down...

[dmsnell]

@t-hamano #39831

Also there was some preliminary exploration in #42015, which was replaced later by #60735 and #60735

[noisysocks]

@dmsnell how confident are you in bits landing eventually? If it's "medium" or higher then I'd say let's hold off on this PR and its alternatives and wait for bits.

[dmsnell]

@noisysocks I feel like Bits are inevitable, and while I don't know if I'd say that they will be fully in 6.7, I think some start of them will be. It's a broad-spanning project that essentially began when we introduced Blocks and proverbially kicked out Shortcodes.

What's most likely to appear first is the ability for WordPress to find and render them, since this is all basically possible today. It can be sped up with help to push forward WordPress/wordpress-develop#6395, which is a fix to prevent Core from corrupting the syntax that is now almost definitely going to be the Bits syntax.

[paaljoachim]

For various blocks where it would be helpful to add prefix and a suffix could the default Pagination block Previews/Next Page feature be used? Do we need to wait for a totally new Bits syntax? When Bits is ready in perhaps 6-10 months perhaps one can convert over where the Previews/Net Page feature is used into using the new Bits syntax?

[dmsnell]

There's now an official proposal for Bits, where I encourage we all participate to move the project forward.

It's probably not too late to have the server preserve Bits syntax on save for 6.6, because the change necessary to do that is fixing an existing bug. If it's in, then the Post Date block can start exploring with others (such as the work @ellatrix is doing, or @SantosGuillamot with Block Bindings).