Loaded Commerce descends from the osCommerce and CRE Loaded lineage, and that history shapes how upgrades behave. The application mixes a PHP catalog engine with a large includes/configure.php file that hardcodes absolute paths and database credentials, a MySQL schema that grows with every module, and an admin/ directory that frequently changes structure between releases. An upgrade is rarely a single-click event: you are replacing core files, running database alterations, and re-checking every path constant while the storefront keeps taking orders. On a managed shared plan you cannot stop services, snapshot a VM, or edit server configuration, so the entire safety net has to be built from account-level tools. The good news is that cPanel Jupiter and DirectAdmin Evolution expose enough backup, file, and database functionality to do this properly.

The failure modes that make upgrades risky are predictable. A half-completed file copy leaves mismatched core and admin files, which throws fatal errors on the checkout page. A schema change applied against the wrong database corrupts order history. A PHP version bump performed at the same time as the upgrade masks which change actually broke the site. And the classic Loaded Commerce trap: the configure.php files carry a physical path such as /home/username/public_html/ that becomes invalid the moment you copy the store into a staging folder. Understanding these causes up front is what turns a nervous upgrade into a controlled one.

Building a complete, restorable backup first

Nothing else in this procedure matters if you cannot restore the exact pre-upgrade state. A Loaded Commerce store has two halves that must be captured together and at the same moment: the file tree under public_html and the MySQL database. Capturing them minutes apart is enough to desynchronize order counters, so schedule the backup during a low-traffic window and take both parts in quick succession.

In cPanel Jupiter, open Files → Backup and use Download a Home Directory Backup for the account files, then under Download a MySQL Database Backup select the store database. If your plan exposes JetBackup 5, generate an on-demand backup and confirm it appears in the restore list before you touch anything. In DirectAdmin Evolution, the equivalent lives under Advanced Features → Create/Restore Backups, where you can tick Home Directory and Databases into a single .tar.gz.

For a more surgical file-level rollback point, use File Manager to compress the live store directory into a dated archive. This gives you an instant local copy that does not depend on the panel's restore queue:

# In cPanel/DirectAdmin File Manager:
# 1. Select the public_html folder (or the store subfolder)
# 2. Click "Compress" -> Zip Archive
# 3. Name it clearly, e.g.:
loadedcommerce_prelive_2026-09-08.zip

Export the database through phpMyAdmin as a second, independent copy. Select the database, choose the Export tab, pick the Custom method, and set the output to a gzip-compressed SQL file. Under the object creation options, enable Add DROP TABLE / VIEW / PROCEDURE so the dump can cleanly overwrite a damaged schema during a restore. Verify the download opens and contains CREATE TABLE statements for tables such as orders and customers before you proceed. A backup you have not opened is a guess, not a safeguard.

Cloning to a staging subdomain

Never test an upgrade on the live storefront. Create an isolated copy where you can break things freely. In cPanel go to Domains → Domains (or Subdomains) and add staging.yourdomain.com with a document root of /home/username/staging. In DirectAdmin, use Account Manager → Domain Setup or the Subdomain Management panel to create the same. Copy the live files into the new root using File Manager's Copy function, then create a fresh database and user under MySQL Databases and import your phpMyAdmin dump into it.

The step people forget is fixing the two configure.php files, because Loaded Commerce stores physical server paths and the base URL inside them. Edit both files in File Manager (use Edit, not download-and-reupload, to avoid encoding changes):

// /home/username/staging/includes/configure.php
define('HTTP_SERVER', 'https://staging.yourdomain.com');
define('DIR_FS_CATALOG', '/home/username/staging/');
define('DB_DATABASE', 'username_stage');
define('DB_SERVER_USERNAME', 'username_stage');

// /home/username/staging/admin/includes/configure.php
define('HTTP_SERVER', 'https://staging.yourdomain.com');
define('DIR_FS_ADMIN', '/home/username/staging/admin/');
define('DIR_FS_CATALOG', '/home/username/staging/');

Keep search engines and casual visitors out of staging with a simple .htaccess gate in the staging document root. LiteSpeed honors standard Apache directives, so basic authentication and IP allowlisting both work:

# /home/username/staging/.htaccess
Require ip 203.0.113.45
# Or password-protect via cPanel "Directory Privacy"

# Discourage indexing regardless
Header set X-Robots-Tag "noindex, nofollow"

Load the staging store, confirm the catalog and admin both render, place a test order, and only then run the upgrade against this copy. If the vendor upgrade package ships SQL alterations, run them through phpMyAdmin's SQL tab against the staging database and watch for errors. Any fatal you see here is one you did not see on the live site.

Running the upgrade and controlling PHP

Loaded Commerce is sensitive to the PHP version because older releases use functions removed in PHP 8. Decide the target PHP version on staging before touching production. In cPanel use Software → MultiPHP Manager to set the staging subdomain's version, or the PHP Selector under CloudLinux for per-directory extension control. DirectAdmin exposes the same through Account Manager → PHP Version Selector. If the current supported Loaded Commerce release targets PHP 7.4, upgrade the application first and change PHP second, as separate, reversible steps. Bundling both changes hides the cause of any regression.

Apply upgrade limits through .user.ini rather than any server file, since core file replacement and schema migration can exceed defaults:

; /home/username/staging/.user.ini
max_execution_time = 300
memory_limit = 256M
upload_max_filesize = 64M
post_max_size = 64M

Copy the new core and admin files into place with File Manager, preserving your customized configure.php files and any theme overrides. Watch the store's local error_log (it appears in the directory where the fault occurs) for path or deprecated-function warnings while you click through catalog, cart, checkout, and the admin order screens. When staging is clean, repeat the identical file and SQL steps on production during a maintenance window, having already refreshed the full backup from the first section.

Rollback protection and go-live checks

Rollback must be defined before you start, not improvised after a failure. Your fastest path is the dated File Manager zip: rename the broken live directory to public_html_failed, extract loadedcommerce_prelive_2026-09-08.zip back into place, and re-import the phpMyAdmin dump over the damaged database using the DROP TABLE statements you enabled earlier. Because the SQL dump and file archive were taken together, the restored order counters and file paths stay consistent.

During the maintenance window, keep customers on a holding page rather than a broken store. A short .htaccess rule serves a static notice while you work, then you remove it to go live:

# /home/username/public_html/.htaccess (temporary)
RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^203\.0\.113\.45$
RewriteCond %{REQUEST_URI} !/maintenance\.html$
RewriteRule ^(.*)$ /maintenance.html [R=302,L]

After removing the rule, confirm HTTPS URLs render, the admin login works, a live test order completes, and the local error_log stays quiet for several minutes under real traffic. Retain both backup copies for at least a week; a subtle schema issue often surfaces days later when a specific report or module runs. Handling upgrades as a staged, backed-up, reversible sequence keeps a Loaded Commerce store online through changes that would otherwise be a gamble on shared hosting.