Add CSS class to paragraph block

[juanfra]

What?

Adding the wp-block-paragraph to the paragraph block elements.

Fixes #46863

Why?

It was reported in #46863 that the style changes for the paragraph block were affecting all the paragraphs, and this was affecting other pieces of the site such as the site tagline (and others).

How?

Adding the wp-block-paragraph class to the paragraph block for new content, and parsing the block output to add it for previously generated content.

Testing Instructions

For new content

1. Create a new page with the build from this PR.
2. Add some paragraphs
3. Save the page.
4. Confirm that the paragraphs have the wp-block-paragraph class.

For previously generated content

1. Create a sandbox with the trunk build for this plugin.
2. Create a page with paragraphs (you can use custom classes).
3. Save the page.
4. Update the build to this one.
5. Open the page and confirm that the wp-block-paragraph class was added to the previously generated content.

For the problem reported in #46863

1. Open Site Editor > Styles.
2. Head to Blocks > Paragraph
3. Make changes and notice it doesn't have an impact on the Site Title and Site Tagline (or any other <p> that doesn't have the wp-block-paragraph class)

Screenshots or screencast

Screen.Recording.2023-02-03.at.17.18.43.mov

[juanfra]

I'll be working on fixing tests and all.

[annezazu]

We're coming up on 6.4 beta 1 and I'm curious where we stand. I can see some recent commits and requests for more feedback but I'm not seeing additional reviews come in. Where do we stand?

[mikachan]

Unfortunately, as we're now also past Beta 1 for 6.4, and based on the conversation above about this being a pretty major change, I think this should now be punted to 6.5. However, it would be great to aim to include it in the next Gutenberg release.

[apeatling]

This is an important change, but it's also a tough one to test because it touches so much. I think we need to start looking at it early if it's going to make 6.5, otherwise it will keep getting punted.

[ramonjd]

This is an important change, but it's also a tough one to test because it touches so much. I think we need to start looking at it early if it's going to make 6.5, otherwise it will keep getting punted.

Agree. Since it touches native files too it might be good to get a sign off list of reviewers. I've smoked tested this PR with existing P blocks and creating new ones and it works great, but the breadth of the changes makes me want a security blanket of concurring reviews 😄

[andrewserong]

Just thinking out loud: since the approach in this PR involves changing a lot of files, and alters how the block is serialized to post content, would it be worth investigating a subtle alternative that uses the wp-block-paragraph classname in the editor, but does not save it to the markup? Then, we could continue to lean on the PHP change in this PR that uses the Tag Processor to inject the classname at render time, so we'd still get the classname appearing on the site frontend.

That way the saved markup is never changed, and we wouldn't need to worry about backwards compat / support in the mobile apps as older versions would still see the earlier markup? I might very well be missing some context, and there could be a good reason to save the classname in post content, so apologies if I've missed something obvious there!

[juanfra]

Thanks for your comments 😄 I was out of the office.

The number of files involved in this PR is related to updating the tests that involve the paragraph block, to include the CSS class. There were no changes to the logic of native, only updating tests and snapshots. The main changes are only these.

I believe that, in favor of consistency with the behavior of other blocks, I would save the data with the class. But that may be subjective. But I'm thinking that maybe it is better to play safe and cover all scenarios where the data is retrieved (in case the post data is retrieved in some way other than being rendered).

[fabiankaegy]

Hey all 👋

We are 1 week out from Beta 1 of WordPress 6.5. Is anyone working on getting this is before then? / What are the current blockers?

[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.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @apeatling.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

Core SVN

If you're a Core Committer, use this list when committing to wordpress-develop in SVN:

Props: juanfra, poena, ndiego, ramonopoly, annezazu, mikachan, andrewserong, fabiankaegy, hbhalodia.

GitHub Merge commits

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Unlinked contributors: apeatling.

Co-authored-by: juanfra <juanfra@git.wordpress.org>
Co-authored-by: carolinan <poena@git.wordpress.org>
Co-authored-by: ndiego <ndiego@git.wordpress.org>
Co-authored-by: ramonjd <ramonopoly@git.wordpress.org>
Co-authored-by: annezazu <annezazu@git.wordpress.org>
Co-authored-by: mikachan <mikachan@git.wordpress.org>
Co-authored-by: andrewserong <andrewserong@git.wordpress.org>
Co-authored-by: fabiankaegy <fabiankaegy@git.wordpress.org>
Co-authored-by: hbhalodia <hbhalodia@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[juanfra]

Hi @fabiankaegy,

Thanks for coming back to this one. I could rebase and fix the merge conflicts, but I believe that it'd be interesting to define if we're ok with the approach of having the class name in the markup, as I've seen some concerns about it.