We noticed that not all the users (or clients) are following what is considered best practices when working with WordPress websites. This can often lead to a string of headaches for anyone charged with the task of maintaining those websites later on. Following your feedback and requests, we decided to tackle one of those issues.
The problem
Let’s say you just got a new client who was unhappy with the previous website administration. Or perhaps he simply needs someone to deal with the hassle of website management.
You inherit the website with all the custom work done, take note of the current setup, and proceed to secure the website by creating regular daily backups and tighten up the security.
Everything is going smoothly until the first website crash, when you are promptly alerted by your Uptime Monitor feature that the website is down and you nimbly proceed to restore the website from the latest backup. You inform the client about the crash and how quickly you handled the situation only to find out from the client that the website is not working properly.
After that awkward talk, you discover that they had a custom plugin solution which stored the customer information in a separate, custom-built database table that is now gone forever.
Dealing with custom database prefixes
Our backup system was built according to best practices advocated by the WordPress community. As such, it automatically includes in the backup all the database tables with a prefix defined within wp-config file.
*For the simplicity or this article we are referring to ‘non standard table’ as a database table that doesn’t have the same prefix as the one defined within wp-config.php file.
By thinking ahead, we predicted that not everyone will follow these practices. Or, that some will simply want to have their own custom solution in place. That’s why one of the main options for our backup solution is the ability to include or exclude specific files, folders, and database tables.
However, there are situations (such as the one described above) when you are simply unaware of some custom website work. Or it’s just one of those situations where the user decided to “try doing it himself.”
This is why we decided to improve our current backup solution. And now, we warn you if the system detects any non standard database tables on the website.
How the improvement works
- Backup is performed on the specific website
- The system detects non-standard database tables. This action is triggered during the first backup after the improvement is released (initial, manual, or scheduled).
- If there are any non-standard tables, the user receives a notification. An option to review and/or include those tables in the next backup is then presented.
Non standard database table notification
- User is prompted with a list of found non standard tables and presented with the question:
Do you want to automatically include them in the future backups?
a. Yes – This will include all the non standard tables in all the future backups by default
b. No, I’ll do it myself – Do not include non standard tables by default in all the future backups
*If the user doesn’t select either of these options, they will be notified again after each additional backup until one of the options is chosen.
Note: Users still have the option to include or exclude specific files, folders, and database tables into the next backup, which includes any chosen or previously excluded files or tables.
Key takeaway
From now on, every user will be warned if there are any non standard database tables found on the website during the performed backup.
*tables with a different prefix from the one defined in wp-config file
Conclusion
Hopefully, this improvement will serve as a reminder about the option to include or exclude any files, folders and database tables into the existing backups. And for those rare situations when clients are expecting everything to be included by default, this new notification will warn you about the existence any non-standard WP tables.
This should help mitigate all of those awkward situations and lead to better client satisfaction. Plus, one more item is removed from the checklist of things you need to worry about.
This is our way of saying: “We heard you. We’ve got your back.”
Alec Kinnear
I’m sorry but I can’t join the general enthusiasm. While I admire you guys for trying to think ahead, this is far too prescriptive a policy. We build sophisticated commercial WordPress sites. We had twenty false alert warnings today to answer.
It’s really not up to ManageWP to tell us how to structure our sites nor when to do updates. We prefer security updates and only the few functional updates that would actually improve our clients’ lives.
Non-stop updates and alerts and noise is distracting to a productive agency and wastes the clients’ money on busywork instead of improving their business.
We engaged ManageWP to reduce the interruptions not to generate them themselves.
Marko Tanaskovic
I am sorry to hear that this has resulted in additional and un-welcomed alerts for your agency.
The best solution that I can offer you at this moment, is to choose the “No, I’ll do it myself” option for each website. After that, you will never be warned again for that website.
We hoped that few warning messages were a lesser issue than discovering on website crash that your backup doesn’t include all the database tables for your website. Were we wrong to assume this?
We would never dream of telling you guys how to structure your websites or when (and if) you should do the updates for your websites.
I’ll hope I can get in touch with you directly and help out further if I can.
Alec Kinnear
Marko, I find your answer here anti-productive. We pay ManageWP monthly to provide backups. Those backups should always have included the additional tables. We shouldn’t even be asked about it. If you l
I can’t imagine that some people have enough time to go website by website, including and excluding tables they may or may not want to back up. This is subject to human error, background changes on the website software, etc. If you are contracted (which you are) to provide backups, please do so. Complete backups.
Best practices of the WordPress community – please point us to the document. If it’s Matt Mullenweg’s idea on how to admin a website, this is a non-starter.
* Start by installing JetPack.
* Continue by enabling all possible WordPress.com tracking.
* Make sure to use VaultPress and pay us a hefty (and constantly changing) fee for Akismet.
* Do all major updates all the time, even though we break everyone’s website completely two or three times/year for three or four days at a time.
Your commercial clients will understand that why their website was crippled or down for three days because you were just following “WordPress community guidelines” as per WordPress co-founder Matt Mullenweg.
We spend monthly on ManageWP to provide a professional solution, not more WordPress community amateur hour.
Alec Kinnear
There’s a typo above, please remove “If you l”
I hope you have the courage to publish this comment as it’s the result of eleven years of hard work and experience working on WordPress.
Marko Tanaskovic
I am sorry that you feel that way Alec. Just trying to help by offering you options that we have available at this moment. I understand that this solution is not ideal for you. But we’re always willing to listen to all of your comments and suggestions, in order to improve our solutions even further. In fact, this solution was developed based on user feedback.
Regarding the backups, I understand your position. I really do. It was made in accordance with the guidelines that were used on the WordPress Codex at the time. And it proved to be performant, robust and reliable solution.
But to answer your questions specifically, here are the guidelines on WordPress Codex regarding the database prefixes: https://codex.wordpress.org/Creating_Tables_with_Plugins#Database_Table_Prefix.
And here is the Plugin Development Guidelines for Plugin developers: https://codex.wordpress.org/Writing_a_Plugin#Plugin_Development_Suggestions, where you can also find the links to WordPress coding standards. To quote it specifically: “Do not hardcode the WordPress database table prefix (usually “wp_”) into your Plugins. Be sure to use the $wpdb->prefix variable instead.“.
There are numerous reasons for why you should not deviate from these standards. Security, consistency, multiple WordPress websites on the same database, etc. But to give one practical example: https://wordpress.stackexchange.com/questions/189982/is-it-mandatory-to-use-wpdb-prefix-in-custom-tables
We believe in following these official WordPress guidelines as they create consistency and there is less chance that something will brake down in case of a ‘custom solution’. However we recognized that not all of the users will use or adhere to this guidelines. That is why the option to include or exclude specific database tables, files and folders was introduced into our solution in the first place.
We noticed that there are a small percentage of our users that are unaware that the plugins they use do not adhere to these guidelines, having as a consequence database tables with different prefixes that the one defined in wpconfig, which in turn were not supported by our solution. We wanted to warn those users and make them aware of this, exactly because we wanted them to be able to rely on our backups.
Thank you for setting out your time and contributing with your suggestions. We will definitely take your feedback very seriously and look at how we can use it to improve our solution even further.
Cliff Rohde
Really a great update to the service. Thanks!
Jean-Francois Arseneault
This is a solid update which will improve the robustness of your (and our) solution to clients, thank you!
Kai
Nice work, thanks!
This is only checked during the first backup? What happens, when the customer adds some tables after the first backup ( and is not telling me, for whatever reason)?
Marko Tanaskovic
Hey Kai,
If you want to avoid that situation, you can pick the option to include any non WP tables in all future backups. In that case, if the client adds something without telling you – those tables will automatically be included and you are covered.
Hope this makes your life just a little bit easier and stress free.
Eric Gracieta
it seems that there is a checkbox for that indeed, but no save button if you check or uncheck the box, so you cant apply the setting…
Dave
Thanks Marko! This really brings the backup product to a new level, to a level that really increases trust on the part of users and clients.