Rewrite Rules failing intermittently

Home Forums BulletProof Security Free Rewrite Rules failing intermittently

This topic contains 13 replies, has 2 voices, and was last updated by  AITpro Admin 3 months, 4 weeks ago.

Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
    Posts
  • #37072

    Hannah
    Participant

    Hi, I’m hoping you can help with an unusual issue I’ve been dealing with for months. One of my clients has 3 websites, and the back end of these sites is nearly identical. He’s hosted at GreenGeeks, if that makes a difference in this situation. The theme is Divi. So, every now and then I go to the blog page and it shows a 404 Not Found error instead of seeing all the posts. Sometimes it’s every page except for Home that gets 404s. After doing a little bit of investigating a while back, I discovered that simply resaving the permalinks settings brings everything back, but this doesn’t prevent my client’s site from being more or less unusable between the time this occurs and when I/we discover that it’s affected again. I’m not sure if it’s an update that does it because I’ve done many updates – themes, plugins, core – while working on the site and it has never happened while I’m watching. I see the code that WordPress wants me to add to htaccess at the bottom of the permalinks settings page:

    If your .htaccess file was writable, we could do this automatically, but it isn’t so these are the mod_rewrite rules you should have in your .htaccess file. Click in the field and press CTRL + a to select all.

    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
    
    

    I can see that this code is in htaccess, though half is in one place and the rest is further down in the file, but it’s like that on every site where I install BPS, and this client’s sites are the only ones that have ever behaved this way. Think you might be able to help?

    #37073

    AITpro Admin
    Keymaster

    Yes, BPS already uses the default WordPress htaccess code, but it is modified and integrated into the BPS root htaccess file.  So you do not want to add that default WordPress htaccess code again and should ignore the WordPress Permalinks message since it is not accurate.  404 errors can be caused by adding duplicate blocks of the default WordPress Rewrite htaccess code with BPS Rewrite htaccess code.  Other things that can cause 404 errors are using an invalid Permalink Custom Structure.  The most commonly used Permalink Custom Structure is this:  /%postname%/. If the problem is intermittent then that sounds like it could be caused by a caching plugin.

    Here is list of things that cause intermittent problems: php memory/cache/caching plugins/CDN’s/VPN’s/Proxy’s/Load Balancers/Host server problems (new security measures added on Host server (Mod Security, etc.), DNS server/DNS configuration problem, MySQL server timeout, server overloaded, etc.), /Browser problems (corrupt cache, Sessions, Cookies, add-on, extension)/ISP (connectivity)/CloudFlare, Incapsula, etc.

    #37077

    Hannah
    Participant

    Thanks, I’ve avoided adding that block since I recognize it in the BPS htaccess code. I suspect it might be Cloudflare acting up when plugins/themes are updated. It always seems to occur after updating something in the site.

    #37078

    AITpro Admin
    Keymaster

    There is an option setting in Cloudflare to cache the WordPress wp-admin area (not sure if it still exists or not).  The WordPress wp-admin area should never be cached for any reason.  Login and check the Cloudflare settings.  Here is a Cloudflare help link that shows what the setting name is > https://community.cloudflare.com/t/how-to-stop-caching-the-wpadmin/13587/2

    And double check BPS Root Custom Code to make sure there is not an fubar htaccess code saved in any Custom Code text boxes.  If the client has some fubar htaccess code saved in any of BPS Root Custom Code text boxes and they re-run the Setup Wizard then that fubar code will be added/created in the Root htaccess file.  You can export BPS Root Custom Code and send the zip file to:  info at ait-pro dot com if you would like for me to check it.

    #37082

    Hannah
    Participant

    Thank you! I added the bypass rule in Cloudflare for just the one site, so we’ll see if it makes a difference after the next updates come in. I’ll send you the Custom Code in a moment just to make sure there’s nothing wonky in it.

    #37118

    Hannah
    Participant

    Well, after being busy with other clients for some time, I came back to this one’s and found that two of the three sites’ blog pages were again down with 404 errors. So I guess the Cloudflare wp-admin bypass didn’t have the effect we’d hoped it would.

    Since you felt the issue could liekly have to do with caching, I double-checked the cache setup. Aside from Cloudflare, the only caching is the BPS Speed Boost custom code on the site for which I sent you custom code (which checked out) previously. I had LiteSpeed on that site, but the host apparently disabled it on the server side, so I removed the plugin and its htaccess code from one of the two sites when we last spoke about this. That site is one of the two that is missing its blog page today. The other one still has the LiteSpeed plugin installed and activated (though it’s not connected to anything on the server) and its cache code is still present in htaccess. So we have two very similar setups, with the main difference being the vestiges of LiteSpeed on one.

    I’m a bit stumped when it comes to assessing which of the other possible variables you mentioned above might be the cause of the issue, so I’m going to open a ticket with the host and see what they find, but wanted to check in with you before resaving the permalinks to bring the blog pages back up in case there’s something that might be helpful for you to see while they’re malfunctioning.

     

    #37119

    AITpro Admin
    Keymaster

    Maybe this does not have to do with htaccess code at all.  When you save WordPress Permalinks 2 things happen:  The WordPress database permalinks options are updated (contains URL rewriting settings) and the root htaccess file is updated (with the WordPress default htaccess code if the Root htaccess file is not locked).  Since you do not want to update the root htaccess file then it should be locked on the B-Core > htaccess File Editor tab page to prevent anything from writing to or flushing the root htaccess file (very common problem).  Is the permalink structure being changed?  When you resave the permalinks are they the same setting as they were before or were they changed to something else?

    #37123

    Hannah
    Participant

    I see. I just checked and htaccess is set to autolock. When I resave the permalinks, I don’t change the settings – it has always been set to Post Name. I just click Save without changing anything and then the missing part of the site reappears. I do not see any change in the urls either before or after doing this.

    #37124

    AITpro Admin
    Keymaster

    Ok well this sounds like either a DB issue or a Cache issue.  I don’t think it’s an htaccess code issue.  Not really sure what else to tell you at this point.  Maybe try turning off Cloudflare on one of the sites to see if this problem is being caused by Cloudflare or create a duplicate test site without Cloudflare on it and see if the problem goes away on the test site.

    Maybe this is happening > the client does something to the site that causes the problem.  Have you asked the client if they are doing anything to the site that does anything with URL’s or permalinks?  Maybe another plugin or the theme has a bug that is screwing up the WordPress Rewrite Rules saved in the DB when resaving plugin or theme option settings?

    #37129

    Hannah
    Participant

    Understood. I’ve opened a support ticket with the host to see if they can figure this out. I can try the Cloudflare test you mention, too, since I have a staging site set up.

    My client actually has me do all the content updates and such, so he doesn’t really touch the site aside from checking the front-facing content. If there’s a user error in play, that would be me. I was terribly surprised when this first happened, but relieved when resaving the permalinks actually worked. Just completely in the dark as to what might have caused it to start happening. It’s been like this for over a year now…nearly from the beginning of my relationship with this client, when I began redesigning his sites. I’ll take another look at the plugins and see if there might be one that could interfere with the permalinks, but I’m doubtful on that one. We’ll see, and I’ll let you know.

    #37130

    Hannah
    Participant

    Ok, weird. I have been working on the site that isn’t having trouble with this right now, so haven’t been checking the other two regularly. However, I just refreshed the blog page on the site which was definitely down yesterday, and it came up with all the blog links/excerpts?! The blog page on the other one that was down yesterday still is. The third site still isn’t having these issues…must be “in remission.” JK. Have to find some humor somewhere as this is a terribly frustrating and longstanding problem with horrible usability and SEO ramifications for my client. 🙂

    I did check the support ticket at the host and they’ve escalated it to higher level techs. They requested my IP for further investigation and I hope to hear from them later today. I’ll let you know if I learn anything significant from their next reply.

     

    #37131

    AITpro Admin
    Keymaster

    I just refreshed the blog page on the site which was definitely down yesterday, and it came up with all the blog links/excerpts

    Are you saying that you did not do anything to fix the problem and it fixed itself? If so, then this is definitely either a caching problem (server-side or client-side) or some kind of server problem.

    #37132

    Hannah
    Participant

    Yes, that’s what I saw! So strange. Here’s what the host’s support has to say:

    I’ve reviewed webserver logs and didn’t find any errors including 404 errors.

    Also, the behavior you described could be cause by wordpress auto-update feature, but you have disabled that option in your softaculous settings. In any case I’ve also corrected permissions for files and folders on your cPanel account ‘lightpat’. (I hope this last sentence doesn’t mean they’ve done something that will mess with BPS!)

    Additionally, according to resource usage log (which can be found within your cPanel->CPU and Concurrent Connections Usage->Details) you are constantly reaching the limit of RAM and I/O wait: https://gyazo.com/74008de87e4245f32fc8d1653d7edcfd  (Not entirely sure what this means except that we might need to upgrade our account. Can you explain?)

    I suggest checking the software on your sites and make sure that your plugins and themes are up to date. Also, I suggest replacing your wp-cron to real cron, here you can check how to do that: https://wpweb.co.in/documents/replace-wordPress-cron-with-a-real-cron-job/ (I would love your opinion on this cron suggestion)

    If your sites require more resources then you can consider upgrading your hosting plan to Ecosite Pro or Premium: https://www.greengeeks.com/kb/4873/greengeeks-shared-hosting-pricing/

    If you can help me untangle all he’s said here, perhaps I can speak with my client about what needs to be done to avoid this in the future…

    #37133

    AITpro Admin
    Keymaster

    If you saw a 500 error at any point then it definitely exists in the server log file. A 404 error could be logged as another HTTP Status Code (403 or 500). So I’m not sure what the tech was looking at, but it does not sound like he/she was looking at the correct server logs for your website.

    Nope, there is no way the problem could be caused by the WordPress auto-update thing.  Make sure the tech did not enable softaculous to update WordPress automatically.  WordPress can automatically update itself if you want to do that.  If softaculous force updates WordPress then your WordPress files will be quarantined by AutoRestore|Quarantine since that simulates a hacker uploading/adding files outside of your WordPress Dashboard.  Not sure how file and folder permissions would come into play and it would have been nice to know what the tech “corrected”.  You should probably contact the tech and find out what file and folder permissions were changed.

    Cute graphic, but it is not relevant and means nothing.  So ignore that.

    Don’t replace your standard WordPress Cron with a direct cron.  That is very bad advice.  So ignore that.

    Techs are told to try and get customers to upgrade their hosting accounts.  So ignore that.

Viewing 14 posts - 1 through 14 (of 14 total)

You must be logged in to reply to this topic.