2.0 RC1 WYSIWYG inserting headers destroys next paragrah

[badrad]

I want to use the new WYSIWYG functionality, but this bug makes it so I cant.

Steps to produce:

1. Begin new post with WYSIWYG editor.

2. Enter a paragrah, a header, then a paragraph. For example, try this text

   <p>A test paragraph.</p>
   <h3>A header.</h3>
   <p>A test paragraph.</p>
   

3. Publish post.

4. Visit post and look at output.

For the above code sample, this will be what makes it into the post:

<p>A test paragraph.</p>
<h3>A header.</h3>
A test paragraph.
</p>

It is missing the opening paragraph tag.

Trying the same code without the WYSIWYG editor works.

[darkfate]

the TinyMCE editor doesnt convert html to text in the main box. if you want to use html you click on the HTML button and type your html and hit ok.

[masquerade]

Well, this brings into play the question on whether TinyMCE should allow you to post your own HTML while in WYSIWYG mode. Either way, even if it means that we replace with HTML entity codes, everything that you put into the box should still be there when you publish.

[badrad]

I forgot to mention, but the headers were inserted with the HTML button popup, not typed directly into the editor.

Type some text and it automatically makes paragraphs. Pop open the HTML dialogue to add a header between any two paragraphs, and the paragraph after the header gets its opening paragraph tag deleted.

[skeltoac]

This behavior is fixed in the patch for #1991, which includes TinyMCE 2.0 Final and some new RegEx cleanups. Changeset is pending review.

There is no guarantee that everything you type in the RTE will be there on the blog. The paragraphs are stripped and text is stored as "A test paragraph.\n\n" unless the <p> has attributes. The <h3> is stored as-is. The default filters put the <p> tags back in on display but plugins can change this behavior. This design pattern makes it possible to switch off the RTE and still be able to edit the post in a natural format, as well as to switch on the RTE and edit old posts without cluttering them with paragraph markup.

[skeltoac]

Okay, now I see your message of 00:11:37. Behavior still exists in that case. It is a problem in wpautop. I'll see to a fix.

[skeltoac]

Block element closing tags followed by text, not a newline, would cause wpautop to chop a <p> while leaving its </p> in place. The attached diff resolves this issue.

The issue was made apparent by a faulty regex in the TinyMCE editor plugin, which functioned to format the source for readability by adding a newline after every block element. The regex missed h[1-6] tags due to an unescaped backslash. This is also fixed by the attached diff.

[ryan]

(In [3273]) autop fixes from skeltoac. fixes #2022

[(none)]

Milestone 2.0 deleted

For themes without theme.json support, we only enqueue the default styles provided by WordPress, such as the preset classes
(font sizes, colors, gradients). These classes should be always present as they may be used by old content and patterns.

For themes with theme.json support, we also enqueue the theme styles.

## More context

In WordPress 5.8 the preset classes (font sizes, colors, gradients) were provided via a CSS stylesheet that we enqueued to all themes plus the global stylesheet for the themes that supported theme.json. To avoid this duplication, in WordPress 5.9 the preset classes were removed from the common stylesheet (see ​https://github.com/WordPress/gutenberg/pull/35182 and ​https://github.com/WordPress/gutenberg/pull/34510) and are now provided by the global stylesheet, which is enabled to all themes as of ​https://github.com/WordPress/gutenberg/pull/34334

Related ​devnote, see "Changes to the global stylesheet" section.

## How to test

• Load the TwentyTwenty theme.
• Go to the front end and verify that there's a stylesheet called global-styles-inline-css.

Related issue at https://core.trac.wordpress.org/ticket/54782

I have a fix for TwentyTwenty at ​https://github.com/WordPress/wordpress-develop/pull/2130 TwentyNineteen and TwentyTwentyone still need a patch.

Merged as of ​https://github.com/WordPress/wordpress-develop/commit/16e0165cf00d87935a0ece5d75053572160b6d53

Thanks @oandregal!

This PR is a proof-of-concept to prove that there is no technical reason to hold back Yoda withdrawal from the codebase.

Related: ​https://make.wordpress.org/core/2022/06/14/upcoming-disallow-assignments-in-conditions-and-remove-the-yoda-condition-requirement-for-php/

Uses 100% automated tooling to swap Yoda conditions in the entire codebase:

### How this was done

Considering that your src folder is in: /home/some-user/wordpress-develop/src

• cd tools/php-cs-fixer
• composer install
• ./vendor/bin/php-cs-fixer /home/some-user/wordpress-develop/src
• ./vendor/bin/php-cs-fixer /home/some-user/wordpress-develop/tests

### How to test

• Unit tests should continue to pass
• E2E tests should continue to pass
• PHPCS should pass once Yoda is no longer enforced

I had to ignore:

• src/wp-includes/class-wp-block-parser.php
• src/wp-includes/blocks

Otherwise E2E tests would fail in the check ​Ensure version-controlled files are not modified or deleted.

Any insight on why these files cannot be modified? I figured they might be a subversion coming from another repo?

I'm closing this in favor of #2973

As per ​https://make.wordpress.org/core/2022/03/23/migrating-wordpress-e2e-tests-to-playwright/, this migrates all Puppeteer usage in core to Playwright.

E2E tests

• [ ] tests/e2e/specs/profile/applications-passwords.test.js
• [x] tests/e2e/specs/cache-control-headers-directives.test.js
• [ ] tests/e2e/specs/dashboard.test.js
• [ ] tests/e2e/specs/edit-posts.test.js
• [x] tests/e2e/specs/empty-trash-restore-trashed-posts.test.js
• [x] tests/e2e/specs/gutenberg-plugin.test.js
• [x] tests/e2e/specs/hello.test.js

Performance tests

• [x] tests/performance/specs/home-block-theme.test.js
• [x] tests/performance/specs/home-classic-theme.test.js

Visual regression tests

• [ ] tests/visual-regression/specs/visual-snapshots.test.js

Note: Can conveniently use toHaveScreenshot()

Other to-dos:

• [ ] Ensure browsers are correctly installed and only when necessary (wp-scripts should handle that, but let's double check)
  • [ ] Remove PUPPETEER_SKIP_DOWNLOAD usage in GitHub Actions workflows (or use PLAYWRIGHT_SKIP_BROWSER_DOWNLOAD if needed)
• [ ] Update documentation

Trac ticket:

Fantastic work, @swissspidy! 🦸

I'll start going through the tests and change the code into an a11y locator where possible.

A general note regarding the Gutenberg plugin test: Maybe we should handle installation via wp-env. As far as I can tell, it doesn't need to test installation; just that activation doesn't cause fatal errors.

Cc-ing @kevin940726 and @WunderBart, in case they've any notes regarding the setup.

A general note regarding the Gutenberg plugin test: Maybe we should handle installation via wp-env. As far as I can tell, it doesn't need to test installation; just that activation doesn't cause fatal errors.

Core doesn't use wp-env. But yes, I don't like how the test is doing a fresh install. It takes a long time and is brittle and difficult to clean up if one of the steps fails. But that's just how it was before, I didn't change any of the logic.

What we could do is downloading Gutenberg separately in the CI step, but that would mean you can't easily run the test locally. So right now I don't see a good solution.

Sounds good. We can improve this in follow-up. It doesn't need to be a blocker here.

Hmm getting Error: Cannot find module '@playwright/test/cli' errors on CI right now, coming from node_modules/@wordpress/scripts/scripts/test-playwright.js 🤔

Locally or on CI?

@WunderBart, I'm working on best practices updates, so that test standards match what we have for Gutenberg.

Locally or on CI?

That was only on CI so far

Thanks for working on this, @swissspidy!

I've started submitting some suggestions, but I'll stop now since I can see this is actively being addressed as I scroll through the files. The few suggestions I submitted can be treated more generally because they apply to other files as well - I just didn't want to copy-paste the same comment. Hope it's OK!

Thank you, @WunderBart!

Committed in https://core.trac.wordpress.org/changeset/56926 🎉

Thanks y'all!