500 Internal Server Error on Customizer Usage

If you're seeing the 500 Internal Server error when using the OceanWP Customizer, the reason could be either due to various errors that can be identified with the help of the WordPress debug mode (such as plugin conflict, PHP version conflict, insufficient WordPress Memory Limit), or it could also be related to your server's configuration.

In order to check for a potential cause, first you need to enable the debug mode and check the error log.

Identifying potential issues using the WordPress debug mode

In order to enable the WordPress debug mode, you need to edit the wp-config.php file, which is located in your website's installation folder.

Enabling WordPress debug mode

By default, the WordPress debug mode is disabled, and the code for the debug mode is already included in the wp-config.php file:

// Enable WP_DEBUG mode
define( 'WP_DEBUG', false );

You can enable the debug mode by changing the value false to true, after which you need to save changes to the wp-config.php file.

After your changes, the piece of code should look like this:

// Enable WP_DEBUG mode
define( 'WP_DEBUG', true );

Of course, enabling the debug mode is insufficient since you're unable to actually see the errors in question, therefore you also need to enable the writing of the debug log.

Enabling the debug (error) log

In order to enable the debug (error) log population on your website, you need to either add the required line of code for it, simply change its value to true.

The code for the enabled debug log looks like this:

// Enable debug log population
define( 'WP_DEBUG_LOG', true );

The debug log piece of code is usually positioned right below the debug mode, so the entire code should appear similar to this:

// Enable WP_DEBUG mode
define( 'WP_DEBUG', true );
// Enable debug log population
define( 'WP_DEBUG_LOG', true );

After applying these modifications, you need to save changes to the wp-config.php file.

The debug (error) log is usually placed in the wp-content folder of your website's installation, as a textual file, and the usual name of the file is called debug ie. debug.txt or debug.log.

Once the debug file has been populated, you can preview it and send any information (or the entire log) to respective support techs.

However, enabling the debug mode and the debug log is not enough on its own. In order to identify the potential problems, you now need to replicate the issue so that the debug mode can start taking tracks of everything you're doing on your website.

Replicating issues in WordPress debug mode

In order for the WordPress debug mode to be able to identify potential problems and inform you about those via the debug log, you need to replicate the issue ie. perform the same actions that have caused an issue on your website.

In case of the 500 Internal Server Error while using the Customizer, you need to start the Customizer again and/or perform additional actions until you see the error on your end again.

Wait a few moments for the debug (error) log to populate then check it.

If the debug log is not there, or is completely empty or has absolutely no records in relation to the timestamps while operating the Customizer, then the nature of the problem is most likely related to some of your server configurations (hosting configurations).

Before getting to the server configuration values, we highly recommend you check further WordPress debug mode recommendations.

WordPress debug mode recommendations

The debug mode is a useful tool, however, when it's enabled, it's constantly running in the background, thus utilizing your website's resources and can contribute to your website's backend and frontend loading issues.

Therefore, it is essential to keep the debug mode disabled, unless you need to identify potential issues on your website, such as critical errors, white screens, visible server errors and similar.

The debug (error) log can contain quite of information, including various positives and pure notifications which do not harm your website in any way. Likewise, to keep the essential info separate from the rest, it is recommended that you clear the debug (error) log, ie. delete all previous content in it, before replicating the issue on your website.

Before clearing the debug log, you can always download it to your PC and keep the old version as a backup.

Depending on your hosting setup, you should be able to access and modify the wp-config.php file on your own, either using the File Manager through your hosting account panel, using sFTP, or directly from your website using plugins such as File Manager or similar.

If, for whatever reason, you're unable to access / edit the necessary files in order to enable / disable the debug mode and debug log, or even use plugins that would enable you to do that, or you're afraid to do it - contact your hosting support techs for assistance. Your website functioning properly and flawlessly is in their own best interest as well.

Identifying issues via ModSecurity server settings

As previously mentioned, if the debug (error) log is completely empty or contains no valid information on the potential cause of the 500 Internal Server Error on Customize usage, the issue might be on the server end, ie. related to ModSecurity settings.

ModSecurity is a web based firewall application (WAF, if you wish), supported by different web servers, such as Apache, Nginx, or IIS. ModSecurity (server firewall) serves to protect the entire server, including your website, against various attacks by utilizing various flexible rules.

The rule that could be preventing you from using the Customizer and triggering the 500 Internal Server Error is called SecResponseBodyLimit.

Default value of the SecResponseBodyLimit is usually 512kb (0.5MB), but some hosting providers can apply different default values based on their own setup.

So, the solution to this problem is getting in touch with your hosting provider support (unless you're hosting your own server) and asking them to increase the value of SecResponseBodyLimit rule to 1MB or more, if needed.

Which value is actually needed can be determined by the ModSecurity Error Response body too large value, which is something only your hosting support techs can see, so we are not going to bother you with the details.

Usually, ModSecurity options and settings are NOT available to you, for security reasons, and that is why you can handle this only by cooperating with your hosting provider support.

Why does the Customizer usage trigger ModSecurity

ModSecurity (server firewall) errors, especially those related to the SecResponseBodyLimit rule are quite common, even for non-WordPress website, because modern website pages and applications are quite different compared to those from 10 years ago.

As explained, these are server rules and not really related to your website's platform (WordPress or no WordPress), your WordPress themes (including OceanWP) or plugins.

In case of the Customizer, the issue is caused by the HTML size of the page where the Customizer is opening + the HTML size of the WordPress backend (aka the WP dashboard).

Likewise, the same error can be triggered with publishing or updating longer pages, longer blog posts, custom CSS and various other completely harmless operations, because the default value of the SecResponseBodyLimit rule is set to (too) low.

In short, this is not something you or us did wrong, it's just a server setting that requires tweaking and is easy to solve. Luckily, 99.9999% of all WordPress users will never experience this problem, because the default rules have been adjusted accordingly from the beginning.

We hope this document has helped you troubleshooting a potential issues, as well as learning something new.

In case of any debug (error) log content related to the OceanWP theme or OceanWP plugins which you're unable to understand, feel free to reach our support.