PeepSo runs as a WordPress plugin suite, so nearly every failure you will see surfaces through the WordPress and PHP execution layer rather than through a standalone application. When a community page returns a blank white screen or an HTTP 500 response, the underlying cause is almost always one of a handful of predictable conditions: a PHP fatal error triggered by a version mismatch, an exhausted memory limit while rendering an activity stream, a missing PHP extension that a PeepSo module depends on, or a corrupted .htaccess directive that LiteSpeed rejects. Because you are working from an unprivileged hosting account, the goal is not to restart services or edit global configuration, but to make the error visible, read the correct log, and correct the specific file or setting responsible.

The most important early step is to stop guessing. A white screen tells you almost nothing on its own, and the generic "There has been a critical error on this website" message that WordPress shows is deliberately vague to avoid leaking details to visitors. The real message lives in your logs. Everything below assumes your PeepSo site is installed under a document root such as /home/username/public_html/ and that you have access to cPanel Jupiter or DirectAdmin Evolution with File Manager, phpMyAdmin, and a PHP Selector or MultiPHP Manager.

Locating the real error in your logs

The fastest route to a root cause is the PHP error log that CloudLinux writes per account. On our LiteSpeed stack, PHP-generated fatals for a given site are usually written to an error_log file in the same directory as the script that failed. For a PeepSo activity page crash, check these locations in order using File Manager:

  • /home/username/public_html/error_log — the document-root log, most common for front-end fatals.
  • /home/username/public_html/wp-content/error_log — plugin-level fatals frequently land here.
  • /home/username/public_html/wp-content/plugins/peepso-core/error_log — PeepSo core faults.

In cPanel there is also a dedicated Errors icon under the Metrics section that shows the most recent web server error entries for your account, and in DirectAdmin the equivalent appears under System Info & Files → Error Log. A genuine PHP fatal looks like this:

[13-Sep-2026 14:22:07 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function mb_strlen() in /home/username/public_html/wp-content/plugins/peepso-core/classes/text.php:88

That single line tells you the failing file, the line number, and the missing function. A line like the one above points directly at a missing mbstring extension rather than a PeepSo bug. Contrast it with a memory failure:

PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in .../peepso-core/classes/activitystream.php

Read the log before changing anything. Note the timestamp so you know the entry matches the request you just made, since old entries accumulate and can mislead you.

Enabling WordPress debug output safely

When the account error log is empty or unhelpful, turn on WordPress debugging so PeepSo's own exceptions are captured to a controlled file instead of being shown to visitors. Open /home/username/public_html/wp-config.php in File Manager, right-click and choose Edit, and place these lines above the /* That's all, stop editing! */ comment:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

With WP_DEBUG_DISPLAY set to false, errors are written to /home/username/public_html/wp-content/debug.log instead of leaking onto the page. Reload the broken PeepSo page once, then open that log. PeepSo modules are namespaced clearly, so you will see traces referencing classes such as PeepSoActivityStream, PeepSoUser, or PeepSoMessages, which narrows the fault to a specific feature. If a recently installed PeepSo add-on such as Messages, Groups, or Photos appears repeatedly in the stack trace, that add-on is the suspect.

Once you have identified the cause, remove or comment out the debug lines. Leaving debug.log writable and growing on a production community site is both a performance and a disclosure risk, so revert the change the moment diagnosis is complete.

Fixing PHP version, extensions, and memory limits

PeepSo has firm PHP requirements, and a large share of 500 errors after an upgrade come from running an unsupported interpreter. Confirm your version in cPanel under MultiPHP Manager, or in DirectAdmin under PHP Selector → Select PHP Version. Modern PeepSo releases expect PHP 7.4 or newer, with 8.1 or 8.2 recommended; running PHP 8.3 against an outdated PeepSo build, or PHP 7.2 against a current one, produces exactly the kind of undefined function and syntax error, unexpected token fatals you saw earlier.

From the same PHP Selector screen, open the Extensions tab and confirm that mbstring, gd or imagick, curl, json, and mysqli are all enabled. PeepSo's avatar and photo processing depends on GD or Imagick, and its text handling depends on mbstring, so a disabled extension there maps one-to-one to the fatals in your log. Tick the missing box and save.

For memory exhaustion, you cannot edit php.ini globally, but you can raise limits for your account through the PHP Options (cPanel) or PHP Selector → Options (DirectAdmin) panel, or by creating a .user.ini file in your document root:

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

PeepSo activity streams with many media items are memory-hungry, and 256M resolves the majority of exhaustion crashes. Reinforce it inside WordPress by adding define( 'WP_MEMORY_LIMIT', '256M' ); to wp-config.php. Note that .user.ini changes can take a few minutes to apply because of PHP's file cache TTL, so wait before retesting.

Repairing .htaccess and isolating the failing plugin

If the log shows no PHP fatal but the server returns a raw 500 before WordPress even loads, suspect .htaccess. LiteSpeed honors Apache-style directives, but a malformed rule or a directive your account is not permitted to override will trigger a 500 immediately. Open /home/username/public_html/.htaccess, and confirm the WordPress block is intact and unmodified:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Remove any stray php_value lines that a plugin may have injected, since those belong in .user.ini on this stack and cause 500s inside .htaccess. To confirm the file is the culprit, rename it to .htaccess_bak in File Manager and reload; if the site returns, regenerate a clean copy by visiting Settings → Permalinks in the WordPress dashboard and clicking Save.

When logs point at PeepSo itself but you cannot reach wp-admin because it is also white-screening, isolate the plugin manually. In File Manager, rename /home/username/public_html/wp-content/plugins/peepso-core to peepso-core-off. WordPress deactivates any plugin whose folder it cannot find, so the site loads, you regain dashboard access, and you can confirm whether PeepSo or a theme conflict caused the crash. Rename it back, then reactivate through Plugins so PeepSo runs its clean activation routine. This same technique — the safe rename-and-reactivate pattern — also helps validate a fix after a version change, much like the staged approach we describe for bbPress safe upgrades and rollback. Work one change at a time, retest the exact URL that failed, and check the timestamp on each new log entry so you always know you are looking at the current request rather than a stale one.