Hi, would it be possible to update the Wordpress install script so that it supports entering a custom table prefix?
https://www.wpbeginner.com/wp-tutorials/how-to-change-the-wordpress-data…
It’s a pain to have to change all of the table names manually and would be much easier if the Wordpress install script supported this feature.
You could avoid the tedious renaming of each table manually with:
RENAME table `wp_commentmeta` TO `wp_a123456_commentmeta`;
RENAME table `wp_comments` TO `wp_a123456_comments`;
RENAME table `wp_links` TO `wp_a123456_links`;
RENAME table `wp_options` TO `wp_a123456_options`;
RENAME table `wp_postmeta` TO `wp_a123456_postmeta`;
RENAME table `wp_posts` TO `wp_a123456_posts`;
RENAME table `wp_terms` TO `wp_a123456_terms`;
RENAME table `wp_termmeta` TO `wp_a123456_termmeta`;
RENAME table `wp_term_relationships` TO `wp_a123456_term_relationships`;
RENAME table `wp_term_taxonomy` TO `wp_a123456_term_taxonomy`;
RENAME table `wp_usermeta` TO `wp_a123456_usermeta`;
RENAME table `wp_users` TO `wp_a123456_users`;
This step is exactly what I was referring to as a pain. If I forget to follow this step after running the install script and then set up a Wordpress site with several plugins, that’s more tables that have to be renamed and I like to have a random prefix for every website that I host and it just becomes very time consuming. It would be nice to have the install script take care of this task. I’d be willing to make a donation for this feature.
Hi,
Thanks. Great point! This feature is added for inclusion for the next release.
For the moment, you can use WordPress CLI to change table prefix:
wp rename-db-prefix --help
You can install WordPress CLI with following steps:
wget https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.pharchmod +x wp-cli.pharsudo mv wp-cli.phar /usr/local/bin/wpFor more information go to https://wp-cli.org/.
Argh. I don’t really like adding more stuff to the form. Virtualmin already supports creating a new database. Seems silly to use prefixes. It needs to at least be very clear that the prefix is optional, which this form does not. Using a prefix is not a good thing, as it adds complexity to future administrative tasks, so it definitely shouldn’t be encouraged by the UI.
Also, that article is dumb. Changing the prefix does not improve security. If someone can access your database, you’re already hosed…prefix won’t save you.
Okay, good point. I made it look more like an optional feature, and now the field has no value, only placeholder.
That will work perfectly. Thank you very much! 
However, we decided that this feature will only be available from CLI via –opt dbtbpref wp_prefix_ param and not from UI.
The easiest way of working around the problem, when WordPress is installed with Virtualmin, to open wp-config.php file manually and edit the following, before performing installation on WordPress side:
/**
* WordPress Database Table prefix.
*
* You can have multiple installations in one database if you give each
* a unique prefix. Only numbers, letters, and underscores please!
*/
$table_prefix = 'wp_';
Well editing the wp-config.php file is a lot easier than following all of those steps in the article if I can remember to do this before performing the Wordpress install. I still don’t understand why this can’t be added to the UI as an optional field? Although, I agree with Joe that changing the prefix won’t save you, it will take a more experienced hacker to do any real damage and most hacking attempts are done by automated codes that just assume that the table prefix is wp_. I happily donated $100 to this project whether this feature gets added to the UI or not. Thank you guys for all of the great work that you do! 
custom table_prefix (preferably at installation time, not at a live wp) doesn’t do much for security (except blocking possible plugin/theme installed-auto-malware-scripts looking just for wp_* ), but there’s another reason wp made it possible…: using the same db for multiple sites…
just 2c.
Which is unnecessary in a Virtualmin system because you can create a new database for each application/site without even thinking about it. It’s why we don’t provide a prefix option. We support the right way automatically and provide a friendly UI for it. There is no overhead cost to using a new database per application/site (and there is no security benefit to prefixes), so why cram multiple applications into one database? Why make it complicated?
I argued against adding it to the UI because it’s not only not necessary, it would encourage old sloppy habits instead of just doing it the right way from the get go. I understand that it’s a habit for some folks because you’ve worked on systems where you could only have one database, but prefixes were implemented in web apps to work around a problem that doesn’t need to exist. Let your users create new databases for each application. It’s good, actually.
I know it’s hard to break habits, or to believe that something you’ve done for years was unnecessary complexity…but, let’s let go and move forward. We all know Virtualmin is too complicated in a lot of areas, and it’s the instinct to add every little option anyone suggests that got us there (we all do it, Jamie and I have been doing it for years, so poor Ilia gets yelled at because I finally figured out we painted ourselves into a complicated corner by adding everything anybody ever asked for)…we’ve gotta get rid of some of those messy bits, and we can’t do that if we’re still adding more messy bits. I know this one thing is tiny, but they all are tiny, and then 15 years later there are literally thousands of tiny options and we’re drowning in confused users.
just to be clear @Joe, i always use different dbs for websites i manage… not into bad habits 
but -in the past- i also had to work with sites in providers that only allowed one db per account (not necessarily virtualmin hosts), so in some scenarios that “ability” proved helpful.
I agree with @Joe about prioritizing simplicity of the interface so that Virtualmin users do not get confused. However there are two advantages the proposed table prefix feature will unlock that should be considered before a final decision is made.
A multi-site environment for WordPress, TikiWiki et al gives the Virtualmin user the advantage of maintaining just a single code base for all websites. This makes updates, patching and other customization much easier to maintain if one code base is used to service multiple websites / domains.
Caching via opcache etc is so much better when there are 10,000 PHP files from a single install which is used to service 100 websites than 10,000 * 100 PHP files when each website is running off its own install of WordPress / TikiWiki etc.
Virtualmin already has the tools (via its cli) that admins need in order to create innovative, scalable solutions and if this is an important use case and target group for Virtualmin then it should be supported by adding a few features and elements to the Virtualmin interface which compliment the other stuff that innovators are able to accomplish with the features that Virtualmin already offers.
@calport I don’t think I understand what prefix vs. new database has to do with either of those things?
this is called wordpress network, and can be done easily from wordpress.
separate domains can be a bit fuzz, but there are tools for that too.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.