TomatoCart is a PHP e-commerce platform built on the osCommerce lineage, meaning it leans heavily on a global configuration include, a flat database structure, and procedural PHP that predates modern exception handling in many code paths. When something breaks on a LiteSpeed shared server running CloudLinux, the storefront usually responds with either a blank page, a terse HTTP ERROR 500, or a half-rendered template that stops mid-page. None of those outputs tell you anything useful on their own, because production PHP settings suppress error text by default. The work of diagnosis is almost entirely about turning the right logging back on, finding where your account writes those logs, and reading the single line that actually matters.

Everything described here is done as an unprivileged hosting user. You will not touch php.ini at the server level, restart services, or run shell commands as root. The controls you need are the cPanel Jupiter or DirectAdmin Evolution file managers, the PHP Selector, per-directory .user.ini files, .htaccess directives, and the TomatoCart admin panel itself. That is enough to surface and fix the overwhelming majority of 500-class failures.

Why TomatoCart fails silently and where the real error lives

A blank white screen is PHP hitting a fatal error while display_errors is off. The script halts, LiteSpeed returns the partially-flushed buffer (often nothing), and the actual message is written only to a log. An HTTP 500 is the same underlying condition, except the web server catches a non-zero exit, a malformed header, or an .htaccess directive it refuses to honor, and substitutes its own status page. Both cases share one fix for diagnosis: find the log line with the file path and line number.

On a LiteSpeed/CloudLinux account, PHP errors are written to a per-directory error_log file in the same folder as the script that failed. For TomatoCart that usually means one of these appears after a failed request:

/home/USER/public_html/error_log
/home/USER/public_html/admin/error_log
/home/USER/public_html/includes/error_log

Open cPanel > File Manager (or DirectAdmin > File Manager), navigate to public_html, enable "Show Hidden Files (dotfiles)" from the Settings gear, and look for error_log. Right-click and View or Edit the file, then scroll to the bottom — the newest entries are last. A typical fatal line reads like this:

[28-Oct-2026 14:02:11 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function mysql_connect() in /home/USER/public_html/includes/classes/database.php:48

That one line names the file, the line number, and the exact failure. Everything else in this guide is about forcing that line to appear and then acting on what it says. cPanel also exposes a web-level view under Metrics > Errors, which captures the server's 500 and permission events; it is useful for correlating the timestamp of a failed checkout or admin action with a PHP fatal written moments earlier.

Turning on safe debugging with .user.ini and the admin panel

If no error_log is being generated, logging is suppressed for your account's PHP handler. Enable it per-directory without touching any server file. Create or edit a file named .user.ini in public_html using File Manager, and add:

display_errors = Off
log_errors = On
error_log = /home/USER/public_html/tomato_errors.log
error_reporting = E_ALL & ~E_DEPRECATED & ~E_NOTICE

Keep display_errors set to Off on a live storefront so customers never see internal paths or database details. Routing output to a named file like tomato_errors.log keeps a clean, timestamped record you control. The .user.ini is read by PHP on a cache interval, so wait up to five minutes (or bump the PHP version and revert it in the Selector to force a pool refresh) before the change takes effect. Reproduce the broken page, then read the new log file.

TomatoCart carries its own error display switch. In the admin dashboard, go to System > Configuration > Store Settings (and in some builds My Store > Error Handling) and confirm the store is not in a forced-display mode on production. The application's own configuration file at includes/configure.php defines STORE_SESSIONS, database constants, and path constants; a single wrong value there, such as a stale DIR_FS_CATALOG after a migration, produces an instant fatal include failure that lands in the error_log as an require(): failed to open stream message. Never leave debug output visible to shoppers — read it from the log, fix the root, and move on.

Fixing the common 500 causes on LiteSpeed and CloudLinux

Once you have the log line, most failures fall into a short list of fixable categories, all solvable from your hosting account.

Deprecated MySQL extension. TomatoCart's original code used the removed mysql_* functions. On PHP 7+ these are gone, producing Call to undefined function mysql_connect(). The correct move on shared hosting is to set a compatible PHP version in cPanel > MultiPHP Manager or DirectAdmin's PHP Version Selector. Select the domain, choose PHP 7.4 if your TomatoCart build still relies on legacy drivers, or apply the official mysqli patch set and run PHP 8.1. Do not pin to an end-of-life version long term; use it only to restore service while you patch the database class.

Missing or disabled extensions. Lines like Class "GD\Image" not found or Call to undefined function curl_init() mean a required extension is off for your selected PHP version. Open cPanel > Select PHP Version > Extensions (the CloudLinux PHP Selector) and tick gd, curl, mbstring, mysqli, pdo_mysql, and zip. GD and cURL are the usual culprits for TomatoCart image handling and any outbound payment call. If your store processes gateway callbacks, correct cURL and TLS configuration is the same work described for other carts in our guide on Loaded Commerce payments and webhooks on shared hosting.

Memory and execution limits. Large catalog imports or report pages can exhaust memory, logged as Allowed memory size of N bytes exhausted. Raise the limits in .user.ini within the bounds your plan allows:

memory_limit = 256M
max_execution_time = 120
max_input_vars = 5000

Broken .htaccess directives. A 500 that appears on every page with no matching PHP fatal is almost always an .htaccess line LiteSpeed rejects — frequently a php_value or php_flag directive left over from an Apache-mod_php host. Move all PHP settings into .user.ini and remove them from .htaccess. A safe rewrite block for TomatoCart's SEO URLs looks like this:

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

To confirm .htaccess is the cause, rename it to htaccess.bak in File Manager and reload the site. If the 500 clears, reintroduce rules a few lines at a time until the offending directive reveals itself.

File permissions. After a restore or FTP upload, a Permission denied fatal on an include means the ownership or mode is wrong. Set directories to 755 and files to 644 using File Manager's Permissions dialog; never use 777, which many security scanners and the server itself will flag. The writable paths TomatoCart needs — includes/work, images, and any cache directory — should be 755 directories owned by your account, not world-writable.

After each change, clear the LiteSpeed cache for the domain if your plan exposes the LiteSpeed Cache controls, reload the failing page, and re-read tomato_errors.log. Work one error at a time from the bottom of the log upward; fixing the first fatal frequently exposes a second one that was never reached before. When the log stops growing and the storefront renders completely, set display_errors = Off, keep log_errors = On for ongoing monitoring, and remove any temporary debug file you exposed publicly.