Flarum is a lean, modern forum built on Laravel components, Composer-managed dependencies, and a client-side JavaScript interface. That architecture produces clean, fast forums, but it also means a single mismatched PHP version, an exhausted memory limit, or one incompatible extension can take the whole site down with nothing more than a blank page. On a managed shared account you cannot restart services or edit server configuration, so diagnosis depends entirely on reading the correct logs and using the debug facilities Flarum ships with. The sections below walk through where failures surface and how to resolve them using cPanel Jupiter, DirectAdmin Evolution, File Manager, phpMyAdmin, and Flarum's own storage logs.
Why Flarum Shows a White Screen or HTTP 500
A white screen almost always means PHP hit a fatal error and either stopped before sending output or suppressed the message for security. An HTTP 500 is the same class of problem reported by LiteSpeed when PHP exits abnormally or when an .htaccess directive is rejected. Flarum keeps most of its interesting detail out of the browser on purpose, so the visible symptom is deliberately vague. The real cause lives in two places: the server-level PHP error log and Flarum's application log under storage/logs/.
The most common triggers on shared hosting fall into a short list. The PHP version selected in cPanel's MultiPHP Manager or DirectAdmin's PHP Selector may be below Flarum's minimum (recent releases require PHP 8.1 or newer). A required PHP extension such as gd, mbstring, dom, json, curl, or fileinfo may be disabled. The memory_limit may be too low for Composer autoloading and extension boot. Or a third-party extension that worked on the previous Flarum version now throws a fatal error during the boot sequence, which halts the entire application because Flarum loads every enabled extension on every request.
Before changing anything, confirm which domain document root serves the forum. Flarum's web root is the public/ directory inside the installation, not the installation root. If the domain points at the wrong folder you will see raw PHP, a 403, or a 500 regardless of the application state. In cPanel check Domains for the document root; in DirectAdmin check Domain Setup. The path should end in /public, for example /home/username/forum/public.
Turning On Debug Mode and Reading the Right Logs
Flarum's configuration lives in config.php at the installation root (one level above public/). Open it with File Manager and locate the debug key. Set it to true temporarily so the browser displays the actual exception and stack trace instead of a blank page:
<?php return array (
'debug' => true,
'database' => array ( ... ),
'url' => 'https://forum.example.com',
'paths' => array ( ... ),
);Reload the forum and the error class, message, and file path usually appear immediately. This is the fastest way to identify a missing extension ("Class not found") or a version problem ("requires PHP >= 8.1"). Return debug to false the moment you finish, because debug mode exposes file paths and internal details that should never be public.
If the page is still blank with debug enabled, PHP is failing before Flarum can render anything, which points at the PHP layer rather than the application. Check Flarum's own log at storage/logs/flarum.log using File Manager's view or download option. Each entry is timestamped and includes the full stack trace, so match the error time to your test reload. The server PHP error log complements this. In cPanel open Metrics → Errors, or use File Manager to read the error_log file that appears in the public/ directory or the account root. In DirectAdmin the equivalent sits under the domain's logs. These server logs capture failures that happen so early that Flarum never gets a chance to write to its own log.
Read logs from the bottom up, since the newest lines are last. A line such as PHP Fatal error: Allowed memory size of 134217728 bytes exhausted tells you to raise memory_limit. A line referencing Call to undefined function imagecreatetruecolor() means the gd extension is off. A line naming a specific vendor path like vendor/acme/flarum-ext-widget/ points straight at the extension responsible.
Correcting PHP Version, Extensions, and Resource Limits
When the logs point at the PHP environment, fix it through the panel rather than touching any server file. In cPanel open MultiPHP Manager, select the forum's domain, and set the PHP version to one Flarum supports (8.1, 8.2, or 8.3 depending on your release). In DirectAdmin open PHP Selector under the Extra Features section or the Select PHP Version tool on CloudLinux accounts, and choose the matching version. After switching, reload the forum; a surprising number of 500s vanish here alone because the account was defaulted to an older interpreter.
To enable missing extensions, stay in the PHP Selector (CloudLinux) or cPanel's Select PHP Version → Extensions tab. Tick gd, mbstring, dom, curl, fileinfo, json, pdo_mysql, and tokenizer. These cover Flarum's documented requirements and the common extension dependencies. Save, then retest.
Memory and execution limits belong in a .user.ini file placed in the public/ directory, which LiteSpeed and PHP-FPM read per-site without any server-wide change. Create or edit it with File Manager:
memory_limit = 256M
max_execution_time = 120
upload_max_filesize = 32M
post_max_size = 34MChanges to .user.ini are cached and can take a couple of minutes to apply; wait before concluding they did not work. Verify the active values by creating a temporary info.php containing <?php phpinfo(); in public/, loading it once, then deleting it immediately so configuration details are not left exposed.
One more frequent culprit is the .htaccess file inside public/. Flarum ships a specific set of rewrite rules, and a merge conflict or a stray directive your host does not permit will return an instant 500. Compare your file against Flarum's shipped .htaccess and remove anything you added manually. A minimal safe front-controller block looks like this:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^ index.php [L]
</IfModule>Recovering From a Broken Extension or Corrupt Cache
Because Flarum boots every enabled extension on each request, one incompatible add-on can lock you out of both the forum and the admin panel. The good news is that extension state lives in the database, so you can disable the offender without SSH. Open phpMyAdmin from cPanel or DirectAdmin, select the Flarum database, and look at the settings table. Find the row where key is extensions_enabled. Its value is a JSON array of enabled extension IDs. Edit that row, remove the suspect extension's entry (keep the JSON valid, no trailing commas), and save. Reload the forum and the application should boot with the remaining extensions.
After disabling anything, clear Flarum's compiled cache, which often holds stale references that keep throwing errors even after the real cause is fixed. The cache lives in storage/cache/. Using File Manager, delete the contents of storage/cache/ and the file storage/formatter/ cache if present, but leave the folders themselves in place. Flarum regenerates these on the next request. If you have access to the admin dashboard, the same effect is available under Administration → Dashboard where the clear-cache control sits, but direct deletion is the reliable path when the dashboard itself is unreachable.
If you recently ran an upgrade and the whole site is down, the mismatch is usually between the installed package versions and the enabled extensions. Restore the pre-upgrade config.php, the database, and the installation directory from your backup, then upgrade one extension at a time while watching storage/logs/flarum.log. This staged approach isolates exactly which component breaks. The same discipline applies to database repair: if logs show table errors, use phpMyAdmin's Operations → Repair table on the affected tables rather than any global command. For broader guidance on diagnosing similar server-level PHP failures, the osCommerce error diagnosis walkthrough covers overlapping log-reading techniques that transfer directly to Flarum.
Once the forum loads cleanly, confirm debug is set back to false in config.php, remove any temporary info.php, and re-enable extensions one by one through the admin panel so you can catch a reintroduced conflict immediately. Keeping a note of which PHP version and extension set produced a stable forum turns the next incident into a five-minute comparison rather than a blind hunt.