Allow XML configuration examples in WP core handbook

[SergeyBiryukov]

In a recent ​working session on WP core testing local workflow with @hellofromTonya, @jrf, and other contributors, the ​documentation on PHPUnit usage in WP core handbook was overhauled.

To make one of the test running workflow options clearer, the article includes this code snippet to be added to the phpunit.xml[.dist] file:

<php>
     <const name="WP_TESTS_PHPUNIT_POLYFILLS_PATH" value="path/to/yoast/phpunit-polyfills"/>
</php>

The problem is that this snippet is removed every time the post is edited, presumably by KSES filtering. So anyone editing the page currently has to keep that in mind, and reinstate the snippet over and over again.

It would be very helpful if the code was not removed on page edits. Since it is not meant to be executed, and is only there for documentation purposes, allowing this in the handbook context should be safe without any security concerns.

[jrf]

Thanks @SergeyBiryukov for opening this ticket. I bet that in the livestream/video, it is quite funny to watch this as we keep referring to this snippet and keep having to put it back.

The risk of it disappearing from the handbook is very real and would be to the detriment of the test instructions.

[dd32]

The problems with this page doesn't appear to be a KSES thing, or a meta thing, it's mostly a combination of Gutenberg parsing, the syntaxhighlighter block having issues, and improper nesting of blocks in the page.

Editing the page visually causes several issues:

• Lists are broken blocks, as they're Ordered lists but lack the ordered attribute in the block meta
• Syntax highlighter bash blocks are removed, for some reason
• The problematic example in question, is a block, contained within a block, that doesn't allow nesting.

On that last one, here's a simplified view of the problem code, used in a few places on that page: (Note: nested, and missing list block meta to specify ordered)

<!-- wp:list -->
<ol>
   <li>List content</li>
   <li>List Contents
   <!-- wp:syntaxhighlighter/code {"language":"bash"} -->
      <pre class="wp-block-syntaxhighlighter-code">
        npm install broken-things
      </pre>
   <!-- /wp:syntaxhighlighter/code -->
   </li>
</ol>
<!-- /wp:list -->

I've attempted to edit this page several times now to fix those items, but every time i fixed one thing I broke another thing, causing me to revert back and start again.

I think this page might need to be rebuilt, or at least copied out of Gutenberg corrected and imported back.

[jrf]

@dd32 Thanks, that would explain (a lot of) it. I tried getting to the back end editing/Gutenberg to do things properly, unfortunately, that just gave me a blank screen, so the only way to edit the pages was by front-end hard coded HTML editing....

I dearly hope this is not the Gutenberg FSE experiences as that would not be a good look.

Any idea why I couldn't do the backend editing ? And why the front-end editing was HTML edits ? (even in the "visual"editor)

[dd32]

Replying to jrf:

I tried getting to the back end editing/Gutenberg to do things properly, unfortunately, that just gave me a blank screen
... Any idea why I couldn't do the backend editing ?

I'm guessing you were running to a Javascript error there, but I have no idea what since I didn't run into any problems myself.

so the only way to edit the pages was by front-end hard coded HTML editing....

I suspect this is why it's broken actually, it's been converted to Gutenberg format, and then manually edited a few hundred times.
I'm going to use that to fix up some of this by manually correcting some broken blocks and see what happens.

And why the front-end editing was HTML edits ? (even in the "visual"editor)

It appears as if the o2 visual editor has broken across all of make.wordpress.org sites, I suspect a change in trunk has made it incompatible with o2, I'm unsure what though.

[dd32]

Ha.. Okay so editing on the front end, and I got the <php> stripped out.

Yep, it's Kses stripping it out there, the ​Syntax Highlight plugin has some special handling in it to encode things before kses I believe or maybe in our custom theme hack for it.. or maybe something else entirely..

It could also be related to the fact the visual editor is broken here, as the problem content should be HTML encoded, but when you edit it via the front end, the it's converted from html encoded to plain html, and so kses is correct in stripping it out.

Having this code block within the <li> is problematic regardless though, as it's improperly nested for the purposes of Gutenberg parsing.

To make it work properly, I've converted this block from a List block, into a HTML block, and then converted the inline Syntax block into a regular code block. It can now be edited properly, both on front-end and within Gutenberg without issue. I've corrected the list elements too, Gutenberg no longer complains that the syntax is broken..

Regardless, there's a need to figure out why the visual editor is not working, which is beyond me right this moment. Really we should get Gutenberg into the front-end editor for o2 instead, to make this a better experience, since chances are future edits to the page (and others) are likely to cause these problems. I ran into some other recently added HTML that was also invalid, so there's a fair bit of human error happening right now.