Problems caused by bloated wp-options table
When we maintain websites that we have not developed ourselves, some blossoms come to light.
The plugin GDPR All in one for WP promises a comprehensive solution for the GDPR security of a website – on closer inspection, however, we see less a comprehensive concept, but a collection of supported plugins that are somehow made GDPR compliant – if you want to use alternatives, you quickly have a problem. Or if you want to install more than 5 own tracking scripts – some limits seem arbitrary.
But if you are satisfied with the feature set, the plugin should enable a clean technical implementation of the GDPR requirements.
This also means that the reactions to the cookie banner should be logged so that, for example, consents to tracking can still be traced afterwards – Usercentrics also keeps logs for this purpose.
However, it’s about the way GDPR All in one for WP stores the logs.
wp_options is not for logs
Store data correctly
Logs have it in themselves that they like to develop a life of their own – they start very small – and can take on monstrous sizes.
For our customer, the size of the wp_options table was inflated by over 450% within about half a year – from about 4.18 MB to 23.80 MB.
We noticed this because an import of the wp_options table via PHPmyAdmin, Plesk and various SQL dump scripts failed – the reason was a single insert query for a field that contained almost 20 megabytes of text data – the MySQL server simply broke off.
But not only the maintenance is made more difficult – also the website performance decreases noticeably – over time more and more. WordPress options are loaded by default with every page view. With each page view, the query is started and the loading time of the page is unnecessarily increased.
Update – After comment of the plugin author must be corrected:
By default, the log entry is not loaded and therefore only directly affects performance when a new entry is added or the existing entries are read out, which does not happen with a simple page view.
Best practice remains to store the logs in a separate table.
Refactoring & Pair Programming
Works – not enough
This article is not about discrediting the plugin of a developer colleague – the basic version is free and everyone has the opportunity to express feedback, just as the Plugin Review Team of WordPress did not notice the problem – the problem only occurs when a website is in use longer or has many visitors.
Rather, the example is an example of how architectural errors can arise in development and no one notices them.
Regular refactoring, code reviews by third parties or pair programming can address such problem areas well – up to automated testing. All this is time-consuming, costs time and money.
Our software is not immune to this either and we all have to admit that there can be no perfect software. Nevertheless, such errors are of course avoidable and sooner or later an escalating log file can affect the stability of a website.
With GDPR plugins reviewed by us in the past, however, a common thread runs through: legal excellence often stings technical excellence.
This makes it all the more important to have a technical examination of the plugin solutions used or desired for the specific purpose.
Our recommendation would be in principle anyway: No cookie consensus required, so the renunciation of cookie banners.