Back Office and Store Setup

A back office lives in a folder with a random name: the installer renames admin to something like admin170xxxxxxxx so that the login page cannot be guessed. Every Symfony page lives below that folder (for example /<admin-folder>/improve/international/taxes/) and every URL carries a _token query parameter that protects against cross-site request forgery. A link without a valid token shows an "Invalid token" page that offers the same link with a correct token, so bookmarking a bare URL is harmless but never skips the check.

The menu has three groups, plus a "Home" entry added by the bundled Classic edition module. The table lists the entries as stored in the ps_tab table of a 9.2.0 installation, with the route prefix of the pages that were migrated to Symfony.

Two facts explain why some screens look different from others. First, PrestaShop has been migrating legacy pages to Symfony and Twig for years: from 9.0 the layout (header, side menu, toolbar) is rendered by Symfony for every page, legacy or migrated, and a legacy page only keeps its own content in the old Smarty and HelperForm style. In 9.2.0 the controllers/admin folder still contains 27 legacy admin controllers (the carrier wizard, groups, import, tabs and shop URL pages among them) next to a few helper files. Second, several pages that were migrated in 9.0 and 9.1 are still behind feature flags, so the same menu entry can open the old or the new page depending on the flag. The flags and their state on a fresh 9.2.0 install are listed by the console.

On the checked installation, country, carrier, tax_rules_group, merchandise_return, tag, quick_access, email_body_translation and hook_module_v2 were enabled (stable), and admin_api_multistore, admin_api_experimental_endpoints, catalog_price_rule, permission, customer_threads, front_container_v2, customer_group, store, improved_shipment, discount, improved_b2b and new_pricing were disabled (beta). The architecture page explains the flag layers; for store setup the practical consequence is that Advanced Parameters > Permissions, Shop Parameters > Customer Settings > Groups and Shop Parameters > Contact > Stores show their new page only after the matching flag is enabled in Advanced Parameters > New and Experimental Features.

Source: PrestaShop devdocs: Changes in 9.0 (Symfony layout, migrated pages)

The screens depend on each other, so the order in which a new shop is configured matters. A carrier needs zones and a tax rules group, a product needs a tax rules group and categories, a payment method needs currencies and countries, and a price shown to customers needs everything before it. The figure shows an order that never forces a second pass.

The sections below follow that order. Steps 1 to 3 are the foundation; changing the default country or currency after products and orders exist is possible but is the most error-prone change in a live shop.

Shop identity is spread over three screens. Shop Parameters > General holds the preferences (SSL, maintenance, the shop-wide switches), Shop Parameters > Contact holds the contact details and the stores, and Improve > Design > Theme and Logo holds the logo and favicon. The values live in the ps_configuration table (one row per key, and per shop when multistore is on) and can be read and written from the console.

For Pocket Coffee the identity step sets the shop name, the shop e-mail on the example.test domain, the time zone Europe/Madrid and Spain as the default country. The console reads and writes the same keys, which is the repeatable way to apply them in a deployment script.

prestashop:config takes the action (get, set or remove) and the key, plus --value for set, --lang for keys that have one value per language, and --shopId or --shopGroupId to target one shop of a multistore. Without a shop option it works on all shops. A get of an unknown key prints an error rather than an empty value, which is a quick way to detect a typo in a key name. The command ran against the checked installation for reading (PS_SHOP_ENABLE=1, PS_REWRITING_SETTINGS=1); values were not written on the shared test shop.

Source: PrestaShop devdocs: prestashop:config

International > Localization is the screen that imports a localization pack. A pack is an XML file in the localization/ folder of the installation (one per country, such as es.xml, de.xml or gb.xml, plus default.xml) that can install a language, a currency, the taxes and tax rules of the country, measurement units and states in one step. The Spain pack defines the euro, the Spanish language, the taxes IVA ES 21%, IVA ES 10% and IVA ES 4%, the tax rules groups ES Standard rate (21%), ES Reduced Rate (10%), ES Super Reduced Rate (4%), ES Foodstuff Rate (4%) and ES Books Rate (4%), plus a group EU VAT For Virtual Products generated from the EU tax data, metric units and the 52 Spanish provinces and autonomous cities. Importing it is the quickest way to get a plausible Spanish tax setup, and the same screen lets the merchant choose which parts of a pack to import.

PrestaShop separates three concepts that merchants often confuse. A tax is a named rate (IVA ES 21%, rate 21.0). A tax rule maps a tax to a country (and optionally a state or a postcode range) with a behaviour for combining several taxes. A tax rules group is a named set of tax rules, and it is the group, not the tax, that is attached to a product or a carrier. Because a group holds one rule per country, a product with the group ES Reduced Rate (10%) is taxed at the Spanish reduced rate in Spain and at the rate its rule defines for every other country that has a rule in the group.

Configuration lives in Improve > International > Taxes (/improve/international/taxes/) and Tax Rules (/improve/international/tax_rules_groups/). The options form of the Taxes page (PS_TAX, PS_TAX_DISPLAY, PS_TAX_ADDRESS_TYPE, PS_USE_ECOTAX) and the rounding options of Shop Parameters > General (PS_ROUND_TYPE, PS_PRICE_ROUND_MODE) are backed by these keys.

The round type is a legal matter in some countries: the default of rounding per line reproduces what most invoices show, but a merchant that sells many cheap items may need the total-based mode to match an accounting package. Whatever the choice, changing it later changes the totals of new carts, not of existing orders.

The EU virtual-products group deserves a note. Since 2015 the VAT on digital services is due in the customer’s country, and the localization packs contain automatically generated taxes (auto-generated="1", from-eu-tax-group="virtual") for every EU country plus a group EU VAT For Virtual Products. The console command prestashop:taxes:update-eu-tax-rule-groups regenerates those taxes and groups from the current EU rates, which is how a shop that sells downloads keeps up when a member state changes its rate. Pocket Coffee sells physical goods only and does not use it.

Catalog setup in PrestaShop is a four-layer model, and understanding the layers prevents most data-modelling mistakes in a new shop.

The product page that merchants see in 9.x is the new page introduced in 8.1; the legacy product page and 18 of its hooks (plus 7 login hooks that went away with the Symfony login) were removed in 9.0. A module or a script that still targets the legacy page breaks on 9.x, and the new page is extended through the product form hooks and the CQRS commands described in the developer pages.

A carrier (Improve > Shipping > Carriers, route /improve/shipping/carriers/) is a delivery option that the customer chooses in checkout. It combines a delivery area, a pricing method and a handful of limits. The migrated carrier list is controlled by the carrier feature flag, which is enabled in 9.2.0; the legacy carrier wizard controller is still present in 9.2.0, so the create and edit steps may still open it.

Shop-wide shipping behaviour is in Improve > Shipping > Preferences, backed by the keys PS_SHIPPING_HANDLING (the handling fee amount, 2 in the checked install), PS_SHIPPING_FREE_PRICE and PS_SHIPPING_FREE_WEIGHT (a cart over this total or weight ships free; 0 disables the rule), PS_SHIPPING_METHOD (the default billing method) and PS_CARRIER_DEFAULT (the default carrier). Two behaviours trip up new merchants. A carrier with no range for a zone is not offered in that zone, and a product can be restricted to specific carriers in its Shipping tab, which silently hides every other carrier for any cart containing it.

Payment methods are modules. Improve > Payment > Payment Methods lists the installed payment modules and Improve > Payment > Preferences (/improve/payment/preferences) holds the restrictions that decide who sees which method. A 9.2.0 installation bundles ps_wirepayment (bank transfer), ps_checkpayment (payment by check), ps_cashondelivery and ps_checkout (card and wallet payments through a hosted provider). The preferences screen has four restriction grids, one per dimension: currency, group, country and carrier. Each grid is a matrix of checkboxes, and a module is offered in checkout only if the current cart’s currency, the customer’s group, the delivery country and the chosen carrier are all ticked for it. The data is stored in the ps_module_currency, ps_module_group, ps_module_country and ps_module_carrier tables, which is also where a module can be checked when it vanishes from checkout.

For Pocket Coffee the bank transfer and the card module are ticked for both EUR and USD, for all three default groups and for Spain and the other EU countries; cash on delivery stays unchecked everywhere because a coffee shop has no use for it. The restrictions are per shop, so a multistore keeps one matrix per shop. The developer view of the same machinery, PaymentModule and PaymentOption, is in the payment and carrier modules page.

The last payment setting that new merchants miss is the order status each method creates. Shop Parameters > Order Settings > Statuses (route /configure/shop/order-states/) holds the 18 default statuses of 9.2.0 (from "Awaiting check payment" and "Payment accepted" to "Partial payment", "Authorized. To be captured by merchant" and "Authorization voided"), and a payment module picks one of them when it creates an order. Renaming a status is harmless; deleting one that a module references breaks that module’s order creation.

Customers have a group (default groups: Visitor, Guest and Customer, ids 1 to 3), and the group is the lever for group-specific pricing and rules. A group carries a percentage reduction on all prices, a price display mode (tax included or excluded) and per-category reductions, and it can be used as a condition of a cart rule. Customer groups (Shop Parameters > Customer Settings > Groups) are on the new Symfony page only when the customer_group flag is enabled.

The "Coffee Club" group of Pocket Coffee is created in the back office and members are assigned to it from the customer form (Ada, ada@example.test, is a member; Grace, grace@example.test, checks out as a guest). The 10% discount on beans is better expressed as a cart rule than as a group reduction, because a group reduction would also apply to the equipment. A cart rule is created in Sell > Catalog > Discounts (route /sell/catalog/discounts/) with conditions (group, category, minimum amount, validity period), actions (percentage or amount reduction, free shipping, gift) and options (priority, cumulability with other rules, whether a code is required). The discount system was rewritten in 9.x behind the discount flag (disabled by default in 9.2.0), so the classical cart rule form shown by default is the one a production shop uses today. Cart rule mechanics, the new discount system and the interplay with specific prices are in the catalog and pricing page.

The two Pocket Coffee rules are therefore: "Coffee Club beans -10%" (condition: group Coffee Club; restriction: category Beans; action: 10% on the selected products; no code) and "Coffee Club free shipping" (condition: group Coffee Club and a minimum amount of 40; action: free shipping).

Back-office accounts are employees, and what they can do is decided by their profile. A fresh installation has four profiles (SuperAdmin, Logistician, Translator and Salesman), and an employee has exactly one. Employees and profiles live under Advanced Parameters > Team (/configure/advanced/employees/ and /configure/advanced/profiles/). A profile carries two kinds of rights, both stored as links between the profile and authorization roles (tables ps_access for the tabs and ps_module_access for the modules, with the roles in ps_authorization_role): the tab permissions, a read, create, update and delete grant per menu entry (for example ROLE_MOD_TAB_ADMINTAXES_READ), and the module permissions, the same four grants per module (for example ROLE_MOD_MODULE_PS_CHECKPAYMENT_UPDATE). The SuperAdmin profile bypasses the checks.

Permissions are enforced by the Symfony security attributes on controllers (#[AdminSecurity]) and by the legacy tab check on legacy controllers, so a new custom page needs a tab entry and a security attribute to be protected at all; the CLI linter prestashop:linter:security-attribute find-missing lists routes without the attribute. The new permissions page (Advanced Parameters > Permissions, /configure/advanced/permissions/) is behind the permission flag.

The console can create a SuperAdmin and reset a password, which is the recovery path when nobody can log in. The first command ran against the checked installation (the resulting employee was deleted afterwards); the second works the same way and prompts for the password when --password is omitted.

The CLI intentionally exposes only e-mail, first name, last name and password, always creates a SuperAdmin on the default language, associated with every shop, and warns that the account has full privileges. Prefer the interactive prompt over --password so that the password does not end in the shell history, and create restricted employees on the Team page. Passwords are scored with the zxcvbn estimator (policy introduced in 8.0.x), and since 9.0 the login is handled by the Symfony security system, which provides authentication events that a module can subscribe to.

Source: PrestaShop devdocs: prestashop:employee:create-admin

Search-engine settings are under Shop Parameters > Traffic and SEO (route /configure/shop/seo-urls/), which is one page with several forms: the list of pages with their meta titles and URL aliases, "Set up URLs", "Shop URL", "URL schema" and "SEO options", plus the robots.txt generator. The page is a good example of why the keys matter more than the screen, because the same switches decide whether links work at all.

The URL schema (the PS_ROUTE_* keys, shown in the form as route patterns made of placeholders such as the id, the rewrite and the category) lets a shop choose between a product URL that includes its category and one that does not; avoid changing it on a live shop without a redirect plan, since every indexed URL changes. The .htaccess that implements friendly URLs is generated by the back office when the SEO settings are saved and by the console.

Without --force the command does not overwrite an existing file. Nginx installations do not use .htaccess: the same rewrite rules have to be written into the server block, which the installation page covers. A robots.txt is generated from the same page (the "Generate robots.txt file" button posts to /configure/shop/seo-urls/generate/robots), and a sitemap is produced by the gsitemap module, which is bundled but must be configured with the shop URL and the languages. Meta titles, descriptions and the URL alias of each page are edited per language, so a Spanish and an English storefront need both versions filled.

The "Shop URL" form changes the domain and the physical and virtual URI of the shop (stored in the ps_shop_url table). It is the form to use after moving to a new domain, together with a search-and-replace of absolute URLs in CMS content; the installation page describes the move.

Source: PrestaShop devdocs: prestashop:htaccess:generate

Order confirmations, shipping notifications and password resets are sent through the mail settings in Advanced Parameters > E-mail (/configure/advanced/emails/), which also lists every e-mail sent and lets the merchant test the configuration. The keys are PS_MAIL_METHOD (1 native mail, 2 SMTP, 3 disabled; the checked install showed 1, with an SMTP placeholder in PS_MAIL_SERVER), PS_MAIL_SERVER, PS_MAIL_SMTP_PORT and PS_MAIL_SMTP_ENCRYPTION. Since 9.0 mail is sent through Symfony Mailer, so the encryption choices are TLS or none; the old SSL option was dropped. A production shop should use an SMTP relay or an e-mail service, with SPF, DKIM and DMARC records on the sending domain, and should send one real order confirmation to an external mailbox before launch.

Two pages decide whether the shop survives its first traffic and its first scan. Advanced Parameters > Performance (/configure/advanced/performance/) switches debug mode off, selects the Smarty cache behaviour and the CCC (combine, compress, cache) options for CSS and JavaScript, and chooses the cache backend. Advanced Parameters > Security (/configure/advanced/security/) holds the account-protection options of the back office. Both are covered in detail in the performance and security pages; the minimum for launch is to run in production mode (not debug), confirm that the front office is served over HTTPS with PS_SSL_ENABLED=1, and make sure the installer leftovers are gone (9.2 removes the install folder automatically after the installation succeeds).

The checklist is ordered so that the steps that are hard to undo come last.

Several books on PrestaShop are still read today, and their setup chapters describe an interface that no longer exists. PrestaShop 1.5 Beginner’s Guide (2013) and PrestaShop 1.3 Theming Beginner’s Guide (2010) describe 1.3 and 1.5 back offices, FTP uploads of the installer, the Google Checkout module (discontinued years ago) and a flat menu that was replaced in 1.7 by the Sell, Improve, Configure structure shown above. PrestaShop Recipes (2017) covers 1.6, which means core overrides for most customization, a different tab structure and XAMPP-based local setups, and no Symfony, Twig, CQRS or Admin API. The concepts survive (zones, carriers with ranges, tax rules groups, cart rules, profiles), but the screens, the URLs, the hook names and the file layout do not, and several recipes rely on overrides that current guidance discourages. Use the books for the vocabulary and the business reasoning, and this page and the official developer documentation for the steps.

By the end of this page Pocket Coffee has its identity (name, e-mail, Madrid time zone), Spanish as the default language with English active, EUR as the default currency with USD as a second one, the Spanish localization pack with the 21%, 10% and 4% taxes, a catalog skeleton (categories Beans and Equipment, the origin, grind and size attribute groups, 18 combinations of the beans and the Starter kit), a Spanish flat-rate carrier and a European one, bank transfer and card payments, the Coffee Club group and its two cart rules, and a closed shop awaiting launch. The pages that follow build the behaviour on top: the module that shows the roast date, the hooks that react to orders, the checkout and payment details, the theme and the APIs.