Clientexec is a PHP billing and support platform that leans on a MySQL/MariaDB database, a set of required PHP extensions, and a writable cache directory. When any one of those pieces drifts out of alignment, the symptom you see in the browser is almost never descriptive: a blank white page, a bare HTTP 500 Internal Server Error, or a partially rendered admin panel that dies mid-request. The actual cause is recorded elsewhere, and the job of diagnosis is knowing which log holds the truth for a given failure mode. This walkthrough assumes an unprivileged hosting account on LiteSpeed with cPanel Jupiter or DirectAdmin Evolution, so every step uses account-level tools only.

Why Clientexec Fails Silently

Production Clientexec installs ship with PHP display errors turned off, which is correct for a live billing system that customers can see. The tradeoff is that a fatal error produces a white screen instead of a message. A white screen (WSOD) almost always means PHP hit a fatal error after it started executing: a missing class, a call to an undefined function from a disabled extension, or a memory exhaustion. An HTTP 500, by contrast, is frequently raised before PHP even runs your code — a malformed .htaccess directive, an invalid php_value line that LiteSpeed rejects, or a handler mismatch after a PHP version change in MultiPHP Manager.

Clientexec also has its own moving parts that mimic server errors. The application caches compiled Smarty templates under library/cache/ and writes runtime data there; if those directories lose write permission after a migration or a permission reset, the template engine throws a fatal during rendering. The config.php file at the document root holds the database credentials and the encryption key. A single mistyped value there produces a connection exception that surfaces as a blank installer redirect loop or a 500. Because these causes look identical in the browser, resist the urge to guess. Read the logs first, then act on what they say.

One more distinction matters on LiteSpeed. Directives that Apache tolerates inside .htaccess using php_value and php_flag are honored by LiteSpeed only when PHP runs as a LiteSpeed SAPI (lsphp), which is the default on Hostiso. If your account uses the CloudLinux PHP Selector with a per-user PHP build, those same limits belong in .user.ini instead. Putting PHP directives in the wrong file is a common source of the very 500 you are trying to fix, so match the mechanism to the handler before you add anything.

Reading the Right Logs Before Touching Anything

There are three log sources available to you, and each answers a different question. Start with the per-directory PHP error log, because Clientexec fatals land there. In cPanel Jupiter, open File Manager, navigate into the Clientexec document root (commonly public_html or a subfolder like public_html/billing), enable Settings → Show Hidden Files (dotfiles), and look for a file named error_log. The last lines carry a timestamp, the fatal message, and the exact file and line number, for example a message pointing at plugins/gateways/ or a memory limit hit inside the Smarty compiler.

If no local error_log exists, force PHP to create one. Add a .user.ini file in the Clientexec root with these lines, then reload the failing page to generate output:

; .user.ini in the Clientexec document root
display_errors = Off
log_errors = On
error_reporting = E_ALL
error_log = /home/USERNAME/public_html/billing/ce_error.log

Replace USERNAME and the path with your real account path, which you can read from the File Manager address bar. Keep display_errors off so customers never see stack traces; you are only redirecting errors into a file you can read. Note that .user.ini is cached by PHP for a few minutes, so wait or clear opcache via cPanel if the change does not take effect immediately.

The second source is the LiteSpeed/Apache error log surfaced in cPanel under Metrics → Errors, or in DirectAdmin under Advanced Features → Error Log. This view captures 500s that never reached PHP: rejected .htaccess directives, rewrite loops, and permission denials on the script itself. If Metrics → Errors shows a line mentioning Invalid command or .htaccess, the fault is a directive, not the application.

The third source is Clientexec's own diagnostics. Log in to the admin area and open Settings → General Settings → Debug (path admin/index.php?fuse=admin&controller=settings). Enabling debug writes verbose entries into the application log and shows SQL and exception detail for the next requests. Turn it off again the moment you finish, since it exposes internal query structure.

Fixing the Concrete Causes

Once the log names a cause, the repair is narrow. Here is how the most common Clientexec failures map to account-level fixes.

Fatal: allowed memory size exhausted. The Smarty compiler and PDF invoice generation are memory-hungry. Raise the limit for this account only. On LiteSpeed with PHP Selector, edit .user.ini:

memory_limit = 256M
max_execution_time = 120
post_max_size = 32M
upload_max_filesize = 32M

If your account instead honors .htaccess PHP directives, the equivalent is:

# Only if the account runs mod-style php via .htaccess
php_value memory_limit 256M
php_value max_execution_time 120

Never add both. If a php_value line itself triggers a 500 (visible in Metrics → Errors), your handler does not accept it — remove it and use .user.ini.

Fatal: Call to undefined function (missing extension). Clientexec needs curl, gd, mbstring, json, openssl, pdo_mysql, and zip. If a payment gateway or template throws an undefined-function fatal, a required extension is off. In cPanel go to Select PHP Version → Extensions, or in DirectAdmin open CustomBuild PHP Options / Select PHP Version, and tick the missing module. Reload the page; the fatal disappears if that was the gap.

500 from a stale handler after a PHP version change. Clientexec current releases expect PHP 8.1 or newer. If MultiPHP Manager was switched to a version the code rejects, you get an immediate 500 or a parse error in the log. Set the domain to a supported version in cPanel → MultiPHP Manager (select the domain, choose the version, Apply) or DirectAdmin → PHP Version Selector.

White screen from unwritable cache. If the log points at library/cache/ or a template compile path, fix permissions in File Manager: select the library/cache and any templates_c folders, choose Permissions, and set 0755 for directories and 0644 for files. Delete the stale compiled templates inside so Clientexec regenerates them cleanly.

Database exception. A log line about a failed connection or unknown database means config.php drifted. Open it in File Manager and confirm the host is localhost, the database name carries your cPanel prefix, and the user exists. Verify the credentials by logging in through phpMyAdmin; if login fails there too, reset the password under MySQL Databases and paste the new value into config.php. After any config edit, reload and re-check ce_error.log to confirm the exception is gone.

Work one change at a time and re-test after each, keeping the log open in a second tab. That discipline turns an opaque 500 into a short, traceable chain of cause and fix, all without ever needing root.