When you say you have tried everything I just need to know a bit more about that to provide some suggestions.
Are you still experiencing the DOS attack? Have you tried renaming the plugins folder via other means to be able to get access back and remove said plugin creating issues?
If you were in-fact attacked 403 error means that the server is dropping any and all connections to conserve it’s bandwidth to endure the attack without causing the bandwidth usage to reach it’s peak.
If that is the case, then you need to contact your host and see if they have done that and how to move forward on removing that restriction placed on your hosting account.
Hopefully some of this is helpful or is making sense, would love to help more.
As a last resort, I just deleted everything from .htaccess except the default bits and this seems to have solved the problem – initially;
# 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
Absolutely no idea what has managed to get inserted into here during a plugin update which would cause this though. Would be interesting to hear people’s thoughts on the topic.
The problem being is that the .htaccess file was 500 lines long, all filled with All-in-One WordPress Security & Firewall along with W3 Total Cache along with only allowing traffic through proxy cloud firewall with Sucuri. The irony is that none of the plugins which were being updated when this happened had anything to do with any of those things. The 3x plugins which were being updated at this point included AddThis Sharing Buttons, Custom Fields Search by BestWebSoft, and WooCommerce.
When the site came back after this, decided to update those same 3 plugins again to rule out the DOS attack which seemed to happen at the same time as the updates previously. Interestingly, as soon as this was updated again, all plugins listed as being installed successfully. Then literally the second this happened, more W3 Total Cache had managed to fill up the .htaccess file again, which caused the CPU on the server to spike over 100%, causing problems again. Disabled W3 Total Cache by renaming the file on the server. So once CPU load comes back down once PHP memory limit times out the processes (hopefully) then I’ll give this another go.
Got to the bottom of the problem, kind of, the issue related to updating the 3 plugins somehow caused The Events Calendar to get into an infinite loop and crash the server.
Glad you removed the plugins causing you the issues, let me know if there are any other problems happening.
Thanks.
