Where HumHub actually stores its configuration

HumHub is built on the Yii2 framework, and that single fact explains most of the confusion people run into when they try to change a setting. There is no .env file and no single dashboard field for every runtime option. Instead, configuration lives in PHP arrays that are merged at boot time. The three files that matter on a shared account are protected/config/common.php (base defaults that ship with the release), protected/config/web.php (web-request overrides), and most importantly protected/config/dynamic.php, which the Admin panel writes to automatically whenever you change something under Administration → Settings.

The database credentials entered during the installer are stored in dynamic.php, not in a plain text file you might expect. When you open it through cPanel's File Manager (Jupiter theme) at public_html/protected/config/dynamic.php, or the equivalent path under your document root in DirectAdmin, you will see a returned array containing a components key. The db component holds the DSN, username, and password. Because this file is machine-generated, formatting is compact and every value is quoted PHP. A misplaced comma or an unescaped quote in a password will produce a white screen or a 500 error rather than a helpful message, so always download a backup copy before editing.

Understanding this layering matters because settings you place in common.php or web.php can be silently overridden by whatever the Admin panel later writes into dynamic.php. For persistent manual changes that the panel will not touch, common.php is the correct place. For anything the installer or Admin UI manages, expect dynamic.php to be authoritative. When a value appears in more than one file, the merge order means dynamic.php generally wins for components it defines.

Fixing database credentials and connection errors

The most common configuration emergency is a database connection failure after a password change or account migration. On shared hosting you cannot touch server-wide MySQL settings, but you can correct what HumHub uses to connect. Open protected/config/dynamic.php and locate the db component. It looks similar to this once formatted for readability:

'components' => [
    'db' => [
        'class' => 'yii\db\Connection',
        'dsn' => 'mysql:host=localhost;dbname=cpuser_humhub',
        'username' => 'cpuser_hh',
        'password' => 'YourDbPassword',
        'charset' => 'utf8mb4',
    ],
],

On both cPanel and DirectAdmin, the database host is almost always localhost, and the database and user names are prefixed with your account username (for example cpuser_humhub). If you reset the database password through cPanel's MySQL Databases page or DirectAdmin's MySQL Management, update the password value here to match exactly. Verify the credentials independently by logging into phpMyAdmin with the same username and password before assuming the file is wrong. Keep the charset at utf8mb4 so emoji and multilingual posts store correctly.

If you moved the account to a new server or changed the database name during a restore, correct both dbname in the DSN and the username. After saving, HumHub caches nothing about failed connections, so a page refresh reflects the change immediately. Should you still see an error, open the local log at protected/runtime/logs/app.log through File Manager; Yii writes the underlying PDO exception there, which tells you whether the failure is authentication, an unknown database, or a socket issue.

Setting PHP limits and runtime options without root

HumHub's marketplace modules, file uploads, and cron-driven background jobs are sensitive to PHP resource limits. Because you have no shell and cannot edit php.ini or my.cnf, the two tools available are the PHP version and settings interface and a per-directory .user.ini file. In cPanel Jupiter, use MultiPHP INI Editor or Select PHP Version → Options; in DirectAdmin Evolution, use Select PHP Version or the PHP Selector under CloudLinux. HumHub 1.15 and newer expect PHP 8.1 or 8.2, so confirm your handler is set to a supported version before tuning anything else.

For values the selector does not expose, create or edit public_html/.user.ini. This works on LiteSpeed with the LSAPI handler used across the platform. Reasonable starting values for a busy community are:

memory_limit = 512M
upload_max_filesize = 128M
post_max_size = 132M
max_execution_time = 120
max_input_vars = 5000
date.timezone = "UTC"

LiteSpeed honors .user.ini but caches it, so changes can take up to the configured refresh interval (commonly 300 seconds) to apply. To force an immediate reload, toggle the PHP version in the selector and switch it back, which recycles the LSAPI process. The post_max_size should stay slightly larger than upload_max_filesize so multipart form data plus the attachment fits. Raising max_input_vars prevents the module configuration and permission matrices from silently truncating when you save large forms in the Admin panel.

If your account allows OPcache tuning through the INI editor, leaving OPcache enabled with a modest opcache.memory_consumption of 128M speeds up HumHub noticeably, since Yii loads a large number of PHP class files per request. Do not attempt to disable OPcache globally; only adjust what the panel exposes for your handler.

Caching, debug mode, and safe troubleshooting

HumHub uses Yii's caching layer to store compiled configuration, module metadata, and rendered fragments. On shared hosting the practical choice is file-based caching, which needs no extra services. The cache component is defined in configuration as FileCache and writes to protected/runtime/cache. When you install a module, change themes, or edit configuration and the change does not appear, the culprit is usually stale cache. Rather than deleting files blindly, use Administration → Settings → Advanced → Caching in the Admin panel and click Flush caches. If the panel itself is broken, you can safely empty the contents of protected/runtime/cache through File Manager; HumHub regenerates it on the next request.

Debug mode is controlled by the application environment. HumHub reads the HUMHUB_ENV constant, or you can set YII_DEBUG and YII_ENV. On a shared account the cleanest method is a small addition to protected/config/common.php or, for whole-request environment values, an SetEnv line in public_html/.htaccess:

SetEnv YII_DEBUG 1
SetEnv YII_ENV dev

Enable this only while diagnosing a specific fault. Debug mode exposes stack traces and slows the application, and leaving it on in production can leak file paths and configuration details to visitors. Once you have captured the error, remove the two lines and flush the cache. For ongoing diagnosis without exposing anything publicly, read protected/runtime/logs/app.log directly; it records exceptions, deprecation notices, and mail delivery attempts with timestamps.

Mail configuration follows the same pattern as other Yii applications: the mailer component lives in configuration and is managed under Administration → Settings → Mailing. If you are aligning SMTP authentication and DNS for reliable delivery, the same principles covered in our Akaunting SMTP delivery guide apply here, since both frameworks queue and send through an authenticated account rather than the local sendmail path. After any configuration edit, confirm success with a real page load and a fresh check of app.log rather than trusting a cached response, and always keep a downloaded copy of dynamic.php before you change it.