This is the How-tos bundle for Adobe Commerce Storefront on Edge Delivery Services # How-tos > Step-by-step storefront tasks for authors and developers > Generated: 2026-10-21T15:11:09.006Z > Source: https://experienceleague.adobe.com/en/tools/commerce-storefront --- # Render an additional wishlist The Wishlist drop-in renders the shopper's active wishlist out of the box. Sometimes you want a **second, purpose-built list** somewhere else on the storefront: a "Save for Later" list in the cart, a "Buy again" list on an account page, or a curated list on a landing page. This how-to shows the general pattern for rendering an additional wishlist beside the main one, and uses **Save for Later in the cart** as the worked example. The two mechanics that make this possible are: - **`wishlistId`** identifies *which* list a container renders and mutates, instead of the active one. - **`scope`** gives that container its own event channel, so its data never overwrites the active wishlist's. > The active wishlist lives on a single shared channel. Without a `scope`, a second container would emit and listen on that same channel and the two lists would overwrite each other. Always pair a specific `wishlistId` with a `scope`. ## Before you begin You should be familiar with: - [Wishlist functions](https://experienceleague.adobe.com/en/tools/commerce-storefront/dropins/wishlist/functions/) — `getWishlists`, `createWishlist`, `getWishlistById`, `addProductsToWishlist`, `mergeWishlists` - [Wishlist events](https://experienceleague.adobe.com/en/tools/commerce-storefront/dropins/wishlist/events/#wishlistdata-emits-and-listens) — the scoped `wishlist/data` event - [Wishlist container](https://experienceleague.adobe.com/en/tools/commerce-storefront/dropins/wishlist/containers/wishlist/) — the `wishlistId` and `scope` props This how-to shows the general approach. The snippets are a reference, not a drop-in-complete integration. ## The pattern ### 1. Choose a stable scope and resolve the list ID Pick a constant `scope` string for your list. It is the event channel every call for this list shares, so keep it stable and unique on the page. Resolving the `wishlistId` differs by authentication state, so wrap it in a helper. Authenticated shoppers have server lists you look up (or create) by name. Guests have no server lists, so you use a reserved local key that the drop-in persists in browser storage. ```js const LIST_NAME = 'Save for Later'; // used to find/create the authenticated list const GUEST_KEY = 'save-for-later'; // reserved local key for guests const SCOPE = 'save-for-later'; // this list's event channel async function resolveListId() { const lists = await WishlistApi.getWishlists(); // getWishlists() returns an array for authenticated shoppers and a single // object for guests. if (!Array.isArray(lists)) return GUEST_KEY; let list = lists.find((w) => w.name === LIST_NAME); if (!list) { list = await WishlistApi.createWishlist(LIST_NAME); } return list?.id ?? null; } ``` > Using the same value as both the guest key and part of your scope keeps the rest of the code auth-agnostic: you pass one `listId` through every call regardless of who is signed in. ### 2. Render the container with `wishlistId` and `scope` Render the `Wishlist` container into your own element, passing the resolved ID and the scope. Everything else (move-to-cart, routing, product data) is the same as the main wishlist. ```js function renderList(listId, $container) { wishlistRender.render(Wishlist, { wishlistId: listId, scope: SCOPE, moveProdToCart: Cart.addProductsToCart, routeProdDetailPage: (product) => getProductLink(product.urlKey, product.sku), getProductData: pdpApi.getProductData, getRefinedProduct: pdpApi.getRefinedProduct, })($container); } ``` Because the container is given a `wishlistId`, it loads and mutates only that list and never touches the active-list state. ### 3. Drive UI off the scoped `wishlist/data` event Subscribe to `wishlist/data` on your scope to keep a count or heading in sync. With `{ eager: true }`, the handler also runs with the current value as soon as it subscribes. Because it is scoped, it only ever receives this list's data. ```js events.on( 'wishlist/data', (list) => setCount(list?.items_count ?? 0), { eager: true, scope: SCOPE }, ); ``` ### 4. Add items to the specific list Pass the resolved `wishlistId` to `addProductsToWishlist` to target this list instead of the active one. In the Save for Later example, you add the cart line to the list and then remove it from the cart. ```js await WishlistApi.addProductsToWishlist( [{ sku: item.sku, quantity: item.quantity || 1 }], listId, ); await Cart.updateProductsFromCart([{ uid: item.uid, quantity: 0 }]); ``` > A targeted add to an authenticated list does not emit on the active channel, so no `wishlist/alert` toast fires automatically. Re-render the section (or show your own confirmation) after the add. For a guest list, pass `{ scope }` as the third argument if you want the updated list broadcast on your channel. ### 5. Merge the guest list on login Guests build their list in browser storage. When a guest signs in, fold that local list into the server list so nothing is lost. Resolve the server list, fetch it on your scope, then hand it to `mergeWishlists` with the guest key. The drop-in owns reading the list, deduplicating items by SKU and selected options, and clearing it afterward. ```js async function mergeGuestListIntoServer(serverListId) { if (!serverListId || serverListId === GUEST_KEY) return; const serverList = await WishlistApi.getWishlistById(serverListId, 200, 1, { scope: SCOPE, }); if (serverList) { await WishlistApi.mergeWishlists(serverList, GUEST_KEY); } } events.on('authenticated', async (authenticated) => { if (!authenticated) return; const serverListId = await resolveListId(); await mergeGuestListIntoServer(serverListId); renderList(serverListId, $container); }); ``` ### 6. Set a guest expiry (optional) The default guest wishlist never expires, but a named guest list can. Configure a time to live, in days, in your wishlist initializer, keyed by the same list key you used above. ```js title="scripts/initializers/wishlist.js" await initializers.mountImmediately(initialize, { isGuestWishlistEnabled: true, guestWishlistTtl: { 'save-for-later': 14, // the guest list expires 14 days after its last save }, }); ``` See [Guest list expiry](https://experienceleague.adobe.com/en/tools/commerce-storefront/dropins/wishlist/initialization/#guest-list-expiry) for details. ## Recap To render an additional wishlist beside the active one: - Resolve a `wishlistId` (server list for authenticated shoppers, reserved local key for guests) and pick a stable `scope`. - Render the `Wishlist` container with both, and drive your UI from the scoped `wishlist/data` event. - Target the list explicitly in `addProductsToWishlist` / `removeProductsFromWishlist`, and merge the guest list into the server list on login with `mergeWishlists`. The same pattern works for any secondary list, not just Save for Later. Swap the list name, key, and scope for your use case. --- # Show targeted content to selected shoppers Add a targeted block to show a promotion, message, or content fragment to selected shoppers. Choose customer groups, segments, or cart rules to control who sees the content. ## Before you start This guide assumes you are comfortable with how commerce block tables are laid out in a document. If you are new to block name rows, key-value settings, and merged full-width content rows, read [Block table structure](https://experienceleague.adobe.com/en/tools/commerce-storefront/merchants/blocks/block-tables/) first. Ask your administrator to confirm the available customer groups, segments, or cart rules, and obtain the identifiers you need. Your storefront must already support the targeted block. Use the configuration example below when following [the authoring steps](#how-to-enable-and-configure-personalization). ## Configuration Add this table to your document to configure a targeted block. A targeted block is a block configuration that conditionally shows content for selected customer groups, segments, or cart price rule contexts: | targeted-block | | | --- | --- | | Customer Segments | 1, 2 (example) | | Customer Groups | 1, 3 (example) | | Cart Rules | 5 (example) | | fragment | /path/to/fragment (example) | | type | promotion-banner (example) | In the `targeted-block` table, most settings use a key-value row: a two-column row where the first cell is the setting name and the second cell is the value (for example, `true`, a number, or a label). If you do not set a fragment path, you must add a final merged full-width row—one cell that spans the full table width so you can place rich page content in one place (for example, headings, text, and images). The `targeted-block` table uses that row for inline content when you do not load a separate fragment document. - `Customer Segments` — A segment is a rule-based way to target experiences to qualifying shopper cohorts. This row holds a comma-separated list of customer segment IDs; the block only appears for shoppers who belong to those segments. Optional. - `Customer Groups` — A customer group in Commerce is used to segment shoppers for pricing, permissions, or targeted content. This row holds a comma-separated list of customer group IDs; the block only appears for shoppers in those groups. Optional. - `Cart Rules` — A cart price rule is a Commerce rule you can use as a condition for targeting content or promotions. This row holds a comma-separated list of cart rule IDs; the block only appears when those cart price rules are satisfied. Optional. - `fragment` — An optional path to a separate content document. When you set a fragment, the `TargetedBlock` loads content from that document. When you omit it, add your content in the last merged full-width row in this `targeted-block` table, as described above. Optional. - `type` — A value that groups `TargetedBlock` entries: when several blocks use the same type, only the first one whose conditions match a shopper is shown, which allows fallback-chain behavior. Set it to the type name to use in that chain. Only the first block that satisfies the conditions of each type is shown. Optional. ## How to enable and configure Personalization Personalization blocks can be configured on each page through Document Authoring. Follow the step-by-step guide below to enable and configure Personalization: ### 1. Create customer segments, groups, or cart rules You must first create the targeting criteria in Adobe Commerce Admin that will determine which customers see your personalized content. 1. Log in to the Adobe Commerce Admin. 1. Create customer segments, customer groups, or cart price rules as needed: - **Customer Segments** - Go to **Customers** > **Segments** and follow the https://experienceleague.adobe.com/en/docs/commerce-admin/customers/segments/customer-segments to create segments. - **Customer Groups** - Go to **Customers** > **Customer Groups** and follow the https://experienceleague.adobe.com/en/docs/commerce-admin/customers/customer-groups to create groups. - **Cart Price Rules** - Go to **Marketing** > **Promotions** > **Cart Price Rules** and follow the https://experienceleague.adobe.com/en/docs/commerce-admin/marketing/promotions/cart-rules/price-rules-cart to create rules. ### 2. How to add and configure the Personalization block You can configure each page to display personalized content by setting targeting criteria and optionally specifying a fragment path or block type. 1. Open the page where you want to display personalized content. 1. Create a new table in your document with the block name `targeted-block`. 1. Add configuration properties based on your targeting needs: **Example: Target specific customer segments:** | targeted-block | | | --- | --- | | Customer Segments | 1, 2 | **Example: Load content from a fragment:** | targeted-block | | | --- | --- | | fragment | /path/to/fragment | **Example: Use fallback with block type:** Create two blocks with the same `type` value. The first block (with conditions) displays when conditions are met, and the second block (fallback) displays otherwise: | targeted-block | | | --- | --- | | Cart Rules | 5 | | type | promotion-banner | Then add a fallback block with the same type but no conditions: | targeted-block | | | --- | --- | | type | promotion-banner | > **Specify a fragment** If you don't specify a `fragment`, the content must be placed in the last merged full-width row, as described in the Configuration section. ## Check the result Preview the page in the shopper context that should match your criteria, then check a context that should not match. Confirm that the targeted content appears only where intended before publishing. Ask your developer for help when you cannot reproduce the required customer or cart context. ## Section metadata Control the section styling, spacing, and layout that wraps your commerce block. All properties are optional: | section-metadata | | | --- | --- | | Style | light (optional) | | Padding | medium (optional) | | Margin | small (optional) | | Column Width | 30% (optional) | | Gap | small (optional) | > **Learn more** See the [Section Metadata guide](https://experienceleague.adobe.com/en/tools/commerce-storefront/merchants/blocks/section-metadata/) for all available values and the [Page Metadata guide](https://experienceleague.adobe.com/en/tools/commerce-storefront/merchants/blocks/page-metadata/) for SEO and caching options. --- # Add product recommendations to a page Add a recommendation unit to a storefront page using a `product-recommendations` block. The unit you choose determines which products are recommended and whether the block needs product context. ## Before you begin Ask your administrator to confirm that Product Recommendations is available for your Commerce backend and that you can create or use a recommendation unit. Your storefront must already support the recommendations block. Follow [the authoring steps](#how-to-enable-and-configure-product-recommendations), using the configuration examples below. ## Configuration Add this table to your document to configure the block: | product-recommendations | | | --- | --- | | recId | 2ed7ea09-d9bd-4691-91c3-2c0a6d4fd869 (example) | | currentsku | crz-eco-tr-std-2017 (example) | | currentprice | 49.99 (example) | - **recId**: Recommendation unit ID from the Admin. Required for all pages. - **currentsku**: Seed product SKU. Required on non-PDP pages for **anchor-based** recommendation unit types (for example, more-like-this, visual similarity, viewed-viewed, viewed-bought, bought-bought). On PDP pages, the boilerplate reads the seed SKU automatically from the Adobe Client Data Layer (ACDL). - **currentprice**: Anchor product price (numeric). Required on non-PDP pages when the unit uses **dynamic or relative** price filter operators (Adobe Commerce Optimizer and Adobe Commerce as a Cloud Service only). Not required for static price filters—a fixed price range in the filter rule does not remove the need for a seed SKU on anchor-based types. On PDP pages, the boilerplate reads anchor price automatically from ACDL when needed. ### When product context is required Whether a seed SKU or anchor price is required depends on the **recommendation unit type** and the **price filter operator**, not on each other: | Unit type | Seed SKU | Anchor price | | --- | --- | --- | | **Anchor-based** (more-like-this, visual similarity, viewed-viewed, viewed-bought, bought-bought) | Required | Only for dynamic or relative price filter operators | | **Context-free** (most-viewed, most-purchased, and similar popularity or behavioral types) | Not required | Not applicable | A **static** price filter defines a fixed price range in the filter rule. It does not mean the unit can run without an anchor product. For example, a more-like-this unit with a static price filter returns no products when the seed SKU is missing, but returns results with the seed SKU alone—`currentprice` is not required. ### Storefront block configuration How you configure the block depends on the page type and unit type: - **PDP pages**: Set only `recId`. The boilerplate supplies the seed SKU from ACDL product context. On Adobe Commerce Optimizer and Adobe Commerce as a Cloud Service it also sends the ACDL anchor price automatically; the backend applies it only when the unit's filter uses a dynamic or relative operator. - **Non-PDP pages (PLP, cart, home, and so on)**: There is no product context on these pages. For **anchor-based** unit types, you must set `currentsku` in block config. Add `currentprice` only when the unit uses dynamic or relative price filter operators (Adobe Commerce Optimizer and Adobe Commerce as a Cloud Service only). - **Context-free unit types on any page**: Set only `recId`. These popularity and behavioral units do not use a seed product. > **Important** - Do not assume `recId` alone is enough on non-PDP pages. That applies to **context-free** unit types only. **Anchor-based** units on non-PDP pages require `currentsku` or they return no products. - Do not omit `currentprice` on non-PDP pages just because the unit uses a static price filter. Static filters still need a seed SKU for anchor-based types; they do not need anchor price. - Add `currentprice` on non-PDP pages only when the unit's price filter uses dynamic or relative operators. ## How to enable and configure Product Recommendations The Product Recommendations block can be configured on each page through Document Authoring. Follow the step-by-step guide below to enable and configure Product Recommendations: ### 1. Create a recommendation unit You must first create recommendation units in the Adobe Commerce Admin (PaaS) or Adobe Commerce Optimizer Admin (SaaS). #### Adobe Commerce Optimizer Admin (SaaS) The following steps apply to merchants using Adobe Commerce Optimizer or Adobe Commerce as a Cloud Service. 1. Log in to the Adobe Commerce Optimizer Admin. 1. On the Admin sidebar, go to **Recommendations**. 1. Follow the steps in the https://experienceleague.adobe.com/en/docs/commerce/optimizer/merchandising/recommendations/create to create a recommendation unit. > For Adobe Commerce Admin (PaaS), follow the steps in the https://experienceleague.adobe.com/en/docs/commerce/product-recommendations/admin/create to create a recommendation unit. ### 2. Get the recommendations unit ID You can specify which recommendation unit to display on each page by using the recommendation unit ID. 1. Navigate to the Product Recommendations page in the Adobe Commerce Admin or Adobe Commerce Optimizer Admin. 1. Click the eye icon next to the recommendation unit that you'd like to display on your store. 1. Copy the **Recommendation ID** from the modal. You will use this ID in the next step to configure the recommendations block. ### 3. Add and configure the recommendations block You can configure each page to display a specific recommendation unit by setting its recommendation ID. 1. Open the page where you want to display the recommendation unit. 1. Create a new table in your document with the block name `product-recommendations`. For product detail pages, set the `recId` to match the recommendation unit ID from the previous step. For example: | product-recommendations | | | --- | --- | | recId | 2ed7ea09-d9bd-4691-91c3-2c0a6d4fd869 | > **PDP pages** — set only `recId` for all unit types. The boilerplate reads seed SKU (and anchor price when needed) from ACDL. **Non-PDP pages — anchor-based unit types** — set `recId` and `currentsku`. For example, a more-like-this unit on a category page: | product-recommendations | | | --- | --- | | recId | 2ed7ea09-d9bd-4691-91c3-2c0a6d4fd869 | | currentsku | crz-eco-tr-std-2017 | This applies even when the unit uses a **static** price filter. The seed SKU is required; anchor price is not. **Non-PDP pages — dynamic or relative price filters** — also set `currentprice` on Adobe Commerce Optimizer or Adobe Commerce as a Cloud Service: | product-recommendations | | | --- | --- | | recId | 2ed7ea09-d9bd-4691-91c3-2c0a6d4fd869 | | currentsku | crz-eco-tr-std-2017 | | currentprice | 49.99 | **Non-PDP pages — context-free unit types** (most-viewed, most-purchased, and similar) — set only `recId`, same as on PDP. ## Check the result Preview the page and confirm that the selected recommendation unit appears. For a unit that needs a seed product, check the product context required by the examples above. Publish when the unit displays as expected; ask your administrator or developer to investigate an empty unit rather than changing its identifier at random. ## Section metadata Control the section styling, spacing, and layout that wraps your commerce block. All properties are optional: | section-metadata | | | --- | --- | | Style | light (optional) | | Padding | medium (optional) | | Margin | small (optional) | | Column Width | 30% (optional) | | Gap | small (optional) | > **Learn more** See the [Section Metadata guide](https://experienceleague.adobe.com/en/tools/commerce-storefront/merchants/blocks/section-metadata/) for all available values and the [Page Metadata guide](https://experienceleague.adobe.com/en/tools/commerce-storefront/merchants/blocks/page-metadata/) for SEO and caching options. --- # Add terms and conditions to checkout Publish agreement documents and link them from the checkbox labels shoppers see at checkout. Work with your administrator and developer to confirm how your storefront defines its agreements before changing their configuration. ## Before you begin - Obtain approved agreement text and the languages or store views that need it. - Check that you can author and publish documents and update the storefront's placeholders sheet. - Ask your developer whether the storefront uses its default agreement, custom agreements, or Admin-managed Commerce agreements, and which Admin settings apply. > The default storefront defines a manually accepted agreement with the label key `Checkout.TermsAndConditions.label`. Adding agreement records in Admin does not automatically replace that code-defined agreement. Additional agreements or a different agreement source require developer configuration; see the [TermsAndConditions reference](https://experienceleague.adobe.com/en/tools/commerce-storefront/dropins/checkout/containers/terms-and-conditions/). > **TermsAndConditions configurable on a per store-view basis** For a storefront configured to use store-view-specific agreements, prepare the corresponding documents and labels for each language. Ask your developer to confirm that checkout uses the intended agreement source for each store view. Visit the [Multi-store setup](https://experienceleague.adobe.com/en/tools/commerce-storefront/setup/configuration/multistore-setup/) documentation for more information on how to build blocks and configure the storefront structure based on **Edge Delivery Services (EDS)**. ## How to enable and configure the Terms and Conditions Confirm the applicable Admin configuration with your developer, publish the agreement documents, and update the labels for the agreement source your storefront uses. ### 1. Enable the component If your developer confirms that your checkout requires the Commerce Admin setting, ask an administrator to enable it as follows: 1. Log in to the Admin Panel. 1. On the Admin sidebar, go to **Stores** > _Settings_ > **Configuration**. 1. In the left panel, expand **Sales** and choose **Checkout**. 1. Expand the **Checkout Options** section. 1. Set **Enable Terms and Conditions** to "Yes". 1. Click **Save Config**. See https://experienceleague.adobe.com/en/docs/commerce-admin/stores-sales/point-of-purchase/checkout/terms-and-conditions documentation for more information on how to enable the terms and conditions using the Admin Panel. ### 2. Create the agreement document For agreement labels that link to storefront documents, create the content in Document Authoring: 1. Create an agreement document at the intended path, such as `/terms-and-conditions` or a locale-specific path. 1. Add the approved agreement text and any required links. 1. Preview and publish the document. 1. Open its published URL and confirm that shoppers can read it without an authoring login. Keep this URL for the checkbox label. ### 3. Configure the agreement checkbox label Use the **EDS placeholders** or the **Admin Panel** instructions in the following tabs to configure the agreement checkbox label. ### Using EDS placeholders For the default storefront agreement, update the **`placeholders`** sheet using the existing label key and the following information. For additional agreements, ask your developer which label keys their configuration uses. - An **_identifier_**: It's the reference that identifies the label translated - A **_label_**: The text displayed next to the checkbox comes from the storefront placeholders for the shopper's language. It accepts HTML links to your published agreement documents. Similarly, the merchant can configure the translation for the validation error that appears when the user clicks the `Place Order` button and an agreement is not checked, using the **"Checkout.TermsAndConditions.error"** identifier. Sample of **placeholders** sheet: ```txt "Checkout.TermsAndConditions.label", "I have read, understand, and accept the [Terms of Use, Terms of Sales, Privacy Policy, and Return Policy](/en/privacy-policy)." "Checkout.TermsAndConditions.error", "Please accept the Terms and Conditions to continue." ``` Replace the example wording with approved text and the example link with the published URL of your agreement document. Follow [Change labels and placeholders](https://experienceleague.adobe.com/en/tools/commerce-storefront/how-tos/change-labels-and-placeholders/) to preview and publish the updated sheet. These labels are used to render the `TermsAndConditions` container in the **commerce-checkout.js** block file. Refer to the Adobe Commerce documentation for examples on how to use these labels. ### Using the Admin Panel Use this option only when your developer has configured checkout to use Admin-managed Commerce agreements. It does not automatically change the default code-defined agreement. The merchant has to configure the checkbox label for each agreement using the Admin Panel. As mentioned before, the Admin Panel allows merchants to create configurations per store-view level as follows: 1. Log in to the Admin Panel. 1. On the Admin sidebar, go to **Stores** > _Settings_ > **Terms and Conditions**. 1. In the upper-right corner, click the **Add New Condition** button. 1. Enter the following **Terms and Conditions** information: - **`Condition Name`** The agreement identifier - **`Status`** Attribute to indicate if it's available or not: - 'Enabled'; the agreement will be retrieved by the GraphQL API query - 'Disabled'; the agreement won't be retrieved by the GraphQL API query - **`Applied`** Specifies how the checkbox should appear: - 'Manually': the user is required to manually check and accept the conditions to place an order - 'Automatically': the checkbox will appear checked by default, conditions are automatically accepted upon checkout - **`Store View`** Defines the scope at store view level for this agreement where you want these Terms and Conditions to be used - **`Checkbox Text`** It contains directly the text to show; it accepts HTML with links to a specific page in EDS > **Some attributes are not used** Although the following attributes are provided by the Admin Panel, they are not going to be utilized in the current solution because they will be handled in EDS. Merchants are able to work on their own solution if they want to use them: - **`Content`** As described above, the content for the agreements pages will be created **ONLY** using EDS - **`Show Content as`** (Text, HTML) Not really needed because EDS pages accept HTML code - **`Content Height (css)`** 1. Click **Save Condition**. These entries are used to render the `TermsAndConditions` container in the **commerce-checkout.js** block file. Refer to the Adobe Commerce documentation for examples of this feature. See the https://experienceleague.adobe.com/en/docs/commerce-admin/stores-sales/point-of-purchase/checkout/terms-and-conditions documentation to learn how to configure the terms and conditions using the Admin Panel. > For storefront-authored agreement documents, the checkbox label must link to the relevant published document for the shopper's language or store view. ## Check the result Preview checkout for each affected store view. Confirm that the intended agreement appears, its links open the published documents, and any required manual acceptance is enforced before an order can be placed. Use your team's test-order process rather than placing an unintended live order. --- # Copy content between Document Authoring projects To migrate content from one Document Authoring project to another, you use the Traverse, Import, and Bulk Operations apps. This page shows you how.  *Migrate content between Document Authoring projects.* ## Before you start You'll need: - Write access to both projects on DA.live - The organization and site path for each project (for example, `/acme/storefront-staging` and `/acme/storefront`) - A target project that already exists with the right GitHub repository and Commerce backend - Permission to preview and publish on the target, or a developer who can run Bulk Operations for you ## Step-by-step ### 1. Traverse the source project 1. Open https://da.live, select **Apps**, and open **Traverse**. 1. Enter the source path `/organization/site` (for example, `/acme/storefront-staging`). Start with `/`. 1. Select **Crawl**, then **Copy list**.  *Traverse your source project.* ### 2. Import into the target project > Import overwrites any file in the target project that has the same name as a file in your list. Review your list before you run it and move any files you want to keep to a different folder in the target project so you can copy them back later as needed. 1. Open **Import** from **Apps** (https://da.live/apps/import). 1. Paste the file paths from the Traverse into **By Url**. 1. In the **Into** field, enter your organization and target site name (for example, `acme` and `storefront`). 1. Select the **Import** button.  *Import into the target project.* ### 3. Traverse the target project 1. Open the **Traverse** app again. 1. Enter the target path (for example, `/acme/storefront`). 1. Select the **Crawl** button, then the **Copy list** button. Use this target list in Bulk Operations, not the source list.  *Traverse the target project.* ### 4. Preview and publish 1. Open the **Bulk Operations** app from **Apps**. 1. Paste the target Traverse list into the **URLs** field. 1. Choose **Preview**, then select **Submit**. Spot-check home, product list, cart, and checkout on the preview site. 1. Choose **Publish**, then select **Submit**. Confirm the live site.  *Preview and publish on the target site.* ## Verify - Open migrated content in https://da.live and on the preview site. - Spot check the home (index) page, product list page, product detail page, cart page, and checkout page. ## Reference ### What Import copies The **Traverse** app lists page paths in a project. The **Import** app copies only the paths you paste from that list. A typical crawl lists storefront documents such as `cart.html` and `checkout.html`, not every image or label sheet file. Import does not copy storefront code, Commerce catalog data, or shopper cart session data in Commerce. After Import, you still run the **Bulk Operations** app so the preview and live sites show the update. ### Images and media When you import a path, you copy the page content and the image references inside that page. Traverse does not list a top-level `media` folder or hidden asset folders. Add `media/...`, sheet, or JSON paths to your list when you need them. If you see a broken image on the target preview site, the page references a media path (for example, `/media/hero.png`) that was not imported. Add that path to the Import list and run Import again, or upload the file in the target project on DA.live. See https://docs.da.live/authors/guides/adding-media on docs.da.live. ### If button labels or URLs look wrong Review [placeholder sheets](https://experienceleague.adobe.com/en/tools/commerce-storefront/merchants/blocks/placeholder-sheets/) (label text for cart, checkout, and other blocks) and `redirects.json` for URL-forwarding rules. ### Troubleshooting | Symptom | What to try | | --- | --- | | Crawl returns nothing | Start the path with `/`. Confirm you have access to the project folder. | | Import fails | Confirm access to both projects. | | Broken images on preview | Add missing `media/...` paths to the Import list and import again. | | Live site unchanged | Run **Publish** after **Preview**. | ## Related topics - https://docs.da.live/authors/guides/apps/content-tree (docs.da.live) --- # Translate storefront content Use the **Document Authoring Tool** (da.live) Translation app to translate your storefront content into multiple languages. After translation, ask your development team to complete the Commerce-specific tasks for placeholder files and store view verification (see [Commerce localization tasks](https://experienceleague.adobe.com/en/tools/commerce-storefront/dropins/all/commerce-tasks/)). > **Before translating** Complete the [multistore setup](https://experienceleague.adobe.com/en/tools/commerce-storefront/setup/configuration/multistore-setup/) to create the folder structure, configure store views, and set up the currency and headers. This guide covers translating the content in those folders. ## Prerequisites - You have a storefront project in the Document Authoring app (https://da.live). - You know the basics of using the Document Authoring tool (https://da.live/docs). ## Overview The following diagram provides the basic workflow for translating the Edge Delivery content of your storefront into multiple languages using the Document Authoring apps from https://da.live.  *Workflow for localizing your storefront* ## Step-by-step These steps provide the details for the translation workflow shown in the diagram. The steps describe how to translate the default English store to another language. In this example, the default English store is translated to French (`fr`). ### 1. Navigate to the apps page for your storefront 1. Open your storefront project in the Document Authoring tool (https://da.live). 1. Select Apps from the left sidebar. ### 2. Use the Traverse app to get a list of site URLs 1. Open the **Traverse** app by selecting its *Go* button. 1. On the Crawl Tree page, enter the organization name and site name for your storefront. Example: `/acme/storefront`. Ensure that you enter a forward slash (`/`) at the beginning of the string or it will not work. 1. Select the **Crawl** button to start the crawl. 1. Select the **Copy list** button after the URLs for the site have been traversed. This puts all the URLs in your clipboard. 1. Return to the Apps page. ### 3. Use the Translation app to translate your storefront 1. Open the **Translate** app by selecting its *Go* button. 1. On the Localization page, enter the title for the translation project: `acme-storefront-fr`. 1. Paste the list of URLs from the **Traverse** app into the **URLs** field. > Exclude configuration files such as `metadata.json`, `redirects.json`, and `sitemap.json` unless your developer has asked you to include them. These are not ordinary page content. 1. Select the **Next** button. 1. View the validated URLs to ensure that they are all correct. 1. Select the **Next** button. 1. Select one or more languages you want to translate to. In this example, the translation is to French (`fr`). 1. For the French language, select **Translate** from the selector, then select the **Create project** button. 1. From the project page, select the **Send all for translation** button. > **Translation services** By default, the Translation app uses the Google Translate service to translate the content of the storefront into the selected language. Your organization can also connect other translation services for a more robust translation experience. For more information on translation services and configuration, see https://www.aem.live/docs/translation-and-localization. ### 4. View the translated site 1. Navigate back to the main (root) folder for your English storefront. 1. Scroll the site files and folders to find the `fr` folder and open it. 1. Select a document to view the translated content. For example, select the `index` document to view the translated home page. ## Check the result Open representative documents in the translated folder and review their text and links. Ask your development team to complete [Commerce localization tasks](https://experienceleague.adobe.com/en/tools/commerce-storefront/dropins/all/commerce-tasks/) and confirm that the translated pages use the intended store view, currency, and storefront labels before publishing them. ## Additional resources ### Edge Delivery Services documentation - https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/edge-delivery/overview - Adobe Experience League - https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/edge-delivery/document-authoring/authoring - Adobe Experience League - https://www.aem.live/docs/ - aem.live ### Translation and localization - https://www.aem.live/docs/translation-and-localization - aem.live - https://da.live/docs/administration/translation - da.live ## Next steps After translating your content with the da.live Translation app: 1. **Hand off Commerce tasks**: Ask your development team to follow [Commerce localization tasks](https://experienceleague.adobe.com/en/tools/commerce-storefront/dropins/all/commerce-tasks/) to: - Translate drop-in placeholder files (`cart.json`, `checkout.json`, `pdp.json`) - Verify store view configuration aligns with your multistore setup - Test Commerce functionality (product data, pricing, currency, store switcher) 2. **Review best practices**: See Commerce-specific best practices in [Commerce localization tasks](https://experienceleague.adobe.com/en/tools/commerce-storefront/dropins/all/commerce-tasks/). 3. **Troubleshooting**: For Commerce-specific issues, refer to the troubleshooting section in [Commerce localization tasks](https://experienceleague.adobe.com/en/tools/commerce-storefront/dropins/all/commerce-tasks/). ## Troubleshooting For da.live Translation app issues, see: - https://www.aem.live/docs/translation-and-localization - aem.live - https://da.live/docs/administration/translation - da.live - https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/edge-delivery/document-authoring/authoring - Adobe Experience League For Adobe Commerce store view configuration issues, see: - https://experienceleague.adobe.com/en/docs/commerce-admin/stores-sales/site-store/store-views - Adobe Experience League - https://experienceleague.adobe.com/en/docs/commerce-admin/config/scope-change - Adobe Experience League --- # Add a block to a page Add a block table to a document to place a shopping feature or content element on your page. Your storefront must already support the block you choose; adding a new block implementation requires a developer. ## Before you begin - Open the page in [Document Authoring](https://experienceleague.adobe.com/en/tools/commerce-storefront/merchants/quick-start/document-authoring/). - Find the block name and required settings in the [Commerce block reference](https://experienceleague.adobe.com/en/tools/commerce-storefront/merchants/blocks/), or use a content block supported by your storefront. - Make sure you have permission to preview and publish the page. ## Add the block 1. Insert a table where you want the block to appear in the document. 1. Enter the block name in the first row, for example, `commerce-cart`. If the table has two columns, merge the cells in this row. 1. Add the settings required by the block's reference page. Put the setting name in the first column and its value in the second column. Some blocks need only the name row. 1. Preview the page and confirm that the block appears where you placed it. 1. Publish the page when the result looks right. For examples of settings and merged content rows, see [Block table structure](https://experienceleague.adobe.com/en/tools/commerce-storefront/merchants/blocks/block-tables/). ## Check the result Open the published page and confirm that the block appears with the settings you chose. If it does not appear, check the block name and required rows against its reference page. For an example that also includes page metadata and section styling, follow [Create your first commerce page](https://experienceleague.adobe.com/en/tools/commerce-storefront/how-tos/create-commerce-page/). --- # Enable Payment Services payment buttons in checkout The Commerce boilerplate's checkout page already includes the Payment Services credit card form, so shoppers can pay by card out-of-the-box. To enable payment with PayPal, Apple Pay, or Google Pay, additional frontend code is required to render those buttons on the checkout page. This how-to shows you how. ## What you'll build By the end of this how-to, you'll have updated the `commerce-checkout` block so that selecting PayPal, Apple Pay, or Google Pay as a payment method: - Shows a short instructional notice, for example, "Complete your purchase using the PayPal button below." - Replaces the "Place order" button at the bottom of the page with the matching branded button. Here's the result for each payment method:     ## Prerequisites Before you begin, make sure you have: - A working [Commerce storefront](https://experienceleague.adobe.com/en/tools/commerce-storefront/get-started/create-storefront/) on Edge Delivery Services - Familiarity with [customizing blocks](https://experienceleague.adobe.com/en/tools/commerce-storefront/blocks/customize-blocks/) in your code repository - Completed the onboarding steps described in [Payment Services installation](https://experienceleague.adobe.com/en/tools/commerce-storefront/dropins/payment-services/installation/) - [@dropins/storefront-payment-services](https://www.npmjs.com/package/@dropins/storefront-payment-services) at version [4.2.1](https://www.npmjs.com/package/@dropins/storefront-payment-services/v/4.2.1) or higher in `package.json` ## Step-by-step The following steps describe how to add PayPal, Apple Pay, and Google Pay buttons to the `commerce-checkout` block. > **Express payment methods** The code snippets in this how-to call PayPal, Apple Pay, and Google Pay _express payment methods_. This code uses the term for a payment method that skips the credit card form and renders its own branded button in place of "Place order,". ### 1. Prepare "place order" action slot In the boilerplate's default checkout, the "Place order" button sits at the bottom of the page, the last action after shipping, payment, billing, terms and conditions, and promo codes on mobile. When a shopper selects PayPal, Apple Pay, or Google Pay, that same spot needs to hold the branded button instead, so both buttons need to share one dynamic slot. > **Why not render it inline?** An alternative would be to render the selected method's branded button below the payment options (in the same spot where the credit card form appears), hiding the default "Place order" button while that payment method stays selected. On smaller mobile screens, everything that follows (the billing address form, terms and conditions, and promo code inputs) can push the branded payment button out of view, leaving shoppers with no visible way to continue. Rendering the button in the same slot as "Place order" keeps the final action at the bottom, visible no matter what renders above it. To add that shared slot, adapt your `blocks/commerce-checkout` block as follows: 1. Navigate to the `blocks/commerce-checkout/containers.js` file and find the `renderPlaceOrder` function. ```js /** * Renders place order button with handler functions - follows multi-step pattern * @param {HTMLElement} container - DOM element to render the place order button in * @param {Object} options - Configuration object with handler functions * @param {Function} options.handleValidation - Validation handler function * @param {Function} options.handlePlaceOrder - Place order handler function * @returns {Promise