Hi Josh.
Sorry I missed your post before.
The behavior you’re describing is very strange. I haven’t seen it before. Nothing in this update (or any of the previous ones in over 2 years) has touched the part of the plugin activation procedure that adds the .htaccess rules.
I did several tests just now, and can confirm that s2 only adds its rules to the file, it doesn’t throw away what was there. And it adds them on installation, not on an update. If you’ve done updates in the past, this was also true and you didn’t have this problem then.
I honestly don’t know what could have happened this time for you. I reviewed s2 code for this and it does several checks to make sure things are okay before trying to add it. I will study that code closer to see if I can imagine a scenario that causes what you experienced, try to reproduce it, and then find how to avoid it in the future.
Do you have a backup of your .htaccess before this that you could put back in the live site? Have you made a backup of the site recently, or does your hosting have a backup?
That missing part that is causing the 404s, is most likely WordPress’: https://wordpress.org/support/article/htaccess/
If you don’t have a backup of the .htaccess file, you can try adding those lines to your current one, right after the s2Member block. E.g.
# BEGIN s2Member GZIP exclusions
<IfModule rewrite_module>
RewriteEngine On
RewriteBase /
RewriteCond %{QUERY_STRING} (^|\?|&)s2member_file_download\=.+ [OR]
RewriteCond %{QUERY_STRING} (^|\?|&)no-gzip\=1
RewriteRule .* - [E=no-gzip:1]
</IfModule>
# END s2Member GZIP exclusions
# BEGIN WordPress
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]
# END WordPress
- You’d just need to change the rewrite base if it’s not the root folder.
I hope that helps! Let me know how it goes. I look forward to your update.