Explore view transitions in Twenty Fifteen for post title and featured image specifically

[felixarntz]

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:

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• The Plugin and Theme Directories cannot be accessed within Playground.
• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[bramus]

I took a look into this and can reproduce on the WordPress Playground. However, it does not reproduce in a standalone repro.

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

(FWIW: The Playground also grinds to a halt when when trying to load it in Safari, without even doing anything)

I’ve done a code suggestion to return early when there is no article which – I hope – prevents code from throwing.

[felixarntz]

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.

[felixarntz]

@bramus I debugged the issue further and got as far as figuring out that it, for some reason, comes down to this:

• When you click on the link to an article without a featured image from the home page, the articleLink variable here will be empty - at least this is how it shows when I add a console.log( articleLink ); below.
• This causes the early return to trigger.

I still don't understand why that's happening, for two reasons:

1. If I manually run this exact document.querySelector( ... ) call in the console using the URL of that post in question, I do get a result, which is the a element in the post title. That's what I would expect. But for some reason, during the view transition it returns nothing.
2. The early return here is triggered if articleLink is empty. But that shouldn't cause the browser to infinitely get stuck on loading the page right? Or is there any "cleanup" to do if a view transition is "aborted" with an early return like this?

[bramus]

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?

[felixarntz]

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. Maybe @swissspidy or @adamsilverstein?

[adamsilverstein]

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

[felixarntz]

@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!

[felixarntz]

@adamsilverstein See #8370

Closing this in favor of the broader exploration, which encompasses the same behavior as this PR achieves, but abstracted to work for any theme.