The file that controls almost every runtime setting in CS-Cart and Multi-Vendor 4.x is config.local.php in the installation root. It holds database credentials, host paths, index filenames, tweaks, cache and session backends. It is plain PHP, so a single stray character breaks the whole store with a blank page or a SERVICE UNAVAILABLE message. Back it up before editing.

Set correct file permissions after any edit so the credentials inside it are not world-readable:

chmod 644 config.local.php

Fix a broken database connection

A generic SERVICE UNAVAILABLE page after a migration, a password rotation, or a restore is almost always wrong database values. The keys CS-Cart reads are:

$config['db_host']     = 'localhost';
$config['db_name']     = 'youruser_cscart';
$config['db_user']     = 'youruser_cscart';
$config['db_password'] = 'your_db_password';

On DirectAdmin Evolution and cPanel Jupiter the database name and user are prefixed with your account username. Copy the exact prefixed values from MySQL Databases in the panel. If MySQL listens on a non-standard socket or port, append it to the host, for example localhost:3307.

Verify the credentials independently before blaming CS-Cart. From SSH:

mysql -u youruser_cscart -p youruser_cscart -e "SELECT 1;"

If that command authenticates and the store still fails, the values in config.local.php do not match. Fix the typo rather than granting broader privileges to the database user.

Correct host and path values after a move

When a store loads with broken CSS, redirect loops, or links pointing at the old domain, the HTTP host and path are stale. These four keys define where CS-Cart thinks it lives:

$config['http_host']  = 'example.com';
$config['http_path']  = '';
$config['https_host'] = 'example.com';
$config['https_path'] = '';

Use an empty path when CS-Cart sits in the document root. If it runs from a subdirectory, set the path to that directory without a trailing slash, such as /shop. Set https_host only once a valid SSL certificate is active for the domain; otherwise HTTPS requests fail. The storefront and admin HTTPS toggles live in the panel under Settings → Security settings, and they depend on these host values being correct first.

Reveal the real error behind a blank page

To turn the vague unavailable message into an actual file and line number, use Development mode. CS-Cart ships a commented block near the top of config.local.php gated by an IP check. Replace 127.0.0.1 with your own public IP so only you see the output on a live store:

if ($_SERVER['REMOTE_ADDR'] == 'YOUR.PUBLIC.IP.HERE') {
    define('DEVELOPMENT', true);
    error_reporting(E_ALL);
    ini_set('display_errors', 'on');
    ini_set('display_startup_errors', true);
    $config['tweaks']['disable_block_cache'] = true;
}

The DEVELOPMENT constant surfaces Smarty and PHP errors. The debugger is reached by appending &debug to an admin URL, or with Ctrl + Alt + D, showing SQL queries, templates, and per-page time and memory. Do not set define('DEBUG_MODE', true) unconditionally on a production site, because it exposes debug data to every visitor. Remove the IP block or revert to the shipped defaults once you have identified the fault, and confirm errors no longer display to normal visitors.

Switch cache and session backends

CS-Cart caches to files by default. If your account has Redis available, moving cache and sessions there reduces disk I/O under LVE. The supported cache backends are file, sqlite, database, redis, xcache, and apc; sessions accept only database or redis. The sqlite, apc, and xcache options need the matching PHP extension compiled in, which is not the case on the standard PHP 8.2 to 8.4 builds here, so treat redis and database as the practical choices.

$config['cache_backend']         = 'redis';
$config['cache_redis_server']    = 'localhost';
$config['cache_redis_global_ttl'] = 0;

$config['session_backend']       = 'redis';
$config['session_redis_server']  = 'localhost';

Set cache_redis_global_ttl to a non-zero value only if your cache footprint approaches the Redis memory limit for your account; leaving it at 0 keeps entries until CS-Cart invalidates them. Confirm Redis is actually running for your account before switching, otherwise the store cannot cache or start sessions and will error out. If Redis is not provisioned, keep file for cache and database for sessions.

After changing any backend, clear the existing cache so stale file-based data is not read back:

php ./admin.php --dispatch=clear_cache

Adjust admin.php to your renamed admin index if you changed it. The active admin filename is defined by $config['admin_index'] in the same file.

Raise PHP limits for imports and large catalogs

Product imports, theme operations, and add-on installs fail when PHP memory or execution time runs out. These are PHP settings, not CS-Cart keys, so change them in the panel rather than in config.local.php. In DirectAdmin Evolution and cPanel Jupiter, open the PHP selector (Select PHP Version or PHP Selector) and raise the relevant values, then confirm your PHP handler is 8.2, 8.3, or 8.4:

memory_limit = 256M
max_execution_time = 300
upload_max_filesize = 64M
post_max_size = 64M

These are reasonable starting points for a mid-sized catalog, not guaranteed values; increase them based on the size of the file you are importing. On CloudLinux the effective ceiling is your account LVE limit. If PHP shows plenty of memory yet processes still die, check the LVE stats in the panel (Resource Usage) for PMEM or CPU faults, and stagger large imports instead of requesting host-wide limit changes you cannot make on shared hosting.

Verify the active values from SSH so you are reading what the CS-Cart request actually uses:

php -i | grep -E 'memory_limit|max_execution_time|upload_max_filesize|post_max_size'

Runtime tweaks in the config file

The $config['tweaks'] array holds runtime switches read on every request. Two are worth knowing while diagnosing behaviour:

$config['tweaks']['anti_csrf']           = true;
$config['tweaks']['disable_block_cache'] = false;

Keep anti_csrf enabled; disabling it removes CSRF protection from forms and is not a legitimate fix for a form that misbehaves. Enable disable_block_cache only while actively developing templates, since it forces block rebuilds on every page and slows the store. Return it to false when you are done.