Resolved Default table prefix: set default and disable security measure

[davemoondog]

Hi,

is it possible to set the default table prefix to be wp_ when installing WordPress and to disable the security measure, that screams DANGER when you are using the default database prefix?

cheers
Dave

PS: Sorry for the double post, I'm new here ;-)

 

[Brujo]

to push it up a bit... I am also interested in an answer to this question. If you search in the internet it is more a question of faith if this offers you more security at all. Additionally this function to change the prefix with the toolkit has already brought me some tickets, because after executing it sometimes wordpress was broken afterwards. Mostly it was due to entries in the wp config, but it shows it is not only fire and forget

For example see a link to it: https://www.wordfence.com/blog/2016/12/wordpress-table-prefix/ and I am sure the opposite as well for example Security through obscurity

 

[davemoondog]

Thanks @Brujo for joining the conversation. The article you posted summarizes pretty well why this security measure is not as essential as Plesk makes it out to be.

My main pain point though is that it's way too easy to change the prefix of production sites by accident. When you open the security tab the option to change the prefix is selected by default so you only need to click the "Secure" button and your site is now broken.

 

[Brujo]

My main pain point though is that it's way too easy to change the prefix of production sites by accident.

I'm totally with you there. Also I've had the situation sometimes that customers have done this because of the warning and then the website didn't work anymore and this should be avoided.

@custer - it would be nice if someone from the Wordpress-toolkit team would join the discussion, we have a "small concern" that can surely be solved in different ways. we don't necessarily want to discuss now whether or not this prefix change makes sense. We are more concerned with the fact that if the warning is displayed in such a way that the customer reacts to it and simply does it and it can lead to the Wordpress pages no longer working. of course we will also support Plesk to find out when it fails.

 

[davemoondog]

Hi again,

is there an official Pleskian, that could comment on this issue? @IgorG @custer @zanuda

Thanks in advance

 

[custer]

Hi everyone,

We're planning to introduce the ability to define the default DB table prefix in the upcoming WPT 4.9 release. This feature will allow server admins to make sure that all new WordPress installations on the server have the same table prefix they've defined in the Global Settings. Note: this prefix can be overridden by users during the WP installation -- it's just a default, after all.

Now, WPT will usually try to change the table prefix if it's 'wp_', but if you specify this prefix in Global Settings, WPT will not change it during the installation of WordPress. However, the security indicator will still go red, and this is something we cannot easily change at the moment, as it requires rethinking our approach to security measures and changing a lot of code. We do plan to reinvent our security measures some time in the future, but I don't have a specific timeframe for that. A possible workaround for the security measure trigger would be to set the default prefix to something like 'wp__', for example.

Let me know if you have any questions.

 

[custer]

I would also like to note that changing the table prefix during the installation is safe and shouldn't cause any issues. Changing the table prefix for an existing site, though, might cause issues with certain plugins and themes written by inexperienced or careless developers.

 

[davemoondog]

@custer After more than 2 years I wanted to check if there were any updates on this or if anything might be planned for the future. Still hoping to get this sorted out

 

[Kaspar]

@davemoondog it looks like a feature to set a default DB table prefix has been added in the WPT version 4.9, back in July 2020. From the change log:

“Global Settings” screen now has the option to define the default database table name prefix for new WordPress installations

 

[davemoondog]

@Kaspar I'm aware of that option. The problem is that the default table prefix "wp_" is seen as a critical security issue by WP-Toolkit.

If we make the conscious decision to use "wp_" as the table prefix for all sites (for which we have several reasons) we'd like to not have ALL sites flagged with having security issues. It's a huge drawback because we lose the ability to quickly identify sites that really have issues in our eyes.

Plesk is not used outside our company, so we don't have this issue, but @Brujo mentioned this, and I think it's quite relevant: Clients who are not that knowledgable can and WILL get triggered by the red security indicator to solve all issues by any means necessary. Which unfortunately leads them to destroy their live sites by changing the table prefix, not knowing the consequences of that.

 

[Kaspar]

I see, so it's actually about the security warning.

If we make the conscious decision to use "wp_" as the table prefix for all sites (for which we have several reasons) we'd like to not have ALL sites flagged with having security issues. It's a huge drawback because we lose the ability to quickly identify sites that really have issues in our eyes.

That makes sense. It would be nice if there was an option to disable certain security checks/measures in WPT (via a panel.ini setting for example). Feel free to create a feature suggestion on Plesk Uservoice for this. I'd be happy to give it my vote. That being said:

[...] I think it's quite relevant: Clients who are not that knowledgable can and WILL get triggered by the red security indicator to solve all issues by any means necessary. Which unfortunately leads them to destroy their live sites by changing the table prefix, not knowing the consequences of that.

I like to argue that it's actually not that relevant at all in the grand scheme of things. I, for one, never had this happend with any of my customers. I am not saying this could never happen, but it feels like a rare scenario. And as @custer already pointed out: if changing the table prefix causes issues it's most likely caused by "plugins and themes written by inexperienced or careless developers". Which in my experience are often the ones introducing serious security issues to Wordpress sites. So in a way a customer that breaks his/her website by (mindlessly) applying the table prefix security fix in WPT is doing themselves and you a service by letting you know they are using a bad theme or plugin.

 

[davemoondog]

@Kaspar Thx for taking the time to answer in detail.

Your point about bad plugins is good one, thx for pointing that out. I haven't thought about this issue like that before