2.7 Admin Validation Fixes

[Viper007Bond]

A generic ticket for validation fix patches.

[Viper007Bond]

8026.patch does not result in 100% validation due to things like autocomplete="off", duplicate nonce ID's, etc. but besides those kinds of things, everything should be mostly valid.

I was unable to validate the dashboard due to a UTF-8 issue coming from the "Other WordPress News" widget. Not sure how to fix that.

Navigation bar has duplicate IDs if a plugin needs updating or a comment is in moderation. Will leave that to ryan or someone else who's already been handling the menu.

[westi]

Looks good
+1

[ryan]

(In [9456]) Validation fixes from Viper007Bond. fixes #8026

[Viper007Bond]

upload.php?detached=1

[Viper007Bond]

Fix validation errors introduced in [9464] (onClick) plus do a CDATA on the inline JS.

[azaozz]

(In [9470]) Fix validation errors, add CDATA on inline JS, props Viper007Bond, fixes #8026

This is an exploration for using [cross-document view transitions]() in a WordPress theme, specifically the Twenty Fifteen theme, similar to #8026.

The difference from that PR is that this one here only transitions specifically the post title and featured image between an archive page and the post's own page, while the other PR transitions the entire main content of the page with slide-in / slide-out transition.

A benefit of the approach explored here is that it could possibly be applied in the same way for almost any WordPress theme, as it only relies on elements commonly used across WordPress themes (both block themes and classic themes), and it avoids more opinionated transitions.

Trac ticket:

My assumption is that the WordPress Playground catches an error somewhere, preventing the code from executing properly and locking things up.

When this happens, nothing shows up in my browser console. FWIW I experience this bug outside of the WordPress Playground, on my local development environment with the same code, so it's not specific to the WordPress Playground. There's no try catch block anywhere in the view-transitions.js file, so I'm not sure what's happening. I'm still experiencing this problem consistently.

FWIW I experience this bug outside of the WordPress Playground, on my local development environment with the same code, so it's not specific to the WordPress Playground.

Does your local dev env also run PHP using WASM, or is it actually a standalone env using a real PHP server? I’m asking because notice that CPU for the tab spikes to 100% when it hangs, which makes me think there is more at play here:

Also, could you check how Safari behaves with your local setup?

Does your local dev env also run PHP using WASM, or is it actually a standalone env using a real PHP server? I’m asking because notice that CPU for the tab spikes to 100% when it hangs, which makes me think there is more at play here:

No, my local env is a PHP server inside Docker, that's why I think it's unrelated to WordPress Playground / WASM.

Also, could you check how Safari behaves with your local setup?

I'm on Chrome OS, so can't easily check that. But maybe someone else from my team can.

This looks great, nice work! 🎉

A benefit of the approach explored here is that it could possibly be applied in the same way for almost any WordPress theme

This point makes me wonder if we could build this capability into core as an API themes could opt into easily, for example by opting into theme support (add_theme_support).

@adamsilverstein

This point makes me wonder if we could build this capability into core as an API themes could opt into easily, for example by opting into theme support (add_theme_support).

That's exactly what I have in mind, planning to explore that next week!

@adamsilverstein See ​https://github.com/WordPress/wordpress-develop/pull/8370