PrestaShop / Fixes & Overrides April 30, 2026 9 min read

How to Fix PrestaShop 1.7 / 8 Stores Without Hiring a Developer

PrestaShop powers ~250,000 stores in Europe. Most "my store is broken" tickets fall into the same five buckets: a stuck Smarty cache, a bad theme override, a hook that disappeared after a module update, or a 500 error from var/cache/. SimpleReview's PrestaShop-aware agent knows the /themes/[theme]/templates/ override system, the override/ directory, and the modules/[module]/views/templates/hook/ structure — so it edits the right file the first time and opens a PR.

mystore.com

MyStore

Search products…

Cart · 0,00 €

Hummingbird Tee

€21.90

Pastel Mug

€9.50

Notebook A5

€7.20

MyStore

Search products…

Cart · 0,00 €

✓ Newsletter hook restored · footer.tpl patched · PR #42 ready

Key Takeaways

PrestaShop theme overrides go in themes/[theme]/templates/ and themes/[theme]/modules/[module]/. Module overrides go in override/modules/[module]/. Never touch classes/ or controllers/ directly — use override/ or a custom module.
Most PrestaShop site issues = var/cache/ not cleared after an admin change, or defines.inc.php _PS_MODE_DEV_ set wrong.
SimpleReview reads themes/[theme]/templates/ and the registered hooks list to find the right file fast.
PrestaShop Addons Marketplace — мы публикуем модуль simplereview в категории Administration → Site Tools. Установка через стандартный uploader: Modules → Module Manager → Upload a module.
Custom payment modules, ERP integrations, multi-store, GDPR — Vibers human review.

The PrestaShop Override Hierarchy in 60 Seconds

PrestaShop's override system is the single most misunderstood thing about the platform — and the reason "simple" edits get quoted at hours of work. The rule is dead simple once you see the hierarchy: always edit at the highest level that solves the problem, never deeper. The agent walks this list top-down on every change.

Level	Where	What it overrides	Use for
1. Theme override (highest)	`themes/[theme]/templates/` `themes/[theme]/modules/[module]/`	Core front-office templates, module-rendered hook templates	Visual changes, hide elements, restructure product / category / checkout layout
2. Module override	`override/modules/[module]/`	A module's classes / controllers	Patch a 3rd-party module without losing changes on update
3. Class / Controller override	`override/classes/` `override/controllers/`	Core PrestaShop classes & controllers	Tiny core behaviour tweak. Last resort.
4. Core (NEVER)	`classes/`, `controllers/`, `src/`	—	Don't. Every PrestaShop update wipes you out.

⚠ Common trap: editing a file inside modules/[module]/views/templates/ directly. That works until the module updates — then your changes are gone. Always copy into themes/[theme]/modules/[module]/ first; PrestaShop will load yours instead of the module's original.

Three-Click Workflow with SimpleReview

Install the SimpleReview Chrome extension from the Chrome Web Store. Free with your own AI key (Claude Code or Codex), built-in mode if you don't have one. The extension auto-detects PrestaShop from the <meta name='generator' content='PrestaShop'> tag.
Connect your store's repo. Paste a GitHub / GitLab / Gitea URL. If your store isn't on Git yet, give SFTP credentials — SimpleReview creates a private working tree and commits from there. The agent reads themes/[theme]/ and the active modules list to build its index.
Open your storefront, click the SimpleReview icon, click the broken or wrong element. Type plainly: "hide 'Powered by PrestaShop'", "add reCAPTCHA to the contact form", "fix this 500 error", "the discount banner is from 2024, remove it". Click Fix it. The agent walks the override hierarchy, finds the right file, edits it, opens a PR.

Common PrestaShop Fixes

Fix "A configuration error has occurred. You can configure your shop using SF mode"

This is the #1 PrestaShop 500 error after a hosting move, PHP upgrade, or failed module install. It comes from Symfony's container failing to boot. Three things to check, in this order:

DB credentials in app/config/parameters.php — host, name, user, password. After a server migration the host is often localhost instead of the new 127.0.0.1 or socket path. The agent reads the file, diffs against the new server's my.cnf, suggests the patch.
Clear var/cache/ — both var/cache/prod/ and var/cache/dev/. PrestaShop caches the compiled Symfony container; a stale cache will keep failing even after you fix credentials. rm -rf var/cache/* and reload.
Check app/config/config.yml — usually fine, but a half-installed module can leave a YAML reference dangling. Look for the latest module name in the file and revert.

# app/config/parameters.php — typical post-migration fix
<?php return array (
  'parameters' => array (
    'database_host'     => '127.0.0.1',  // was 'localhost'
    'database_port'     => '',
    'database_name'     => 'prestashop',
    'database_user'     => 'ps_user',
    'database_password' => 'NEW_PASSWORD_HERE',
    // ...
  ),
);

Add reCAPTCHA to the Contact form

Three options, easiest to hardest:

Module: install pscaptcha (PS 1.7+) or one of the official ps_emailalerts + pscleaner bundles. Hooks displayCustomerAccountForm and actionContactFormSubmitCaptcha are where the validation runs.
Theme override: copy modules/contactform/views/templates/widget/contactform.tpl to themes/[theme]/modules/contactform/views/templates/widget/contactform.tpl, drop a Google reCAPTCHA v3 snippet inside the form, and add a actionContactFormSubmitCaptcha validation hook in a small custom module.
Controller override: last resort. override/controllers/front/ContactController.php with a server-side reCAPTCHA verify before parent::postProcess().

The agent picks option 2 by default — module override, no core changes, survives module updates.

Hide "Powered by PrestaShop" from the storefront

Per the Creative Commons license, the link can legally be removed (PrestaShop's own FAQ confirms this). For the Classic theme, the link lives in themes/classic/templates/_partials/footer.tpl. For a Custom theme, the same path under your theme name. Search for creative-commons or powered-by:

{# themes/classic/templates/_partials/footer.tpl — before #}
<div class="copyright">
  <a href="https://www.prestashop-project.org" class="creative-commons">
    {l s='Powered by PrestaShop&trade;' d='Shop.Theme.Global'}
  </a>
</div>

{# after — remove the link, keep the copyright string if you want #}
<div class="copyright">
  &copy; {$smarty.now|date_format:"%Y"} MyStore
</div>

Note: PrestaShop's storefront is still Smarty (.tpl), not Twig. Twig is back-office only (PS 1.7.7+). The agent writes Smarty for the front-office and Twig for the admin — and knows which to use by file path.

Module conflict / hook not displaying

A module installed cleanly but its block doesn't render. 90% of the time the hook isn't transplanted to the position the module expects. Admin → Modules → Positions → search the hook your module needs (e.g. displayHome, displayProductActions, paymentOptions); if the module isn't listed under that hook, transplant it.

Common offenders: payment-module hooks paymentOptions and paymentReturn getting overridden by an "all-in-one" theme that ships its own checkout. The agent reads the registered hook list (SELECT * FROM ps_hook_module) and tells you exactly which module is hijacking the slot.

Slow admin / "Site under maintenance for too long"

Admin lag in PrestaShop is almost always caching off or debug mode on. Five-minute fix:

Admin → Advanced Parameters → Performance: Smarty Force Compile = Never, Smarty Cache = Yes.
Same page: CCC (Concatenate, Compress, Cache) — turn on for CSS, JS, smart cache, apache optimization.
In config/defines.inc.php set define('_PS_MODE_DEV_', false); — debug mode in production = 5–10× slower admin.
Check var/logs/ for SQL slow queries. Common culprit: a module logging every page view to ps_log with no index. The agent reads the slow query log, suggests the index.

Real numbers: Force Compile=Never alone often cuts admin response time from 3.5s to 0.4s. CCC on a Classic-theme storefront drops the page from ~80 HTTP requests to ~12.

PrestaShop Addons — Our Module

PrestaShop Addons is the official marketplace at addons.prestashop.com — 5,000+ modules + 2,000+ themes. We publish simplereview (in approval). Install: download the .zip from PrestaShop Addons → Module Manager → Upload a module → Install. Until then: SimpleReview Chrome Extension auto-detects PrestaShop from the <meta name='generator' content='PrestaShop'> and reads themes/[theme]/.

PrestaShop runs Smarty (.tpl) for the front-office and Twig (.html.twig) for the SF-based back-office (PS 1.7.7+). Our agent knows which template engine to write — it picks Smarty when the file lives under themes/[theme]/templates/ or modules/*/views/templates/, and Twig when the file lives under src/PrestaShopBundle/Resources/views/ or an admin-side module template.

Module Manager (Modules → Module Manager) replaced the old "Modules and Services" page in PrestaShop 1.7. It's where you upload a .zip, enable/disable, configure, and check which modules are hooked to which positions. Anything you install from PrestaShop Addons lands here.

Comparison Table — Freelancer vs SimpleReview

Step	PrestaShop freelancer (€30–60/hr)	SimpleReview agent
Brief	30–45 min email/Skype back-and-forth	Type one sentence in the popup
Repo / SFTP setup	30–60 min (per freelancer, every time)	Once, then cached
Locate the override level	30–90 min (theme? module override? class override?)	Instant — hierarchy walked automatically
Find the right Smarty / Twig file	15–60 min, depending on theme	Indexed at connection
Make the edit + clear `var/cache/`	5–30 min	5–30 seconds
Open a PR	If they use Git at all	Always
Cost for a 1-line change	€30–150 (1-hour minimum)	€0 (BYO key) or pennies of API usage

When You Do Want a Senior PrestaShop Developer

This isn't anti-freelancer. It's anti-paying-an-hour-for-five-minutes. You still want a human in the loop for the structural / money-touching work:

Custom payment module. Stripe, Adyen, a national PSP, or a B2B invoice flow. Money flows through it; the hook contract (paymentOptions, paymentReturn, validation order, webhook idempotency) needs human review.
Multi-store with shared catalog vs separate. PrestaShop's multistore is powerful but the data model (ps_product_shop, ps_category_shop, shop-group quirks) is non-obvious. Picking shared-catalog vs separate is a one-way door.
PS 1.6 → 1.7 → 8 migration. Smarty 2 → Smarty 3, the controller refactor, hook renames, theme-format breaking changes (theme.yml), Symfony framework underneath the back-office. Plan it; don't agent-it.
Custom shipping carrier. Carrier classes, cost-by-weight/zone matrices, label printing, tracking webhooks. Lots of edge cases.
Performance audit. Doctrine N+1 queries in 1.7.7+ admin, missing indexes on ps_product_shop, slow SELECT on cart hydration, ps_cache_hook bloat. Needs someone reading EXPLAIN output and the slow query log, not pattern-matching templates.
GDPR / data export / right-to-be-forgotten. Especially for EU stores under DSA — a real audit, not a generated module.

That's exactly the slice Vibers handles — a real human reviews any PR you flag, sends a fix-up if needed, and approves before merge. Use the agent for the 80% of one-line fixes; use a human for the 20% that actually earns its hourly rate.

Stop Paying €40/hr for One-Line PrestaShop Edits

SimpleReview's PrestaShop agent reads themes/[theme]/templates/, walks the override hierarchy, opens a PR for the change you described.

Install SimpleReview Chrome Extension →

Payment module, multi-store, PS 1.6 migration? Get a human review →

Frequently Asked Questions

Can I edit a PrestaShop store without a developer?

For most cosmetic, content, and structural fixes — yes. The PrestaShop back-office handles products, categories, CMS pages, modules, and hooks via the admin UI. For Smarty .tpl theme overrides, Twig back-office templates, module hook overrides, or fixes inside override/, SimpleReview's PrestaShop-aware agent reads themes/[theme]/templates/ and the registered hook list, edits the right file, and opens a Pull Request you can merge.

Is this safe for a live PrestaShop store?

Yes — every change is a Pull Request, never a force-push. We strongly recommend a staging clone (most managed PrestaShop hosts include one). Pair the agent's PR with var/cache/ cleared on staging, verify, then promote to production. Worst case is a PR you decline.

Which PrestaShop versions are supported?

PrestaShop 1.7.x — full support (Smarty front-office + Twig back-office on 1.7.7+). PrestaShop 8.x — full support. PrestaShop 1.6.x — limited (legacy AdminController and old hook system; we recommend migrating before doing structural work).

Theme override vs module override — does SimpleReview pick the right one?

Yes. The agent walks the override hierarchy on first connection: theme override (themes/[theme]/templates/ and themes/[theme]/modules/[module]/) > module override (override/modules/[module]/) > class/controller override (override/classes/, override/controllers/) > core. It always picks the highest level that solves the problem and never modifies core files in classes/ or controllers/ directly.

What about paid PrestaShop themes (Warehouse, Alysum, Transformer)?

Yes — paid themes still follow the standard PrestaShop override pattern (themes/[theme]/templates/, themes/[theme]/modules/[module]/, themes/[theme]/assets/). The agent reads your theme's actual file layout on first connection. For themes that ship their own framework on top (extra abstraction layers, custom hook system), you'll get a heads-up that human review is recommended for non-trivial changes.

Is it cheaper than a PrestaShop freelancer?

Substantially. A PrestaShop freelancer charges €30–60/hr in the EU, with a 1-hour minimum. Most stores have a backlog of 5–15 small fixes (hide "Powered by PrestaShop", stale banner, footer phone, missing reCAPTCHA, slow admin) — that's €150–500 of freelancer time. SimpleReview is free with your own AI key, and pennies of API usage per PR. Use the agent for the 80%, use Vibers' human review for the payment-module / multi-store / migration 20%.