Open configured after a live activation in OpenStation

[epeicher]

What it does

Photo Editor opens with the editor rendered after being activated from the OpenStation Plugins window, without a page reload. Previously the window opened empty until an F5.

Rationale

The app in apps/photo-editor/photo-editor.os.php declared only its client view. That view mounts the editor but does not contain it: the editor is the lienzo script handle, which only reached the page through lienzo_enqueue_in_shell() on openstation_mode_init, a hook that fires while the shell page renders at boot. A plugin activated mid-session never saw it, so mountEditor() polled for window.lienzo.renderDesktopWindow for MAIN_BUNDLE_WAIT_MS and gave up.

Deactivating and reactivating in one session did not reproduce it, because the bundle printed at boot was still in the page. A fresh install is the case that failed.

Two more things were attached at the wrong moment, inside lienzo_enqueue_editor(): the window.lienzoConfig inline and the lienzo stylesheet. OpenStation harvests a handle's inline data off the registered handle when it builds a window payload, so data added only at enqueue time was invisible on the live path.

Implementation

The app window now names the bundle and its stylesheet through openstation_app_window_args, the seam OpenStation exposes for riding registered handles on an app window:

function lienzo_app_window_args( $args, $id ) {
	if ( 'lienzo' !== $id ) {
		return $args;
	}
	$args['scripts'] = array_merge( array( 'lienzo' ), (array) ( $args['scripts'] ?? array() ) );
	$args['styles']  = array_merge( (array) ( $args['styles'] ?? array() ), array( 'lienzo' ) );
	return $args;
}

The script is prepended so window.lienzo exists before the client view's first mount attempt rather than its first poll. The poll stays as a safety net.

The wp_add_inline_script() call moves from lienzo_enqueue_editor() into lienzo_register_assets() on init, right after wp_register_script( 'lienzo', … ). The "already enqueued" guard in lienzo_enqueue_editor() is gone: the inline is on the handle once per request regardless of how many times it is enqueued. This is the same pattern AllTerrain Forms uses for its config handle.

lienzo_enqueue_in_shell() is unchanged. A normal boot still gets the bundle up front, and WordPress prints an enqueued handle once, so a boot that takes both paths does not inject lienzo.js twice.

Follow-up to WordPress/openstation#825 (WordPress/openstation#825), which makes a window's companion scripts carry their declared dependencies and inline data on a live activation. That PR fixed the shell-side gap; this one fixes Photo Editor's own reason for failing, which is that it never told the shell about its main bundle. On an older shell this change is harmless but does not fix the bug.

Testing instructions

npx wp-env start
npm run test:php:install
npm run test:php

135 tests pass, 6 of them new: the config is on the registered handle before any enqueue, repeated enqueues print it once, and lienzo_app_window_args prepends the script, appends the style, and leaves other apps alone.

For the live path, with OpenStation at or after WordPress/openstation#825:

1. Deactivate Photo Editor, then load the shell at admin.php?page=openstation.
2. Activate Photo Editor from the Plugins window. Do not reload.
3. Open it from the dock tile or desktop icon.

The editor should render. In the console, window.lienzo.renderDesktopWindow is a function, window.lienzoConfig is defined, and document.querySelectorAll('script[src*="lienzo.js"]').length is 1.

4. Reload and open it again. The boot path should still work with one lienzo.js script tag, one lienzo.css stylesheet, and one inline config.