Where ConcreteCMS Actually Reads Its Configuration

ConcreteCMS does not keep everything in one file, which is the first thing that trips up people who edit a setting and see no effect. The framework loads configuration in layers. The bootstrap-level values that must exist before the database is even reachable live in application/config/database.php and application/config/generated_overrides/. Runtime application settings, such as cache methods, mail configuration, and the site canonical URL, are stored partly in files and partly inside the database in the Config table. On top of that, the environment file at application/config/environment.php (when present) determines which named environment ConcreteCMS considers active, which in turn changes which override files are read.

On our LiteSpeed and CloudLinux platform your document root is typically /home/USERNAME/public_html, and a standard ConcreteCMS install places the application, concrete, and packages directories directly inside it. When you open cPanel Jupiter File Manager or DirectAdmin File Manager, enable Show Hidden Files (dotfiles) from the settings gear so you can see the .htaccess and any .user.ini in the same folder. The distinction that matters most: anything under application/config/generated_overrides/ is written by the Dashboard itself. If you hand-edit those files while also changing the same value in the Dashboard, the Dashboard write wins and silently reverts your file edit. That mismatch is the single most common reason a configuration change appears to do nothing.

The database credentials are the exception because they can only live in a file. Open application/config/database.php and you will find a returned PHP array with a connections key containing the database server, database, username, and password. On shared hosting the server value should almost always be localhost, not an external IP, because the MySQL/MariaDB socket is local to your account. If a migration left a remote hostname there, the site will hang on load or throw a connection error in the local error_log. Before touching this file, download a copy through File Manager so you have an instant rollback.

Fixing Database Settings and Connection Errors

When ConcreteCMS shows a white screen or a generic "Unable to connect to the database" message, the cause is almost always inside application/config/database.php or a mismatch between what that file claims and what actually exists in cPanel. Verify the real database name and user in cPanel under MySQL Databases, or in DirectAdmin under MySQL Management. Remember that both panels prefix names with your account, so the database is something like userna5_c5db and the user is userna5_c5user. The file must contain those full prefixed strings exactly.

A correct connection block looks like this:

<?php
return [
    'default-connection' => 'concrete',
    'connections' => [
        'concrete' => [
            'driver'   => 'c5_pdo_mysql',
            'server'   => 'localhost',
            'database' => 'userna5_c5db',
            'username' => 'userna5_c5user',
            'password' => 'YOUR_DB_PASSWORD',
            'charset'  => 'utf8mb4',
            'collation'=> 'utf8mb4_unicode_ci',
        ],
    ],
];

If you reset the database user password in cPanel, the new password must be pasted into this file immediately or every page request fails. When you suspect the password is wrong, open phpMyAdmin from cPanel or DirectAdmin and confirm you can browse the tables using that user; if phpMyAdmin lets you in but the site does not, the fault is in the file, not the credentials. Watch the character set too. Older ConcreteCMS databases sometimes carry utf8 rather than utf8mb4, and forcing utf8mb4 in the file against a table that only supports the shorter set can produce collation errors on save. Match the file to what phpMyAdmin reports under the Operations tab for the database.

Because you have no shell access, you cannot run the ConcreteCMS console commands. Everything achievable through the CLI here is instead done through the Dashboard at /index.php/dashboard/. After correcting the database file, clear the compiled cache by deleting the contents of application/files/cache/ through File Manager. That directory is safe to empty; ConcreteCMS regenerates it on the next request.

Raising PHP Limits with PHP Selector and .user.ini

ConcreteCMS is memory-hungry during package installation, theme compilation, and large image uploads. The symptoms of an exhausted limit are precise: a truncated page, a 500 error, or an allowed memory size exhausted line in the error_log that File Manager shows in the site root. Because our stack runs LiteSpeed with PHP as a per-user process, you control these values yourself without any root involvement.

Start in cPanel under Select PHP Version (or DirectAdmin's PHP Selector). Confirm you are on PHP 8.1 or 8.2, which current ConcreteCMS releases require, then open the Options tab. There you can raise memory_limit to 512M, max_execution_time to 120, post_max_size to 64M, and upload_max_filesize to 64M through drop-downs, and enable extensions such as intl, gd, and opcache that ConcreteCMS depends on. These panel settings are the cleanest method because they survive updates.

When you need a value the panel does not expose, create or edit .user.ini in your document root. LiteSpeed honors this file per directory:

memory_limit = 512M
max_execution_time = 120
upload_max_filesize = 64M
post_max_size = 64M
max_input_vars = 5000

The max_input_vars line matters for ConcreteCMS forms with many blocks or large permission grids, which can silently drop fields when the default 1000 is exceeded. Changes to .user.ini are not instant; LiteSpeed caches it for up to five minutes, so wait before retesting. Never attempt to set these through php_value directives in .htaccess on this stack, because PHP runs as a LiteSpeed SAPI rather than a module and those lines will throw a 500 error.

Debug Mode, Caching, and Runtime Options

When something breaks, turn on ConcreteCMS debug output rather than guessing. The safest switch is the Dashboard itself at System & Settings > Environment > Debug Settings, where you can set the error reporting level to display detailed errors. If the site is too broken to reach the Dashboard, create application/config/concrete.php and add a debug override:

<?php
return [
    'debug' => [
        'level' => 'developer',
        'display_errors' => true,
    ],
];

Remove that override or set the level back to message once you have captured the error, because leaving verbose errors on a live site exposes file paths and credentials. Pair this with the raw PHP log by opening error_log in the document root through File Manager; ConcreteCMS also writes its own log to the database, viewable at Reports > Logs.

Caching is where most ConcreteCMS performance and "my change won't appear" problems originate. Go to System & Settings > Optimization > Cache & Speed Settings. During troubleshooting, set Block Cache, Overrides Cache, and Full Page Caching to off, save, then clear the cache with the Clear Cache button on that same page. Once the site behaves, re-enable Overrides Cache and Full Page Caching for speed. On our LiteSpeed servers the built-in full-page cache works well without Redis, so you do not need to configure an external cache driver; the default filesystem cache under application/files/cache/ is sufficient for shared accounts. If you edit theme or block PHP files directly and see no change, it is the Overrides Cache holding the old compiled version, and clearing it resolves the issue every time. For a deeper look at how LiteSpeed page caching interacts with PHP tuning on the same platform, see our guide on performance and caching with OPcache, Redis, and LiteSpeed.

One runtime value worth checking after any domain move is the canonical URL, stored in the Dashboard under System & Settings > SEO & Statistics > URLs and Redirection. A stale canonical URL there causes redirect loops that no .htaccess edit will fix, because ConcreteCMS forces its own redirect at the application layer. Clear it or set it to your live domain, save, then clear the cache to apply. Keep a downloaded backup of every config file you touch, work in one change at a time, and confirm each result in a private browser window so cached responses do not mislead you.