Upon re-saving the permalinks, it absolutely solves the missing pages issue…for a while. And like 1000 other posts just like this one, the 404’s come back.
The .htaccess file should never change, unless there is a need to *hard ban* an ip. Excepting for requiring a ban of a specific IP which would be written in the .htaccess file, the .htaccess file should *never* be re-written. This re-writing of the .htaccess file is a myth that just won’t go away. .htaccess should remain as unchanged as possible. When permalinks are added, subtracted, or changed in any way, the .htaccess file does *not* need to be informed of the changes. .htaccess only converts url’s with stbs, to post links. That’s all it does. It should *never* be changed, except for adding an IP to ban for good.
But you’re right, after re-saving the permalinks, it solves the issue…but only for a while. So, what must be happening is the database that holds stub information is either not readable, or simply inaccurate when the 404’s happen (to thousands of people that have reported this same issue). So, why would the database that holds stub information ever need to change? It shouldn’t. Just like the .htaccess, there’s no need to ever change the permalinks unless adding or subtracting on. but *something* is editing those stubs in the database, and that’s causing the 404’s.
I have a theory. My theory is that the database might be taking too long to pull the information about the stub, in order to figure out where the real url is. If the database call for pulling up that stub information takes too long, it might come back with something like an empty database query. And then it just reports it as not found, a 404.
The other theory I have is that one of the security plugins is reading the database or writing to the database, at the moment of the 404, and locking the database so nothing else can write to the database until the plugin’s job is done. In that case, the lock on the database (to prevent possible corruption when one reads and the other writes) could be returning an empty query because of the lock.
What I might have to do is create actual index.php files at those virtual stubs so that I can use a redirect in those headers to try to point to the correct post location when there’s a 404. because at the time of the 404, the client is *probably* looking at the actual url, not the stub->post .
I dunno. It just feels like this whole permalink thing is a bad idea that caught on and it’s too late to change it now.
If anyone has any ideas how these 404’s happen, lemme know. For us, sometimes they are there, sometimes they are not. And *nothing* changes on the site at all. Some days 404’s and some days not. Just like 1000 other people have reported. Ideas?
