Softaculous push-to-live creates temporary 301 redirects in .htaccess; browser stuck

I have been trying out the Softaculous WordPress Manager to push changes in staging to a live site. Mostly it’s worked pretty well, and by trial and error I’ve learned many details they should have put in their documentation.

One problem cropped up today though. While pushing to live, the software choked on a table it should have been able to create in the live site. I removed the unneeded tables manually and later performed the push with no errors.

Before pushing to live, Softaculous changes .htaccess to redirect visitors to the staging site. After successful completion, the rewrites are changed back. Because I was fixing tables in the interim, my browsers picked up the redirects. I wasn’t astute enough to capture all the changes it made, but because my browsers are stuck with the redirect, I assume the software did not specify an expiry time or perhaps even distinguish between 301/302.

I found a couple of helpful docs online, but I don’t know how best to implement them in this situation. Apparently there are nocache rules that can be added to .htaccess.

My question is: would adding some of the lines from the following reference to my .htaccess (permanently) work in conjunction with the temporary modifications Softaculous makes?

Nocache examples here: https://github.com/markkolich/blog/blob/master/content/entries/set-cache-control-and-expires-headers-on-a-redirect-with-mod-rewrite.md

General background on 301/302 redirects: https://moz.com/learn/seo/redirection

Here’s my current .htaccess:

# BEGIN WordPress

<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

RewriteCond %{HTTP_REFERER} !^https://example.org/.*$      (NC)
RewriteCond %{HTTP_REFERER} !^https://example.org$      (NC)
RewriteCond %{HTTP_REFERER} !^http://example.org/.*$      (NC)
RewriteCond %{HTTP_REFERER} !^http://example.org$      (NC)
... (lots of other variations with subdomains)

I viewed this file during a push to live and I believe Softaculous simply added the staging site’s subdomain to the RewriteConds:

RewriteCond %{HTTP_REFERER} !^https://dev.example.org/.*$      (NC)
RewriteCond %{HTTP_REFERER} !^https://dev.example.org$      (NC)
RewriteCond %{HTTP_REFERER} !^http://dev.example.org/.*$      (NC)
RewriteCond %{HTTP_REFERER} !^http://dev.example.org$      (NC)