I spent hours today tracking down why all my sites could not connect to the database after updating Local. I need to include the whole socket path in my wp-config.php to allow Wordmove to push/pull db like so:
define( ‘DB_HOST’, ‘localhost:/Users/Me/Library/Application Support/Local/run/xxxxxx/mysql/mysqld.sock’ );
This changed from /mysqld.sock to /mysql/mysqld.sock
A popup on updating would have been nice.
Thanks
Also when overwriting fields in my wp-config.php file !!!
Several operations will OVERWRITE EVERY mention DB_NAME, ‘DB_USER’, DB_PASSWORD’, etc.
Even values IN MY COMMENTS - that I need for quickly updating these values for live or dev sites located elsewhere.
I PARTICULARLY HATE rewrites of WP_HOME and WP_SITEURL, because I have WordPress files installed in a subdirectory. I need these two values to be different from one another (so the url does not include the wordpress install directory), AND one must include the install directory.
Another VITAL piece of information that people NEED to be made aware of:
While Local By Flywheel <=v3.3 allowed you to use any database (name, user, password) you wanted (taking a bit of trouble to set it up manually, of course),
Local v 5+ Does NOT. In fact, it’s worse than that. You can set it up: update your wp-config.php file, create a database (I did so via MySQL Workbench), set appropriate user permissions for this db that match your user and password from the wp-config file, etc…
And the site SEEMS to work - actually, for the time being, it does work.
But you can Never Stop your site. because once you do, it will be broken.
But when you STOP SITE from Local, your database is NOT exported and saved to the sql folder !!!
When you then (re)START SITE from Local, your database is no longer referenced/accessed by Local.
If you go into (MySQL Workbench) the database is still there. But Local won’t use it.
You have to recreate, reimport, etc the database again. Oh, and since Local didn’t export the files when it stopped the site, hope you did a manual export yourself… otherwise you need to start over.
Say yo manually export your db, and save it in the sql folder alongside the local.sql file. And you give the file the same name as your database, just like they did for ‘local’ (eg mydb.sql).
When you restart the site, Local still refuses to read in your db. And of course still refuses to use it.
This is a MAJOR departure in behavior from any v3+ version of the app.
This took much testing and hairpulling to come to the conclusion that v5+ REQUIRES me to use their opinionated naming and credentialing of its database.
And that a SECOND DATABASE MAY NOT even EXIST in a Local site. Which is ridiculous.
I really DISLIKE that I cannot control these values myself.
But that Flywheel does Not Bother to Tell Me about this Major Breaking Change is Unacceptable!
So fine. I caved.
That I have to change my workflow and my master config file to bend to Local’s stricter "herding’ policies.It does save me from creating the db. But it also keeps me from using their ‘local’ db as a troubleshooting db. It also makes my wp-config.php a bit more complicated, so I don’t have to swapping them out with the server version. For people that don’t create a master config file that can be used for both their online and their local websites, it’s a much bigger hassle to keep their wp-config.php files sorted amongst different servers.
The MAJOR issue is that I should have been informed UPFRONT at install, or at import, or at Create New Site that this was a breaking change. It does not affect everyone. But it was a decision you made that was guaranteed to affect many.
This kind of information MUST be conveyed to your users.
Any Breaking Change Must be conveyed to your users.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.