Published by

WordPress “Upgrade database” process hangs on Laravel Valet

I’m working on a WordPress site for a client that involves importing a whole bunch of their legacy content. I decided to work with a copy of their old database for this. I set it up locally in Sequel Pro, accessed /wp-admin, and was met (as expected) with a “You must upgrade this database”-style screen. I clicked the button and… nothing. Eventually I had a 504 error.

I use Laravel Valet to develop PHP sites locally on my MacBook Pro, so I checked the NGINX error log ~/.config/valet/Log/nginx-error.log for hints about what was going on. I repeatedly saw an error along these lines (highlighted bits are altered by me to be more generic):

YYYY/MM/DD HH:SS:MM [error] 52486#0: *14 upstream timed out (60: Operation timed out) while reading response header from upstream, client: 127.0.0.1, server: , request: "GET /favicon.ico HTTP/1.1", upstream: "fastcgi://unix:/Users/username/.config/valet/valet.sock", host: "hostname"

I searched online and found a bunch of suggestions, about checking the valet.sock file, about increasing the fastcgi settings in the NGINX config, etc. Nothing seemed to work.

I then came across this issue which sounds super similar, and they seemed to resolve it with a reboot.

Worked for me too. Turn it off and on to the rescue again. Wanted to mention it here in case anyone else is banging their head against the wall at some point.

Published by

Resolving Craft 3 Setup Wizard error

I keep encountering issues when running Craft’s setup command locally. Note that I use MAMP Pro for this sort of thing. I entered all the database creds correctly, and then got a SQLSTATE[HY000] [2002] No such file or directory error. This StackExchange answer sorted it for me. Add 'unixSocket' => getenv('DB_SOCKET') to /config/db.php and DB_SOCKET="/Applications/MAMP/tmp/mysql/mysql.sock" to .env.

Still encountering database connection issues on staging for one site currently under development. All of the credentials are set correctly in .env, but getenv() in /config/db.php retrieves the wrong DB_USER value. Ended up explicitly adding the problematic value to the /config/db.php file as a quick workaround, but it’s not ideal.

Published by

Rhizome blog article about meltingperson.com

Databases are generally associated less with open-endedness than with the muted horrors of bureaucracy, in which the fear and pain and misery of human experience is reduced to data and evidence.