phpBB keeps its runtime configuration in two very different places, and confusing them causes most of the environment problems support tickets we see. The file config.php at the forum root holds static connection details written once during installation: database host, name, user, password, table prefix, and the ACM (cache) driver. The live tunable settings that control sessions, cookies, server URL, and feature behavior live in the phpbb_config database table and are edited through the Administration Control Panel. When a board throws a white screen, a database error, or refuses to load after a host migration, the fix almost always involves reconciling these two layers without root access.

On Hostiso Managed Cloud Shared Hosting you work as an unprivileged user, so you cannot restart services, edit php.ini under /etc, or run SET GLOBAL in MySQL. Everything below is done through cPanel Jupiter or DirectAdmin Evolution, the File Manager, phpMyAdmin, a per-directory .user.ini, and the phpBB ACP itself. That is enough to resolve the vast majority of configuration and environment issues on a forum.

Reading and repairing config.php database settings

When phpBB cannot reach its database it typically shows "General Error" with a message such as "Could not connect to the database" or "Unable to connect". This points directly at the credentials inside config.php. Open cPanel File Manager (or DirectAdmin's File Manager), navigate to your forum's document root (commonly /home/username/public_html/ or a subfolder like /forum/), and view config.php. The important lines look like this:

<?php
$dbms = 'phpbb\\db\\driver\\mysqli';
$dbhost = 'localhost';
$dbport = '';
$dbname = 'username_phpbb';
$dbuser = 'username_forum';
$dbpasswd = 'your-db-password';
$table_prefix = 'phpbb_';
$phpbb_adm_relative_path = 'adm/';
$acm_type = 'phpbb\\cache\\driver\\file';
@define('PHPBB_INSTALLED', true);

On shared hosting $dbhost should almost always be localhost, not a remote IP. The database name and user carry your account prefix (username_) because cPanel and DirectAdmin add it automatically when you create them. The most common breakage after a migration or password reset is a mismatch between $dbpasswd and the actual MySQL user password. To confirm the credentials, open phpMyAdmin from your panel and verify the database and tables exist, then re-set the password: in cPanel use MySQL Databases > Current Users to set a new password for the user, and in DirectAdmin use Account Manager > MySQL Management. Copy that exact password back into $dbpasswd and save.

If you restored a backup from another host, also check $table_prefix. phpBB will report missing tables if the prefix in config.php does not match the real table names shown in phpMyAdmin. Edit the file to match, never rename the tables blindly. Keep config.php permissions at 644 so the web server can read it but it is not world-writable, and remember the install/ directory must be absent or renamed for the board to boot — phpBB deliberately refuses to run while it exists.

Adjusting PHP version and limits without root

phpBB 3.3.x requires PHP 7.1.3 or newer and runs cleanly on PHP 8.1 and 8.2. Picking the version is done in the panel, not on the command line. In cPanel open Software > Select PHP Version (MultiPHP / PHP Selector); in DirectAdmin open Account Manager > Select PHP Version. From the same screen you can toggle extensions — phpBB needs mysqli (or pdo_mysql) and benefits from gd for CAPTCHA images and zlib for gzip output.

Resource limits that cause failures during big operations — importing a large forum, running database updates, or uploading attachments — are raised through CloudLinux PHP Selector's "options" tab or, more reliably per-folder, with a .user.ini file placed in your forum root. Create or edit .user.ini alongside config.php:

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

The max_input_vars value matters when saving ACP forms with many permission checkboxes; too low a value silently drops settings. Because .user.ini is cached, changes take effect after the user_ini.cache_ttl window (default 300 seconds) rather than instantly — wait a few minutes or touch the file again. Confirm the active values by creating a temporary phpinfo.php file containing <?php phpinfo();, loading it once, then deleting it. Note that attachment size limits also live inside phpBB itself under ACP > Posting > Attachment settings, so the PHP limit and the board limit both need to be high enough.

Enabling debug mode and fixing the board URL

A blank white page or a vague "General Error" with no detail is phpBB hiding exceptions in production mode. To see the real cause, temporarily enable debug output by adding these lines to config.php just before the closing PHPBB_INSTALLED define:

@define('DEBUG', true);
@define('PHPBB_DISPLAY_LOAD_TIME', true);

With DEBUG on, phpBB prints the actual PHP error and stack trace, which usually names the file and line involved. Pair this with your account's PHP error_log. Set logging in .user.ini so messages land in a file you can read:

log_errors = On
error_log = /home/username/public_html/php_errors.log
display_errors = Off

Reproduce the failing page, open the log in File Manager, and read the newest lines at the bottom. Always remove the DEBUG define and delete the log once resolved, because debug output can expose paths and query structure to visitors.

Many "logged out immediately" or "redirected to wrong domain" complaints come from a stale server URL stored in the database, not config.php. Fix these in ACP > General > Board settings > Cookie settings and Server settings, where you set server_protocol to https://, the correct server_name, and matching cookie domain. If the ACP is unreachable because of the bad URL, edit the values directly in phpMyAdmin: open the phpbb_config table, find server_name, server_protocol, cookie_domain, and force_server_vars, and correct them there. These session and cookie behaviors are closely tied to HTTPS enforcement, which is covered in our phpBB security hardening article.

Clearing and configuring the cache

phpBB compiles templates and stores configuration, permissions, and language data in cache/. After editing config.php, changing permissions, or updating styles, stale cache files cause settings to appear to "revert" or layouts to break. Clear it from ACP > General > Purge the cache. If the ACP itself is broken, delete the contents of the cache/production/ folder in File Manager — remove the files inside, not the folder, and leave .htaccess and index.htm in place. phpBB rebuilds the cache automatically on the next page load.

The cache driver is set by $acm_type in config.php. The default phpbb\cache\driver\file is correct for shared hosting because it needs no services you cannot control. Avoid switching to redis or memcached drivers unless your plan explicitly provides those backends, since on a managed shared account you cannot start or configure those daemons and the board will fail to load. If the cache/ directory ever becomes unwritable — common after a restore that changes ownership — phpBB throws "Unable to write to cache". Verify the folder is 755 and its files 644 using File Manager's permissions dialog, which resolves most write failures without any server-level intervention.