.htaccess file corruption

Hi Trinity13,

First of all thank you for showing interest in our plugin.

Please note that our plugin does in no way interact with the .htaccess file, i.e. I can confirm it from the developer point of view.

Most probably it could be something else. To confirm, can you please specify what is being added to the .htacess file?

Looking forward to hearing from you.

Hey Guys,

I’m also getting the same problem. I’ve tested this extensively since I have your awesome plugin on multiple sites and this issue popped up with version 1.0 and 1.1.0. When I go to 0.6.3 the problem disappears.

It looks like something with your plugin is causing WordPress to modify the htaccess file every few seconds. It adds these lines over and over until eventually the file corrupts and causes a 500 error:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

With all plugins off or all on except yours, everything is fine. With your plugin on, htaccess file gets modified every few seconds and eventually corrupts.

If you need more data from me let me know.

-Neil

Hi Neil,

Thanks for your update. Just to confirm, do you mean that once our plugin is installed the lines you’ve attached in your post are being copied several times in the htaccess file?

Or is it something else? Can you please send us a copy of a corrupted htaccess file (remember to omit any sensitive details if you have).

you can send it to us via email alternatively give us the download link.

Looking forward to hearing from you.

In my case, it sometimes rewrites that section removing extra line space and line returns. Other times it puts stray characters into the area. Here are a few examples:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress
 BEGIN Test area
# END Test area

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine OnRewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RRewriteRule . /index.php [L]
</IfModule>

# END WordPress

# BEGIN Test area
# END Test area

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress
s

# BEGIN Test area
# END Test area

@wpwhitesecurity

Not once installed, but installed and active.

Sending htaccess file to you following this post.

If you need anything else just let me know.

Thanks for your fast responses on this guys. Much appreciated ??

Hello Gents,

I noticed one thing in common between both cases: WordFence plugin. Most probably in your particular case it is conflicting with our plugin. P.S. WordFence writes to the htaccess file, so it should be it.

Can you please try to disable WordFence, enable our plugin for a couple of minutes and see if everything works well? We tried it from our end but couldn’t replicate the problem, though of course our scenario is not like yours.

Keep me posted.

It must be a conflict between the 2 plugins. It only occurs when both are active. This is frustrating as I have been fighting this issue for weeks. Here is more information.

1) The .htaccess file is modified every couple of seconds after both plugins are activated and an initial Wordfence scan has started.

2) This continues to happen as long as you stay on the Wordfence admin page (even after the scan is over).

3) If I navigate away from the Wordfence admin area, the .htaccess file is only modified when I change pages in the admin area.

I am going to link this information to Wordfence also so someone can figure out why this is occuring.

Hi Trinity,

Sorry for the delay in replying though this is taking some time. Just wanted to let you know that we are looking into this issue.

Will keep you posted.

Hey guys,

We were contacted via our premium support and given a link to this thread. I just did a brief look at WP Security Audit Log’s code and I don’t see anywhere they open/modify the .htaccess (as WPWhiteSecurity mentioned above) so I don’t think it’s them.

I also don’t think it’s us because we use advisory file locking when we edit .htaccess which prevents multiple web server threads from conflicting, or even conflicts with other plugins trying to modify the .htaccess, provided they’re also using file locking (flock()).

So… I think it may be another plugin that is not using file locking. My suggestion is to do a search in the source code of all your plugins for “.htaccess” without quotes and where you find they’re modifying it, check if they’re calling the flock() function before hand to avoid conflicts. If not, you found the culprit.

Regards,

Mark.
PS: WPWhiteSecurity sorry to jump your forums, but I hope that helped a little.

Hi Mark,

No problem at all and thanks a lot for the clarification. Gents, as confirmed by Mark and us it seems that the problem is not related to our plugin.

Please check all other plugins. I will close this ticket then. If you notice anything else, you’re more than welcome to open another forum support query.

Thank you for using our plugin.

Hey guys,

Just spent some time tracking this problem down on a client site that had WP Audit Log installed. Looking through the code I don’t see where the .htaccess file is being directly modified, but I can confirm that immediately after disabling the plugin, the issue stopped. WordFence is not installed on the site, but there are some plugins touching .htaccess. However, without Audit Log, no corruption.

I agree you are not making .htaccess modifications directly, but something the plugin is doing is causing the issues with the writes happening to that file, at least in some environments.

Kindly,

Luke

Hi Luke,

Thank you for the detailed feedback. In that case the best approach (if possible) is to enable WP Security Audit Log and disable the other plugins that do modify the .htaccess file one by one to see with which plugin we might be clashing with.

Would it be possible to do such tests? If not can you send us an email on [email protected] with all the installation details (list of plugins etc) to do the test ourselves?

Thanks a lot.

Hate to add to the pile. Got a problem occurring with my plugin that is directly caused by your plugin and it seems similar in nature, but not exactly the same so I will create a new thread and link back to this thread.

Thanks. We are looking into your other ticket.

Great thanks. I will dig deeper too around 10am today (3 hours from now my time). Just wanted to mention that looking at the flock() function is probably a dead end. Logically this issue would not have anything to do with flock() write locking since it is just a temporary lock and not a real “lock” like CHMOD. ??