Oxwall sits on a combination of a PHP framework layer, a MySQL database, and a plugin architecture where any single misconfigured component can take the whole site down. When a page returns a blank white screen or an HTTP 500, the server is almost always refusing to render output because PHP hit a fatal condition, LiteSpeed could not parse a directive, or the application bootstrap failed before it reached the template engine. On a managed shared account you cannot inspect the global server logs, restart services, or touch /etc/, so diagnosis has to work entirely from your home directory, the control panel, and Oxwall's own debug facilities. The good news is that every failure Oxwall produces leaves a trace somewhere you can reach.

Before changing anything, decide which of three symptom classes you are facing. A fully blank page with a 200 status usually means PHP died with display_errors off and never printed the error. An explicit HTTP 500 usually points at a parse-level problem in .htaccess, a PHP memory or time limit, or a fatal thrown during include. An Oxwall-styled error page that says something like "An internal server error occurred" means the framework caught the exception itself and the detail is sitting in the application log. Matching the symptom to the right log saves hours of guessing.

Locating the right logs from your account

Oxwall writes its own application errors separately from the web server. The framework log lives inside the installation at ow_log/ relative to your document root (commonly public_html/ow_log/). Open cPanel File Manager or DirectAdmin's File Manager, browse into that folder, and sort by date. The newest file in that directory captures PHP exceptions, failed database queries, and plugin load failures with a timestamp and often a stack trace. This is the first place to look when you see an Oxwall-branded error page rather than a raw server 500.

The web server side logs the PHP fatals that kill a request before Oxwall can catch them. On LiteSpeed with CloudLinux, PHP writes an error_log file into whichever directory the failing script ran from. Look for error_log in public_html/ first, then inside subdirectories like public_html/ow_plugins/ if a specific plugin page is failing. In cPanel there is also a Metrics > Errors screen that aggregates the most recent web server errors for your domain, and it is the fastest way to catch a parse error in .htaccess because those never reach PHP at all. DirectAdmin exposes a similar view under Advanced Features > Error Log or within the per-domain logs section.

When the log files are empty or stale, the cause is almost always that PHP error logging is disabled for your account. You can force it on without root by creating or editing a .user.ini file in public_html/ containing a few directives, which LiteSpeed honors per directory:

; public_html/.user.ini
display_errors = Off
log_errors = On
error_log = /home/USERNAME/public_html/php_error.log
error_reporting = E_ALL

Replace USERNAME with your real account name, which you can read from the top of cPanel or from the home path shown in File Manager. Keep display_errors off on a live site so visitors never see raw paths or stack traces. Changes to .user.ini are cached, so wait up to five minutes or touch the file again before retesting. Once the log exists, reproduce the broken page and the fatal will land in php_error.log with a file name and line number.

Turning on Oxwall debug mode safely

Oxwall ships with a developer mode flag that converts caught exceptions into detailed on-screen output and disables aggressive caching that can hide the real cause. The switch lives in ow_includes/config.php at the root of your install. Open that file in File Manager's editor and look for the constant that controls development mode. Set it so that developer and debug output is enabled:

// ow_includes/config.php
define('OW_DEV_MODE', 1);
define('OW_PROFILER_ENABLE', false);

With dev mode active, Oxwall stops serving stale compiled templates and class maps, which matters because a surprising share of white screens come from a corrupted cache after a half-finished upgrade or a plugin that was deleted by hand. If enabling dev mode immediately restores the page, your real fix is clearing the generated cache rather than leaving debug on. Clear it by emptying the contents of ow_static/ generated subfolders and the ow_smarty/template_c/ compiled template directory through File Manager, leaving the folders themselves in place with their original permissions. After confirming the diagnosis, set OW_DEV_MODE back to 0 so the storefront does not leak internal detail or run slower than necessary.

If the config file itself is the problem, the symptom is a very early fatal naming config.php in the log. A common cause is a database credential that no longer matches because the account was migrated or the database user password was rotated. The host and socket are managed for you on shared hosting, so the value for the database host should normally stay localhost, and the user plus password must match exactly what is shown in cPanel's MySQL Databases screen. Correct them in config.php and the bootstrap will complete.

Isolating .htaccess, PHP version, and limit failures

A raw 500 with nothing in the PHP log almost always traces back to .htaccess. Oxwall's rewrite block is required for friendly URLs but a stray directive copied from an unrelated tutorial, or an php_value line that LiteSpeed rejects under your handler, produces an instant 500. Rename the file to htaccess.bak through File Manager and reload the site. If the error clears, the file is the culprit. Rebuild it with only the standard Oxwall rewrite rules and move any PHP tuning out of .htaccess and into .user.ini, since php_value and php_flag lines are frequently disallowed and throw 500s on LiteSpeed. For a deeper treatment of the rewrite rules themselves, the companion article on Oxwall friendly URLs covers the canonical block in detail.

When the log shows Allowed memory size exhausted or Maximum execution time exceeded, raise those limits within your account rather than touching server config. Add the following to public_html/.user.ini:

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

The max_input_vars line matters specifically for Oxwall admin pages that save large plugin or permission forms, where a low default silently truncates POST data and triggers odd fatals. If a fatal names a missing function such as mbstring, gd, curl, or intl, the active PHP build lacks that extension. Open Select PHP Version (cPanel) or PHP Selector (CloudLinux/DirectAdmin), confirm you are on a supported branch for your Oxwall release, and tick the missing extensions in the extensions tab. Switching PHP branches also resolves the class of fatals where newer PHP removes a function an older Oxwall core still calls; dropping to the highest branch your version supports is often the complete fix.

Work one layer at a time: confirm the log source, enable the matching debug facility, change a single variable, and retest. A disciplined pass through the application log, the PHP error_log, the .htaccess rename test, and the PHP Selector extension check will identify nearly every Oxwall 500 or white screen without ever needing shell or root access.