WPML 3.5.1.1 With Bug Fixes and More Speed

WPML 3.5 included a major change to String Translation. As we went live with it, we learned about a number of cases that didn’t show up during development. The follow-up updates handle all issues and further improve performance.

Fixes since WPML 3.5

• Fixed uncaught exception in cases where domain_name_context_md5 column didn’t exist in icl_strings table
• Fixed Fatal error: Uncaught exception ‘InvalidArgumentException’ with message ‘Argument ID must be numeric and greater than 0 when filtering permalinks
• Fixed fatal error appearing during upgrade: WordPress database error: specified key was too long; max key length is 1000
• Fixed Fatal error: Declaration of WPML_Post_Element::get_type() must be compatible with that of WPML_Translation_Element::get_type() for PHP 5.2
• Removed leading backslash \ to avoid warnings in PHP before 5.3

Speed improvements

We’ve made a few tweaks to the new table that stores which strings appear on what page. These changes significantly reduce the table size, improve performance and reduce memory consumption.

• Split one big table with redundancies to two small and efficient tables
• Optimized table indexes
• Limited the possible table growth for sites that use URL arguments, by using a whitelist of arguments that modify page selection

The results

We took some measurements of the performance of our own site during the version updates. You can see how load decreased, then went up (when the table indexes were not optimized) and now it’s back and below the original.

The absolute numbers in all these graphs are less significant, because they were taken in different days of the week. On Fridays, our traffic is far lower than on Mondays. To understand the changes, look at the proportion between the segments. You can see that originally, the icl_strings access took roughly the same as fetching posts (which is not a good thing). Now, all of WPML’s database access take in average 1/3 of the posts queries. This is very significant, because WPML needs to load a whole lot of strings, while WordPress needs only a few posts.

A better process next time

We had to release this update before being able to run the complete performance measurements, because it included changes for WordPress 4.6. In the future, we’ll make sure to decouple performance improvements from WordPress compatibility. As soon as a new version of WordPress reaches “release candidate”, we’ll do a minor release with only compatibility changes. We’ll keep time to run longer performance changes, unrelated to bug fixes and compatibility updates, and only release them after we’ve very happy with the results.

The next release of WPML will continue to be about stability and performance. 99% of the sites running WPML are working smoothly now, but there are a few sites that use “unique” configurations of the web server, PHP or database. We’re going to address these in the upcoming minor release. We’re also including a few more performance optimizations, which will make both the admin and front-end leaner.

Feedback?

if you have questions, ideas and suggestions, please add your comments. We’re very happy to get your feedback and we do our best to deliver what you need.