Backups & maintenance
Everything here lives under Tools in the admin panel.
Backups
Section titled “Backups”Tools → Backup data exports two things, and a complete backup needs both:
- A SQL dump of the database — listings, users, categories, settings, everything. Downloaded directly, or written to a directory on the server.
- A zip of the install, which carries
oc-content/— uploads, installed plugins and themes.
A database dump without the uploads restores a site whose every photo is missing.
On a large site the zip is the part that fails first: it is built in one request, so a big uploads directory can exhaust the memory limit or the execution time. When that happens, use the command line below instead — it has neither limit.
From the command line
Section titled “From the command line”More reliable on a large site, because there is no web-server timeout to hit:
mysqldump -u USER -p DATABASE | gzip > backup-$(date +%F).sql.gztar -czf uploads-$(date +%F).tar.gz oc-content/Rules that make a backup real
Section titled “Rules that make a backup real”- Store it somewhere else. A backup on the same server is not a backup; it is a second copy of the thing that will fail.
- Restore one. An untested backup is a guess. Restore into a staging copy once, and you will find the problem before you need it.
- Automate it. A backup you take by hand is a backup you take until you get busy.
- Take one before every update, migration, cleanup and bulk change. Every destructive action in this documentation says so for a reason.
Maintenance mode
Section titled “Maintenance mode”Tools → Maintenance mode puts the site into maintenance while you work. Signed-in admins always keep full access. What everyone else sees is up to you.
The top of the screen shows the current state — Maintenance mode is: ON / OFF — with one button to switch it.
Two ways to run it
Section titled “Two ways to run it”Under Visitors there is a checkbox, Block the public site (HTTP 503).
| Checkbox | What a visitor gets |
|---|---|
| Ticked (the default) | An HTTP 503 page carrying your message. Nobody can browse or post. |
| Unticked | The site as normal, with your message as a banner across the top. |
Tick it before a major update, a large migration or a schema change — nobody publishes a listing into a database you are in the middle of moving.
Leave it unticked for work that does not risk the data: a theme change, a price update, a slow import. Visitors keep shopping and simply know something is going on.
Your choice is remembered when you turn maintenance mode off again.
The message
Section titled “The message”The Message box under the checkbox is shown on the banner and on the 503 page. Plain text only, up to 500 characters — HTML is stripped. Leave it blank and Shopclass writes a polite default using your site name.
Cleanup
Section titled “Cleanup”Tools → Cleanup removes dead content in bulk:
| Group | What it removes |
|---|---|
| Expired listings | Past their expiration date |
| Blocked listings | Disabled or blocked |
| Spam listings | Flagged as spam by visitors |
| Unactivated listings | Never activated from the confirmation e-mail |
| Unactivated accounts | Never activated from the confirmation e-mail |
Run it on demand, or save the settings and let the daily cron do it.
On an established site this is what keeps the database fast — dead rows cost you on every search. Back up before the first run, and think about expired listings specifically: deleting them 404s pages that may still rank.
The activity log
Section titled “The activity log”Tools → Activity log records admin actions with their details and originating IP, searchable by details, action or IP.
This is what answers “who disabled that category” and “when did this setting change” on a site with more than one admin. It can be filtered, and cleared entirely.
Behind a reverse proxy, the logged IP is only meaningful if the real client IP is being passed through — see the caching contract.
Import
Section titled “Import”Tools → Import data takes SQL directly — the route for location data, bulk-loading listings, or anything prepared outside the admin.
It substitutes the /*TABLE_PREFIX*/ placeholder for your actual prefix, which
is why data prepared for it should keep the placeholder rather than a
hard-coded oc_.
Back up first. An import runs whatever SQL you give it.
Tools → Cache clears the object cache after a bulk import or a direct database edit — anything that changed data behind the application’s back.
php oc-cli.php cache:flushSee object caching.
System info and health
Section titled “System info and health”Tools → System info reports the PHP version, memory limit, upload limits, extensions, database version and disk space — the details every bug report should include.
The same ground, from a shell, with pass/fail verdicts and a non-zero exit code when something is wrong:
php oc-cli.php doctorRun it after any change to the server, and put it in your monitoring.
A maintenance routine
Section titled “A maintenance routine”Weekly — check reported listings and the moderation queue; skim new users for spam registrations.
Monthly — run doctor; apply core, plugin and theme updates on a staging
copy, then live; check the cleanup ran.
Quarterly — restore a backup into staging and confirm it works; review location data for updates; re-read your category tree against what people actually search for.