WP Rewrite Loop Added to Bottom of .htaccess File on Every Site after WordPress Core 5.6 Update

[Living Miracles]

Hello,

We recently updated all our sites to the new WordPress core major version (5.6). Afterward, I happened to notice that the following code got automatically inserted to the bottom of each sites’ current root .htaccess file:

# BEGIN WordPress
# The directives (lines) between "BEGIN WordPress" and "END WordPress" are
# dynamically generated, and should only be modified via WordPress filters.
# Any changes to the directives between these markers will be overwritten.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

Do you know anything about this? Was this supposed to happen? Should this be kept there? Our understanding after past communications with you is that the WP Rewrite Loop is supposed to start in box 8 of the custom code and that’s what we’ve done across our sites. This is the code we had manually added and currently have at the top of box 8:

# WP REWRITE LOOP START
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]

Then, from what we can tell, the WP Rewrite Loop automatically ends in the .htaccess file after custom code from box 12 but before box 13. This is the code we see for that in our .htaccess file:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# WP REWRITE LOOP END

So, with that being said, would you recommend that we remove that code that got automatically inserted to the bottom of each sites’ current root .htaccess file, and then integrated the new RewriteRule from the WordPress core update into the WP Rewrite Loop code we have in box 8 of our custom code. The following would be the code we use at the top of box 8 instead:

# WP REWRITE LOOP START
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]

Please let us know.

Thank you,
Living Miracles

[AITpro Admin]

Yep, I am aware of the new Rewrite Rule htaccess code that was added in WordPress 5.6 > https://forum.ait-pro.com/forums/topic/authorization-header-is-missing-autorisierungs-header-fehlt/. I missed that new addition during WP Beta and RC testing and will have a solution in BPS Pro 15.1.  I’m a little concerned that the new WP Rewrite Rule htaccess code causes problems for some people.  So I am researching this issue.  The new WP Rewrite Rule htaccess code is supposed to prevent problems with Basic Auth when using the WP REST API.

So what I recommend is that you do add that new Rewrite Rule htaccess code in BPS Custom Code, but if it causes any problems then remove it.

[Living Miracles]

Okay, thank you for letting us know. I checked out the forum topic you shared but I’m not sure I understand where we might see this error message about the authorization header being missing if we don’t add that Rewrite Rule. Would this just show up as a PHP error log entry? Along with that, how obvious would the problems be, or what could they be that we might encounter if we do add that Rewrite Rule? I’m just trying to get an idea of what to look for here either way as I don’t have a good understanding of this code at the moment.

Next, I want to ask if it’s worth waiting until BPS Pro version 15.1 before we do anything with this custom code in box 8? We have 40+ WordPress sites (including staging sites), so if that update will somehow take care of adding the Rewrite Rule for us or just save us from needing to change things twice, we’d likely prefer that. If it is worth waiting for, do you have an idea at this point when version 15.1 will be released?

Also, whether we wait for version 15.1 or not, would we still need to remove the block of code that WordPress inserted at the bottom of our .htaccess file, or will it somehow remove this for us?

[AITpro Admin]

The better approach would be to not add that new WP Rewrite Rule htaccess code to BPS Custom Code.  If you are currently not using or experiencing problems with the WP REST API then you do not need that new WP Rewrite Rule htaccess code.  That new WP htaccess code may only be needed if someone is using Basic Auth.  Until I fully test that new WP htaccess code and setup the problem scenario that that code is supposed to resolve I don’t have any definite answers to give you yet.  No idea when BPS Pro 15.1 will be released.  It’s looking like I will need to take care of more important things and release BPS Pro 15.1 sooner and push back less important things to BPS Pro 15.2.

To remove the new WP Rewrite block of htaccess code from your Root htaccess file all you need to do is to click the Root folder BulletProof Mode Activate button.

[Living Miracles]

Okay, thank you for sharing that with us. In this case, we’ll just wait until it becomes more clear/obvious to us that this WP Rewrite Rule htaccess code is actually needed on any of our sites before adding it.

Also, thank you for mentioning how to easily remove the new WP Rewrite block of htaccess code, I tried that out on a couple of sites and that worked very nicely and easily.

[Living Miracles]

Along with the situation I initially inquired about in this forum topic, we have another situation that feels related that is only occurring on one of our sites. On that one site, the new WP Rewrite block of htaccess code immediately re-inserts itself to the bottom of the .htaccess file as soon as we try to remove it. On our other sites, when we remove this from the htaccess code, it doesn’t come back.

We were able to determine that this seems to be occurring due to the Divi Machine plugin installed on the site but we don’t know why this is happening or how to stop this. This site, like our other sites, uses the same WP Rewrite Loop start code at the top of box 8 in the custom code and the WP Rewrite Loop code automatically ends in the .htaccess file between the custom code from box 12 and box 13.

In case it helps, I can also mention that the situation on this particular site was also occurring before the new WordPress core major update except that the WP Rewrite block of htaccess code didn’t include the new WP Rewrite Rule htaccess code that it does now.

We’ve asked the plugin developers about this situation but it hasn’t really gone anywhere yet. So we wanted to try to ask you to see if you had any idea what can we do about this so that the new WP Rewrite block of htaccess code doesn’t insert itself at the bottom of the .htaccess file anymore.

[AITpro Admin]

Try locking your Root htaccess file on the BPS Pro > htaccess File Editor page.  Click the Lock htaccess File button and the Turn On AutoLock button.

[Living Miracles]

Thank you for that suggestion, however, I forgot to specify that the server API is using DSO where this site is located. So we don’t see the lock and unlock buttons on that page. Also, ideally, we would rather not rely on having to lock the .htaccess file on this site unless there was really no other way of dealing with this circumstance.

Is there anything else you can suggest for us to resolve this situation?

[AITpro Admin]

Try something like this to trick the Divi Machine plugin into not creating this problem repeatedly.

1. Copy the WordPress Rewrite htaccess code that the Divi Machine plugin is creating.
2. Paste the WordPress Rewrite htaccess code that the Divi Machine plugin is creating into this BPS Root Custom Code text box: 14. CUSTOM CODE BOTTOM HOTLINKING/FORBID COMMENT SPAMMERS/BLOCK BOTS/BLOCK IP/REDIRECT CODE.
3. Edit the htaccess code and comment out the htaccess code lines as shown in the example htaccess code below.
Note: This is example htaccess code. Use your actual Divi Machine plugin htaccess code.
4. Click the Save Root Custom Code button.
5. Go to the Security Modes page and click the Root folder BulletProof Mode Activate button.

# BEGIN WordPress
# The directives (lines) between "BEGIN WordPress" and "END WordPress" are
# dynamically generated, and should only be modified via WordPress filters.
# Any changes to the directives between these markers will be overwritten.
<IfModule mod_rewrite.c>
#RewriteEngine On
#RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
#RewriteBase /
#RewriteRule ^index\.php$ - [L]
#RewriteCond %{REQUEST_FILENAME} !-f
#RewriteCond %{REQUEST_FILENAME} !-d
#RewriteRule . /index.php [L]
</IfModule>

# END WordPress

[Living Miracles]

Thank you for this suggestion. I went ahead and tried this but unfortunately it didn’t work.

On the “htaccess File Editor” page, when I click on the “secure.htaccess” tab, I see the commented out htaccess code at the bottom:

# BEGIN WordPress
# The directives (lines) between "BEGIN WordPress" and "END WordPress" are
# dynamically generated, and should only be modified via WordPress filters.
# Any changes to the directives between these markers will be overwritten.
<IfModule mod_rewrite.c>
# RewriteEngine On
# RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
# RewriteBase /
# RewriteRule ^index\.php$ - [L]
# RewriteCond %{REQUEST_FILENAME} !-f
# RewriteCond %{REQUEST_FILENAME} !-d
# RewriteRule . /index.php [L]
</IfModule>

# END WordPress

But, on the same page, when I click on the “Your Current Root htaccess File” tab, the htaccess code is not commented out:

# BEGIN WordPress
# The directives (lines) between "BEGIN WordPress" and "END WordPress" are
# dynamically generated, and should only be modified via WordPress filters.
# Any changes to the directives between these markers will be overwritten.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

Do you have anything else that you can suggest for us to resolve this situation?

[AITpro Admin]

Double check that you did all of the steps.  Did you activate Root folder BulletProof Mode?  If that does not work then send a WordPress Administrator login to your website to: info at ait-pro dot com and I’ll try to figure out some kind of solution for the problem that the Divi Machine plugin is causing.

[Living Miracles]

Okay, I just double-checked that I did all of the steps and the issue, unfortunately, is still occurring. So thank you for the offer to access our website and to try to figure out some kind of solution for this situation with the Divi Machine plugin. I’ve just gone ahead and emailed the address you’ve provided with the login details.

[AITpro Admin]

Problem Divi Machine plugin file/code: /wp-content/plugins/divi-machine/lib/create-post.php, line 211
flush_rewrite_rules();

Note: The flush_rewrite_rules() function is loaded on every page load everywhere in your WordPress backend.  That is not how this WordPress function is supposed to be used. This is a coding mistake that needs to be fixed by the Divi Machine plugin author.

Solution:
Since the Divi Machine plugin is using the WordPress flush_rewrite_rules() function with a value of $hard/true and since you cannot lock your Root htaccess file then since a hard flush removes and adds new default WordPress default Rewrite htaccess code then the htaccess code cannot be modified to prevent this problem from reoccurring.  So that leaves this simple fix: Created an htaccess Skip Rule and saved it in this BPS Root Custom Code text box: 14. CUSTOM CODE BOTTOM HOTLINKING/FORBID COMMENT SPAMMERS/BLOCK BOTS/BLOCK IP/REDIRECT CODE

1. Copy all of the htaccess code below. ie the Skip rule to bypass/skip the default WordPress Rewrite htaccess code and the WordPress default Rewrite htaccess code.
2. Paste the htaccess code that into this BPS Root Custom Code text box: 14. CUSTOM CODE BOTTOM HOTLINKING/FORBID COMMENT SPAMMERS/BLOCK BOTS/BLOCK IP/REDIRECT CODE.
3. Click the Save Root Custom Code button.
4. Go to the Security Modes page and click the Root folder BulletProof Mode Activate button.

Important Note: You also need to include the default WordPress Rewrite htaccess code in the BPS Custom Code text box, otherwise this could cause problems.  Example: If for some reason the default WordPress Rewrite htaccess code does not exist in your Root htaccess file then the Skip rule will skip/bypass the first 3 RewriteRules in the beginning of your Root haccess file.

# Skip rule to bypass/skip the default WordPress Rewrite htaccess code.
# Skips 3 RewriteRules in the default WordPress Rewrite htaccess code.
# Or in other words bypasses/skips the default WordPress Rewrite htaccess code entirely.
RewriteCond %{REQUEST_METHOD} ^(GET|POST|HEAD) [NC]
RewriteRule . - [S=3]

# BEGIN WordPress
# The directives (lines) between "BEGIN WordPress" and "END WordPress" are
# dynamically generated, and should only be modified via WordPress filters.
# Any changes to the directives between these markers will be overwritten.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

Additional issues/problems fixed:
This custom code below was in the wrong BPS Root Custom Code text box.
I have moved it to the correct Custom Code text box.

# WP AUTHOR ENUMERATION BOT PROBE PROTECTION
# Rewrites to author=999999 that does not actually exist
# which results in a standard 404 error. To the hacker bot
# it appears that this author does not exist without giving
# any clues that the author does actually exist.
RewriteCond %{QUERY_STRING} ^author=([0-9]){1,}$ [NC]
RewriteRule ^(.*)$ $1?author=999999 [L]

Divi Machine plugin Debug Mode:
Debug Mode was enabled. I have disabled Debug Mode in the Divi Machine plugin.

[Living Miracles]

Thank you for discovering the cause of this problematic situation and for providing a temporary solution to this! We’ll go ahead and share your finding with the Divi Machine plugin developers so that they can hopefully provide the necessary and permanent fix from their end.

As for the “Additional issues/problems fixed,” we took a look in the Custom Code page, along with the .htaccess file itself, and we cannot find where you moved the “WP AUTHOR ENUMERATION BOT PROBE PROTECTION” custom code to that was in box 8 (i.e., CUSTOM CODE WP REWRITE LOOP START) for us. Can you please share with us exactly where you moved this to and/or what the correct Custom Code box is that this code should have been placed in?

[AITpro Admin]

This is a permanent fix and not a workaround/temporary fix for DSO server types. Even if they fix their incorrect usage of the flush_rewrite_rules() function in this file: /wp-content/plugins/divi-machine/lib/create-post.php you are still going to run into problems with other plugins that use the flush_rewrite_rules() function correctly. The Divi Machine plugin uses this function correctly on plugin activation. So when you deactivate and activate the Divi Machine plugin the same problem would occur. So that is why the solution I posted above is a permanent fix.

The WP AUTHOR ENUMERATION BOT PROBE PROTECTION custom code should go in Custom Code text box: 14. CUSTOM CODE BOTTOM HOTLINKING/FORBID COMMENT SPAMMERS/BLOCK BOTS/BLOCK IP/REDIRECT CODE. If I forgot to save that code in Custom Code text box 14 then add and save it.

[Author]

Posts