Updating ShopClass

ShopClass updates itself. When a new release lands, a notice appears in the admin panel and the built-in updater fetches and applies the package for you. The manual route below exists for hosts that block outbound HTTP, and for anyone who prefers to see every file move.

The one-click update

Open Admin → Tools → Update.
If a release is available, the page offers it with its changelog.
Press update and wait — the updater downloads the package, replaces core files, and runs any pending database migrations.

That is the whole procedure on a healthy install.

Upgrading to 6.2.0 specifically

6.2.0 rebuilds foreign keys on twenty-four tables so the database removes dependent rows along with their parent. Three consequences:

Back up the database first. This is the one release where that instruction is not boilerplate.
It takes time proportional to your row count. Measured over a quarter of a million listings and three quarters of a million custom-field values, the whole rebuild took about six seconds. A much larger site, or slow shared hosting, should expect longer.
A timeout page does not mean it failed. The upgrade is still running and will finish. With shell access you can sidestep the browser entirely:
Terminal window
```
php oc-cli.php db:upgrade
```

An interrupted upgrade is safe to resume — each step is recorded as it completes and every step can be re-run, so starting it again finishes it.

Before each key is rebuilt, any row still pointing at a parent that no longer exists is removed. A healthy database has none; if yours does, they were rows nothing could reach. The backup is what lets you look at them afterwards.

Google Analytics is gone from core

The Tracking ID field has been removed from Settings → General and no measurement snippet is rendered on public pages. If you were using it, paste your own snippet into a Custom Code widget under Appearance → Manage widgets, or install a plugin that provides one.

Your saved measurement ID is left in the database untouched, so a theme printing its own snippet keeps working.

Updating by hand

Use this when the updater cannot reach GitHub, or when you deploy from your own pipeline.

1. Download the release

Get the latest package from the Releases page and unpack it locally.

2. Replace the core files

Upload the new files over the old ones, replacing:

oc-admin/ and everything under it
oc-includes/ and everything under it
the root-level PHP files — index.php, item.php, contact.php, ajax.php, oc-load.php, oc-cli.php and their siblings

3. Run the database migration

Core files alone are not an update — the schema has to catch up. Either open the admin panel, which offers the migration as a button, or run it from a shell:

php oc-cli.php db:upgrade

db:upgrade reconciles a drifted schema before applying pending migrations, so it is also the repair tool when an interrupted update leaves a site half-way.

4. Check the site

Load the front page and the admin panel. If you disabled friendly URLs before updating, turn them back on now.

When an update goes wrong

The site shows a blank page. Turn on PHP error display temporarily and read what it says. A blank page after an update is almost always a leftover file from an older version.

The admin panel loads unstyled. You deployed from a branch rather than a release package. Branches do not carry the compiled admin CSS and JavaScript. Re-deploy from the release zip.

A plugin fatals on load. Disable it from a shell and update it afterwards:

php oc-cli.php plugin:deactivate --plugin=<folder>

You are locked out of the admin panel.

php oc-cli.php user:reset-password --user=admin