Skip Navigation

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.

WPML 3.4 - the String Translation is taking longer to load because we are preloading a whole lot of strings
WPML 3.4 – the String Translation is taking longer to load because we are preloading a whole lot of strings
String Translation is down, but now the have a big string_pages table
Loading time of String Translation is lower, but now we have a big string_pages table.
We split the string_pages table to two smaller ones, but an extra index makes selects slow
We split the string_pages table to two smaller ones, but an extra index makes selects slow
Smaller tables and correct index. We're finally good.
Smaller tables and correct index. We’re finally good.

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.


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.

6 Responses to “WPML With Bug Fixes and More Speed”

  1. Fantastic, great work guys can’t wait to try it out as speed has always been an issue.

  2. Sorry, but I dont give a flying fuck about speed improvements. Get the ACF support done properly (if s/o paid me big money, I’d do it myself, but I simply aint got that nor the time!) – then we can talk about nice-to-haves!

    Else, WPML stays the PITA is has always been past the last 5 years.

    cu, w0lf.

    • We are actually working with Elliot, the author of ACF on the last remaining compatibility issues between ACF and WPML. This development will complete in about a week. Would you be interested in beta testing, to see if this resolves all the issues that you are having?

      I don’t want WPML to be a pain in your a**. What problems are you having? I’m sure that we can handle them.

      • It has been a constant PITA since consumers started frolicking about it (ie. since 2010/2011). Partially broken duplication, this and that not working, because of simple solvable GUI issues or missing cross-checks, bad or missing documentation (Codex anyone?), and so on. That mostly includes regular scenarios like WooCommerce, Custom Post Types, ACF, etc. pp. Anything but non-regular usage.

        Half of the time I had to revert using qTranslate(X), making my job much harder and life more miserable.

        Currently, I’m developing a few helpers that might make life less hard, including some shortcodes working quite similar as the qTranslateX ones – which is one of those nasty ironic jokes of life, having had started with qTranslateX and only switched to WPML thanks to the customer preferring it.

        Nah, I dont think WPML will ever be less than a total PITA. After 6 years or so in the making, nothing has changed. Sorry that I dont believe it will ever change 😉

        BTT: We will see. Like I said, I dont believe your ways will change. It might work for a few months, then its destined to break again, because nobody cares about it anyway }:->

        cu, w0lf.