Your WordPress plugins is probably silently losing enterprise statistics

If your WordPress web page makes use of 0.33-celebration plugins, you may be experiencing records loss and different tricky conduct without even knowing it.

Like a lot of you, I’ve grown to be quite connected to WordPress over the past 15 years. It is by far the maximum famous content material control machine, powering 28 percentage of the Internet, and nevertheless the quickest growing, with over 500 sites created on the platform each day. Considering myself properly versed within the software, I became amazed to discover — even as running on a digital layout challenge for a patron — what could be the Y2K of WordPress. Many WordPress plugins are struggling statistics loss, and it seems like this problem will soon explode if not properly addressed.

The difficulty is basically due to the reality that WordPress discards whole datasets even if best one of the elements of the records inside the set includes too many characters for the insertion subject. Because WordPress doesn’t log the information loss or any errors related to it, few developers are aware of the difficulty. And because of one precise situation involving storing a traveler’s records after they’re connecting with an IPv6 cope with, the state of affairs is exponentially worse.

Example: Say a WordPress website online owner has a plugin installed that lets customers upload remarks. Plugins like that generally store the user’s IP address along side remarks they put up, for analytics functions. For years, plugin builders have assumed that IP addresses have been constant within the preferred IPv4, the 15-individual format that looks as if this: Thus, plugin developers typically set the most allowed characters for the IP address database subject their plugin makes use of to about 15-20 characters. However, IPv6 has a much longer 39-character format that looks as if this: 2001:0db8:85a3:0000:0000:8a2e:0370:7334.

Unbeknownst to many customers, web page owners, and builders alike, those longer IPv6 addresses are getting an increasing number of good sized. Those new addresses received match into the database fields developers have been the use of for years. Furthermore, for security purposes, WordPress especially validates that each part of an information set approximately to be saved will match. In the instance above, if the IP deal with is too lengthy, WordPress discards the complete information set (not simply the oversized IP cope with string). Worse, WordPress doesn’t log mistakes whilst this takes place. The information is really misplaced to the other, with out leaving a trace. This -year-vintage WordPress trojan horse thread suggests how lengthy the WP center devs have acknowledged that the network didn’t like this, however, they nonetheless haven’t addressed it.



Yes, this presently just influences information coming from IPv6 addresses (presently about 17 percent of customers). But at the same time as IPv6 use may be in the minority right now, it ain’t be for lengthy, and as it becomes the general public, these unexplained issues with records loss will reach pandemic proportions if left untreated.

Just how significant is that this?

1.02 million energetic WordPress plugin installs are silently discarding actual vacationer logs, content submissions curated with the aid of customers, and more, proper now, all due to the fact IPv6 addresses are present within the facts being stored. Here are a few other thrilling stats:

50,336 plugins are to be had at wordpress.Org these days
2 hundred plugins (~1 in 250) create IP deal with fields which are too short
Those 2 hundred plugins have over 1 million lively installs — a complete of one,023,280.
Here’s a publicly-handy Google Sheet my group created that lists all regarded offending plugins. For every plugin, that sheet includes one example where that plugin publicizes an IP deal with a subject that is too brief.
The restore is easy peasy: You definitely want to change the desk schema for the column that shops IP addresses from 15 to 39 (or greater).


This hassle can affect packages other than WordPress; surely, any utility that utilizes IP addresses and stores them in MySQL/PostgreSQL tables (particularly in STRICT mode, which would save you row inserts) where the column max is awaiting a 15-character IPv4 IP address.

Debuggin’ the plugin

I exposed this case even as currently operating on a domain that needed a rating system that allowed authenticated customers to vote on particular put up types. So certainly, I did a search of present plugins that would meet the necessities and discovered one pretty fast, CBX Rating, and it became a breeze to configure and get running. Then got here the intermittent reports of the shape submissions now not going via.

I spent hours deactivating other plugins, digging thru code, and guiding customers via screen share. I changed into not able to slender it down or find any smoking gun. No achievement message, no error message, no errors inside the console log, nothing within the server logs. How may want to form submissions be failing with out errors?

I remembered something I had visible in WordPress earlier than row inserts silently failing if the statistics strings were longer than the desk column maximums. So I shifted my attention to the again cease, and that’s in which I located the problem and my boss, Erik Neff (the enterprise’s CTO), helped pick out precisely why it changed into going on.

MySQL databases, not in STRICT mode, will truncate values if they’re over the max individual count number for a specific column and could insert the brand new document with a warning. When in STRICT mode, MySQL will now not be given the report and will return mistakes. WordPress, on the other hand, received execute a query if it determines the duration is longer than the max, and will rather go back fake, with out a mistakes or caution.

When the use of the WordPress $wpdb->insert method, you get back a 1 upon fulfillment and a 0 upon failure. But a function is referred to as earlier than any MySQL statements are completed, and that’s wherein the trouble lies. The feature is referred to as protected feature process_field_lengths, and its assessments to peer if the records’ length is less than the max allowable length for that desk column. If the period is longer than allowed, the entire insert is aborted and false is lower back with no blunders message or clarification. This is an acknowledged problem with WordPress center and makes debugging that plenty more difficult.

The CBX Rating plugin we were using didn’t account for this failure factor. I checked the plugin’s desk scheme and started increasing varchar max lengths throughout the board. Touchdown! Soon after, I got the wind from users of every kind that all paperwork have been now being submitted correctly.

My mind raced to how this will be an epidemic, so Erik and I set out to determine the dimensions. The result of an (alternatively prolonged) test of WordPress plugins yielded a list of each area an IP deal with area became declared with an incorrect period. You can locate those outcomes inside the Google sheet that I’ve made public.