DreamHost has a special way of telling you PHP is gone. The page is not a Forma 500. It is not your branded error template. It is a blank white screen and five words:
No input file specified.
That is FastCGI failing to hand Apache a script filename. Every .php URL on the vhost is unreachable — admin, Agent API, /up, the homepage, everything that still has to execute PHP. Changing the PHP version in the panel does not always fix it. Killing PHP processes does not always fix it. Sometimes you wait on a ticket while the public site is a ghost.
We watched it happen on forma-cms.me. That is why Forma now treats PHP as optional for reading a site.
What actually broke
Forma is PHP + SQLite. The front controller is index.php. Apache asks FastCGI for that file. If the mapping is wrong — a re-provisioned vhost, a stale wrapper, a panel change that did not stick — FastCGI answers with nothing. Apache has no document to serve.
A SQLite page cache does not help here. That cache still needs PHP to look up the row and print the HTML. The site is “cached” and still dead.
The only thing Apache can serve without PHP is a file that already exists.
The rule we shipped
Files for real URLs. PHP for ad-hoc questions.
When HTML cache is on, a save writes a real .html file under fallback/. Apache is told to prefer that file. The homepage becomes fallback/index.html. A blog post becomes a file. The 404 page becomes a file.
These stay dynamic, on purpose:
/admin/api/search?q=…- feeds,
robots.txt,sitemap.xml /up
Search is a question. Admin is a question. A product page that only changes when an editor hits Save is a document.
If FastCGI dies again, the documents stay up. The questions wait.
How you know PHP is sick
Hit /up. If PHP is alive you get JSON: product, version, timestamp, HTML-cache status. If /up fails but fallback/php-ok.json is still there, you know when PHP last completed a request. That is the difference between “the server is down” and “PHP-FPM had a bad afternoon.”
Hosting Check in admin also reports the heartbeat and whether the HTML cache is actually written.
What to do on a client site
- Turn on Settings → Cache → HTML cache.
- Click Rebuild HTML cache.
- Confirm
/, a page, and a post still load. - Bookmark
/upfor the monitor.
You still need backups. You still file the host ticket. But the client’s homepage should not be a FastCGI error message while you do it.
That afternoon was ugly. The site does not have to be the next time.