Recently a customer decided that his website, which is hosted externaly, should move to our plesk webserver since we also manage other sites and all domains.
The site is a WordPress site. We’ve imported all sql data into a new database, copied all files and changed databasecredentials in the config file.
Since the domainname didn’t change everything was working perfectly. As a good practise we apply some security-improvements for WordPress sites from within Plesk.
Everything keeps working until we apply the ‘change database prefix’ option. What this does is the following to the help-information-link:
WordPress database tables have the same names in all WordPress installations. When the standard wp_ prefix to the database tables’ names is used, the whole WordPress database structure is not a secret and anyone can obtain any data from it. The security check should verify that the prefix to the database tables’ names is other than wp_. If the security check failed and you choose to secure the WordPress installation, the maintenance mode is turned on, all plugins are deactivated, the prefix is changed in the configuration file, the prefix is changed in the database, the plugins are re-activated, the permalink structure is refreshed, and then the maintenance mode is turned off.
After we apply this improvement the site still works but all pages which show custom field data do not display that data anymore. I can’t image there is a hardlink to the database using the ‘wp_’ prefix, it should also dynamically query the prefix.
Anyone experienced this before or technical enough to provide a solution?
There is nothing that I know of in ACF that stores any information about the WP table prefix. ACF uses WP function the get and set values. The ACF functions are simply wrappers for WP functions and what anyone can do using those functions.
On a side note, altering the table prefix does nothing to improve security of a site: https://www.wordfence.com/blog/2016/12/wordpress-table-prefix/
There are multiple recent sources saying it does improve security, including a VERY big company behind Plesk and highly rated plugin developers like WMUDEV.
I read you article and while it seems correct there is a litte point they’ve missed: the possibility for SQL injection does not mean they can output contents of the database. They can change the content but not extract data. Also, there are a lot script kiddies around that run automated scripts that are hardcoded with the ‘WP_’ prefix to check if SQL injection works.
I agree, it doesn’t guarantee anything but no security ever will.. All you can do is put in as much fences to block an attacked that make you feel are a contribution to a safer enviroment and worth the effort. It doesn’t harm anything to change the prefix but possibly blocks some hackingactivity that otherwise would’ve been successfull…
Anyhow 🙂 I couldn’t quite manage to get the adminmenu running when manually changing the prefix, some records also needed to be updated. In the end I installed the plugin DEFENDER which also has the option to change the databaseprefix. When I used that option all kept working with an altered databaseprefix. I never had any problem before using the Plesk option to change the prefix and the only thing not working that I could see were the custom fields…
If there’s a problem with changing the prefix then I’d look elsewhere, maybe in another plugin is causing it or the theme? It would seem that something would actually need to be saving the prefix, or assuming that the prefix is wp_ instead of using $wpdb->prefix.
You must be logged in to reply to this topic.
Welcome to the Advanced Custom Fields community forum.
Browse through ideas, snippets of code, questions and answers between fellow ACF users
Helping others is a great way to earn karma, gain badges and help ACF development!
© 2022 Advanced Custom Fields.