Your WordPress plugins might be silently losing business data

If your WordPress site utilizes third-party plugins, you may be experiencing information loss and other bothersome behavior without even understanding it.Like a lot of you, I have actually ended up being rather connected to WordPress over the previous 15 years. It is by far the most popular content management system, powering 28 percent of the Internet, and still the fastest growing, with over 500 websites created on the platform each day. Considering myself well versed in the software, I was shocked to discover– while dealing with a digital style task for a customer– what could be the Y2K of WordPress. Lots of WordPress plugins are suffering information loss, and it appears like this problem will quickly take off if not effectively addressed.The issue is essentially due to that WordPress discards entire datasets even when just one of the information aspects within the set consists of too many characters for the insertion field. Due to the fact that WordPress doesn’t log the data loss or any errors related to it, few designers know the problem. And because of one specific scenario involving keeping a visitor’s information when they’re getting in touch with an IPv6 address, the circumstance is exponentially worse.Example: State a WordPress site owner has actually a plugin installed that lets users

include remarks. Plugins like that typically keep the user’s IP address together with comments they send, for analytics purposes. For several years, plugin developers have actually presumed that IP addresses were always in the standard IPv4, 15-character format that appears like this: Hence, plugin designers typically set the optimum allowed characters for the IP address database field their plugin uses to about 15-20 characters. IPv6 has a much longer 39-character format that looks like this: 2001:0 db8:85 a3:0000:0000:8 a2e:0370:7334. Unbeknownst to many users, site owners, and designers alike, these longer IPv6 addresses are ending up being increasingly prevalent. Those brand-new addresses will not suit the database fields designers have been using for many years. For security functions, WordPress particularly verifies that each part of an information set about to be saved will fit. In the example above, if the IP address is too long, WordPress disposes of the whole data set( not just the large IP address string ). Worse, WordPress does not log a mistake when this happens. The data is merely lost to the ether, without leaving a trace.< a href= > This two-year-old WordPress bug thread demonstrate how long the WP core devs have understood that the neighborhood didn’t like this, however they still haven’t attended to it.Yes, this currently just affects data originating from IPv6 addresses( currently< a href= > about 17 percent of users). While IPv6 use may be in the minority right now, it will not be for long, and as it ends up being the bulk, these inexplicable concerns with information loss will reach pandemic proportions if left untreated.Just how prevalent is this? 1.02 million active WordPress plugin installs are calmly discarding real visitor logs, material

submissions curated by users, and more

, right now, all because IPv6 addresses exist in the data being kept. Here are some other fascinating statistics:50,336 plugins are offered at today 200 plugins(~ 1 in 250 )produce IP address fields that are too short Those 200 plugins have more than 1 million active installs– an overall of 1,023,280. The fix is

  • easy peasy: You merely have to change the table schema for the column that shops IP addresses from 15 to 39(or more ). This problem can impact applications besides WordPress
  • ; really, any application that uses IP addresses and shops them in MySQL/PostgreSQL tables(especially in STRICT mode, which would avoid row inserts)where the column max is expecting a 15-character IP address.Debuggin ‘the plugin I discovered this circumstance while recently dealing with a site that required a rating system that enabled verified users to vote on particular post types. Naturally, I did a search of existing plugins that might satisfy the requirements and found one

    relatively quickly, CBX Ranking, and it was a breeze to set up and get working. Then came the intermittent reports of the form submissions not going through.I invested hours deactivating other plugins, digging through code, and directing users via screenshare . I was not able to narrow it down or find any cigarette smoking weapon. No success message, no error message, no errors in the console log, absolutely nothing in the server logs.

    How could form submissions be stopping working without errors?I kept in mind something I had actually seen in WordPress before: row inserts calmly stopping working if the information strings were longer than the table column optimums. I moved my attention to the back end, and that’s where I discovered the issue and my boss, Erik Neff(the company’s CTO), helped recognize

    exactly why it was happening.MySQL databases, not in RIGOROUS mode, will truncate values if they’re over the max character count for a specific column and will place the new record with a warning. When in< a href = > STRINGENT mode, MySQL will decline the record and will return a mistake. WordPress, on the other hand, won’t carry out an inquiry if it figures out the length is longer than the max, and will rather return incorrect, with no error or warning.When using the WordPress$wpdb- > insert method, you get back a 1 upon success and a 0 upon failure. However a function is called prior to any mySQL statements are executed, and that’s where the problem lies. The function is called protected function process_field_lengths, and it inspects to see if>the information’s length is less than the max allowed length for that table column. If the length is longer than enabled, the whole insert is aborted and incorrect is returned without any mistake message or explanation. This is a recognized concern with WordPress core, and makes debugging that much harder.The CBX Rating plugin we were using didn’t represent this failure point. I inspected the plugin’s table schema and began increasing varchar max lengths across the board. Goal! Not long after, I got wind from users of all types that kinds were now being sent

    successfully.My mind raced to how this could be an epidemic, so Erik and I set out to figure out the scale. The result of a(rather lengthy )check of WordPress plugins yielded a list of every location an IP address field was stated with an incorrect length. You can find those lead to the Google sheet that I have actually revealed. Brett Exnowski is senior developer at Primitive Spark and focuses on intricate web applications.

    Written by 

    Related posts