How to choose and evaluate a PrestaShop theme

What we would do

We would compare replacing the theme with improving the one you already run. The right route depends on your catalogue, modules, payment and delivery integrations, custom templates, languages, markets and the people who will maintain the shop. A working, maintained theme can be the better choice when the requirement is mainly visual; a replacement needs to justify the cost of rebuilding those connections.

When a switch is justified, make the change on a private staging copy with your actual data and module stack. Rehearse the deployment and recovery, agree who signs off the shopping tests, then switch in a planned window with a reversible change prepared. Change the theme and upgrade the core in separate steps where compatibility allows, so a failed test has a traceable cause.

If you want help comparing candidates before purchase, PrestaShop Theme Selection & Fit Assessment evaluates them against your shop's requirements; theme licences, installation, migration, design and fixes are separate.

Evaluate a theme against your real shop

Start with your catalogue, customer journeys and installed integrations. Prioritise supported releases, maintainability, usable shopping pages and measured performance, then assess the visual fit. A theme affects many pages, but profiling determines whether it, hosting, images or third-party code dominates a performance problem.

1. List the PrestaShop and PHP versions you will deploy, required modules, languages, currencies and checkout/delivery integrations.
2. Choose representative home, category, search, product, cart and checkout pages. Include long names, large menus and several product combinations.
3. Request the theme's current compatibility matrix, changelog, update process, support terms and customisation documentation.
4. Inspect the public demo with browser tools. For filesystem inspection, use an authorised archive or staging installation, or request an inventory from the vendor. A public demo does not expose its template directories.
5. Test a candidate on staging with your actual module stack before committing the migration.

Update age is a prompt to investigate, not an automatic pass/fail after a fixed number of months. Read resolved and unresolved support issues and ask how the developer handles core/PHP changes. A version label alone does not validate your full stack.

Check the current PrestaShop PHP compatibility chart. PrestaShop 9.0 supports PHP 8.1 to 8.4 and recommends 8.4; 9.1 supports PHP 8.1 to 8.5 and recommends 8.5. Your theme, companion modules and other integrations must also support the chosen runtime. “PHP 8.1+ tested” is too vague for that decision.

Complete a scorecard before choosing

Include your current theme as a candidate. For each requirement, record Pass, Work needed or Unknown, the evidence and who would resolve the gap. Attach a tested page or support answer, rather than a star rating. A payment failure cannot be balanced out by a better-looking header.

Compare Classic and Hummingbird accurately

Classic remained the default through PrestaShop 9.0. Hummingbird 2 became the default in 9.1. An existing shop can retain its compatible theme; changing the core version does not port your custom templates.

The Classic development dependency file uses Bootstrap 4.0.0-alpha.5 and Webpack 5. This URL tracks a development branch; check the dependency file in the exact Classic release you will install. Do not describe every Classic version as Bootstrap 4.6 or Webpack 4. Hummingbird's JavaScript documentation says core.js still supplies jQuery for existing modules. A module does not need rewriting solely because it uses jQuery. Check selectors, events, Bootstrap components and actual loaded dependencies.

CSS custom properties help with specific changes, but one primary-colour variable does not recolour the whole theme. Review component states and supported Sass overrides, then rebuild where necessary. See Hummingbird's CSS conventions.

For a new 9.1 shop, evaluate Hummingbird as the official baseline. For a working Classic-based shop, compare measured benefits with the effort to rebuild overrides and validate modules. No theme name guarantees a particular Core Web Vitals result or all historical module releases. Both front-office themes use Smarty; do not base a purchase on a Twig migration promise without a published release commitment.

Measure performance and inspect assets

1. Run repeatable mobile performance checks on category and product pages as well as the homepage. Use the same device/network conditions and distinguish lab results from available field data.
2. Inspect network transfer sizes, render-blocking resources and third-party requests. Investigate duplicate libraries, icon fonts, unused components and scripts loaded on pages that do not need them.
3. Inspect the largest content element, image dimensions, responsive image choices, loading behaviour and layout shifts. Avoid lazy-loading the critical visible image simply because a theme has a global lazy-load option. For off-screen images, check whether native loading="lazy" can replace a separate JavaScript loader without losing required behaviour.
4. Check main-thread work during filters, variants, add-to-cart and checkout refreshes. An attractive first paint is not enough if controls stall.
5. Profile the real staging shop with the intended modules, analytics, banners and catalogue, then retest optimised production assets.

Request count alone is not a quality score; bytes, dependencies, caching and execution cost matter. Readable CSS/JavaScript does not prove no build process exists. Investigate why production minification is absent if that adds unnecessary transfer cost. Do not impose a universal PageSpeed cutoff as a purchase verdict.

Inline styles are sometimes appropriate for dynamic values. Extensive hard-coded styling can make maintenance harder, but it does not make customisation inherently impossible. Inspect how settings are generated and overridden. A visual theme editor does not necessarily accumulate a new CSS file on every save; verify the actual implementation.

Use only the fonts and weights your design needs. A system font stack avoids font downloads. For custom fonts, review WOFF2 files, test font-display: swap so text can appear in a fallback font while the web font loads, and preload only faces needed for the initial viewport. Test layout shift rather than assuming a universal speed gain.

For example, a candidate demo may feel faster because it has no consent banner, tracking or delivery widgets. Compare the same category and product on controlled copies with the same integrations and cache conditions. If the advantage disappears, investigate those shared costs before paying for a replacement. Record whether a delay happens before the page responds, while it renders or only after a variant change, so the developer has a reproducible task.

Check modules, hooks and child-theme behaviour

Request an inventory of bundled modules, theme-level module overrides, replaced core components and proprietary data formats. Confirm who maintains each part, whether a licence is needed independently, and how content can be exported if you switch themes.

Inspect authorised config/theme.yml, templates/ and modules/ contents. A small inherited configuration can be valid; missing sections do not automatically prove poor quality. A standalone parent theme normally has no parent key. That reference belongs in the child.

1. Create a child with parent pointing to the installed theme and check parent asset handling.
2. Activate it on staging and test a small named-block override and a module-template override.
3. Verify the hooks required by your installed modules, rather than demanding every historical hook on every theme. Test payment, delivery selection, pickup widgets, product extras, search and filters.
4. Compare theme module overrides with current module templates. A stale copy can hide fixes even when the module itself is current.
5. Check translated labels in templates and configurable module content. Hard-coded text can bypass the translation workflow.

Use dedicated modules when functionality needs its own lifecycle, and verify their compatibility with the candidate theme. “Independent module” does not mean “works on every theme”. For implementation, see the child-theme and custom-assets guide.

Suppose your shop relies on a theme-only menu and a pickup-point carrier. Treat navigation recovery and carrier compatibility as separate tasks. Mega Menu provides desktop navigation and nested phone menus independently of the old theme; include rebuilding your menu and testing its new placement in the work list. That change does not establish whether the carrier widget works at checkout.

Turn a failed test into a useful report

• A pickup selector disappears: record the cart, address and carrier, then compare the required hook and module output with the working theme.
• A variant changes but its price or cart does not: capture the console error and failed network request, if present, and check the theme's selectors and event handling.
• A campaign page loses its content: identify whether the text belongs to a native page, a companion module or a builder before changing templates; test recovery in every required language.

If an update breaks the theme, reproduce the issue on staging, inspect logs and compare with a compatible default theme. Review vendor fixes and child/module overrides. An abandoned base may need replacement, but plan the migration and content recovery first.

Test mobile use, accessibility and search markup

Use actual iOS and Android devices as well as browser emulation. Your analytics determines device priorities; do not assume a universal mobile checkout share. Complete the purchase flow, including:

• Menu opening/closing, search, filters and readable product grids without horizontal overflow.
• Product galleries, variants, customisation fields and a reachable add-to-cart action.
• Address entry, validation, appropriate input types, delivery widgets and payment handoff.
• Keyboard-only navigation, visible focus, meaningful link/button names, form labels and useful error recovery.
• Zoom, contrast, text expansion, alternative text and reduced-motion preferences.

Run automated accessibility checks, then test manually. Assess legal compliance against the requirements and exemptions applicable to your service; do not equate all e-commerce laws with one universal WCAG statement.

Inspect headings for a meaningful hierarchy, image sizing and alternative text, canonical URLs and translated URL output. Validate any product, breadcrumb or review structured data against the actual page content. A theme can support these features, but other modules may also emit them; check for conflicting duplicates.

On an isolated staging installation, debug mode can expose template or PHP warnings hidden in production. Investigate reproducible errors and console failures during interactions. Do not judge compatibility only by a clean homepage.

Compare total ownership cost and support terms

Free, paid and official describe provenance or pricing, not a guaranteed level of performance, security or support. Compare the exact licence, support period, renewal price, update entitlement, changelog and developer record for each candidate. The Marketplace support terms explain the relevant subscription model; other suppliers can use different terms.

Use legitimate packages from an identifiable source. Avoid pirated or modified “nulled” archives whose contents and maintenance cannot be trusted. An official free theme is a practical candidate when budget is constrained; a commercial theme can be worthwhile when its tested features and support reduce your real implementation cost. Price alone establishes neither outcome.

For a theme you already own, PrestaShop Theme Installation & Setup Service covers the agreed setup; the licence, design, content migration and new custom behaviour are separate.

Rehearse the switch and agree the handover

Before switching, retain matched files/database backups, document the old configuration, stage the migration and verify rollback. Use the rehearsal to make a deployment checklist you can repeat against the current live shop.

1. Isolate the copy. Restrict access and indexing, suppress customer emails and fulfilment exports, and use payment test accounts. Check scheduled jobs and external integrations before making test orders.
2. Record what activation changes. Save module positions, companion-module settings, logos, image sizes, translations and custom assets. Keep a list of content to rebuild, then repeat the setup from that list to expose undocumented manual steps.
3. Run the acceptance tests. Use the earlier shopping checklist and save the resulting test order. Include guest and returning customers, the relevant customer-group prices and each required language and currency. Have staff perform an ordinary content edit without the developer guiding every click.
4. Deploy against current data. Transfer the agreed files and configuration changes. Do not overwrite the live database with the rehearsal copy: orders, customers and stock may have changed while you tested.
5. Rehearse recovery. Record how to restore theme, assets, module settings and content together. Simply reselecting the old theme may not reverse its companion-module changes. Agree how to preserve or reconcile orders taken after the backup before attempting a database restore.

Activate through Design > Theme & Logo only after completing the representative shopping tests. Confirm the agreed image derivatives and production assets are ready, then check the live purchase route, order records and relevant logs. Name the person who can approve recovery if an essential journey fails.

What to ask the developer or agency

• Which requirements are included in the quote, and which need separate design, content recovery or custom development?
• Where are the child-theme changes and build instructions, and who will compare overrides after future parent or module updates?
• Who maintains each bundled module, and what happens to its content if support ends?
• Where are the test evidence, deployment steps, recovery instructions and unresolved issues we must accept before launch?

Questions owners ask

Will changing the theme remove my products and orders?

A theme switch is not a catalogue or order migration. Check what its installer and companion modules change, and verify existing records on staging.

Can I import the demo to get the same appearance?

Try that only on a disposable copy after checking the package instructions. Demo imports can add or replace content and settings; extract the configuration you need into the deployment checklist instead of assuming the import is safe for a trading shop.

Will a new theme guarantee better search rankings?

No. Keep an inventory of important landing pages and check their URLs, visible content and internal links before and after the change. Investigate missing pages or content immediately, and assess search performance separately from a laboratory speed score.