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.