A blank storefront or a plain "500 Internal Server Error" page is one of the more unsettling things an osCommerce shop owner can see, because the error itself tells you almost nothing. osCommerce is a mature codebase, and many production shops still run on osCommerce 2.3.x with layers of contributions and hand-edited core files. That history is exactly why errors surface: a PHP version jump in MultiPHP, a leftover register_globals assumption, a corrupted configure.php, or a single contribution that references a function removed in modern PHP can all take the whole site down at once. The good news is that every clue you need lives inside your hosting account, and you can reach all of it without root, SSH, or server-wide configuration changes.

Finding the real error behind the blank page

The first rule of diagnosis is to stop guessing and read the logs. A white screen almost always means PHP hit a fatal error while display_errors was turned off, so the message was written to a log file instead of the browser. On LiteSpeed with CloudLinux, PHP writes to a per-directory error_log file in whatever folder the failing script lives in. For a storefront fatal error, look first in your document root, usually /home/youruser/public_html/error_log, and in the admin area under /home/youruser/public_html/admin/error_log.

Open cPanel's File Manager (Jupiter theme: Files → File Manager) or the DirectAdmin File Manager, navigate to public_html, and enable "Show Hidden Files (dotfiles)" from the settings so nothing is hidden. Open the newest error_log and read the last few lines. A typical osCommerce fatal looks like this:

[04-Oct-2026 11:42:07 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function eregi() in /home/youruser/public_html/includes/functions/validations.php:28

That single line localizes the problem to a file, a line number, and a cause. In the example above, eregi() was removed in PHP 7, which tells you the shop is running code written for PHP 5 on a newer interpreter. cPanel also keeps an account-level log under Metrics → Errors, which aggregates recent PHP and web server errors and is useful when you are not sure which directory the failure came from. If the log shows a 500 with no PHP message at all, the cause is usually the web server rejecting your .htaccess rather than PHP itself, which we handle separately below.

Enabling debug output safely with .user.ini

When the log is empty or you want to reproduce the error live, turn on error display temporarily. Never edit a global php.ini on shared hosting; instead use a per-account .user.ini file, which LiteSpeed reads for your document root. Create or edit /home/youruser/public_html/.user.ini through File Manager and add:

display_errors = On
display_startup_errors = On
error_reporting = E_ALL
log_errors = On
max_execution_time = 120
memory_limit = 256M

Changes to .user.ini are cached and can take up to five minutes to apply, so wait before retesting. Once the error shows on screen, record the full message and then set display_errors = Off again. Leaving errors visible on a live shop exposes file paths and database details to customers, so treat this strictly as a diagnostic window.

osCommerce has its own error handling as well. In osCommerce 2.3.4 and the Phoenix fork, the storefront loads includes/application_top.php, which sets the PHP error level. If you need deeper visibility, confirm that STORE_PAGE_PARSE_TIME_LOG and the error logging constants in Admin → Configuration are not pointing to an unwritable path. A common silent failure is osCommerce trying to write its own log to a directory that your account cannot write to, which produces a blank page before any useful output. The memory_limit and max_execution_time values above also matter: a half-rendered page that dies mid-load is frequently PHP hitting the memory ceiling during a large category listing or a bulk product import, and raising the limit through .user.ini confirms that diagnosis immediately.

PHP version mismatches and broken .htaccess rules

The single most common cause of a fresh 500 on osCommerce is a PHP version change. If your host moved the default from PHP 7.4 to 8.1, or you selected a new version yourself, deprecated functions and old MySQL calls will throw fatal errors. In cPanel, open Software → Select PHP Version (PHP Selector) and, in DirectAdmin, open Account Manager → Select PHP Version. Legacy osCommerce 2.3.x without heavy patching runs most reliably on PHP 7.4. Phoenix builds are tested on PHP 8.0 and 8.1. Set the version that matches your codebase, then confirm the required extensions are enabled in the same screen: gd for product thumbnails, curl for payment gateway callbacks, mbstring, mysqli, and openssl. A missing mysqli extension produces an immediate fatal about an undefined database function and looks identical to a code bug in the log until you check the extension list.

When the log shows a 500 with no PHP trace, suspect .htaccess. osCommerce ships .htaccess files in the root, admin/, and several includes directories. Contributions and SEO URL add-ons frequently inject directives that LiteSpeed rejects, most often legacy php_value or php_flag lines that must now live in .user.ini instead. Rename the root file to .htaccess_off in File Manager and reload the storefront. If the site returns, reintroduce directives in small blocks until the offender appears. A safe baseline for an osCommerce SEO-friendly URL setup looks like this:

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteBase /
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule ^(.*)-p-([0-9]+)\.html$ product_info.php?products_id=$2 [L]
</IfModule>

Keep PHP tuning out of this file entirely. Any php_value memory_limit or php_flag display_errors directive left over from an Apache-era tutorial will trigger a 500 under LiteSpeed and belongs in .user.ini. If you have worked through resource-related slowdowns and timeouts separately, our guide on media and storage optimization on shared hosting covers complementary tuning ideas for image-heavy stores.

Database connection failures and corrupted configuration

If the log points at a database error or you see osCommerce's own "Unable to determine the page link" or a connection failure, the problem is usually in includes/configure.php or in the database itself. osCommerce stores credentials in two files: /home/youruser/public_html/includes/configure.php for the storefront and /home/youruser/public_html/admin/includes/configure.php for the admin panel. After a migration or account move, these commonly still reference the old database host or user. Open each file and verify the defined constants: DB_SERVER should be localhost, DB_SERVER_USERNAME and DB_DATABASE must match what appears in cPanel's Databases → MySQL Databases screen, including the account prefix such as youruser_osc.

define('DB_SERVER', 'localhost');
define('DB_SERVER_USERNAME', 'youruser_oscadmin');
define('DB_SERVER_PASSWORD', 'your-real-password');
define('DB_DATABASE', 'youruser_osc');

If credentials are correct but the connection still fails, confirm the database user is attached to the database with ALL PRIVILEGES in the MySQL Databases screen, then test the login directly in phpMyAdmin. A storefront that loads but throws fatals only on certain pages often has a crashed table. Open phpMyAdmin, select your database, tick the suspect tables such as sessions, categories, or products, and choose "Repair table" from the dropdown. For MyISAM tables this clears the vast majority of "table is marked as crashed" fatals without any server-level intervention. After every change, clear osCommerce's cache by emptying the cache/ directory contents in File Manager and reload the shop. Working methodically from the error_log entry to the specific file, extension, rewrite rule, or table keeps each fix verifiable and prevents one blank page from turning into an afternoon of trial and error.