feat(composables): add support for deep link code option in order loading

[Maciej D (mdanilowicz)]

This pull request introduces a comprehensive order detail feature for the Vue demo store, supporting both guest and authenticated users. It adds new dedicated pages for order details, implements guest order lookup via deep link code, and introduces several new UI components for displaying order information. The useOrderDetails composable has been enhanced to support fetching orders either by ID or deep link code, and relevant tests have been added to ensure this functionality.

Order detail pages and guest order lookup:

• Added order detail page accessible via deep link code (/account/order/[deepCode]) with guest verification (email + postal code) and a dedicated order details page for logged-in users (/account/order/details/[id]).
• Enhanced useOrderDetails composable to support an options parameter with isDeepLinkCode flag, enabling order fetching by deep link code for guest users. [1] [2] [3] [4]
• Added and updated tests for useOrderDetails to cover deep link code and ID-based order fetching scenarios.

New order detail components:

• Introduced new components for order details: Addresses.vue, LineItems.vue, PriceSummary.vue, PaymentMethodCard.vue, ChangePaymentModal.vue, and ShippingMethodInfo.vue, each handling specific aspects of the order UI and i18n. [1] [2] [3] [4] [5] [6]

Internationalization and UI improvements:

• Added i18n support for order authentication and messages, improving the user experience for both guest and logged-in users.

closes #2063
closes #1390

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
frontends-starter-template-extended	Ready	Preview, Comment	Mar 4, 2026 10:56am
frontends-vue-starter-template	Building	Preview, Comment	Mar 4, 2026 10:56am
old-frontends-demo	Building	Preview, Comment	Mar 4, 2026 10:56am
shopware-frontends-docs	Ready	Preview, Comment	Mar 4, 2026 10:56am

[Copilot]

Pull request overview

Enhances the useOrderDetails composable to support fetching an order via a guest deep link code (instead of an order ID), addressing issue #2063 and adding tests plus a changeset entry.

Changes:

• Add UseOrderDetailsOptions with isDeepLinkCode flag to useOrderDetails.
• Update the readOrder post /order request to use a deepLinkCode filter when isDeepLinkCode is enabled.
• Add test coverage for both deep-link-code and order-id loading paths.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
packages/composables/src/useOrderDetails/useOrderDetails.ts	Adds options + conditional request body to support deep link code lookups.
packages/composables/src/useOrderDetails/useOrderDetails.test.ts	Adds tests validating request shape for deepLinkCode vs ids loading.
.changeset/warm-pandas-glow.md	Declares a minor version bump and documents the new option.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 34 out of 34 changed files in this pull request and generated 6 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Patryk Tomczyk (patzick)]

i think isGuestOrder would be more descriptive in what we're trying to do here, we definetly should propose an endpoint where it's resolved automatically, but first a few questions:

• Is the order structure exactly the same as with logged in user? Can we use the same methods like cancel or changePaymentMethod?
• Why you did not implemented this in this PR but you manually load these orders in [order].vue page?
• other methods are using orderId in invocations, this would use deepLink in the cover of orderId fact which would be very hard to debug

To sum that up, I'm more leaning toward creating dedicated useGuestOrder composable

[Maciej D (mdanilowicz)]

i think isGuestOrder would be more descriptive

Done

Is the order structure exactly the same as with logged in user? Can we use the same methods like cancel or changePaymentMethod?

We are receiving a new context API token, so the customer is logged in as a guest customer

Why you did not implemented this in this PR but you manually load these orders in [order].vue page?

Sorry, but I don't understand. Can you add more context?

other methods are using orderId in invocations, this would use deepLink in the cover of orderId fact which would be very hard to debug

deepLink code is used only on the init call to verify token or credentials (if form is displayed). All other calls are using orderID as an entity ID, the deepLink code is not used.

To sum that up, I'm more leaning toward creating dedicated useGuestOrder composable

There is no need to have a separate composable because of the context token for guest users.

We could stop fetching data directly inside the composable and instead inject the data into it from the outside. However, this would be a breaking change, as it would alter the way the composable is currently used.

[Patryk Tomczyk (patzick)]

We are receiving a new context API token, so the customer is logged in as a guest customer

So when you load order with deeplink you're also logging in as guest during that operation?

Sorry, but I don't understand. Can you add more context?

Not sure how to describe it differently - you changed composable but haven't used that change anywhere :)

deepLink code is used only on the init call to verify token or credentials (if form is displayed). All other calls are using orderID as an entity ID, the deepLink code is not used.

And this is where confusion will also start for other users - you're passing orderId creating composable but in fact it's deepLInk - any other method will use that as orderId, you added logic only in a single loadOrder method so it can actually recognise that it's not orderId. This speaks even more into having separate composable for that case

[Maciej D (mdanilowicz)]

So when you load order with deeplink you're also logging in as guest during that operation?

Yes

Not sure how to describe it differently - you changed composable but haven't used that change anywhere :)

Ah, useOrderDetails, sure, removed

And this is where confusion will also start for other users - you're passing orderId creating composable but in fact it's deepLInk - any other method will use that as orderId, you added logic only in a single loadOrder method so it can actually recognise that it's not orderId. This speaks even more into having separate composable for that case

No, no, we are using deepLink only for the init request. After that, you use orderId as the main identifier key. The main problem is that we are fetching data inside the composable. Injecting data into the composable resolves all problems, one composable for all types of order data.

[Patryk Tomczyk (patzick)]

let's just remove unnecessary changeset for composable

[Patryk Tomczyk (patzick)]

this file not relevant anymore, right?