Admin and Store Setup

The Admin lives at a random path chosen by the installer (see Installation); bin/magento info:adminuri prints it, for example /admin_483qz01. The login page answered 200 on that path and 404 on the guessable /admin. After the login every Admin URL carries a secret key (.../admin/dashboard/index/key/<64 hex characters>/) because Add Secret Key to URLs is on by default under Stores > Configuration > Advanced > Admin > Security; a bookmarked URL without a valid key redirects to the dashboard.

The top-level menu of the Mage-OS 3.6.0 Admin, read from the rendered page, with the leaf pages. Every leaf link answered HTTP 200 when it was followed with the session of the test administrator.

Things you may expect from the Adobe documentation but will not find in this menu: customer segments, content staging and scheduled changes for products, B2B company accounts, reward points and gift registries. Adobe’s documentation presents them as Adobe Commerce features. Many Adobe pages carry an edition or platform badge; if a feature you read about is missing from your menu, check the badge and your edition. Mage-OS also changes the look: the Admin pages of the test install were rendered with the Mage-OS admin theme (MageOS/m137-admin-theme, from the static URL of the logo), and the stock Magento/backend theme is deployed beside it.

Stores > Configuration has seven tabs, and the sections listed here were present on the install: General (General, Web, Currency Setup, Store Email Addresses, Contacts, Reports, Content Management, New Relic Reporting, Content Security Policy, Security.txt), Security (Google reCAPTCHA for the Admin and for the storefront), Catalog (Catalog, Inventory, XML Sitemap, RSS Feeds, Email to a Friend), Customers (Login as Customer, Newsletter, Customer Configuration, Wish List, Promotions, Persistent Shopping Cart), Sales (Sales, Sales Emails, PDF Print-outs, Tax, Checkout, Shipping Settings, Multishipping Settings, Delivery Methods, RMA, Google API, Payment Methods, 3D Secure), Services (Magento Web API, OAuth, AI Integration) and Advanced (Admin, System, Developer). The Developer section is visible only in developer mode.

Source: Adobe: Admin overview

Create the first administrator with the installer (see the installation page) and further ones from the command line or under System > Permissions > All Users. Restrict what each person can do with System > Permissions > User Roles, which ties a role to a set of resources (the same ACL resources that acl.xml files define in modules).

Source: Adobe: Two-factor authentication

admin:user:create printed "Created Magento administrator user named grace" in the test; the other commands appear in bin/magento list. Stores > Configuration > Advanced > Admin > Security holds the policies you should read before launch: Admin Session Lifetime (seconds), Maximum Login Failures to Lockout Account, Lockout Time (minutes), Minimum Admin Password Length, Password Lifetime (days), Password Change, Admin Account Sharing, Login is Case Sensitive, Add Secret Key to URLs and the password-reset limits. Two-factor authentication is on by default (module Magento_TwoFactorAuth) and applies to the Admin and to admin API tokens: on the test install POST /rest/V1/integration/admin/token answered "Please ask an administrator with sufficient access to configure 2FA first." until the module was disabled on a laptop. Do not disable it anywhere real. When Adobe IMS sign-in is enabled instead (Adobe Commerce), the native two-factor screens are disabled because Adobe IMS handles the sign-in.

Almost every setting under Stores > Configuration can be set for the whole installation (Default Config), for a website, or for a store view. Magento reads a value from the most specific scope that has one and falls back outward, and finally to the module’s config.xml default. Values written to app/etc/env.php or app/etc/config.php override the database and make the field read-only in the Admin.

The same setting is available in three equivalent ways, which is what makes a store reproducible:

Source: Adobe: Set configuration values

Facts observed with these commands: the path must exist in a module’s system.xml (an unknown path prints The "x" path doesn't exist. Verify and try again.); config:show prints only the values stored at the scope you ask for, so a store view that inherits prints an empty line; a locked value cannot be changed again without --lock-env (The value you set has already been locked. To change the value, use the --lock-env option.); --lock-config writes to the shared config.php instead. Values stored with --lock-env end up under a system key of env.php, for example {"default":{"web":{"cookie":{"cookie_lifetime":"7200"}}}}. A change made with the CLI shows in the Admin at once; the Tax page of the test install showed the values set below as Including Tax, After Discount and Total.

A website holds shared customers, a base currency and often payment and shipping methods; a store (a store group) is a catalogue with a root category and a default store view; a store view is one language and presentation of a store. A single-language shop still has one website, one store and one store view; Pocket Coffee adds a second store view for English. The four entities are managed under Stores > Settings > All Stores and can be listed from the command line.

Source: Adobe: Stores and store views

There is no CLI command and no REST endpoint to create a store view in 2.4.9; use Stores > All Stores > Create Store View, or a short PHP script that bootstraps the framework and uses the store resource model of Magento_Store (this is what produced the table above, and it is idempotent):

Source: Adobe: Stores and store views

Run it as the file system owner from the project root (php create-store-view.php), then set the locale of the new view, which needs the language to exist (bin/magento info:language:list printed 94 locales, including es_ES, en_US, ca_ES and de_DE; further language packs install with Composer):

Source: Adobe: Stores and store views

By default a store view is chosen by a cookie or the ___store query parameter; to give each language its own URL set Add Store Code to Urls (web/url/use_store) under General > Web > Url Options or give each store view its own base URL under Base URLs. The Pocket Coffee names for the website, the store and the first store view (the installer names the website Main Website and the view Default Store View) were set with the same kind of script.

Stores > Configuration > General is where the country, locale, store identity and emails live. These are the sections used by Pocket Coffee with their Admin labels (read from the Admin pages), the configuration path and the value applied.

Source: Adobe: General configuration

The Pocket Coffee settings were applied with one config:set per line; every command answered Value was saved.:

Source: Adobe: General configuration

Spain is one of the 39 countries for which a state or province is required (general/region/state_required), so an address for a Spanish customer needs region_id as well: Madrid is region 161 of the 52 Spanish regions in the directory. The REST checkout rejected a Spanish address without it with Please check the shipping address information. "regionId" is required. Enter and try again.

Stores > Configuration > General > Currency Setup > Currency Options has three fields: Base Currency (currency/options/base, the currency the catalogue is priced in and the one orders are charged in), Default Display Currency (currency/options/default) and Allowed Currencies (currency/options/allow). Pocket Coffee’s base and display currency is EUR, set by the installer; adding USD makes it selectable:

Source: Adobe: Configure currency

The Catalog Price Scope (catalog/price/scope, Stores > Configuration > Catalog > Catalog > Price) is global by default; set it to Website to price the same product differently per website, which also lets each website have its own base currency.

The exchange rates are managed under Stores > Currency > Currency Rates (the page lists the rates between the allowed currencies and an Import Service selector) and stored in directory_currency_rate. A new install already holds a rate of 1.415 USD for 1 EUR, which is a placeholder: a store that shows a second currency must replace it with a real rate or schedule an import. The import services in the 3.6.0 code are Fixer.io (legacy), Fixer Api (APILayer) and Currency Converter API, each with an API Key and Connection Timeout in Seconds, plus Scheduled Import Settings (Enabled, Service, Start Time, Frequency and the error-email fields). Adobe states that Fixer.io was deprecated and replaced by Fixer API (APILayer) from 2.4.6. Scheduled imports run in cron.

Checked from the storefront side: with USD allowed and the placeholder rate, the GraphQL request below returned the starter kit at 33.96 USD (24.00 EUR x 1.415):

Source: Adobe: Configure currency

The header is Content-Currency; a request that sends Currency: USD was ignored and returned EUR. Customers see the display currency, and the amounts are converted at the stored rate, but the payment method receives the order in the base currency unless it supports the display currency, so confirm with your payment provider before you promise "charge in USD". Currency symbols are customised under Stores > Currency > Currency Symbols.

A customer group decides which prices, rules and tax class apply to a shopper. Four groups exist after the install:

Create the Pocket Coffee group under Customers > Customer Groups or with the API; it returned id 4:

Source: Adobe: Customer groups

The customer tax class chosen for the group (Tax Class) is the one tax rules match against; you need a second customer tax class only when different customers pay different taxes (for example tax-exempt organisations). The rest of the customer behaviour sits in Stores > Configuration > Customers > Customer Configuration:

With Require Emails Confirmation on, a customer created through the API could not obtain a token: POST /rest/V1/integration/customer/token answered "This account isn’t confirmed. Verify and try again." The Pocket Coffee setup turns it off for development; leave it on in production and send the confirmation email.

Customers > All Customers lists customers, Login as Customer Log records the "Login as Customer" feature (Magento_LoginAsCustomer, which lets an administrator open the storefront as a customer; configure it under Stores > Configuration > Customers > Login as Customer), and Now Online shows active sessions.

Magento’s tax model has four parts: tax classes (labels for products, customers and shipping), tax rates (a rate for a country, region and postcode pattern), tax rules (which class combinations use which rates) and the calculation settings that decide how the maths is done. Pocket Coffee sells a food product with a reduced VAT rate and equipment at the standard rate, prices include VAT, and the customer pays the tax of the shipping address. The rates 10 and 21 percent below are illustrative values for the walkthrough, not tax advice; take the rates, thresholds and rules for each country from your tax adviser.

Source: Adobe: Tax rules

The Admin screens are Stores > Taxes > Tax Rules and Tax Zones and Rates (with System > Data Transfer > Import/Export Tax Rates for bulk loads). A tax rate with postcode * matches every postcode in the country. Product tax class 2, Taxable Goods, exists after the install and is the default for products; class 3, Retail Customer, is the default customer class.

The calculation settings are under Stores > Configuration > Sales > Tax. These are their Admin labels, the CLI values used and the value the Admin showed back:

Source: Adobe: Tax settings

The result for a Coffee Club member in Spain is the worked example below: two 250 g bags of Ethiopia beans at 9.90 EUR and the starter kit at 24.00 EUR, prices including VAT. Read from the cart totals of the REST API (GET /V1/carts/mine/totals):

A guest with one bag and the kit saw subtotal_incl_tax 33.90 and tax_amount 5.07. A guest shipping to Germany saw tax 0.00 on a 29.90 order, because no rate exists for Germany in this setup: with Enable Cross Border Trade the gross price stays the same, and the German VAT, the EU One Stop Shop scheme and VAT ID handling are legal topics you configure with real rates and the customer groups above. Adobe’s pages on international tax cover those cases.

Source: Adobe: International tax guidelines

Stores > Configuration > Sales > Shipping Settings holds the Origin address (set above) and the optional Shipping Policy Parameters; Delivery Methods configures the carriers. The Mage-OS install lists these carriers: Flat Rate, Free Shipping, Table Rates, In-Store Delivery (in-store pickup), and the live carriers UPS, FedEx, DHL and USPS (the last four need accounts with the carrier). Each carrier has Enabled, Title, Method Name, Ship to Applicable Countries / Ship to Specific Countries, Show Method if Not Applicable, Displayed Error Message and Sort Order, and the offline carriers add Calculate Handling Fee and Handling Fee.

Pocket Coffee has two zones (Spain; six other countries) and a free-shipping threshold:

Source: Adobe: Shipping settings

The Table Rates carrier needs rows. They are imported from a CSV file in the Admin, at website scope (switch the scope selector to the website, then use Import next to Table Rates in Delivery Methods, which is not shown at the default scope). The CSV has five columns in this order: Country, Region/State, Zip/Postal Code, Weight (and above) (the header changes with the chosen Condition: Weight vs. Destination, Price vs. Destination or # of Items vs. Destination) and Shipping Price. The importer accepts ISO 3-letter country codes and stored the two-letter code:

The import was performed with the Admin’s own form (a multipart POST of the CSV together with the Condition to the configuration save URL at website scope). It answered "You saved the configuration." and shipping_tablerate held six rows (website_id 1, dest_country_id DE and so on, condition_name package_weight, condition_value 0, price 9.90). Two errors are worth knowing. Posting the file without the Condition field failed with "Something went wrong while importing table rates." (an Array to string conversion in the CSV column resolver in the log). And rows inserted with website_id 0 (the "all websites" id) were not used: the rate lookup matches the website of the request, so rows must belong to website 1 when the store runs on website 1.

Checked with the shipping estimate API for a postcode of the destination:

Both rates stay available when free shipping qualifies: Magento offers every applicable method, so the free method is listed next to the 4.90 flat rate and the customer picks. To remove the paid method when the threshold is met, Adobe’s documentation describes a Cart Price Rule with a free-shipping action (not run here), or sort and label the methods so the cheapest is obvious. About the threshold, the Include Tax to Amount switch (carriers/freeshipping/tax_including) was No, yet the amount compared was the VAT-inclusive subtotal after discounts: with the member cart (37.83 excluding VAT, 41.82 including VAT after the 1.98 discount) thresholds of 38 and 40 offered free shipping and 42 did not, with the switch at either value. That is the behaviour when catalogue prices include tax; re-test it if you switch to prices excluding tax.

Also note that the offline carriers do not enforce a parcel weight limit. A cart of six 1 kg bags (6 kg) still received the 9.90 table rate to Germany. A 5 kg limit per parcel must be modelled with table-rate tiers, a live carrier’s Maximum Package Weight, or a validation module.

Stores > Configuration > Sales > Payment Methods lists the methods available for the Merchant Location (Spain on the test install). The page showed PayPal solutions (Express Checkout, Payments Pro Hosted Solution, Website Payments Standard) and the Other Payment Methods: Zero Subtotal Checkout, Check / Money Order, Bank Transfer Payment, Cash On Delivery Payment and Purchase Order; 3D Secure settings sit in their own section. Card processing needs an extension from the Marketplace or the payment provider; see Checkout and Payments. For the test orders the offline Check / Money Order method was used and was the only method offered at checkout.

Two kinds of rule give discounts. Catalog Price Rules change the displayed price of products matching conditions (the indexer catalogrule_rule applies them); Cart Price Rules apply in the cart and can use coupons. The Coffee Club rule is a cart price rule restricted to the Coffee Club group and to category Beans:

Source: Adobe: Cart price rules

In the Admin this is Marketing > Promotions > Cart Price Rules, with the customer group in Customer Groups and the category in the Actions tab. The condition field in the API is attribute_name; sending attribute fails with "%fieldName" is not supported. The rule discounted only the two bean lines (1.98 EUR) and left the kit alone; it applied once the customer was signed in as a Coffee Club member. Guests, who are in group 0, saw no discount.

Run a test order for every zone before launch. These two were placed through the guest checkout API with the offline Check / Money Order method: a Spanish order with the kit and flat-rate shipping, and a German order with a 1 kg bag and the table rate.

Source: Adobe developer docs: Orders tutorials

The order API returned the order ids and GET /V1/orders listed them: 000000001 (Germany, grand total 39.80 EUR with 9.90 shipping and no tax) and 000000002 (Spain, grand total 28.90 EUR, of which shipping 4.05 net and 4.90 gross, and 5.02 tax: 4.17 on the kit and 0.85 on shipping), both with status pending. Sales > Orders shows them. Before the Spanish region was added the order failed with the regionId message quoted above.

Content > Elements > Pages holds pages, Blocks holds reusable fragments, Widgets places blocks and dynamic lists on pages, and Templates stores Page Builder layouts. The default install ships pages home, no-route, enable-cookies and privacy-policy-cookie-restriction-mode. Pocket Coffee adds a "Shipping and returns" page and a banner block through the API, which is also how you migrate content between environments:

Source: Adobe: Pages

The page answered 200 at /shipping-and-returns with the meta description set. The page was created for all store views; a store_id field in the body is rejected by the API ("%fieldName" is not supported). Stores > Configuration > General > Content Management sets the WYSIWYG Options and Advanced Content Tools (Page Builder); in 2.4.9 the default editor is HugeRTE, which replaces TinyMCE. Content > Design > Configuration applies a theme, logo, head defaults (title, description, scripts) and the robots instructions per scope, and Content > Design > Themes lists the registered themes (Magento Luma, Magento Blank and the backend themes on the test install).

Magento sets sensible technical defaults; your work is URLs, meta data, the sitemap and robots.txt.

URLs. Stores > Configuration > General > Web > Search Engine Optimization > Use Web Server Rewrites (web/seo/use_rewrites) removes index.php from URLs. Catalog > Catalog > Search Engine Optimization offers Product URL Suffix, Category URL Suffix, Use Categories Path for Product URLs, Create Permanent Redirect for URLs if URL Key Changed, Generate "category/product" URL Rewrites, Apply transliteration for product URL, Product URL Rewrite Scope, Page Title Separator and Use Canonical Link Meta Tag for categories and products. Pocket Coffee uses .html for products and an empty suffix for categories (set before the categories were created):

Source: Adobe: SEO overview

The result: /beans, /equipment, /single-origin-beans.html and /starter-kit.html. A rewrite is stored as a row of url_rewrite (request_path, target_path, redirect_type, store_id); Marketing > SEO & Search > URL Rewrites manages them. With Create Permanent Redirect for URLs if URL Key Changed on, changing the starter kit’s URL key to starter-kit-grinder made the old URL answer 301 to the new one (starter-kit.html redirected to http://localhost:8093/starter-kit-grinder.html) and added the row starter-kit.html -> starter-kit-grinder.html with redirect type 301. Settle the suffixes before you create the categories and products, because the rewrites are written when a record is saved.

Meta data. Each product, category and CMS page has a meta title, description and keywords. On the configurable product page the rendered head contained <meta name="description" content="Ethiopia, Colombia and Brazil beans roasted in Madrid, in 250 g and 1 kg bags."/>, <meta name="robots" content="INDEX,FOLLOW"/>, <title>Single-origin specialty coffee beans</title>, <link rel="canonical" href="http://localhost:8093/single-origin-beans.html" />, Open Graph tags (og:title, og:url, og:image, og:description) and the product wrapped in schema.org/Product microdata. No hreflang link and no JSON-LD block was present: add hreflang for the two store views and JSON-LD with a theme change or an extension if you need them.

Sitemap. Marketing > SEO & Search > Site Map defines one or more sitemap files; Stores > Configuration > Catalog > XML Sitemap has Categories Options, Products Options and CMS Pages Options (frequency and priority), Generation Settings (a cron schedule), Sitemap File Limits and Search Engine Submission Settings (add the sitemap to robots.txt). The sitemap grid entry and generation were created with a script that uses the sitemap model, and the resulting pub/sitemap.xml listed the home page, both categories, the privacy page, the shipping page and both products with lastmod, changefreq and priority; the cron job sitemap_generate (class Magento\Sitemap\Model\Observer) regenerates the files on the schedule you set.

robots.txt. Magento serves /robots.txt from configuration, so no file is deployed: set the content in the design/search_engine_robots/custom_instructions value (Content > Design > Configuration > Search Engine Robots) and the default meta robots in design/search_engine_robots/default_robots:

Source: Adobe: Sitemap

The value you edit is custom_instructions; default_custom_instructions holds the factory text that the reset button restores, and design/head/default_robots is not a valid path (config:set rejects it). Keep the staging and development hosts at NOINDEX,NOFOLLOW.

Speed and links. Magento’s Full Page Cache, JavaScript and CSS minification and bundling, image formats and the Back/Forward Cache and Speculative Loading settings under Advanced > System are performance topics covered on Caching, Indexing and Performance. The books and Adobe recommend fast pages, clean URLs, one canonical URL per page and a sitemap as the base; product and category copy is the rest of the work.

Transactional emails use templates under Marketing > Communications > Email Templates and the sender identities in Store Email Addresses. Stores > Configuration > Sales > Sales Emails enables each order, invoice, shipment and credit memo email with a template and optional copy recipients, Contacts configures the contact form, and Newsletter the subscription emails. Email delivery needs a transport (see Mail Sending Settings above); on a laptop use a mail catcher. Brand the templates and Stores > Configuration > Sales > Sales > Invoice and Packing Slip Design before launch: Adobe’s pre-launch checklist asks for both.

Adobe’s prelaunch checklist (updated 2026-10-08) groups the checks as General settings (store URLs, a signed and trusted certificate for the base URL domain, all store email addresses), Marketing settings (email templates, sales communications such as invoices and packing slips, Google tools), Sales settings (cart options, checkout options with terms and guest checkout, taxes, delivery methods, payment methods with test transactions in sandbox mode) and System settings (cron jobs running at the right interval). The table adds the verification command for each item and the Pocket Coffee value.

Source: Adobe: Prelaunch checklist

A launch is a deployment as well as a configuration exercise: the configuration above is exported with bin/magento app:config:dump into app/etc/config.php so every environment gets the same values, secrets stay in env.php or in environment variables, and the deployment itself follows the build and release steps of Upgrades.

Run on 2026-10-27 on the Mage-OS 3.6.0 install: the config:set and REST commands shown, the Admin login with the session of a test administrator, every leaf link of the Admin menu (each answered HTTP 200), the Admin configuration pages for General, Currency Setup, Tax, Shipping Settings, Delivery Methods, Customer Configuration, Checkout, Web, Catalog, XML Sitemap, Admin and System (their fields, labels and selected options were read back), the Table Rates import through the Admin’s own form, a configurable product, customers, a cart price rule, test orders for Spain and Germany, CMS pages, the sitemap and robots.txt. Documented from Adobe’s pages and not executed: the Admin forms through a browser (the pages were fetched over HTTP, not clicked), app:config:dump, scheduled currency imports (needs a provider API key), live carriers (UPS, FedEx, DHL, USPS), PayPal and card payments, customer emails, Adobe Commerce-only features (segments, staging, B2B, reward points, gift registry) and the Adobe IMS sign-in.