Add View Transitions to WP Admin

[westonruter]

The View Transitions plugin as part of Performance Lab includes a feature to enable cross-document view transitions in the WP Admin. This improves the user experience of navigating around the admin, by making it feel more like a single-page app without the added implementation complexity (and backwards-compatibility breaks). This is part of the new coat of paint being worked on for the WP Admin in #64308.

The feature is ​now implemented in all browsers, except for Firefox (see ​Bugzilla 1860854). Nevertheless, it is purely a progressive enhancement, the same as Speculative Loading, so Firefox users will not experience a degraded experience.

View Transitions in the admin was first implemented in the plugin via ​https://github.com/WordPress/performance/pull/2038

This is also related to enabling bfcache for instant back/forward navigation (#63636). To further improve the fluidity of navigating the WP Admin, ​speculative loading of admin menu items may make sense.

This was discussed in the ​Performance Team 2025 year-end chat.

See #64471 for implementing View Transitions on the frontend.

[joedolson]

I'm adding the accessibility focus to this, because I've encountered some strange behaviors testing View transitions. They aren't necessarily problems, but I want to make sure they get adequately explored before committing them. The issues I observed were cases were focus would be inconsistently placed following a view transition. Also doing the same with #64471.

• Adds "virtual" CSS asset wp-view-transitions-admin with inline CSS for basic view transitions in WP Admin, including smooth transitions between admin menu items.
• Enqueues the asset on admin_enqueue_scripts by default.
• Provides a function with the inline CSS so that it lives in the view-transitions.php file rather than the generic script-loader.php file.
• Tests included.

Trac ticket: https://core.trac.wordpress.org/ticket/64470

@westonruter Do you have an idea how to best fix ​https://github.com/WordPress/wordpress-develop/actions/runs/20884023219/job/60004547145?pr=10699 or why it fails? My hunch is that it's because the .min file that's created as part of the build doesn't exist maybe and then it causes a fatal error?

@felixarntz That's strange, because for the E2E test it does a full build, right? For running PHPUnit tests, I know a build isn't done, and this causes all kinds of headaches when SCRIPT_DEBUG is off. We have to touch files to make sure they exist so errors don't happen, for example:

​https://github.com/WordPress/wordpress-develop/blob/376539ea5ac7d02ddb53cab0e724b156b3fa25b3/tests/phpunit/tests/formatting/emoji.php#L18-L19

But I don't see how this would be needed for E2E tests if they were working correctly with SCRIPT_DEBUG was off previously. If SCRIPT_DEBUG was off and a build isn't done, then none of the minified JS/CSS files would exist, and nothing would work.

To debug whether the build is the problem, maybe temporarily change:

$affix = SCRIPT_DEBUG ? '' : '.min';

To:

$affix = '';

Alas, E2E tests are ​still failing after ​https://github.com/WordPress/wordpress-develop/pull/10699/commits/8ff0383bb5c056ae1cace5525f3812a8b8369f6d:

> [email protected] test:e2e
> wp-scripts test-playwright --config tests/e2e/playwright.config.js

Notice: Could not find @wordpress/env package. Using WP_BASE_URL environment variable or else the default http://localhost:8889 URL for tests.

Failed to load resource: the server responded with a status of 503 (Service Unavailable)
Running 25 tests using 1 worker
··········×±··×±····××F·····××F

  1) [chromium] › tests/e2e/specs/install.test.js:34:6 › WordPress installation process › should install WordPress with pre-existing database credentials 

    Error: expect(locator).toBeVisible() failed

    Locator: getByRole('heading', { name: 'Welcome to WordPress', level: 2 })
    Expected: visible
    Timeout: 5000ms
    Error: element(s) not found

    Call log:
      - Expect "toBeVisible" with timeout 5000ms
      - waiting for getByRole('heading', { name: 'Welcome to WordPress', level: 2 })


      81 | 		await expect(
      82 | 			page.getByRole( 'heading', { name: 'Welcome to WordPress', level: 2 })
    > 83 | 		).toBeVisible();
         | 		  ^
      84 | 	} );
      85 | } );
      86 |
        at /home/runner/work/wordpress-develop/wordpress-develop/tests/e2e/specs/install.test.js:83:5

    attachment #1: screenshot (image/png) ──────────────────────────────────────────────────────────
    artifacts/test-results/install-WordPress-installa-08866-isting-database-credentials-chromium/test-failed-1.png
    ────────────────────────────────────────────────────────────────────────────────────────────────

    attachment #2: trace (application/zip) ─────────────────────────────────────────────────────────
    artifacts/test-results/install-WordPress-installa-08866-isting-database-credentials-chromium/trace.zip
    Usage:

        npx playwright show-trace artifacts/test-results/install-WordPress-installa-08866-isting-database-credentials-chromium/trace.zip

I'll revert the debug commit.

Looks like 8bd1633 fixed the E2E test! The issue was the lack of checking whether the init action was done as is the pattern other dependencies that add inline data. I'm not entirely sure why that is needed for all of those cases, but it fixes the problem.

As a companion to this core commit, a PR to disable the functionality in the plugin when it is present in core: ​https://github.com/WordPress/performance/pull/2344

[flixos90]

@joedolson I'll commit a first pass of this now given the positive reviews and the quite simple implementation, purely backing on the foundational web API without bells and whistles. I think with WP Admin, it's also a great place to start since far fewer people are exposed to that experience than visiting/browsing WordPress sites.

I would recommend you open follow up tickets if you encounter any problems with the implementation, or reopen this one if it's a more severe problem.

[flixos90]

In 61491:

Administration: Add view transitions throughout WP Admin.

This changeset enables smooth transitions between the different admin screens. For the admin menu items, distinct view transition names are used to facilitate a simple visual slide effect when the active submenu changes between screens.

Props westonruter, mukesh27, joedolson.
Fixes #64470.

[westonruter]

In 61502:

Administration: Ensure View Transitions only apply when reduced motion is not preferred.

Developed in ​https://github.com/WordPress/wordpress-develop/pull/10762

Follow-up to [61491].

Props mukesh27, wildworks, solankisoftware, westonruter.
See #64470.
Fixes #64529.