DEV Community: MEG Venture & Consulting Ltd.

Your database dumps are protected by an .htaccess. Your server may not read it.

MEG Venture & Consulting Ltd. — Thu, 27 Aug 2026 06:40:02 +0000

We ran an audit of our own shop this summer. Three .sql files were sitting in the web root, downloadable by anyone who typed the right URL. Nobody had been careless in any dramatic way. They were the ordinary residue of ordinary work: an export taken before an upgrade, a copy made to test something locally, a dump someone pulled through a hosting panel and never came back for.

That is the honest version of how this happens, and it is worth writing down, because the usual response — "PrestaShop protects the backup folder" — is true and does not help.

What PrestaShop actually does

Credit where it is due. A fresh install ships admin-dev/backups/.htaccess, and it contains exactly what you would want:

# Apache 2.2
<IfModule !mod_authz_core.c>
    Order deny,allow
    Deny from all
</IfModule>

# Apache 2.4
<IfModule mod_authz_core.c>
    Require all denied
</IfModule>

There is an index.php stub next to it, so a directory listing gives you nothing either. The DB Backup page under Advanced Parameters writes into that folder, and PrestaShopBackup builds the name with a random component:

public static $backupDir = '/backups/';
// ...
$rand = dechex(mt_rand(0, min(0xFFFFFFFF, mt_getrandmax())));
$date = time();
$backupfile = $this->getRealBackupPath() . $date . '-' . $rand . '.sql';

So the design is: the folder denies everything, and the filename is not guessable at a glance. Two layers. Fine.

Now the part that matters. The folder is inside the web root — _PS_ADMIN_DIR_ is a directory your web server serves. Nothing about that path is outside the document root. The entire protection is one text file that the web server has to choose to read.

Four ways the one text file stops working

1. Your server does not read .htaccess at all.

nginx has no such mechanism. It never had one. An .htaccess file on an nginx host is a text file with no special meaning whatsoever — the deny-all block is inert, and the URL resolves straight to the dump. The same is true of Apache configured with AllowOverride None, which is the recommended production setting in Apache's own documentation for performance reasons.

A large share of managed PrestaShop hosting is nginx, or nginx in front of Apache with static files served by nginx directly, which produces exactly the same outcome for a .sql file. If you have never checked which one you are on, you do not know whether that file is doing anything.

2. The folder can come back without it.

PrestaShopBackup writes the dump. It does not write the .htaccess. That file exists because it shipped with the install, so it survives only as long as nobody removes the folder. Delete the backups folder to clear space and let something recreate it, deploy with a hand-written file list that leaves dotfiles out, restore from an archive built with a glob that skipped them, and the folder comes back with dumps in it and nothing guarding it.

We know this happens because our own cleanup module writes the pair back if they are missing:

if (is_dir($dir) && !file_exists($dir.'.htaccess')) {
    @file_put_contents($dir.'.htaccess', "<Files ~ \"\.(sql|gz)$\">\nOrder Allow,Deny\nDeny from all\n</Files>\n");
}
if (is_dir($dir) && !file_exists($dir.'index.php')) {
    @file_put_contents($dir.'index.php', "<?php\nheader('Location: ../');\nexit;\n");
}

You do not write that check unless you have seen the folder without them.

3. The shop's main .htaccess does not cover it either.

It is tempting to assume PrestaShop's generated root .htaccess — the one the Traffic & SEO page rewrites — has a rule for this. It does not. In 8.2 the only <Files> block it generates protects composer.lock. There is no rule for .sql, no rule for the backups path, no Options -Indexes. So regenerating your .htaccess, which merchants do fairly often, adds nothing here and (if you had hand-edited a rule in) removes it.

4. Most dumps never went through that page.

This is where ours came from, and I suspect where most of them come from. A dump produced by phpMyAdmin's "save on server", by a hosting panel's export button, by mysqldump > backup.sql in whatever directory the SSH session happened to open in — none of those land in the protected folder, and none of them get a random name. They get the name you chose, which is backup.sql, or db.sql, or shop-2026-08.sql.gz, in the directory where you were working, which is the web root.

No amount of correctness in PrestaShopBackup touches this case.

What is in the file

Worth being specific, because "a database dump" sounds abstract and the contents are not.

A PrestaShop dump contains ps_customer and ps_address: names, email addresses, postal addresses, phone numbers, and customer password hashes, for every account the shop has ever had. It contains ps_orders with what everyone bought and ps_order_payment with transaction references. It contains ps_employee, which is your back-office accounts and their password hashes. And it contains ps_configuration, which is where PrestaShop and every module you have installed keep their settings — including the SMTP credentials your shop sends mail with, webservice keys, and whatever API credentials your payment and shipping modules were configured with.

That last one is why "we deleted the file" is not the end of the incident. If a dump was reachable, the credentials in it have to be treated as disclosed, and that means rotating them, not just removing the file.

Checking your own shop, in about two minutes

All of this is on your own server, so there is nothing clever involved:

Find them. From the shop root: find . -maxdepth 3 $ -name '*.sql' -o -name '*.sql.gz' -o -name '*.sql.zip' $. Include your archive extensions. A full-site .zip or .tar.gz from a migration is the same problem wearing a different extension.
Ask your own server for one. Request the exact URL of a file you just found, from outside, with a browser that is not logged in. This is the only test that answers the question, because it is the server's actual configuration answering, not your assumption about it. A 403 is what you want. A 200 with a download is the finding.
Check the backups folder specifically, including whether .htaccess and index.php are still there.
Know which server you are on. nginx -v, or the Server response header, or ask your host. If the answer is nginx, every .htaccess on that host is decoration.

The fix that does not depend on the answer

Move dumps out of the document root. That is the whole fix, and it is the only one that survives a server migration, a control-panel change, or a colleague who does not know the rule. A directory one level above the web root, or an object store, or your laptop. If the file is not addressable by URL, no server configuration can accidentally serve it.

Everything else is mitigation, in descending order of reliability:

A server-level rule, in the nginx server block or the Apache vhost, not in an .htaccess. On nginx: a location matching your dump extensions with deny all; and return 404;. In a vhost it cannot be silently disabled by AllowOverride, and it does not vanish when a folder is recreated.
Delete the dump when you are done with it. Almost every exposed dump was needed for one afternoon two years ago. A backup you are keeping deliberately belongs in your backup system, which is not a folder in your shop.
Rotate what was in it if it was ever reachable. Employee passwords, webservice keys, module API credentials, SMTP.

And if the file is reachable, do not stop at the shop. Search engines index what they can reach, so a dump that sat in the open for a while may be findable independently of your server, which means removing the file is step one of two.

Our own module is not innocent here

Since this is a field note and not marketing: our cleanup module writes its backups into that same folder, and its filenames look like prestacleaner_check-fix-20260827-084500.sql.gz. That is a prefix, a date and a time. It is entirely predictable to anyone who knows the format, which is now everyone reading this.

That is a deliberate trade — the files have to be recognisable in a list so the merchant can tell which is which, and so cleanup never touches a backup somebody else's tool wrote. But it means the naming contributes nothing to secrecy and the folder-level deny is carrying all of it, which is precisely the arrangement this post is about. On an nginx host, that is one layer, and the layer is not there.

The point of writing it down is that we found this in our own shop, by looking. The looking is the part that generalises.

From maintaining around sixty PrestaShop modules at MEG Venture. Verified against PrestaShop 8.2 source: classes/PrestaShopBackup.php, classes/Tools.php, admin-dev/backups/.htaccess.

PrestaShop's Configuration table is global, and uninstalling your module can delete someone else's settings

MEG Venture & Consulting Ltd. — Wed, 26 Aug 2026 11:36:32 +0000

Configuration::updateValue('width', 40) looks harmless. It is one row in ps_configuration, it holds your module's setting, and it works.

It works until a second module does the same thing. ps_configuration is a shop-wide key/value table with no namespace and no owner column. Two modules that pick the same name share one row: whichever saves last wins, and neither has any way to notice. Then one of them is uninstalled, runs its tidy-up, and deletes it:

public function uninstall()
{
    Configuration::deleteByName('width');   // whose width?
    return parent::uninstall();
}

That is the bug we found in one of our own modules. It stored theme, background, width and effect as bare names. Fixing that one module was easy. The interesting part was the question it raised: how many of the others do this?

The sweep, and why the first one was wrong

We have 57 module repositories. Grepping them for Configuration:: calls produces a lot of hits, most of them fine, so the sweep needs a filter. Our first filter was:

A name that is UPPERCASE with underscores is prefixed. Anything else is suspect.

That is wrong, and it is wrong in the direction that hides bugs. It passed three names that are uppercase, underscored, and completely unprefixed:

API_DATE_FROM and PRODUCT_PAGE_FRONT_ENABLE — in a seller-dashboard module
VIDEO_PRODUCTS_NBR — in a product-video module

API_* is about as generic as a key can get. It looks disciplined. It is not.

The right test is not capitalisation, it is derivation: does the prefix come from the module's own name? CG_ for combinationgrid, CSF_ for customerservicefile, PCT_ for productcustomtab — initialisms are fine, because they derive. API_ derives from nothing.

We re-ran the sweep with that criterion. Total: five real cases across the catalogue, four found in the first pass and one found later, by accident, during unrelated work.

Not every cross-module read is a bug

The sweep surfaced plenty of modules reading keys with another module's prefix. Almost all of those were deliberate — two modules that integrate on purpose, one reading the other's setting to decide whether to render something. That is a dependency, and it should be documented, but it is not this bug.

The distinction that matters is write and delete, not read. Reading a foreign key is a coupling decision. Writing one is a collision. Deleting one on uninstall is data loss in someone else's module.

One finding was a false positive worth mentioning because of what it turned out to be. A module appeared to touch a bare key named theme. The hit was in tests/ReviewNudgeTest.php, in a fixture that plants a foreign unprefixed key and then asserts that uninstall left it alone. It was not the bug; it was the test that proves the bug is absent.

Where the risk actually sits

In all five cases, the modules' current settings were properly prefixed. Nobody was actively writing bare names. The damage was concentrated in one place: legacy cleanup in uninstall().

The pattern goes like this. Version 1.x stored show_notavailable and colorshape. Version 2.x migrated to COLORSONPRODUCTLIST_* and, being tidy, kept deleting the old names on uninstall so a reinstall would start clean. The intent is right. The effect is that uninstalling this module deletes a row that, on some other shop, belongs to a different module entirely.

The same lines had also been copied into the upgrade-2.0.0.php scripts — same bug class, second location, and easy to miss if you only audit uninstall().

The fix

Deleting your own historical leftovers is not worth risking another module's data. Two options, in order of preference:

1. Stop deleting them. The residue costs a few bytes in ps_configuration and harms nothing. This is what we did in every case.

public function uninstall()
{
    // Only this module's own prefixed keys. The bare 1.x names
    // ('show_notavailable', 'colorshape', ...) are left alone: configuration
    // is shop-wide and the module cannot prove another module does not own
    // a row by one of those names.
    foreach (array_keys(self::defaultSettings()) as $key) {
        Configuration::deleteByName($key);
    }

    return parent::uninstall();
}

The comment is load-bearing. Without it, the next person to read this file sees dead cleanup code and helpfully restores it.

2. If you must delete, prove ownership first. Check that the stored value is a shape only your module writes. This is fragile, and it is only worth it when the leftover actually causes a problem.

Full prefix migration — read the bare key, write the prefixed one, keep the old row — is a bigger change and it is only warranted when the module is still reading bare names. If your current keys are already prefixed, the uninstall step is the whole bug.

Making it stay fixed

A grep sweep finds this once. A test keeps it found. Ours plants foreign keys and asserts uninstall left them alone:

Configuration::$store = [
    'MYMODULE_SETTING'  => '1',
    'MYMODULE_OTHER'    => 'tok',
    'theme'             => 'another-modules-value',
    'OTHERMODULE_THING' => 'another-modules-value',
];

$module->uninstall();

ok(Configuration::get('theme') === 'another-modules-value',
   'a bare foreign key was not touched');
ok(Configuration::get('OTHERMODULE_THING') === 'another-modules-value',
   'another module prefixed key was not touched');

Configuration is a small enough surface to stub — get, updateValue, deleteByName over an array — so this runs as plain php tests/ConfigurationKeyTest.php with no PrestaShop and no database. Cheap enough that every module can carry one.

If you are running the sweep yourself, a per-module negative match is more reliable than a global positive one:

deleteByName\('(?!MYPREFIX_)

Run it once per module with that module's own prefix substituted in. Semi-generic names like API_* slip past hand-written positive patterns; they do not slip past "anything that is not my prefix".

Why this is worth an hour of your time

The failure mode is invisible from inside either module. Module A's setting resets and its author blames a caching layer. Module B's uninstall is the cause and its author never finds out, because it happened on someone else's shop, three months later, after an unrelated support ticket.

Nothing errors. Nothing is logged. The support conversation goes nowhere, because both authors are looking at code that is correct in isolation.

Grep your own modules for deleteByName and read every line of what follows. It is a short list.

We maintain around sixty PrestaShop modules at MEG Venture. The audit above took an afternoon and closed five bugs that no customer had reported and no test could have caught, because the damage happens in someone else's code.

Your PrestaShop hook renders nothing, and nothing is logged

MEG Venture & Consulting Ltd. — Mon, 24 Aug 2026 21:40:40 +0000

A module hook that returns an empty string looks exactly like a module hook that was never called. PrestaShop gives you nothing to tell them apart: no error, no log entry, no stack trace, no fallback text. The page renders fine. Your block is just absent.

We spent three releases of one module chasing this, and the cause turned out to be three different mechanisms stacked on top of each other. Each one alone is enough to make output vanish silently. This is what they are, in the order we peeled them off.

The setup

The module registers displayHeader and renders a small template: a <script> block that carries a public site key into the page, and a <style> block that hides a third-party badge. Roughly:

public function hookDisplayHeader($params)
{
    $this->context->smarty->assign([
        'recaptcha_pubkey' => $this->getActivePublicKey(),
        'recaptcha_hide_badge' => $hideBadge,
    ]);

    return $this->display(__FILE__, 'views/templates/front/header_script.tpl');
}

Deployed, cache cleared, hook registered, Design > Positions shows the module attached. Page source: nothing. Not the script, not the style, not even a stray whitespace.

Mechanism 1: core swallows the exception

Hook::callHookOn() wraps every module hook call in a try/catch. When debug mode is off, it catches whatever the hook throws and returns an empty string. No error, no log, no trace.

That is a defensible design decision — one broken module should not take down a storefront — but as a debugging experience it is brutal. Every possible failure inside your hook, from a typo to a missing file to a template that will not compile, arrives at your screen as the exact same symptom: nothing.

The first thing to do, before theorising about causes, is to stop letting core swallow it:

try {
    return $this->display(__FILE__, 'views/templates/front/header_script.tpl');
} catch (Throwable $e) {
    $message = 'mymodule header_script.tpl render failed: ' . $e->getMessage()
        . ' in ' . $e->getFile() . ':' . $e->getLine();
    PrestaShopLogger::addLog($message, 3, null, 'Mymodule');

    return '<!-- ' . str_replace('--', '- -', $message) . ' -->';
}

Two outputs on purpose. The log entry survives after the page is gone and shows up under Advanced Parameters > Logs. The HTML comment is right there in view-source while you are looking at the page, and it survives filters that strip <script> and <style> tags specifically — which matters, because the thing you are debugging may itself be a script tag.

Throwable, not Exception. A TypeError is an Error, and catch (Exception $e) sails straight past it. That distinction has cost us time in more than one module.

Turning debug mode on would also have surfaced it, and if you can reproduce the problem locally you should. We could not: this only appeared on a hosted environment we do not control.

Mechanism 2: one CSS brace kills the whole template

With the try/catch in place, the log finally said something. The template would not compile.

The offending line was plain CSS:

.grecaptcha-badge{visibility:hidden!important;}

Smarty's default delimiters are { and }. It reads {visibility:hidden!important;} as a template tag, tries to parse visibility:hidden as a Smarty expression, chokes on the colon, and fails to compile the file.

The part that turns a small bug into a mystery: Smarty compiles a template as a single unit. A syntax error anywhere fails the whole file. The <script> block sitting above that CSS was perfectly valid and had nothing to do with the problem, and it never rendered either — for three releases we were debugging the script, which was fine, because the thing breaking it was thirty lines below.

The fix is Smarty's own mechanism for raw text that contains braces:

{literal}
.grecaptcha-badge { visibility: hidden !important; }
{/literal}

If you would rather not think about it every time: any { immediately followed by a letter is a Smarty tag. { visibility with a space is not. But {literal} states the intent, and intent is what you want in a file someone else will edit.

This applies to inline JavaScript too — object literals, arrow function bodies, anything with a brace next to a word.

Mechanism 3: the platform rejected `nofilter`

Before we found the brace, we had already removed a nofilter from the same template. That one is worth recording because the reasoning that led us to it was sound and the fix was correct, even though it was not the bug we were hunting.

The template embedded a value into inline JavaScript the way PrestaShop's own theme templates do:

var key = {$recaptcha_pubkey|json_encode nofilter};

PrestaShop Cloud's integration checklist explicitly requires {$variable|escape:'javascript':'UTF-8'} for values used in inline JS, and forbids nofilter. A platform-side Smarty security policy rejecting nofilter at compile time would produce exactly the signature we were seeing: a template that will not compile, on that host only, silently.

We could not prove that was happening — the brace bug was masking everything — but the guidance holds on its own terms. Use the documented escaper.

The general lesson is narrower than "avoid nofilter": a template that compiles on your machine can fail to compile on a managed host with a stricter Smarty policy, and it fails the same silent way. If your module ships to hosts you do not control, the try/catch from mechanism 1 is not a debugging aid you remove afterwards. Leave it in.

What we changed permanently

Every hook that renders a template is wrapped. Log plus HTML comment, catching Throwable.
No hand-built HTML or JS inside PHP. PrestaShop's integration checklist asks for this anyway, and it means every failure of this class now happens in a template, where the try/catch can see it.
Assets carry a version. Separate problem, same family of "I fixed it but nothing changed": registerJavascript($id, $path, ['version' => $this->version]). Without it there is no cache-buster, and returning visitors keep running the previous file. There is a further trap with PrestaShop's combined asset cache that the version parameter does not solve — that is its own post.

The shape of the lesson

Silent failure is not one bug, it is a category. When a system is designed to keep serving pages no matter what a plugin does, it will also keep serving pages when your plugin is broken, and it owes you nothing in the way of an explanation.

The response is not to guess better. It is to make the silence impossible: catch what the platform would have swallowed, write it somewhere that outlives the request, and put a marker in the page you are already looking at. We got three releases of guessing before we did that, and roughly one afternoon of actual debugging afterwards.

We build and maintain around sixty PrestaShop modules at MEG Venture, which is a productive way to accumulate stories like this one. If you have hit a variant of this — especially the Smarty brace, which we suspect is more common than its search results suggest — I would like to hear about it.