Where Sngine actually reads its configuration from
Sngine splits its configuration into two very different places, and understanding that split saves hours of guesswork. The first is the file includes/config.php in your document root (usually /home/USERNAME/public_html/includes/config.php or a subfolder if Sngine lives under a subdirectory). That file holds low-level connection constants: the database host, database name, database user, database password, table prefix, and the base URL through which the software builds links and loads assets. If any of those constants are wrong, Sngine never gets far enough to render a page and you see a blank screen or a raw database connection error.
The second location is the system_options table inside your MySQL database. Once the connection succeeds, Sngine loads dozens of runtime options from that table on every request: the site name, cache toggles, third-party API keys, chat and node settings, the debugging flag, and behaviour switches for uploads and notifications. Most of these are edited through the Admin Panel at yourdomain.com/admin, but when the Admin Panel itself will not load, phpMyAdmin becomes the only safe way in. Knowing which layer holds a given setting tells you immediately whether to open File Manager or phpMyAdmin.
On our LiteSpeed and CloudLinux platform there is a third layer that Sngine never stores but always depends on: the PHP runtime limits enforced per account. Memory, execution time, and input limits are controlled by the PHP Selector and by a .user.ini file, not by anything inside Sngine. When a configuration change appears to be ignored, the cause is frequently a PHP limit or an opcode cache serving a stale copy of config.php, rather than the value you edited. Keep these three layers separate in your mind and every troubleshooting step below becomes predictable.
Editing config.php and database connection settings safely
Before touching includes/config.php, make a backup. In cPanel open File Manager, navigate to public_html/includes, right-click config.php, and choose Copy to create config.php.bak. In DirectAdmin the File Manager under the Evolution skin offers the same copy action. A one-second backup means a broken edit is a thirty-second restore instead of a support ticket.
Open the file with Edit and confirm the connection block. The values Sngine expects look like this:
define('T_DBHOST', 'localhost');
define('T_DBNAME', 'cpuser_sngine');
define('T_DBUSER', 'cpuser_snguser');
define('T_DBPASS', 'your-strong-password');
define('T_DBTABLEPREFIX', '');
define('T_URL', 'https://yourdomain.com');Two mistakes cause the majority of connection failures on shared hosting. The first is using a remote host or 127.0.0.1 when the account requires localhost. On our stack MySQL is reachable through the local socket, so localhost is correct in nearly every case. The second is a mismatch between the database user and its assigned password. If you rotated the password in cPanel's MySQL Databases screen but never updated config.php, Sngine authenticates with the old value and fails. Reset the password in MySQL Databases, confirm the user is still attached to the database with ALL PRIVILEGES, then paste the exact password into T_DBPASS.
The T_URL constant deserves attention because it drives asset loading and AJAX endpoints. If you migrated the site or added an SSL certificate, set this to the canonical https:// form with no trailing slash. A stale http:// value produces mixed-content warnings and broken chat or upload requests even when the database is perfectly healthy. To verify the credentials independently of Sngine, open phpMyAdmin from cPanel, select the database, and confirm the system_options and users tables are present. If phpMyAdmin logs in with those exact credentials but Sngine does not, the fault is almost always a typo or a hidden whitespace character inside config.php.
Tuning PHP limits, cache, and debug behaviour
Sngine is sensitive to PHP runtime limits because it processes image uploads, builds large notification queries, and runs a chat system that opens frequent requests. Set the PHP version and extensions through cPanel's Select PHP Version (or DirectAdmin's PHP Selector under PHP Extensions & Options). Sngine 3.x runs best on PHP 8.1 or 8.2 with gd, mysqli, curl, mbstring, fileinfo, and json enabled. Missing gd is a classic cause of failed avatar and cover uploads that produce no obvious error.
Per-account limits are best set in a .user.ini file placed in your document root. Create or edit public_html/.user.ini in File Manager with values that match Sngine's real needs:
memory_limit = 256M
max_execution_time = 120
max_input_time = 120
post_max_size = 64M
upload_max_filesize = 64M
max_input_vars = 3000Because .user.ini is cached by PHP-FPM, changes are not instant. The refresh interval is governed by user_ini.cache_ttl and typically applies within a few minutes; if you need it sooner, toggle the PHP version in the selector, which recycles the process pool. Confirm the applied values by creating a temporary phpinfo.php containing <?php phpinfo();, loading it in the browser, checking the Local Value column, then deleting the file immediately so you never leave server details exposed. For upload-specific tuning that overlaps with these limits, our companion article on fixing the Sngine upload limit and media size errors covers the media pipeline in more depth.
Cache and debug behaviour live in the database. In the Admin Panel under Manage > Configurations you will find options for cache and system mode. When you cannot reach the Admin Panel, edit the system_options table directly in phpMyAdmin. Locate the row where option_name equals debugging_reporting and set option_value to 1 to expose PHP errors while you diagnose a problem, then return it to 0 the moment you finish so visitors never see stack traces. If LiteSpeed serves an old page after you change a template or option, purge it: place a .htaccess directive or use the built-in cache. A minimal, safe way to bypass stale static caching during debugging is a rule such as:
<IfModule LiteSpeed>
RewriteEngine On
CacheLookup off
</IfModule>Remove that block once the site is stable, because disabling cache lookup permanently sacrifices the performance LiteSpeed gives you.
Reading logs and recovering from a bad change
Every configuration edit should be verified against a log rather than by eye. Sngine and PHP write to an error_log file in the directory where the error occurred, most often public_html/error_log. Open it in File Manager and read the last lines: a fatal error naming config.php points to a syntax mistake in your edit, an Access denied for user line points to database credentials, and a Allowed memory size exhausted line points straight back to memory_limit in .user.ini. cPanel's Errors tool and the Metrics section also surface recent PHP errors for the account.
If a change breaks the site, recovery is deterministic. Restore config.php.bak over config.php to undo a connection edit. Revert a database option in phpMyAdmin by editing the same system_options row back to its previous value, which is why noting the original value before changing it matters. For a corrupted or emptied .user.ini, delete the file entirely so the account falls back to the PHP Selector defaults, then rebuild it carefully. Because none of these actions require root, SSH, or server daemon restarts, you can always return a Sngine installation to a working state using only File Manager, phpMyAdmin, and the PHP Selector. Work one layer at a time, verify with the error log after each step, and configuration problems that looked catastrophic resolve quickly.