After months of development, we’ve just released WPML 3.5. This version focuses on String Translation, improving performance and adding few features. WPML 3.5 also handles a few compatibility issues with WordPress 4.6.
Compatible with WordPress 4.6
WordPress 4.6 is almost ready (due tomorrow morning). This update of WPML includes a number of changes to support WordPress 4.6. Before you upgrade WordPress, be sure to upgrade WPML and all its add-ons. Like we recommend in every WordPress release, you should update with caution. We always test first on a staging site, review the site and see that nothing is broken, check the PHP error log and see that it’s clean and then update. Before updating the production site (even after we’ve tested on a staging site), we prepare a complete backup.
Usually, we never need to use that backup. However, in the very rare cases when it’s needed, having this backup will prove to be a good idea.
String Translation improvements
We introduced the changes to String Translation in the WPML 3.5 beta announcement blog post. Since the betas, we’ve made more performance improvements to String Translation in the admin and front-end. The overall performance improvement numbers depend on your content, the theme, other plugins and PHP version.
The graph on the right looks very promising, but please keep in mind WHAT we’re showing there. These are the numbers for String Translation only. Of course, a real site has more running than WPML String Translation. On our production site, the overall improvement is about 5% in CPU and 10% in memory. From that, you can see the part that String Translation was responsible for. We’re also running PHP 7.
Generally speaking, sites that have a large number of strings, not so many other plugins and run PHP 5.x will see the greatest performance improvement. PHP 7 is already a lot faster than PHP 5, especially for the functions that String Translation uses. There’s a significant performance improvement with PHP 7, but it’s smaller than on PHP 5 (which is a good thing). Sites that have many many plugins are likely to be less optimized for performance, so the overall gain from the new String Translation is less significant.
Since the performance gain in WPML 3.5 is both in CPU and in memory allocation, it’s best to measure the actual server load, rather than only use a profiling plugin. Profiling plugins are great, but they don’t give you the full picture of how your site handles real load.
I recommend to check:
- The overall server load, both CPU and memory
- The response time for front-end pages
- The response time for admin pages
We will be monitoring the server loads of our sites and will post updates about the changes that we’re seeing. We need a week to collect these updated stats, so that we can show a meaningful comparison.
A bit more coming in WPML 3.5.1
The last pocket of inefficiency is in the interaction between GetText and WPML. Today, translation happens twice. WordPress loads .mo files, which sometimes are huge. Then, WPML basically overrides all translations in String Translation.
You can see how this is wasting resources.
In WPML 3.5.1, we are planning to prevent WordPress from loading .mo files for contexts that String Translation is handling. You will not lose anything and only gain in page load time. This gain can be very significant, because WPML now only loads the strings that are needed for each page (while WordPress would load the entire .mo file).
WordPress 4.6 changed the loading of .mo files. Now that it’s out, we can complete this feature in WPML.
A glitch in String Translation update causes a (harmless) warning
Immediately after release of WPML 3.5, we noticed a cosmetic glitch which may happen in some of the sites updating automatically. These messages will appear only once and they don’t cause any problem to the site.
This glitch doesn’t look nice, but it’s not causing any damage. Since WPML 3.5 is needed for WordPress 4.6 (which is coming out tomorrow), we didn’t hold with that update. We’ll fix that glitch tomorrow morning and release a minor update for WPML String Translation.
Removed the WPML Widget from the WordPress Dashboard
Until WPML 3.5 there was a WPML Widget on the Admin Dashboard. This widget started with good intentions, but grew to be a resource sink. Over time, we kept adding all sorts of information to that widget. It pulled and displayed recent blog posts, the languages summary and translation status and a host of other trivia. You can imagine that all this wonderfully useless information required database queries (and some remote queries) and PHP processing.
We decided that the added value in this information doesn’t justify the load it produces and we removed it. If you feel that any of that information was useful to you, let us know. Our admin dashboard became a lot faster, just by removing that widget.
As a side note, while reviewing that widget, we noticed a few similar widgets, suggestions and “nice to know” tips from other plugins and themes. If you’re seeing them on your dashboard, make sure that they’re not slowing down your sites (like WPML’s widget did).
Download and update
As always, the best way to get updates to WPML is by registering your sites and updating automatically. You can always download from your WPML account. Be sure to update all of WPML’s components that you’re using.
Feedback?
Let us know your thoughts about this update by leaving a comment. We’re eager to know how it’s working for you. If you need help resolving problems, please first create a ticket in our technical support forum. Then, add a comment here with a brief description and a link to the support ticket.
Great work. Did some testing and no errors/bugs so far. The speed difference is also noticeable. Also the admin seems to be faster 🙂
Thanks for letting us know. The entire WPML team will be happy with this feedback.
When searching I get this error. I will look into it tomorrow.
[17-Aug-2016 16:37:34 UTC] PHP Fatal error: Uncaught exception 'InvalidArgumentException' with message 'Argument ID must be numeric and greater than 0.' in /home/develop/public_html/wordpress/wp-content/plugins/sitepress-multilingual-cms/classes/translations/class-wpml-translation-element.php:28
Stack trace:
#0 /home/develop/public_html/wordpress/wp-content/plugins/sitepress-multilingual-cms/classes/canonicals/class-wpml-canonicals.php(29): WPML_Translation_Element->__construct(-1, Object(SitePress))
#1 /home/develop/public_html/wordpress/wp-content/plugins/sitepress-multilingual-cms/classes/canonicals/class-wpml-canonicals.php(51): WPML_Canonicals->must_filter_permalink(-1)
#2 /home/develop/public_html/wordpress/wp-content/plugins/sitepress-multilingual-cms/inc/url-handling/wpml-url-filters.class.php(124): WPML_Canonicals->permalink_filter('https://dev-wor...', -1)
#3 [internal function]: WPML_URL_Filters->permalink_filter('https://dev-wor...', Object(WP_Post))
#4 /home/develop/public_html/wordpress/wp-includes/plugin.php(235): call_use in /home/develop/public_html/wordpress/wp-content/plugins/sitepress-multilingual-cms/classes/translations/class-wpml-translation-element.php on line 28
Thanks. We’ll check. Did you create a ticket about this in our support forum? It would be easier to follow up there. If so, please give me the link to the support thread and I’ll assign it to the right person.
It is related to category search in Relevanssi Premium. Here is my support topic: https://wpml.org/forums/topic/wpml-3-5-update-not-compatible-with-relevanssi-premium/
Thanks for creating the problem report. I see that it’s related to Relevanssi Premium. Would you be able to send the plugin to our support, so they can debug the problem?
Hello Koen,
We have released a beta of WPML (Core and String Translation) to fix this issue.
Is called “beta”, this version only contains fixes to issues reported after the release of WPML 3.5.0 and you can safely use it in production sites (even though, a backup is always recommended).
Please head to https://wpml.org/account/downloads/, scroll way to the bottom and download the “CMS Beta Package” (mind that it can be only installed manually).
I hope this helps.
The beta did not fix it. When I know more about this issue I’ll start a support topic.
I think the error was cached. It seems to work again. Thx for the beta!
It is crashing on particular searches. I think it is multisite related.
I also notice speed improvements, great job! Also a very good initiative to remove the dashboard widget; may other plugin developers follow your steps 😉
Does this super, great release also fix known bug with double redirection? We give a shit if there is no dashboard widget since you dont face true and priority 1 bug. This is so Lame, but I guess you are happy if we all pay you for support…
We’re checking this. It should be covered in WPML 3.5.2. We’re closing 3.5.1 with a few other fixes (which are probably not needed for you, but are important to other clients with different site configurations). 3.5.2 should follow soon after. I’m sorry for this delay and I understand that this is not helping your sites. I hope that you understand that we’re doing our very best.
I installed WordPress 4.6, Enfold Theme 3.7.1, Woocommerce 2.6.4 and WPML 3.5.11 with PHP 7.0.10 and memory limit 768MB on SiteGround Server.
It gives me internal server error (500).
Is these compatible?
Sorry, I missed this comment before. The combination of theme, plugins and PHP should be fine. If you’re getting a 500 error, we would need to see the detail of the error. You can see how to enable debug logging here:
https://wpml.org/documentation/support/debugging-wpml/
When you have the specific error, please open a new thread in our technical support forum. Our supporters will be able to understand the problem and get you to a solution.
https://wpml.org/forums/forum/english-support/