DEV Community: MEG Venture & Consulting Ltd.

"Duplicate entry '0' for key PRIMARY" usually means your database lost AUTO_INCREMENT

MEG Venture & Consulting Ltd. — Tue, 29 Sep 2026 13:15:06 +0000

Installing a plugin fails with:

Duplicate entry '0' for key 'PRIMARY'

The obvious reading is that the plugin tried to insert a row with id 0. The actual reading is usually the opposite: the plugin inserted a row without naming the id column, relied on AUTO_INCREMENT to supply one, and got 0 because the column no longer has AUTO_INCREMENT on it. The second such insert then collides with the first.

This is not a plugin bug, and chasing it as one wastes a lot of time. Here is how it looks, why it spreads, and how to repair it without setting a second trap.

The tell: it moves

We first saw this installing a module on a PrestaShop shop. The failure walked through the tables in order:

ps_configuration — first setting the module writes
then ps_log — the "starting module install" row
then ps_module — the row that registers the module itself

Fix one table, run the install again, fail on the next. That whack-a-mole is the diagnostic. A plugin bug does not migrate to core tables. If your failure changes table each time you fix one, the corruption is database-wide.

Later the same shop failed in the storefront: adding anything to the cart threw the same error on INSERT INTO ps_cart. Same cause, another table nobody had touched yet. If it had got as far as checkout it would have been ps_orders next.

Where it comes from

A bad import or restore. mysqldump, phpMyAdmin exports and various migration tools can produce a schema that recreates the primary key without the AUTO_INCREMENT attribute — and such a restore often leaves the internal counters stale as well, with rows stranded at id 0.

On the shop we repaired, every AUTO_INCREMENT in the database was gone: products, combinations, modules, configuration, employees, shops, languages, and around fifty-five module tables.

The trap when you fix it

The natural fix is:

ALTER TABLE `ps_log` MODIFY `id_log` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT;

which fails with:

#1062 - ALTER TABLE causes auto_increment resequencing,
        resulting in duplicate entry 'N' for key 'PRIMARY'

Adding AUTO_INCREMENT makes MySQL renumber the existing id = 0 row, and the stale counter hands it an id that is already in use.

Prevent the renumber:

SET SESSION sql_mode = 'NO_AUTO_VALUE_ON_ZERO';
ALTER TABLE `ps_log`           MODIFY `id_log`           INT(10) UNSIGNED NOT NULL AUTO_INCREMENT;
ALTER TABLE `ps_configuration` MODIFY `id_configuration` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT;
ALTER TABLE `ps_module`        MODIFY `id_module`        INT(10) UNSIGNED NOT NULL AUTO_INCREMENT;

NO_AUTO_VALUE_ON_ZERO tells MySQL to treat a literal 0 as a real value rather than a request for the next id, so the existing row keeps its id and nothing is renumbered.

Run the SET and the ALTERs in the same submission. SET SESSION lasts for one connection; phpMyAdmin may hand you a different connection for a separate query, and then the ALTER fails exactly as before while you are certain you just set the mode.

Finding every affected table

Do not do this by hand. Ask the schema:

SELECT TABLE_NAME, COLUMN_NAME, COLUMN_TYPE
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = 'your_database_name'
  AND COLUMN_KEY = 'PRI'
  AND EXTRA NOT LIKE '%auto_increment%'
  AND DATA_TYPE IN ('int','bigint','smallint','mediumint','tinyint')
ORDER BY TABLE_NAME;

Hardcode the schema name. A generator built on DATABASE() returns nothing when phpMyAdmin is sitting in the information_schema context, which it often is if you arrived through the schema browser. The query runs, returns zero rows, and you conclude the database is fine.

That query lists candidates. It does not list fixes — and the difference matters, because some of those primary keys are legitimately not auto-increment.

What to exclude

Blindly ALTERing everything the query returns will damage your database. Exclude:

Every composite primary key. AUTO_INCREMENT applies to a single column that is the leftmost part of a key. Multi-column PKs in that list are joins and pivots and must be left alone.
Single-column integer PKs that are by design not auto-increment — a foreign key doubling as the primary key. In PrestaShop those include ps_address_format (id_country), ps_product_sale (id_product), ps_ip2location (ip_to), the ps_layered_indexable_* tables, ps_pscheckout_address / ps_pscheckout_customer (id_customer), ps_psshipping_address, and the ps_eventbus_* tables. Your schema will have its own equivalents: the test is whether the value is assigned by another table or generated here.

Two special cases worth knowing, because they look like exclusions and are not: ps_customization.id_customization and ps_cms_role.id_cms_role sit in composite primary keys but are legitimately AUTO_INCREMENT, as the leftmost column.

The workable process: generate the ALTER statements with a query that CONCATs them, read the output, delete the rows that belong to the exclusion list, then run what is left. Two failure modes we hit doing exactly this:

Running the generator and believing that fixed something. It only prints statements. You have to run its output.
Deleting the id = 0 rows instead of running the ALTERs. That clears the immediate collision and leaves the schema still broken, so it comes back on the next insert.

One more operational detail: if you paste a large batch into phpMyAdmin and the newlines are lost, a -- comment swallows the statement that follows it. Ship comment-free SQL for bulk paste.

What to do instead, if you can

Repairing in place works — we did it across about 130 tables and verified the storefront afterwards — but think about what it means. A restore that dropped AUTO_INCREMENT from every primary key was not selective. It may also have dropped foreign keys, defaults, or column attributes you have not noticed yet, and no amount of ALTERing primary keys tells you about those.

If a clean dump from before the bad import exists, restore that instead. The in-place repair is what you do when it does not.

The five-second version

Plugin install fails on a core table with Duplicate entry '0' → suspect the schema, not the plugin.
Failure moves to a different table each time you fix one → confirmed, it is database-wide.
SET SESSION sql_mode = 'NO_AUTO_VALUE_ON_ZERO' in the same submission as the ALTERs.
Drive it from information_schema, hardcode the schema name, and curate the list before running it.
Prefer restoring a good dump.

From maintaining around sixty PrestaShop modules at MEG Venture. We lost a fortnight to this one in two separate incidents before recognising the shape.

What your comments changed in my AI-agent office (Cubicle v0.7)

MEG Venture & Consulting Ltd. — Mon, 28 Sep 2026 18:09:08 +0000

Yesterday I wrote about Cubicle, a live pixel-art office for AI agents that is read-only on purpose. A few of the comments were better code reviews than I get from most tools, so here's what they changed.

1. The hook was losing updates

ContentClips pointed out that several Claude Code sessions fire hooks at the same moment, and every hook run rewrites the same claude-code.json. I was already writing to a temp file and renaming it, so a reader never sees half a file. But that only solves torn reads, not lost updates: two runs can both read the file, both change it, and the second rename silently throws away the first one's change.

I measured it before touching anything. 30 hook runs started at once, each registering a different session:

sessions recorded: 20 of 30

A third of the updates were gone. With subagents in the mix (more on that below), bursts like this are normal.

The fix is a lock file created with O_EXCL around the read-modify-write. The constraint that shaped it: this hook runs on every tool call, so it must never hold Claude up. It waits at most one second and then writes anyway, and a lock left behind by a crashed run is taken over after two seconds.

function withLock(fn) {
  const deadline = Date.now() + LOCK_WAIT_MS;
  let fd = null;
  while (fd === null) {
    try { fd = fs.openSync(LOCK, 'wx'); break; } catch (e) { if (e.code !== 'EEXIST') break; }
    try { if (Date.now() - fs.statSync(LOCK).mtimeMs > STALE_LOCK_MS) { fs.unlinkSync(LOCK); continue; } } catch (_) {}
    if (Date.now() > deadline) break;   // write anyway rather than block Claude
    pause(5 + Math.random() * 10);
  }
  try { return fn(); } finally {
    if (fd !== null) { try { fs.closeSync(fd); fs.unlinkSync(LOCK); } catch (_) {} }
  }
}

After: 40 of 40, three runs in a row, no lock file left behind. Both cases are in the test suite now.

2. The office was showing more than it should

The same comment raised a second point: in kiosk mode the office ends up on a shared TV, and task titles or tool calls can contain things you don't want on a wall.

When I looked, the problem was bigger than the bubbles. The proxy passed Paperclip's responses through unchanged. A single issue on my own instance had more than 70 fields: descriptions, workspace settings, run ids, monitor notes. The page uses about five of them. Read-only was never the same as minimal.

Two changes in v0.7:

Always: the server now forwards only the fields the page draws. Descriptions, adapter and workspace configuration, run ids and closed issues never leave the server.
--redact: task titles, commands and error text are stripped on the server too. The office shows MEG-35, Edit, allow Bash and statuses, and the "needs you" signal still works. Because it happens server-side, changing the page URL doesn't bring the details back, and neither does someone calling the API on that port directly.

The test for it feeds in an AWS key, an SSH key path, an API key in adapter config and a bearer token inside a curl command, then checks that none of them come out of any endpoint.

3. Observability hooks vs. enforcement hooks

Hamid Ahmadian made a point I wish I'd written down myself: a hook that draws the office and a hook that blocks tool calls have opposite contracts. The first must never fail loudly; the second exists to fail loudly (exit 2). If one script does both, a bug in the drawing code can start blocking tool calls.

Cubicle keeps to the first contract: it always exits 0, prints nothing, and install-hooks adds its own separate entries next to whatever hooks you already have instead of merging into them. Reid Marlow's comment on ignoring the one-minute idle reminder was the same idea from the user's side: the office is only useful if the raised hands mean something.

4. The first community PR

A day after launch, @omeruyanik03 opened the first pull request. Claude Code subagents share their parent's session id, so a session that fans out to four subagents showed up as one character whose bubble flickered between five tool calls. The PR gives every subagent its own character, keyed on the agent_id that Claude Code puts on hook events, with tests for the awkward cases: a subagent first seen halfway through its run, older Claude Code versions without agent_id, and a session ending while its subagents are still at their desks.

Because that hook runs on every tool call on my machine, I read it line by line before merging: no network, no child processes, no new dependencies, still exits 0 on every error. It shipped in v0.6.0 the same evening, and it's also why the lock in section 1 mattered so quickly.

Try it

# Paperclip and Claude Code in one office, details hidden for a shared screen
npx @caglarutkuguler/cubicle@latest install-hooks
npx @caglarutkuguler/cubicle@latest --source paperclip,claude-code --redact

Then open http://127.0.0.1:3200/?kiosk. Or try the live demo without installing anything.

Thanks to everyone who took the time to read the code and not just the post. The repo is github.com/caglarutkuguler/cubicle, MIT licensed, and the open issues labelled good first issue are a nice place to start.

I gave my AI agents an office (and made it read-only on purpose)

MEG Venture & Consulting Ltd. — Sun, 27 Sep 2026 20:44:36 +0000

I run several AI agents at once: a handful of Claude Code sessions, plus a small "company" of agents on Paperclip that works on our online store. Giving them work is easy. The hard part is knowing, at a glance, which one is working, which one is done, and which one has been waiting for my answer for twenty minutes.

Logs don't answer that at a glance. So I drew an office.

Live demo, no install · GitHub · npx @caglarutkuguler/cubicle

What the office shows

Every agent is a character:

Working: sits at its desk and types, with the current task or tool call above its head
Needs you: raises a hand, and the monitor turns amber
Done: says "✓ done" and walks to the lounge for a coffee
Error: slumps at the desk, red screen

The header keeps a count of how many agents need you. That single number turned out to be the most useful thing on the screen.

Three design decisions

1. Zero dependencies

The server is a single Node file of under 200 lines, using only the standard library: it serves one HTML page and proxies a few requests. The page draws everything with fillRect on a 352×208 canvas. There are no image assets, no framework, and no build step.

This wasn't minimalism for its own sake. A tool that sits next to your agents all day should be something you can read in ten minutes and trust.

2. Read-only by design

Cubicle only ever makes GET requests. In Paperclip mode it forwards exactly three endpoints and refuses everything else:

const ALLOWED = [
  /^\/api\/health$/,
  /^\/api\/companies$/,
  /^\/api\/companies\/[\w-]+\/(agents|issues)$/,
];

POST, PATCH and DELETE get a 405, any other path gets a 403. If you point it at an authenticated Paperclip, the API key is added on the server side only: it never reaches the browser, and the browser's own cookies are never forwarded upstream. There is deliberately no --token flag, because flags show up in the process list.

3. "Needs you" from real signals

For Claude Code, Cubicle uses the official hooks. A tiny script rewrites ~/.cubicle/claude-code.json on every event:

Claude Code event	In the office
`PreToolUse`, `PostToolUse`	Types at the desk; bubble shows e.g. `Edit checkout.php`
`PermissionRequest`	Raises its hand
`Stop`	Goes to the lounge
`SessionEnd`	Leaves the office

The hook always exits 0 and prints nothing, so it can never block a tool call or add tokens to the context. One thing I had to handle: Claude Code also sends a notification after a minute of idling ("waiting for your input"). Treating that as "needs you" made every idle session raise its hand, so those are ignored.

For Paperclip, the interesting signal was hiding in the issue data. When an agent asks the board a question, Paperclip records it in the issue's reviewAttention.paths with the board as the responder. Often the agent is already busy with another issue, so its own status says running. Cubicle keeps it typing, but its bubble flashes the waiting issue's ID every few seconds and the card links straight to it. The first time I turned this on, it found two questions I didn't know were waiting for me.

Try it

# Paperclip (default, expects it on :3100)
npx @caglarutkuguler/cubicle

# Claude Code
npx @caglarutkuguler/cubicle install-hooks
npx @caglarutkuguler/cubicle --source claude-code

# anything that can write a small JSON file
npx @caglarutkuguler/cubicle --source ./agents.json

Open http://127.0.0.1:3200. Add ?kiosk for a full-screen view on a TV or second monitor.

What's next

A few issues are open and labelled for first-time contributors: a new UI language, per-agent spend for Paperclip, an example adapter for Codex or Gemini CLI, and a replay mode to watch a whole day in 30 seconds. PRs welcome, as long as they keep the two rules: no dependencies, and read-only.

It's MIT licensed: github.com/caglarutkuguler/cubicle

jQuery's .trigger('submit') drops the submit button, and your backend may be checking for it

MEG Venture & Consulting Ltd. — Tue, 15 Sep 2026 07:36:53 +0000

A contact form was posting and leaving nothing behind. No message stored, no e-mail sent, no thread created — and no error either. The page just reloaded, empty and calm, as if the visitor had never pressed anything.

The cause is a one-line detail about how forms are submitted from JavaScript, and it is not specific to the framework we hit it in. If any part of your backend decides whether to act by testing for a submit button's name, you can hit this too.

What the code did

The form was protected by an invisible CAPTCHA. Tokens for that kind of CAPTCHA expire in about two minutes and are single-use, so the sensible design is to fetch a fresh token at the moment of submit rather than on page load:

$form.on('submit', function (e) {
    e.preventDefault();
    grecaptcha.execute(siteKey, { action: 'contact' }).then(function (token) {
        $form.find('[name="g-recaptcha-response"]').val(token);
        $form.trigger('submit');          // <- here
    });
});

Intercept, get the token, put it in the hidden field, submit for real. That is the standard shape, and it appears in a lot of tutorials.

What actually goes over the wire

$form.trigger('submit') does not simulate a click. jQuery, finding no more handlers to run, calls the element's native form.submit().

A native submit has no submitter. The HTML spec is explicit that the entry list is built from the form's controls, and a submit button contributes its name/value pair only when it is the button that activated the submission. Nothing activated anything here, so:

the clicked button's name and value are simply absent from the POST body;
every other field is present and correct.

So you get a POST that looks complete in the Network tab. Unless you know which key is missing, nothing jumps out.

Why that is fatal for some backends

Plenty of server code — PrestaShop, older WordPress plugins, hand-rolled PHP, anything with several forms posting to the same controller — decides what to do by asking which button was pressed:

if (Tools::isSubmit('submitMessage')) {
    // validate, store, send mail
}

isSubmit('submitMessage') is a presence test on $_POST['submitMessage']. With the submitter dropped, that key is not there, the branch never runs, and the controller falls through to rendering the page again.

This is the worst possible failure shape:

No error. The controller did not fail; it was never asked to do anything.
No validation message. Validation lives inside the branch that did not run.
No log line. Nothing threw.
The CAPTCHA looks innocent. Our module's own "blocked submission" counter never moved, which was the clue that finally mattered: the request had not even reached the verification step. We had been tuning the score threshold for a week. The threshold was never involved.

We reproduced it on PrestaShop 9.1.4: the contact form posted, left no thread, no message and no mail, and displayed nothing.

The fix

Re-attach the activating button before submitting:

function submitPreservingButton($form, event) {
    var form = $form.get(0);
    if (!form || form.tagName !== 'FORM') {
        form = $form.closest('form').get(0);
    }
    if (!form) { $form.trigger('submit'); return; }

    var submitter = (event && event.originalEvent && event.originalEvent.submitter)
        || form.querySelector('button[type="submit"][name], input[type="submit"][name]');

    if (submitter && submitter.name
        && !form.querySelector('input[type="hidden"][name="' + submitter.name + '"]')) {
        var keep = document.createElement('input');
        keep.type = 'hidden';
        keep.name = submitter.name;
        // Buttons often carry an empty value; a presence test is happy either
        // way, but an empty string is easy to lose in transit.
        keep.value = submitter.value || '1';
        form.appendChild(keep);
    }

    form.submit();
}

Three details worth keeping:

event.submitter first. Modern browsers put the activating element on the submit event. Use it when it is there; it is the only source that is actually correct when a form has several named submit buttons.
Fall back to the first named submit control. Older browsers, and synthetic submits with no event, need something. It is a guess, but on a single-button form it is the right guess.
Do not add the hidden input twice. A user who submits, fails validation and submits again would otherwise accumulate duplicates.

If you are not carrying jQuery for other reasons, the modern equivalent is form.requestSubmit(submitter), which does the right thing natively — it fires the submit event and includes the submitter. It is widely supported now. requestSubmit() is what form.submit() should always have been.

The part that generalises

Two APIs that look interchangeable are not:

	fires `submit` event	includes submitter
user clicks the button	yes	yes
`form.requestSubmit(btn)`	yes	yes
`form.submit()`	no	no
`$(form).trigger('submit')` with no handlers left	ends in `form.submit()`	no

And a backend convention that looks harmless — "check which button was pressed" — turns that difference into a silent no-op.

If you are debugging a form that posts and does nothing, before you touch validation, tokens or thresholds: open the Network tab, look at the actual form data, and check whether the submit button's own name is in there. It is a ten-second check that we did not do for an embarrassingly long time.

Found while maintaining PrestaShop modules at MEG Venture. The same shape affects account creation, newsletter sign-up and checkout on that platform, since all four are gated on a button name.

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.

DEV Community: MEG Venture & Consulting Ltd.

"Duplicate entry '0' for key PRIMARY" usually means your database lost AUTO_INCREMENT

The tell: it moves

Where it comes from

The trap when you fix it

Finding every affected table

What to exclude

What to do instead, if you can

The five-second version

What your comments changed in my AI-agent office (Cubicle v0.7)

1. The hook was losing updates

2. The office was showing more than it should

3. Observability hooks vs. enforcement hooks

4. The first community PR

Try it

I gave my AI agents an office (and made it read-only on purpose)

What the office shows

Three design decisions

1. Zero dependencies

2. Read-only by design

3. "Needs you" from real signals

Try it

What's next

jQuery's .trigger('submit') drops the submit button, and your backend may be checking for it

What the code did

What actually goes over the wire

Why that is fatal for some backends

The fix

The part that generalises

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

What PrestaShop actually does

Four ways the one text file stops working

What is in the file

Checking your own shop, in about two minutes

The fix that does not depend on the answer

Our own module is not innocent here

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

The sweep, and why the first one was wrong

Not every cross-module read is a bug

Where the risk actually sits

The fix

Making it stay fixed

Why this is worth an hour of your time

Your PrestaShop hook renders nothing, and nothing is logged

The setup

Mechanism 1: core swallows the exception

Mechanism 2: one CSS brace kills the whole template

Mechanism 3: the platform rejected nofilter

What we changed permanently

The shape of the lesson

Mechanism 3: the platform rejected `nofilter`