Output post classes in the editor

[huubl]

What?

This pull request addresses issue #33887 (and I think #10640 is related to this) by introducing post classes within the query loop in the Gutenberg editor.

Note:
I would like to know if the approach in this pull request is in the right redirection.

Why?

This allows users to target specific elements and apply custom styles to them.

How?

Extends the WordPress REST API to include post classes in the response data for all public post types.

Alternatives

• Alternative using a new REST API route to retrieve CSS classes of a specific post: #60645

• Recreating all the classes in JS along with a JS filter could be an alternative solution.

Testing Instructions

Insert a Query block and observe the post classes added next to the wp-post-block class in the block inspector.

Testing Instructions for Keyboard

--

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: huubl <huubl@git.wordpress.org>
Co-authored-by: ntsekouras <ntsekouras@git.wordpress.org>
Co-authored-by: ellatrix <ellatrix@git.wordpress.org>
Co-authored-by: TimothyBJacobs <timothyblynjacobs@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, @huubl! 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.

[TimothyBJacobs]

My main flag here is that get_post_class calls template tags functions like is_home that won't be reliable when used over the REST API.

That being said, I don't think that's a blocker since this is a well known property of the REST API already.

[TimothyBJacobs]

Thanks for making those changes! This looks good to me from a REST API perspective.

[ntsekouras]

Thanks @huubl! I've left a couple of small comment where we can simplify and it should be good to land.

[ntsekouras]

Thank you! Let's 🚢

[ellatrix]

What happens when you change categories etc.? These things don't remain constant in the editor like they do on the front-end.

[ntsekouras]

What happens when you change categories etc.? These things don't remain constant in the editor like they do on the front-end.

What do you mean? Classes are applied from REST API using get_post_class, same as we do in front end, as it's a dynamic block. Do you have a specific use case that something is wrong?

[ellatrix]

If you edit a post and change the categories, the generated classes for these categories should change too? Same for status, featured image and a lot of these properties.

[ellatrix]

Ah, if this is just for the query block and not for editable content in a template, then I guess it's not relevant. At some point we'll have to apply this class outside the query block as well and make it dynamic.

[youknowriad]

The query block can be dynamic as well, it can show posts that are "dirty". So this is more of an escape hatch I would say.

[ntsekouras]

it can show posts that are "dirty".

@youknowriad what do you mean with this?

[youknowriad]

@ntsekouras I mean posts with unsaved changes.

[ellatrix]

@anton-vlasenko or @TimothyBJacobs Would it be possible to make a backport PR for this?