A blank page or an HTTP 500 response in Dolibarr almost never happens at random. The ERP sits on top of a stack of PHP version requirements, loadable extensions, a MySQL/MariaDB connection, a writable documents directory, and its own conf.php settings. When any one of those pieces drifts out of alignment, the web server either refuses to finish the request or PHP dies mid-execution and sends nothing useful to the browser. The symptom you see in the browser is deliberately vague for security reasons, so the real work is pulling the actual message out of the logs and Dolibarr's own debug facilities.
On Hostiso's Managed Cloud Shared Hosting you work entirely as an unprivileged account user. You cannot restart services, edit files under /etc, or touch the server MySQL configuration. That is not a limitation here, because every cause of a Dolibarr 500 that you can actually fix is reachable through cPanel Jupiter or DirectAdmin Evolution, the File Manager, phpMyAdmin, your PHP Selector, and two small text files: .htaccess and .user.ini. The sections below move from reading the evidence to fixing the three families of failure that produce the overwhelming majority of Dolibarr outages.
Finding the real error behind a blank page
The first mistake is trusting the browser. A white screen means PHP hit a fatal error while output buffering was active, so the half-built page was discarded. A 500 means LiteSpeed received a broken response or an invalid directive. Neither tells you why. The message you need is written to a log file, and on shared hosting there are two you can reach.
Start with the per-directory PHP error log. In cPanel open File Manager, navigate into your Dolibarr document root (commonly public_html or a subfolder like public_html/erp/htdocs), and look for a file named error_log. In DirectAdmin the same file appears in the directory where the failing script lives. Open it and read the last few lines. A typical fatal entry looks like this:
[09-Oct-2026 14:22:01 UTC] PHP Fatal error: Uncaught Error: Call to undefined function mb_substr() in /home/user/public_html/erp/htdocs/core/lib/functions.lib.php:412That single line tells you the mbstring extension is missing, which you can fix in the PHP Selector. If no error_log file exists, PHP logging may be suppressed. Create a .user.ini file in your Dolibarr htdocs directory and add:
display_errors = Off
log_errors = On
error_log = /home/user/public_html/erp/htdocs/php_errors.log
error_reporting = E_ALLReplace the path with your real home directory, then reload the failing page. LiteSpeed reads .user.ini within a few seconds (the refresh interval), so wait a moment before retrying. Keep display_errors off on a live site so visitors never see internal paths.
Dolibarr also keeps its own application log, which is far more useful for logic errors, database problems, and module failures than the raw PHP log. Log in to the Dolibarr back office, open Home > Setup > Logs (Debug), and set the logging level to Debug. Enable the File handler and note the target, which defaults to dolibarr.log inside your documents directory (for example documents/dolibarr.log, outside htdocs). When you can still reach the admin panel but a specific screen 500s, this log captures the SQL statement and the PHP trace that caused it.
Fixing PHP version and missing extension failures
The most frequent cause of a sudden Dolibarr 500 after a migration or an upgrade is a PHP version mismatch. Each Dolibarr release declares a supported range, and running it on a PHP build that is too new or too old produces fatal errors from removed functions or unparsable syntax. You control this per domain without any server access.
In cPanel open MultiPHP Manager, select the domain or subdomain running Dolibarr, and assign a supported version such as PHP 8.1 or 8.2 for current Dolibarr branches. In DirectAdmin the equivalent is Account Manager > PHP Selector, where you choose the version from the dropdown. After changing versions, always clear the browser and LiteSpeed cache and retest.
Missing extensions are the second common fatal. Dolibarr needs mysqli (or pdo_mysql), mbstring, gd, intl, curl, zip, and xml at minimum. PDF generation and Excel exports pull in more. In cPanel open Select PHP Version, switch to the Extensions tab, and tick the boxes for any extension named in your error log. DirectAdmin exposes the same list under the PHP Selector Extensions view. A line such as Call to undefined function curl_init() maps directly to the curl checkbox; imagecreatetruecolor() maps to gd.
Resource limits produce 500s that look like crashes. If the log shows Allowed memory size of 134217728 bytes exhausted or an execution timeout during a large import or PDF batch, raise the limits in .user.ini:
memory_limit = 512M
max_execution_time = 180
post_max_size = 64M
upload_max_filesize = 64MThese values are capped by your hosting plan, so if a setting does not take effect it has hit the account ceiling and the fix is a lighter operation or a plan review, not a bigger number. The same approach appears in our Flarum error diagnosis guide and applies identically to any PHP application.
Resolving .htaccess, permission, and config breakage
A 500 that appears on every single page, including the installer, usually originates in .htaccess rather than PHP. LiteSpeed rejects directives that belong only to full Apache modules the account does not expose. Open the .htaccess file in your Dolibarr htdocs directory and look for php_value or php_flag lines. Under PHP running as a CGI/FPM handler those lines throw an immediate 500. Move any such settings into .user.ini using the syntax shown above and delete them from .htaccess. A clean working file needs very little beyond the rewrite block Dolibarr ships with:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /erp/htdocs/
</IfModule>If you are unsure whether .htaccess is the culprit, rename it to .htaccess_off through File Manager and reload. If the 500 disappears, a directive inside was the problem and you can reintroduce lines in small groups until the offending one reveals itself.
File permissions trigger fatal errors when Dolibarr cannot read code or write to its documents tree. On shared hosting directories should be 755 and files 644; never use 777, which LiteSpeed's security layer may refuse to execute. In File Manager select the Dolibarr folder, choose Permissions, and correct anything that looks wrong. The documents directory must be writable by your user, and conf.php at htdocs/conf/conf.php should be 644.
That same conf.php is worth inspecting whenever errors reference database connectivity or a wrong URL. Check that $dolibarr_main_url_root matches the live domain, that $dolibarr_main_document_root points at the real absolute path, and that the database host, name, user, and password are current. A mistyped password here produces a fatal at every request. Verify the credentials independently by logging in to phpMyAdmin from cPanel or DirectAdmin and confirming the database exists and the user can open it. If the installer still runs because conf.php is empty or missing its lock, make sure the file htdocs/install/install.lock is present to keep the setup wizard closed on a production site.
Working through the logs first, then PHP version and extensions, then the configuration and permission layer resolves nearly every Dolibarr 500 you will encounter on shared hosting. The discipline that saves time is resisting the urge to change several things at once. Make one adjustment, reload the failing page, and read the log again so each fix is confirmed against real evidence rather than guesswork.