The Short Version
- The setup screen doesn't mean WordPress is missing. A client's site started sending every page, including the login, to the WordPress install screen. The site was fine. The database user had lost permission to read its own database, so WordPress got nothing back and assumed it was new.
- The cache hid how broken it was. Some pages still loaded, so the outage looked random. Test with a page nobody has visited, not the one you remember.
- The fix was one permission, and one question is still open. Re-granting it in the host's control panel brought the site back. Who changed it, I can't say.
A client's site went down in the strangest way I've seen this year. I had WordPress redirecting to install.php on every page, front end and wp-admin both. That's the setup screen you only see on a brand new site, and this one wasn't new. Every row in the database was still there. The database user had lost its SELECT permission (the right to read) on its own database. Here is how that looks from the outside, how to tell it apart from the other causes, and the one question I still can't answer.
What WordPress Was Actually Telling Me
The screen said WordPress wasn't installed. The truth was smaller. WordPress connected to MySQL (the database server) with the right login, asked for its options table, and got nothing back. Without the right to read, an empty answer looks exactly like an empty database.
According to the WordPress developer reference, when WordPress can't find its saved site address, it checks whether any of its tables exist. If it finds none, it treats the site as new. A second core function then redirects to /wp-admin/install.php. I haven't traced which exact query came back empty on this site. What I can say is that the site behaved exactly that way.
How to Tell the Causes Apart
Unexpected install.php means WordPress can't read its own data. It doesn't mean WordPress is missing. With WordPress redirecting to install.php, the list of causes is short. Here is how I check each one:
- Wrong database. The wp-config.php file points at a different, empty database. Compare the database name in that file to the one in the host's control panel.
- Wrong table prefix. The tables exist, but WordPress is looking for names that start differently. Compare the prefix in wp-config.php to the real table names in the host's database viewer.
- A missing options table. Open the database in that same viewer and look for the options table. If it's there, check that it has rows in it.
- A permission change. Everything above checks out and WordPress still reads nothing. Log into the database tool as the same user WordPress uses and try to open a table. An access denied error while the host's panel shows data is your answer.
A plain wrong password usually gives a different screen: "Error establishing a database connection." The WordPress common errors page says that error is usually caused by the database settings in wp-config.php. So a login problem and a permission problem look different, which helps.
The Cache Lied the Whole Time
This site had a caching layer (LiteSpeed here) still serving old copies of the homepage and the login page. So how broken the site looked depended on which URL I tried and whether I was logged in. Some pages loaded fine. Others went straight to the installer.
If you're testing a fix, ask for a URL nobody has ever visited, or purge the cache first. A page that loads isn't proof the database is healthy.
The Half I Can't Answer
Privileges don't drop themselves. This site had a history of login-attack traffic, so a changed permission isn't something I shrug off. I can't tell you whether a person, a hosting change or an attacker made it. I'd rather say that than guess. The fix was the easy half. Who or what changed the grant is still open. If you suspect more than a permission slip, that's when a malware check makes sense.
What the Client Got Back
Once the permission was re-granted through the host's control panel, the site came back. Same content, same login, nothing rebuilt, because nothing had been lost. I wouldn't click through the installer on a guess. It's built for an empty site, and this one wasn't.
Seeing a setup screen on a site you've had for years is a scary moment. It looks like everything is gone. Usually it isn't. If it happens to you, don't click Install. Call me and I'll check the database before anyone touches anything.
Questions I Expect About This
Why is WordPress redirecting to install.php on my site?
WordPress sends visitors to install.php when it decides it isn't installed. That usually means it can't read its own database. The causes are a wrong database name, a wrong table prefix, a missing options table, or a permission change.
Is my data gone if I see the setup screen?
Not necessarily. On this client's site every row was still in the database and WordPress just couldn't read it. Don't run the installer until someone has checked the database.
Why do some pages load while others show the setup screen?
A caching layer can keep serving saved copies of pages like the homepage and the login page. Uncached URLs reach WordPress and hit the problem. Test with a URL nobody has visited, or purge the cache first.
0 Comments