ClipBucket is a PHP video-sharing platform that leans heavily on specific PHP extensions, external encoder binaries, and a MySQL schema that expects particular settings. When it breaks on a LiteSpeed/CloudLinux shared account, the symptom is usually one of three things: a bare HTTP 500 page, a completely white screen with no text, or a fatal PHP error printed mid-page. These all trace back to a small set of causes, and each leaves a fingerprint in a log you can read without root access. The work below assumes you are an unprivileged hosting user working through cPanel Jupiter or DirectAdmin Evolution, so every fix uses the panel UI, File Manager, phpMyAdmin, .htaccess, or .user.ini.

Finding the real error before touching anything

A 500 or white screen is a generic symptom, not a diagnosis. ClipBucket (built on the legacy CodeIgniter-style structure) hides the actual PHP fatal error unless display is enabled or the log is consulted. Never guess; read the log first. On a managed LiteSpeed account, PHP errors land in a per-directory error_log file written by the PHP handler. Open cPanel File Manager and browse to your document root, typically /home/USER/public_html, and look for a file literally named error_log. Scroll to the bottom and read the most recent timestamped lines. In DirectAdmin the same file appears in the site's home directory, and the panel also exposes a combined view under Metrics or System Info depending on the Evolution skin.

cPanel users also have the Errors interface (Metrics section), which shows the Apache/LiteSpeed-level error stream for your account. That view is where you see FastCGI timeouts, Premature end of script headers, and .htaccess syntax rejections that produce a 500 before PHP ever runs. If the Errors page is empty but the page is still blank, the fault is almost certainly inside PHP and you need the local error_log instead.

To force ClipBucket to surface the message on screen while you debug, create or edit a .user.ini file in public_html with these lines, then wait up to five minutes for the PHP handler to reload the file:

display_errors = On
display_startup_errors = On
log_errors = On
error_reporting = E_ALL
error_log = /home/USER/public_html/cb_error.log

ClipBucket itself also carries a debug switch. In older 2.x and the 4.x/5.x branches, open includes/config.inc.php (or upload/includes/config.inc.php depending on the install layout) through File Manager and confirm whether a constant such as DEBUG or an error-reporting line is suppressing output. Turn display back off the moment you have captured the message, since leaving stack traces visible exposes database paths to the public.

Missing extensions and version mismatches

The single most common cause of a ClipBucket white screen on a fresh install or after a server PHP upgrade is a missing or disabled PHP extension. ClipBucket requires mysqli (not the ancient mysql_* functions), gd for thumbnail generation, curl, mbstring, json, and exif. If any of these is absent, a call like mysqli_connect() throws a fatal Call to undefined function and the page dies silently. The error_log entry looks like:

PHP Fatal error:  Uncaught Error: Call to undefined function mysqli_connect() in /home/USER/public_html/includes/dbconnect.php

Fix this through the PHP version and extension controls rather than any server command. In cPanel open Select PHP Version (the MultiPHP / PHP Selector tool). First confirm the version: ClipBucket 4.x runs cleanly on PHP 7.2–7.4, while 5.x tolerates PHP 7.4 through 8.0. Running ClipBucket on PHP 8.1+ frequently triggers fatals because of removed functions and stricter type handling, so if a server-wide upgrade just happened, set your domain back to 7.4 from the version dropdown. Then switch to the Extensions tab and tick mysqli, gd, curl, mbstring, exif, fileinfo, and zip. In DirectAdmin the equivalent lives under PHP Selector inside CustomBuild's user interface, with the same extension checklist.

Two deprecations cause ClipBucket fatals specifically on newer PHP. The removal of create_function() and the magic-quotes family breaks older 2.x code, and each() removal breaks certain plugin loops. If you cannot change the code and the panel only offers PHP 8.x, staying on the oldest available 7.x line is the practical path on shared hosting. For a broader walkthrough of isolating these faults, our Piwigo error diagnosis guide covers the same log-reading method applied to a different PHP application.

.htaccess rejections and resource-limit 500s

When the fault is a 500 that appears instantly, before any ClipBucket output, the usual culprit is the .htaccess file in public_html. ClipBucket ships rewrite rules for pretty URLs, and a rule that references an Apache module the LiteSpeed account does not expose, or a stray php_value directive, will produce a 500 immediately. LiteSpeed reads php_value lines, but a malformed one such as a bad memory_limit string still errors out. Test by temporarily renaming the file to htaccess.bak in File Manager and reloading the site. If the 500 clears, the file is the problem. Rebuild a minimal working version:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?/$1 [L]

Do not place PHP tuning values in .htaccess on this platform. Put them in .user.ini instead, which the PHP handler honors per directory. ClipBucket uploads and encoding jobs frequently die halfway with a blank player or a truncated 500 because PHP ran out of memory or wall-clock time. The log entry reads Allowed memory size of N bytes exhausted or Maximum execution time of 30 seconds exceeded. Raise the ceilings within your plan's allowance using .user.ini:

memory_limit = 256M
max_execution_time = 300
max_input_time = 300
upload_max_filesize = 512M
post_max_size = 512M

These values are capped by the limits your hosting plan enforces, so if the panel's Select PHP Version Options tab shows a lower maximum, that figure wins. The Options tab is also the cleanest place to set these without a file, since the panel validates the input and prevents the typos that cause fresh 500s.

Encoding failures deserve a separate note. ClipBucket shells out to ffmpeg and mencoder for transcoding. On shared hosting those binaries are often unavailable and exec()/shell_exec() may be disabled by the disabled_functions list. The upload completes but the video never processes, and the conversion queue logs a failure rather than a PHP fatal. Check the ClipBucket AdminCP under Tool Box → Manage Conversion / Server Settings to confirm the detected paths, and verify whether exec is allowed by reviewing the Select PHP Version Options list. If exec is blocked by the platform, transcoding cannot run on that account regardless of configuration.

Database connection faults and corrupted tables

A ClipBucket page that loads partially and then halts, or shows Error establishing a database connection, points at the MySQL layer. Open includes/config.inc.php and confirm the four connection constants match the database you actually created in cPanel's MySQL Databases tool. On shared hosting the database name and user are prefixed with your account name, for example cbuser_videos and cbuser_cbadmin; a missing prefix is the classic migration mistake. Also confirm the host is localhost, not a remote IP, since shared accounts connect over the local socket.

When credentials are correct but queries still fail intermittently, suspect a crashed MyISAM table, which ClipBucket uses heavily for its video and comment tables. The error_log shows Table './cbuser_videos/video' is marked as crashed. Repair it without any shell: open phpMyAdmin from the panel, select the database, tick the affected tables, and choose Repair table from the With selected dropdown at the bottom of the table list. For the same tables you can run Check table first to confirm the damage. If a repair reports success but the error returns under load, the table is accumulating corruption from a different cause such as hitting the account's disk quota or inode limit, which you can verify in the cPanel statistics sidebar before anything else.

Finally, keep display of errors switched off once the investigation ends. Delete the display_errors lines from .user.ini, keep log_errors on so future faults are still captured in your private log, and restore the original .htaccess if you renamed it. With the log as your starting point, nearly every ClipBucket 500 resolves to one of these four categories, and all of them are fixable from the hosting panel without ever needing root.