Is KSES removing all images encoded as data? Do we ever inline images in the block editor? Is that a concern?

Other than that, it looks like a nice addition to the verification process 👍

Is KSES removing all images encoded as data? Do we ever inline images in the block editor? Is that a concern?

The data: "protocol" has never been allowed in Core, KSES strips it off. I'm fine with assuming that this is just how some of the tests were set up originally, then the rest are a product of copy/pasta. I also had a quick search through the block editor source, I didn't find any concerning references to data:.

If the block editor was storing inline images, we probably would've heard about it by now. (I'm looking forward to this comment coming back to bite me in the future. 😛)

If the block editor was storing inline images, we probably would've heard about it by now. (I'm looking forward to this comment coming back to bite me in the future. 😛)

I know that the block editor uses data: to show images when uploading/processing them, then replaces that with the final URL. I guess it’s fine to use URL with tests, but it still would be good to clarify why data version infected all those fixtures 😅

I know that the block editor uses data: to show images when uploading/processing them, then replaces that with the final URL. I guess it’s fine to use URL with tests, but it still would be good to clarify why data version infected all those fixtures 😅

Ugh, we probably need to figure out a different way to do it, the data: URLs were added on purpose in #14625.

Ugh, we probably need to figure out a different way to do it, the data: URLs were added on purpose in #14625.

Those fixtures are no longer used with e2e tests so it might be no longer a limitation. The other option could be to run another rule in test_kses_doesnt_change_fixtures that replaces data: with some fake URLs.

@gziolo: Good idea on doing the replace in test_kses_doesnt_change_fixtures(), makes for much less churn. 🙂

Since WP54261 has landed, the tests all pass correctly now.

Great, let's move forward with this PR. We could add a similar test case in WordPress core, but we don't have the same test fixtures there. Maybe, it's enough to have full coverage in the plugin since we sync the code from here anyway.

We could add a similar test case in WordPress core, but we don't have the same test fixtures there. Maybe, it's enough to have full coverage in the plugin since we sync the code from here anyway.

I think coverage in the plugin is fine, as long as there's a process to ensure that simple changes to KSES that can be done in the plugin (eg, adding a new tag or attribute through the wp_kses_allowed_html filter) make their way to Core.