Feat: WooCommerce orders open on new window - #730
Merged
AllTerrainDeveloper merged 3 commits intoSep 2, 2026
Merged
Conversation
AllTerrainDeveloper
approved these changes
Sep 2, 2026
AllTerrainDeveloper
left a comment
Collaborator
There was a problem hiding this comment.
LGTM! Thank you!
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #721.
The problem
Clicking an order in the WooCommerce Orders window navigated the list away, so the only route back was closing the window and reopening it from the dock.
Why
The bridge routes an admin link by comparing
deriveWindowId( url )against the source window's slug: same slug navigates the iframe in place, a different slug opens its own window. WooCommerce's High-Performance Order Storage moves the order editor offpost.php?post=N&action=edit— whereposthas always been identity-bearing — ontoadmin.php?page=wc-orders&action=edit&id=N, which derives the Orders list's slug. The click read as in-page navigation.idcan't simply join the identity set: plugin list screens useadmin.php?page=foo&action=…&id=Nfor row actions, and those must keep the list's slug so they run in place and land back on the list.The fix
A scoped pass in
src/utils.ts(scopedIdentityParams), keyed on the URL shape rather than onwc-orders:admin.php+ apage+action=edit+id=N→idis identity-bearing.admin.php+ apage+action=new→actionis identity-bearing (the blank editor — Add order had the same problem, and the admin bar's + New → Order already spawned its own window).action=stays transient, so row actions still run in place.An order now opens beside the Orders list, two orders are two windows, and closing one leaves the list where it was. Any plugin routing a feature through one
admin.php?page=file gets the same behaviour.Screenshot
Testing
tests/vitest/utils.test.tsfor the identity rule and its scoping, 2 insrc/window/iframe-bridge.test.tsrunning the real slugifier through the dispatcher (order link → new window, order row action → in place).npm run test:js(5355 passing),npm run lint,npm run typecheck,npm run buildall clean. No PHP touched.Docs
docs/bridge-protocol.md(the same-slug / cross-slug dispatch rules) anddocs/javascript-reference.md(deriveWindowId, a Stable public API).