Editor (TinyMCE) disabled after hardening wp-includes

same problem for me
any idea???

I fixed the problem
I deleted folders wp-admin and the wp-includes, and i uploaded them back.
I hope this helps you too.

Hi pey22,

When you uploaded them back, do you include the .htaccess as well?

I am not sure if that’s the best way to fix the problem or not? I kinda hope the plugin author can explain the issue and provide the solution / final fix so I can prevent such problem occurring again.

Hello
yes i include the .htaccess i have 5 sites with this problem and all works good now.

Hi,

I just tried to delete wp-admin and wp-includes folders, then upload them back. It’s not working for me. The problem is still there ??

Hi,
you upload new wp-admin , wp-includes or from your backup?
i upload new one after i deleted the old one.
dont override the folders, deleted them.

also try shut down all your plugins.

I deleted the folders (not override) then I uploaded back the folders from my backup.

Did you upload the new folders from a fresh WordPress installation?

Hi
yes i upload new folders from a fresh WordPress installation.

Hi,

I just got chance to try it again.

I deleted wp-admin and wp-includes folders, causing my site to go down for few minutes. Then, uploaded new wp-admin and wp-includes from a fresh WordPress installation.

The problem still happen when I hardened the wp-includes on the Sucuri setting again. So, unfortunately that solution does not work for me.

I simply removed the .htaccess file in wp-includes.

That resloved the issue. I’ll leave the harden rules alone until this is resolved.

I have the same problem, but it only happened after I migrated the website to a GoDaddy Linux cPanel hosting account. It worked fine on the development server with a different host on a Linux cPanel setup.

I just had to disable the hardening of the wp-include directory in the Sucuri plugin. Which basically removes the .htaccess file from that directory.

Would like to know of any solutions that might work.

Couple of hours of hunting here… it’s the mod_authz_core.c module in the /wp-includes/.htaccess file. My dev server (Site5) doesn’t have this module, and the production GoDaddy box does, and it causes wp-tinymce.php and its compiled scripts to be denied.

<IfModule mod_authz_core.c>
    Require all denied
</IfModule>

How I figured this out:

I created a test file at webroot (same directory as wp-config.php) named test.php and populated it with this:

<?php print_r($_REQUEST); ?>

Then I edited the webroot .htaccess file and added this to the very top:

<IfModule mod_authz_core.c>
  RewriteCond %{REQUEST_URI} test.php
  RewriteRule .* test.php?authz=getbent [L]
</IfModule>

So if the server does have mod_authz_core.c installed, visiting /test.php will dump out an extra GET variable. The dev box that doesn’t have this module prints the following (shortened up a bit):

Array ( [_ga] => GA1.2.1458764591.1437866529 [wordpress_test_cookie] => WP Cookie check [wordpress_logged_in_d5eb8073a5244643c7eb647ae837bc24] => user|1234567890|j39f203j9j|2j03f [wp-settings-1] => editor=html&libraryContent=browse&hidetb=1&wplink=0 [wp-settings-time-1] => 1446786369 [PHPSESSID] => f3j829 )

… and the same setup on the GoDaddy server prints this:

Array ( [authz] => getbent [PHPSESSID] => mnalfnli [_ga] => GA123fj3f9.232f.f [wordpress_test_cookie] => WP Cookie check [wordpress_logged_in_ab293761296bd4] => user|1234567890|j390f2j39|fa3m9j3j9pa [wp-settings-1] => editor=html&libraryContent=browse&hidetb=1&wplink=0 [wp-settings-time-1] => 1446790629 )

You can confirm this yourself by simply modifying the /wp-includes/.htaccess file and commenting the module lines:

<FilesMatch "\.(?i:php)$">
  <IfModule !mod_authz_core.c>
    Order allow,deny
    Deny from all
  </IfModule>
  # <IfModule mod_authz_core.c>
  #  Require all denied
  # </IfModule>
</FilesMatch>
<Files wp-tinymce.php>
  Allow from all
</Files>
<Files ms-files.php>
  Allow from all
</Files>

Commenting these lines will permit the tinyMCE scripts. A potential solution would be to remove the mod_authz_core.c test and just stick with the good ol’ Order allow,deny directive, like so:

<FilesMatch "\.(?i:php)$">
  Order allow,deny
  Deny from all
</FilesMatch>
<Files wp-tinymce.php>
  Allow from all
</Files>
<Files ms-files.php>
  Allow from all
</Files>

… but since this is a plugin-inserted file, we don’t have much control over what is generated. The only lasting solution I have right now is to disable the wp-includes protection. This is probably a good issue for investigation by Sucuri.

Nice investigation, Eric. It explains a lot why on one server there is no problem and on another it causing problem.

Yes, right now I disabled it too on my production server. Hopefully Sucuri can do something about this issue.

Thanks Eric!

It took several days to find the solution, I would never would never thought the mod_authz_core.c could be the problem!

Resurrecting this thread to submit a potential fix…

The wp-includes/.htaccess hardening was causing 403/404 problems for wp-tinymce.php for me on WiredTree and my localhost. While there’s a mix of 2.2 (Allow, Order, Deny) and 2.4 (Require) access statements for all of wp-includes, there’s not for the individual wp-tinymce.php and ms-files.php whitelists.

For these to work, the whitelisting needs to also contain the if/else check for mod_authz_core:

<Files wp-tinymce.php>
  <IfModule !mod_authz_core.c>
    Allow from all
  </IfModule>
  <IfModule mod_authz_core.c>
    Require all granted
  </IfModule>
</Files>

Here’s how I fixed it in sucuri.php line 8118 (version 1.7.16) I changed the line:

return sprintf("<Files %s>\n\x20\x20Allow from all\n</Files>\n", $file);

to:

return sprintf("<Files %s>\n\x20\x20<IfModule !mod_authz_core.c>\n\x20\x20\x20\x20Allow from all\n\x20\x20</IfModule>\n\x20\x20<IfModule mod_authz_core.c>\n\x20\x20\x20\x20Require all granted\n\x20\x20</IfModule>\n</Files>\n", $file);