I’ve been having trouble with table prefixes which may, it turns out, be related to how Local deals with multisite.
Try this…
Create a new Local Site.
Name it “TestMU” and Continue
Leave it Preferred and Continue
Choose Advanced Option multisite “Yes - Subdirectories” and Add Site
View the site. All should be OK.
Go to the site’s wp-config.php file, change the table prefix to “tmu_” and save the file.
Reload the site.
At this point I always get an “Error establishing a database connection.”
This should not happen. Instead, WP should notice that the db tables do not exist and ask to set up a new show the beginning of the site-setup process. This is what happens if the site is not multisite on Local.
In exploring this problem I’ve also had odd cases where Local seems to not re-read the wp-config.php file each time. Maybe that is a known issue? In any case, it seems unrelated to the multisite table prefix issue.
Yes, @clay, I just tested and can confirm that this is “normal” WP behavior. But this just makes the point that Local really needs to have an option for changing the table prefix before it sets up a site, otherwise, with multisite, there is no easy way to change the prefix later.
(I know there are tools to change a table prefix after the site is established, but they are a bit risky to use.)
Please, let the Local team know that a setting for table prefix would be very helpful.
I understand, @clay, though I disagree with this priority. Taking your reasons…
I am not talking about deploying a site. A common use case for Local is creating development or staging sites from live sites. We are doing the reverse of deploying, we are recreating a live site within Local. Changing the table names is widely considered to be a non-trivial issue in this scenario, just look at the ongoing discussion within the WP-CLI community around database export and import to see this.
I tend to agree with you about the security aspect. But that said, it is a widespread and common practice. When we take on support of an existing site, we don’t get to choose the prefix, we inherit it.
Blueprints of multisite installations seem to be broken as well (I just posted about that in a separate support message). We cannot just create/change/blueprint. Besides, that is still risky given the non-trivial nature of changing the table prefix after the fact (though, I admit, if you do this right away before adding any content or plugins to the site, then the prefix changing plugins and tools have a better shot at getting this right).
All in all, being able to specify the prefix under the “advanced options” (same place you specify multisite now) would make a whole lot of sense. And it would give Local a way to sidestep some very thorny multisite issues.