What is still open

This is the page that makes the other four worth reading. Anything that claims only improvements is selling; the useful question is what we have not solved, and what that costs you.

A restore does not run migrations

A backup holds exactly three things: the database, the application's .env, and the uploaded-files tree. That is the right set, because the code itself is in git.

A restore puts all three back and points the restored .env at the server it lands on (its database, its cache and their paths), so a restore onto a rebuilt or a different server connects. What it does not do is run the application's database migrations. An older backup restored under newer code therefore sits behind the schema until the next deploy runs them.

To move a working shop to another server, rather than rebuild one, use Move between servers in the panel: it brings the app up on the new server with its migrations and caches, and parks the old copy, with all its data, until you delete it yourself.

A rollback does not undo database changes

Rolling the code back to a previous release does exactly that: the code. It does not reverse database migrations that ran in between.

If an update changed the database and you then roll the code back, the shop is running old code against a newer schema. Recovering from that needs a backup restore, not a rollback. Worth knowing before you need it at 2 a.m.

Measurements come from one server size

Every number on these pages was taken on a 4 GB, 2-core server, with one real shop's dataset.

We have not measured 8 GB or larger machines, so nothing here predicts them. And your catalogue's shape (how many products, how they are categorised, how add-ons are used) affects which queries matter. A shop very different in shape from the one we tested may find a slow screen we never hit.

Storage-speed figures from those runs are not usable as evidence either: they reflect which physical host the virtual machine happened to land on, not the software.

The report pages that stay in the hundreds of milliseconds

All 297 pages of the 6amMart admin panel were timed on the real 66,701-order dataset, warm, with every query profiled. The seven genuinely broken pages this section used to list, including a day-wise report that took over 17 seconds because one query ran once per day in the reporting range, were fixed in the August 2026 round; the before-and-after table is on the measured results.

What remains open is smaller, and it is a boundary rather than a defect: 22 pages still take over 200 ms, and all but two of them are report aggregates in the 300–900 ms band whose cost is one honest scan of the whole order history. A SUM over every order a shop has ever taken reads every order; that is the job. Two of those pages were explicitly measured, considered, and left unchanged because the candidate indexes made them no faster or slower.

The number worth keeping from the broken era: the day-wise report's cost grew with the length of the reporting period, not the amount of data (63 ms over 21 days, 18.6 seconds over all time), so a developer with three weeks of test data would never see it. That is why these pages are timed on a real shop's history, and why we publish the two that will not get faster next to the five that did.

Vendor updates need a real merge

The optimised code is 6amMart with our changes on top. When the vendor ships a new release, their files and ours overlap, and the overlap is resolved deliberately, not automatically.

That is work, and it is work we do rather than work you do. But it is honest to say the shape of it: this is not a plugin that survives an update untouched. It is a maintained codebase, and maintaining it is the ongoing part of the arrangement.

Some checks stay unknown rather than guessing

Where a check cannot read what it needs, such as on a hardened host that blocks process or system access, the result is reported as "not measured" and excluded from any score, rather than assumed good or counted as a failure. A check that could not read its input has not passed and has not failed.

That means a clean report on a locked-down host genuinely covers less ground than the same report on a server you control end to end.

One case does not yet behave that way, and it is the exception rather than the rule: where PHP runs inside a kernel sandbox, one web-server timeout is reported as unset rather than as unreadable, when the web server has in fact set it. That is a wrong answer, not a blank one, and it marks a hardened server down for being hardened. It is written up in full on the limitations page under SixChecker.

One smaller one, for completeness

The panel reads its own HTTPS certificate once, when it starts. The nightly renewal reloads nginx, which serves your shops, but not the panel itself, so a renewed panel certificate is picked up the next time the panel restarts. Every SixPanel update restarts it.

What this list is for

Every claim on the measured results and defects fixed is something we can show you. This page is everything we cannot, and it is short on purpose: not because there is nothing else, but because we only list what we have actually confirmed rather than padding it to look thorough.

If something here matters to your shop, ask before you buy. That conversation is cheaper for both of us than finding out afterwards.