When supporting websites that were not developed by us, we always come across interesting surprises.
The DSGVO All in one for WP plugin advertises that it offers a holistic solution for website DSGVO compliance. However, a closer look reveals that it follows less of a well thought-out overall concept. Instead, it only allows influencing the behavior of selected third-party plugins. If you want to use alternative plugins or integrate more than 5 of your own tracking scripts, you will quickly come up against limits that sometimes seem arbitrary.
Nevertheless, for users who are satisfied with the offered features, the plugin basically offers possibility to meet GDPR requirements.
An important feature of any GDPR-compliant solution is the logging of user responses to cookie banners. This means, for example, that consent to tracking can also be tracked at a later date. The competitor Usercentrics also keeps logs.
The crux, however, lies in the method “DSGVO All in one for WP” uses to store these logs.
Logs have a way of taking on a life of their own – they start out very small – and can grow to monstrous sizes.
For our customer, the size of the wp_options table was inflated by over 450% in 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 containing almost 20 megabytes of text data – the MySQL server simply crashed.
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 is to store the logs in a separate table.
This post is not about putting a colleague’s plugin in a bad light. Although the basic version of the plugin is free and offers room for feedback, the WordPress review team overlooked this particular issue. It only becomes apparent when a website has been in operation for a long time or has particularly high traffic.
This example illustrates how architectural errors can be overlooked during the development phase.
Practices such as regular refactoring, external code reviews, or pair programming can help identify such vulnerabilities early, as can automated testing. Admittedly, these measures are resource-intensive and cost time as well as money.
No software, including ours, is safe from such errors. We have to accept that perfect software is illusory. Nevertheless, such errors are avoidable and, if not fixed, can jeopardize the stability of a website.
A pattern we’ve noticed in previous DSGVO plugin reviews: legal perfection often trumps technical excellence.
Therefore, it is crucial to conduct technical reviews of the plugin solutions deployed or being considered.
Our advice: if possible, do without cookie banners – because if no cookie consent is required, no banner is necessary.