Fix: Site Crash, HTTP 500, or HTTP 502 After Activating a PHP Snippet in Woody

This article explains how to recover your site when it shows an HTTP 500 error, an HTTP 502 Bad Gateway error, a blank screen, or a WordPress critical error caused by a PHP snippet in Woody, and how to test PHP snippets safely to prevent the problem. The error can appear as soon as you save or activate the snippet, or later, at the moment the snippet actually runs.

Troubleshooting: Site crash, HTTP 500, HTTP 502, or critical error caused by a PHP snippet

If your site shows an HTTP 500 error, an HTTP 502 Bad Gateway error, a WordPress critical error, or a blank screen and a Woody PHP snippet is involved, the usual causes are:

• The snippet contains a PHP error, such as invalid syntax or a call to a function that does not exist.
• The snippet runs code that should not run on every page load. This is most common when Snippet Scope is set to Run everywhere.
• The snippet conflicts with your theme or another plugin at the point where it runs.

The same snippet failure does not always produce the same error page. If your site runs behind Nginx or another proxy, a snippet that crashes the PHP process or uses up all the memory available to it can return HTTP 502 Bad Gateway instead of an HTTP 500 error or the usual WordPress critical error screen. The cause and the recovery steps are the same, so continue with the steps below.

Whatever the cause, Woody Safe Mode temporarily stops Woody snippets from running so you can regain access to your WordPress admin area and fix the problem. Safe Mode does not delete, edit, or overwrite your snippets.

1. Enable Safe Mode:
   • If Woody shows an error notice after saving the snippet, click Enable Safe Mode.
   • If the normal Woody screen will not load, go to https://your-site.com/wp-admin/?wbcr-php-snippets-safe-mode while signed in as an administrator.
   • If that address also returns an error and you cannot reach the admin area at all, deactivate Woody by renaming its folder in /wp-content/plugins/ over SFTP or in your host's file manager. Once the admin area loads, rename the folder back, reactivate the plugin from Plugins, and open the Safe Mode address straight away so you can edit the snippet without it running.
2. Open Woody snippets and look for the most recently created, edited, or activated PHP snippet.
3. Deactivate that snippet.
4. Fix the code or delete the snippet if you no longer need it.
5. After the site loads normally again, click Disable Safe Mode in the Woody admin notice and test the affected page again.

📝 Info: Safe Mode is a recovery tool. It temporarily disables Woody snippet execution so you can get back into the admin area and correct the broken code.

Critical error that appears when the snippet runs, not when you activate it

A snippet does not always fail at the moment you save it. When Snippet Scope is set to Where there is a shortcode, the snippet only runs where you place its shortcode, so an error inside it stays hidden until something on your site triggers it. A common example is a page that loads normally but returns a critical error when you submit a form on it.

In this situation, the most recently edited snippet is not necessarily the one at fault, so identify the snippet from the error log instead of by date:

1. Reproduce the error by repeating the exact action that triggers it, such as submitting the same form.
2. Open /wp-content/debug.log on your server and find the newest PHP Fatal error or Uncaught entry. If the file does not exist, enable WordPress debug logging first, then reproduce the error again. The same details also appear in your host's PHP error log and in the error email WordPress sends to the site administrator. Web server logs usually contain unrelated notices as well, such as requests for missing .well-known files, so ignore those and read only the newest PHP Fatal error or Uncaught entry.
3. Read the file path and line number in that entry to work out which snippet ran. Woody executes snippet code on your behalf, so the trace points back to the plugin rather than to a theme or plugin file of your own.
4. Open that snippet, deactivate it, and review its code. Enable Safe Mode first if the error blocks access to your WordPress admin area.
5. If the snippet content includes shortcode syntax in square brackets and you have turned on Execute Shortcodes in Snippets in Woody snippets > Settings, turn that setting off temporarily and repeat the triggering action. That setting makes the plugin process shortcodes embedded in snippet content, so disabling it tells you whether shortcode processing is involved in the failure.

Verify the fix

After you change or deactivate the snippet, repeat the exact action that caused the error, such as submitting the same form again. Confirm that the page now loads instead of returning an HTTP 500 or HTTP 502 error. Then check /wp-content/debug.log once more and confirm that no new PHP Fatal error entry was added. Only disable Safe Mode after the triggering action completes without a new error.

Testing PHP snippets safely

Before you activate a new PHP snippet on a live site:

• In Woody snippets > Settings, disable Auto-activate New Snippets so new snippets stay inactive until you are ready to test them.
• Prefer Where there is a shortcode over Run everywhere when the code only needs to appear in a specific post, page, or widget area.
• Review the snippet first, then activate it manually only after you are ready to test it.
• Create a fresh backup before adding complex or experimental PHP code.
• In Woody snippets > Settings, enable Enable Error Email Notifications and confirm the Error Notification Email is correct.

After you activate the snippet, test the exact page where it should run first. If the page loads normally and Woody does not report a new error, you can keep the snippet active.

⚠️ Warning: Themeisle support can help you use Woody features and Safe Mode recovery steps, but writing or debugging custom PHP snippets is outside standard support.