You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[6.x] Port the order index to the Inertia element index - #4387
The order index was still rendered from orders/_index.twig through the legacy element index bridge, so the custom behaviour in CommerceOrderIndex.js no longer ran. That meant no date range filter, no New order button, no status handle URLs, and actions with JS triggers (Update Order Status, Share cart, Download PDF) didn't work.
Orders now follow the same pattern as Products and Transfers. OrdersController::index renders commerce::orders/Index with a new OrderIndexViewModel, and the sources go in the secondary nav.
What the view model handles:
commerce/orders/{handle} URLs keep working for status and cart sources (via Order::sourceCpUri() and defaultSourceKey()), so existing links and bookmarks still land on the right source.
The site menu picks the store, as before. Orders aren't localized, so showSiteMenu() is overridden to show it on multi-site installs, and storeId is added in baseCriteria().
The date range filter (the legacy presets plus a custom From/To) applies to the source's date-attr and is kept in the URL and across source switches.
New order is only offered with commerce-editOrders.
Actions that need a settings step are swapped for window events in actions() and handled on the page:
Update Order Status opens a dialog (status, message, suppress emails).
Download PDF opens a popover anchored to the Actions button (PDF choice, collated or ZIP). The choice is hidden when the store has one PDF, and the download type when one order is selected.
Share cart opens the CP copy text prompt. It's now single-select, and get-load-cart-url accepts an id since the Vue bulk bar sends IDs rather than numbers.
Every action request now carries ?site=. Without it defineActions()/defineSources() resolve the current site's store, so actions on a non-primary store's cart sources can't find their source.
Other fixes this turned up:
The Vite build now uses relative URLs for chunk assets. The order page is the first lazily loaded page with its own CSS, and it was being preloaded from /build/ instead of Commerce's published path, which left the page blank.
DownloadOrderPdfAction::pdfFileName() crashed when a PDF has no file name format (ZIP and single order downloads). It now falls back to {handle}-{number}.
The {num, plural, =1{Order} other{Orders}} updated. translation had a lowercase value.
Removed: orders/_index.twig, the DownloadOrderPdf trigger template, CommerceOrderIndex.js, CommerceUpdateOrderStatusModal.js, DownloadOrderPdf.js (with the commercecp bundle rebuilt) and the actions' getTriggerHtml() methods.
Left out on purpose: source badge counts. They should be a native cms element index feature, so get-index-sources-badge-counts and badgeCount => 0 in defineSources() stay for now, and the index shows no counts until that lands.
Date bounds are passed in UTC to work around cms Query::whereDateParam() comparing local times against UTC-stored dates. That will be fixed separately in cms, and the workaround stays correct afterwards.
Covered by OrderIndexTest, and checked in the browser across sources, both stores, date presets and custom ranges, all three custom actions and export.
createFromFormat() normalizes invalid calendar dates instead of rejecting them (for example, 2026-02-30 becomes 2026-03-02). A crafted custom-range URL therefore filters on and echoes a different date rather than ignoring the invalid bound. Validate the parsed value with an exact round trip before returning it.
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
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.
Description
The order index was still rendered from
orders/_index.twigthrough the legacy element index bridge, so the custom behaviour inCommerceOrderIndex.jsno longer ran. That meant no date range filter, no New order button, no status handle URLs, and actions with JS triggers (Update Order Status, Share cart, Download PDF) didn't work.Orders now follow the same pattern as Products and Transfers.
OrdersController::indexrenderscommerce::orders/Indexwith a newOrderIndexViewModel, and the sources go in the secondary nav.What the view model handles:
commerce/orders/{handle}URLs keep working for status and cart sources (viaOrder::sourceCpUri()anddefaultSourceKey()), so existing links and bookmarks still land on the right source.showSiteMenu()is overridden to show it on multi-site installs, andstoreIdis added inbaseCriteria().date-attrand is kept in the URL and across source switches.commerce-editOrders.Actions that need a settings step are swapped for window events in
actions()and handled on the page:get-load-cart-urlaccepts anidsince the Vue bulk bar sends IDs rather than numbers.Every action request now carries
?site=. Without itdefineActions()/defineSources()resolve the current site's store, so actions on a non-primary store's cart sources can't find their source.Other fixes this turned up:
/build/instead of Commerce's published path, which left the page blank.DownloadOrderPdfAction::pdfFileName()crashed when a PDF has no file name format (ZIP and single order downloads). It now falls back to{handle}-{number}.{num, plural, =1{Order} other{Orders}} updated.translation had a lowercase value.Removed:
orders/_index.twig, the DownloadOrderPdf trigger template,CommerceOrderIndex.js,CommerceUpdateOrderStatusModal.js,DownloadOrderPdf.js(with thecommercecpbundle rebuilt) and the actions'getTriggerHtml()methods.Left out on purpose: source badge counts. They should be a native cms element index feature, so
get-index-sources-badge-countsandbadgeCount => 0indefineSources()stay for now, and the index shows no counts until that lands.Date bounds are passed in UTC to work around cms
Query::whereDateParam()comparing local times against UTC-stored dates. That will be fixed separately in cms, and the workaround stays correct afterwards.Covered by
OrderIndexTest, and checked in the browser across sources, both stores, date presets and custom ranges, all three custom actions and export.