Phorum keeps its entire runtime configuration in a single PHP file rather than a database settings table, which makes environment changes both simpler and riskier than many modern forums. One misplaced semicolon or a stale database password in include/config.php takes the whole board offline with a blank page or a fatal connection error. On a Managed Cloud shared account you cannot touch MySQL globals, the PHP master config, or anything under /etc/, so every adjustment has to flow through the cPanel or DirectAdmin interface, the File Manager, phpMyAdmin, and the per-directory .user.ini and .htaccess files. The sections below walk through the configuration surface Phorum actually reads at runtime and how to modify each piece safely.

Understanding include/config.php and editing it safely

Phorum's database and core behavior live in include/config.php, located inside your forum's document root, for example /home/youruser/public_html/forum/include/config.php. The installer writes a $PHORUM array (older builds) or a set of $PHORUM['DBCONFIG'] keys that define the database server, name, user, password, table prefix, and the database layer. A typical connection block looks like this:

<?php
$PHORUM['DBCONFIG']['type']          = 'mysql';
$PHORUM['DBCONFIG']['server']        = 'localhost';
$PHORUM['DBCONFIG']['name']          = 'youruser_phorum';
$PHORUM['DBCONFIG']['user']          = 'youruser_phorum';
$PHORUM['DBCONFIG']['password']      = 'StrongPasswordHere';
$PHORUM['DBCONFIG']['table_prefix']  = 'phorum';
$PHORUM['DBCONFIG']['mysql_use_ft']  = true;

The safest way to open this file is cPanel's File Manager (Jupiter theme: Files → File Manager) or DirectAdmin's File Manager. Navigate to the include directory, highlight config.php, and use Copy to create config.php.bak before you change anything. Then choose Edit rather than downloading and re-uploading, which avoids line-ending corruption. When editing, preserve the exact quoting style already present and never leave a trailing ?> followed by whitespace or a blank line, because Phorum sends headers early and any stray output triggers a "headers already sent" warning or a white screen.

If the board goes blank immediately after an edit, the cause is almost always a syntax slip: a missing semicolon, an unescaped single quote inside a password, or a smart-quote pasted from a document. Passwords containing a ' or \ must be escaped ('pa\'ss') or the string terminates early. Restore the backup, re-edit carefully, and prefer generating a password without shell-sensitive characters when you create the MySQL user.

Fixing database settings and connection errors

A Phorum message like "Could not connect to the database" or a MySQL access-denied notice means the four credential values in config.php no longer match what the server expects. This frequently happens after a migration, a password reset, or an account rename where the cPanel username prefix changes. On shared hosting you cannot run GRANT or edit my.cnf; instead, reconcile the credentials entirely through the panel.

In cPanel open Databases → MySQL Databases. Confirm the exact database name and the user attached to it under "Current Databases" — both carry your account prefix, so the real name is something like youruser_phorum, not phorum. If you are unsure of the password, scroll to "Current Users," click the user, and set a new password; then copy that identical string into $PHORUM['DBCONFIG']['password']. Verify the user is actually granted to the database in the "Add User To Database" section with ALL PRIVILEGES. In DirectAdmin the equivalent is Account Manager → MySQL Management, where you can reset the password and confirm the database-user pairing.

Keep server set to localhost on nearly all Hostiso shared plans — the database runs on the same node and remote TCP hosts are not used for local forums. To prove the credentials independently of Phorum, log into phpMyAdmin from the panel; if it opens your database there, the login works and any remaining error points back to a typo in config.php. When you need to inspect or correct the table prefix, phpMyAdmin's left-hand table list shows the real prefix (for example tables named phorum_messages, phorum_users). Set table_prefix to whatever precedes _messages, without the trailing underscore that Phorum adds automatically.

If you are relocating the forum to a new domain, update any absolute URL stored in the Admin control panel under General Settings after the database connects, rather than hard-coding paths in config. The underlying idea mirrors how other PHP applications store serialized URLs — a problem covered in depth for another platform in CubeCart's domain replacement guide — but Phorum keeps its base URL as plain settings you can edit safely from the AdminCP.

Setting PHP limits and runtime options with .user.ini and the selector

Phorum itself is lightweight, but large attachments, bulk user imports, and avatar uploads push against PHP's default memory, upload, and execution limits. Because LiteSpeed on CloudLinux runs PHP in a per-user context, you adjust these values with the PHP Selector and a per-directory .user.ini file — never a global php.ini you do not own.

First confirm your PHP version. In cPanel go to Software → Select PHP Version (MultiPHP / PHP Selector); in DirectAdmin use Account Manager → Select PHP Version. Phorum 5.2 runs cleanly on PHP 7.4 and works on PHP 8.x with current patches, so pick a version your build supports and enable the mysqli and gd extensions there — gd is required for avatar resizing. The selector's "Options" tab exposes editable directives; changing memory_limit, upload_max_filesize, and max_execution_time there writes the values into your account automatically.

For directives the selector does not expose, or to keep settings version-independent, create a .user.ini in the forum root (public_html/forum/.user.ini):

memory_limit = 256M
upload_max_filesize = 32M
post_max_size = 40M
max_execution_time = 120
max_input_vars = 3000

Keep post_max_size larger than upload_max_filesize or multi-file attachment posts silently fail. Changes to .user.ini are cached for up to five minutes by default, so wait before testing or reload after the interval. To confirm the values took effect, create a temporary phpinfo.php containing <?php phpinfo(); in the forum root, load it once, read the "Local Value" column, then delete the file immediately so it is not exposed publicly.

Debug output, error logs, and cache directory settings

When Phorum shows a white screen instead of a readable error, the fastest diagnosis comes from your local error_log. LiteSpeed writes PHP fatals to an error_log file in the directory where the fault occurred, and cPanel's Metrics → Errors aggregates recent entries. Open File Manager, enable "Show Hidden Files" from Settings, and look for error_log inside the forum root; the final lines name the file and line number of the fault, which usually points straight back to a bad config.php edit or a missing extension.

To surface errors in a controlled way during troubleshooting, add temporary lines to .user.ini rather than editing Phorum's source:

display_errors = On
log_errors = On
error_reporting = E_ALL & ~E_DEPRECATED & ~E_NOTICE

Set display_errors back to Off the moment you finish, since visible PHP paths and queries help attackers. Phorum also honors a debug flag you can add to config.php as $PHORUM['DBCONFIG']['empty_search_table'] = true; only when advised, but the generally safe diagnostic toggle is simply watching the error log while reproducing the fault.

Phorum's file-based caching, when enabled, writes to the cache directory under the forum root. Confirm that folder is writable by your user (permissions 0755 on the directory, 0644 on files) using File Manager's "Change Permissions" dialog — do not use 0777, which CloudLinux may reject and which exposes the folder. If the AdminCP reports it cannot write cache, the usual cause is ownership drift after a restore; re-create the directory through File Manager so it inherits your account's ownership. Clearing stale cache is as simple as deleting the generated files inside that folder; Phorum regenerates them on the next request. After any configuration change, visit the AdminCP under Admin → Settings and let it re-read the live values so the board and config.php stay in agreement.