Why a Domain Swap Breaks CubeCart in Non-Obvious Places

A CubeCart store is not a collection of static pages that simply follow wherever you point a domain. The store URL, SSL preference, cookie domain, and image base are written into the database the moment you first install, and several of those values live inside the CubeCart_config table as a single serialized PHP string rather than tidy individual columns. When you move the store to a new hostname such as oldshop.com to newshop.com, or shift the files from public_html into an add-on domain folder like public_html/newshop, the files happily load but the application keeps emitting the old address in canonical links, admin redirects, email templates, and product image sources.

The serialized storage format is what trips up most people. A serialized PHP string records the byte length of every value, for example s:17:"https://oldshop.com";. If you do a blind find-and-replace that changes the text but not the recorded length, the string becomes corrupt and CubeCart silently ignores it, reverting to defaults or throwing a blank admin screen. That is why a casual SQL REPLACE() across the whole database is risky for CubeCart. The safe path is to edit the few known settings through the admin panel where the application re-serializes them correctly, and only touch the database directly for values the UI cannot reach.

There is also a caching layer. CubeCart writes compiled Smarty templates and a serialized copy of the configuration into cache/ (and optionally into the CubeCart_cache table). Even after you correct the stored URL, the store can continue serving the old domain until that cache is purged. On shared hosting you resolve all of this through cPanel File Manager, phpMyAdmin, the PHP Selector for the correct runtime, and the CubeCart admin dashboard itself. No SSH, no service restarts, and no server-wide configuration are required or permitted on a managed shared account.

Preparing Files, Document Root, and the PHP Runtime

Begin with the files. If you are relocating the store, use cPanel File Manager (Files → File Manager) or DirectAdmin's file manager to move or extract the CubeCart directory into the document root that matches the new domain. For a primary domain that is usually /home/USERNAME/public_html; for an add-on or subdomain it is the folder you assigned when creating it, for example /home/USERNAME/newshop.com. Confirm the real path under Domains in cPanel or Domain Setup in DirectAdmin before moving anything, because CubeCart writes absolute paths into its cache and session handling.

Set permissions after the move. Directories should be 0755 and PHP files 0644. The writable folders CubeCart needs are cache/, images/source/, images/uploads/, and includes/extra/; these should allow the account user to write, which is the default 0755 on a CloudLinux account running under suPHP/LSAPI. Avoid 0777 entirely. Use the File Manager Permissions dialog rather than any shell command.

Match the PHP version next. CubeCart 6.5 and later expect PHP 7.4 through 8.1 depending on the exact build, and running it on a mismatched interpreter is a frequent cause of a white screen after migration. In cPanel open Software → Select PHP Version (MultiPHP / PHP Selector); in DirectAdmin use Account Manager → Select PHP Version. Pick the version that matched the source server, then confirm the extensions pdo_mysql, mysqli, gd, curl, mbstring, and zip are enabled. You can raise limits for the migration without editing any server file by creating or editing .user.ini in the store root:

; .user.ini in the CubeCart document root
memory_limit = 256M
max_execution_time = 120
upload_max_filesize = 64M
post_max_size = 64M

The .user.ini changes take effect after the PHP process recycles, typically within a few minutes. If the admin area still fails to load at this stage, check the per-directory error_log that LiteSpeed writes into the store folder (or Metrics → Errors in cPanel) before changing anything else. Reading the actual fatal error saves hours of guessing, a habit worth borrowing from this error-diagnosis walkthrough for a similar PHP cart.

Repointing the Database Connection and Store URL

CubeCart stores its database credentials in includes/global.inc.php, not in the database. After importing the SQL dump through phpMyAdmin → Import into a database you created under cPanel MySQL Databases (or DirectAdmin MySQL Management), open that file in File Manager and update the connection block to the new credentials:

$glob['dbdatabase'] = 'newuser_cubecart';
$glob['dbusername'] = 'newuser_ccuser';
$glob['dbpassword'] = 'your-new-password';
$glob['dbprefix']   = 'CubeCart_';
$glob['dbhost']     = 'localhost';

On shared hosting the database host is almost always localhost; do not point it at the old server's IP. Remember that cPanel and DirectAdmin prefix both the database name and the user with your account name, so the values must match exactly what the panel created.

With the connection live, fix the store URL from inside the application rather than by hand. Log into the CubeCart admin at https://newshop.com/admin.php (the admin folder may be renamed on hardened installs) and open Store Settings → Advanced. Update the SSL URL and the Non-SSL URL fields to the new domain, then save. CubeCart re-serializes the CubeCart_config row correctly, which is the whole point of using the UI. If you cannot reach the admin because the old URL forces a redirect loop, you can edit the one setting directly in phpMyAdmin by browsing CubeCart_config, finding the row where name equals config, and carefully correcting the serialized s:LENGTH:"URL"; value so the byte count matches the new string length. Count characters precisely. After editing, clear the cache so the fix propagates.

Clearing Cache, Sessions, SEO URLs, and Image Paths

Purge the compiled cache so the new URL takes effect everywhere. In the admin go to Maintenance → Rebuild / Clear Cache, or in File Manager empty the contents of the cache/ directory, leaving the folder itself and its index.html in place. Also truncate the CubeCart_cache table in phpMyAdmin if your build stores cache rows there. CubeCart regenerates these files on the next page load using the corrected configuration.

Sessions tied to the old cookie domain will log admins out or appear to hang. That is expected after a domain change; clearing browser cookies for both domains resolves it. If sessions misbehave broadly, confirm the PHP session save path is writable by adding session.save_path to your .user.ini only if your account lacks a default, otherwise leave it to the platform default.

Search-engine-friendly URLs rely on .htaccess. CubeCart ships a rule set that LiteSpeed reads natively. Confirm the rewrite base reflects the new location. For a store in the document root the file should contain:

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?_a=$1 [L,QSA]

If the store lives in a subfolder, set RewriteBase /newshop/ accordingly. To force HTTPS after installing the AutoSSL or Let's Encrypt certificate from the panel, add this above the CubeCart block:

RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Finally, address stored image paths. Product and category images are referenced relative to the store root, so a correct store URL fixes most of them automatically after a cache rebuild. Mixed-content warnings usually mean an absolute http://oldshop.com link survives inside a product description, a page in Content → Documents, or an email template. Search for those strings in phpMyAdmin with a targeted SELECT on CubeCart_inventory and CubeCart_documents, then edit each matching record through the admin dashboard so the data stays valid. Rebuild the cache once more, load the storefront in a private browser window, and verify that the catalog, cart, and checkout all render on the new domain over HTTPS.