BugWP logo BugWP
Back to Community
Home / Community / General

Troubleshooting: Why Sucuri's wp-includes Hardening Breaks Your WordPress Visual Editor

22 threads Sep 7, 2025

Content

Many WordPress users rely on the 'Sucuri Security – Auditing, Malware Scanner and Security Hardening' plugin to improve their site's security. A common and effective hardening measure is to Restrict wp-includes access, which blocks public access to PHP files in the wp-includes directory. However, a well-documented side effect is that this can break the TinyMCE visual editor on post and page edit screens.

What's the Problem?

When you activate the "Restrict wp-includes access" feature, the plugin creates an .htaccess file inside your wp-includes folder. This file contains rules to deny access to all .php files. Crucially, it also tries to create exceptions for two specific files required for WordPress to function correctly:

  • wp-tinymce.php: Required to load the TinyMCE visual editor.
  • ms-files.php: Required for file handling on WordPress Multisite installations.

Users will know they are affected if they see a blank white area in the post editor, cannot switch between the 'Visual' and 'Text' tabs, and find console errors in their browser like:

  • Failed to load resource: the server responded with a status of 403 (Forbidden) for wp-includes/js/tinymce/wp-tinymce.php
  • Uncaught ReferenceError: tinymce is not defined

Why Does This Happen?

Based on community reports and analysis, the conflict arises for a few key reasons:

  1. Apache Rule Precedence: The generated .htaccess file uses both a <FilesMatch> rule to block all .php files and separate <Files> rules to allow wp-tinymce.php and ms-files.php. On some server configurations (particularly older Apache 2.2 or mixed environments), the deny rule can unintentionally override the allow rules, blocking access to the critical editor file.
  2. Outdated File Reference: The exception rule was written for a file (wp-tinymce.php) that may have been moved or changed in newer WordPress versions, making the rule ineffective.
  3. Multisite Complexity: The issue is reported to be more prevalent on WordPress Multisite installations, where the interaction between the rules for ms-files.php and wp-tinymce.php can be more complex.
  4. Nginx Configurations: For sites running on the Nginx web server, the plugin provides code snippets for manual configuration. These snippets initially lacked a specific exception for the wp-tinymce.php file, causing it to be blocked.

How to Fix the TinyMCE Editor Conflict

Here are the most common and effective solutions, starting with the simplest.

Solution 1: Use the Plugin's Built-in Whitelist Tool (Recommended)

Newer versions of the Sucuri Security plugin include a tool to whitelist specific PHP files that are being incorrectly blocked.

  1. In your WordPress dashboard, go to Sucuri Security → Hardening.
  2. Find the section for "Restrict wp-includes access" and click View Whitelisted Files.
  3. Use the tool to add wp-tinymce.php to the whitelist. This tells the hardening rules to explicitly allow access to this file.

This is the cleanest solution as it maintains security while fixing the editor functionality.

Solution 2: Manually Edit the .htaccess File

If the whitelist tool is not available or does not work for your setup, you can manually edit the .htaccess file in your wp-includes directory. The goal is to ensure the allow rules for the critical files use the correct, modern syntax that takes precedence.

Find this code in wp-includes/.htaccess:

<Files wp-tinymce.php>
  Allow from all
</Files>
<Files ms-files.php>
  Allow from all
</Files>

Replace it with this updated code:

<Files wp-tinymce.php>
  Allow from all
  Require all granted
</Files>
<Files ms-files.php>
  Allow from all
  Require all granted
</Files>

Adding Require all granted ensures the rule is compatible with Apache 2.4 and will properly override the deny rule. Always back up the .htaccess file before making changes.

Solution 3: For Nginx Users

If your site runs on Nginx and you used the plugin's suggested configuration, you need to add an explicit exception for the TinyMCE file. Add a location block to your Nginx server configuration before the rule that blocks PHP files in wp-includes.

# Allowing TinyMCE only
location = /wp-includes/js/tinymce/wp-tinymce.php {
        allow all;
        # Include your standard PHP handling directives here (fastcgi_pass, etc.)
        fastcgi_pass unix:/var/run/php5-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;
}

# Blocking other PHP files in wp-includes
location ~* /wp-includes/.*.php$ {
        deny all;
}

Solution 4: Temporary Reversion

If you need an immediate fix and are not comfortable editing server files, you can temporarily revert the hardening.

  1. Go to Sucuri Security → Hardening.
  2. Find the "Restrict wp-includes access" option.
  3. Click the Revert Hardening button.

This will remove the .htaccess file and restore the visual editor. Remember that this slightly reduces your site's security, so consider it a temporary measure until you can implement a more permanent solution.

Conclusion

The conflict between wp-includes hardening and the visual editor is a known issue that stems from the complex interaction of Apache/Nginx rules. The 'Sucuri Security – Auditing, Malware Scanner and Security Hardening' team has addressed this in more recent plugin versions with the whitelisting tool. For most users, Solution 1 (using the whitelist) is the safest and most effective fix. If that is not an option, carefully applying the manual .htaccess edit (Solution 2) will resolve the problem while keeping your security hardening intact.

Related Support Threads Support