We found several issues with WPML 3.1 release and we had to take down that version from the downloads page. Instead, there is a Beta version, which includes fixes to all known problems. You will find it in your WPML.org account, under Downloads. Scroll all the way to the bottom, where you can download the CMS Beta Package 3.1.4-b2. This is a ZIP that contains all of WPML’s components.
Before installing, please back up your database. Our own site is currently running this version and we are happy with it.
We will be finishing re-testing tomorrow and will have this as a production release. If you installed WPML 3.1 and your site is stuck due to problems, you can use this beta. Please, please backup your database. If anything goes wrong, it’s easy to go back and we can debug what’s happened.
The biggest news about WPML 3.1 is the new internal languages caching, which offers a performance boost that any site will feel. WPML 3.1 also allows to grant permission to its admin screens to different users and fixes a number of nagging problems.
20% to 50% Less CPU and DB Load
WPML 3.1 uses the same advanced caching techniques for language information, as WordPress uses for posts and taxonomy. WPML now preloads the language information for posts that will appear on the page. It means that many individual queries are collapsed into a single database access. In plain English, the number of queries and the amount of CPU processing goes dramatically down. This improvement is most noticeable on the homepage or blog page, or where ever multiple posts are displayed. Heck, even rendering the standard WordPress menus just got a lot faster.
Are we there yet? Almost. After we eliminated the per-post database calls, other calls became more noticeable. This version of WPML cuts the CPU and processing time by half, for many pages. We are going to continue on this path and gradually optimize more areas in upcoming releases. When you get into it, performance optimization becomes fun!
If you are tracking our Toolset plugins, you might have noticed that a similar performance boost just completed for Views. Now, you can build sites with Views, in a fraction of the time it takes to code them in PHP, and achieve the same performance as you can get with finely optimized PHP. Views and WPML developers worked on this performance optimization together and the results of multilingual Toolset sites are just amazing.
Custom Capabilities for Custom Roles
Did you ever want to create users who can manage translations, but don’t necessarily have full administrator privileges? How about users who will be able to edit strings, or taxonomy?
WPML 3.1 makes this easy, by using custom capabilities. Each admin screen and admin operation in WPML is now linked to a custom capability. Naturally, site admins get all these capabilities by default. You can manually grant these capabilities to other users and roles, allowing them specific access to different parts of WPML.
You can assign these new capabilities using several WordPress plugins. Our own Access plugin lets you define custom roles and grant their capabilities. True, it costs money, but it comes with our guarantee and is also fully integrated with WPML. You will see the different WPML capabilities clearly and accurately and can choose which operations you allow to different role types.
Other WPML 3.1 Features
Besides the big performance optimization and the custom capabilities, WPML 3.1 also includes a number of other features, which may make you happy:
- When setting a value for “This is a translation of”, and the current content already has translations in other languages, each translation gets properly synchronized, as long as there are no conflicts. In case of conflicts, translation won’t be synchronized, while the current content will be considered as not linked to an original (in line with the old behavior).
- Categories, tags and taxonomies templates files don’t need to be translated anymore (though you can still create a translated file). Taxonomy templates will follow this hierarchy: ‘{taxonomy}-{lang}-{term_slug}-{lang}.php’, ‘{taxonomy}-{term_slug}-{lang}.php’, ‘{taxonomy}-{lang}-{term_slug}-2.php’, ‘{taxonomy}-{term_slug}-2.php’, ‘{taxonomy}-{lang}.php’, ‘{taxonomy}.php’
- Administrators can now edit content that have been already sent to translators.
- Added the ability to set, in the post edit page, an orphan post as source of translated post.
Bugs Closed
- Admin Strings configured with wpml-config.xml files are properly shown and registered in String Translation
- Removed max length issue in translation editor: is now possible to send content of any length
- Taxonomy Translation doesn’t hang anymore on custom hierarchical taxonomies
- Is now possible to translate content when displaying “All languages”, without facing PHP errors
- Fixed issues on moderated and spam comments that exceed 999 items
- Changed “Parsi” to “Farsi” (as it’s more commonly used) and fixed some language translations in Portuguese
- Deleting attachment from post that are duplicated now deleted the duplicated image as well (if “When deleting a post, delete translations as well” is flagged)
- Translated static front-page with pagination won’t loose the template anymore when clicking on pages
- Reactivating WPML after having added content, will properly set the default language to the orphan content
- SSL support is now properly handled in WPML->Languages and when setting a domain per language
- Empty categories archives does not redirect to the home page anymore
- Menu and Footer language switcher now follow all settings in WPML->Languages
- Post metas are now properly synchronized among duplicated content
- Fixed a compatibility issue with SlideDeck2 that wasn’t retrieving images
- Compatibility with WP-Types repeated fields not being properly copied among translations
- Compatibility issue with bbPress
- Removed warnings and unneeded HTML elements when String Translation is not installed/active
- Duplicated content retains the proper status
- Browser redirect for 2 letters language codes now works as expected
- Menu synchronization now properly fetches translated items
- Menu synchronization copy custom items if String Translation is not active, or WPML default languages is different than String Translation language
- When deleting the original post, the source language of translated content is set to null or to the first available language
- Updated localized strings
- Posts losing they relationship with their translations
- Checks if string is already registered before register string for translation. Fixed because it wasn’t possible to translate plural and singular taxonomy names in Woocommerce Multilingual
- Fixed error when with hierarchical taxonomies and taxonomies with same names of terms.
Download and Upgrade
As always, the easiest way to get updates for WPML is via our Installer plugin. You can also download WPML manually from your account page.
How do you like this upgrade? Feedback? Ideas? Suggestions? Leave your comments and we’ll get back to you.
Sounds like an amazing update, great work!
And do I read this correctly? Custom Capabilities?! At last 😉 And fantastic news! Can’t wait to give it a go!
Keep up the great work!
Yup. Implemented and documented here:
http://wpml.org/documentation/support/wpml-admin-capabilities/
Very cool, thanks for that one!
That’s great news, we have all been very much looking forward to this much needed speed and resource optimisation update.
But…. its early days but I’m not seeing any improvements in server usage, or page load times after installing this. Could you share your setup (if you used a caching plugin, and what settings you used) to get 20% to 50% Less CPU and DB Load with this update?
Thanks,
Chris
First, you should really separate and check where the actual load is coming from. WPML is one plugin on your site. You also have a theme and maybe other plugins. To look into it, try a plugin like Debug Objects:
http://wordpress.org/plugins/debug-objects/
If WPML’s queries are down 20% or 50%, this makes us happy, but it’s not going to be 20% for your site. It’s just WPML’s part.
Debug Objects will show you everything that is happening between PHP and the database. If you see a pretty huge number of queries that come from WPML, we want to know about it. Sometimes, this happens because plugins and themes bypass the WordPress API. WPML’s cache works similarly to the WordPress posts cache. When a function loads a list of content, everything (now, including the language information) is cached. Then, as it’s displayed, it goes pretty quickly and lightly.
On the other hand, if the theme or other plugin is addressing each item separately, there is no chance for caching and pages take pretty long to display.
So, when you have some data from Debug Objects, please open a support thread in our technical forum. Indicate that it’s for Konrad. Konrad is continuing with the performance optimization for upcoming versions. He will take your DB (if you give it) and see what can be improved. If he finds a way to further optimize WPML, we will do it. Konrad may have other suggestions for configuration changes. This really depends on the issue.
Does this make sense?
Hi Amir,
I’ve been reporting slow performance on the forum since November 2013, and since I’ve been working with my hosting company to try and tune our server in order to improve performance and server load. I’ve tested and tested, and I can assure you that the bottleneck is within WPML!
If WPML is disabled, my CPU usage drops to 5%, and pages are loaded within 1-2 seconds. If WPML is enabled, my CPU usage can go as high as 95% or more within a few visits, and pages load in 10-20 seconds).
Now you may be happy with a 20-50% drop in queries generated by WPML, but at the end what matters is how fast our pages load, and how many resources our sites take.
I’m interested in knowing what setup you are using to benchmark WPML, because I’m not seeing any performance improvements on my servers.
-My live environment which is a 2 CPU / 4 GB Ram managed SSD VPS (using 6 languages, it takes roughly 10-15 seconds for the admin pages to load, and 13-20 seconds for front end pages to load)
-My test environment which is a 4 CPU / 8 GB ram SSD VPS (using 12 languages, it takes roughly the 10-15 seconds for the admin pages to load, and 10-20 seconds for the front end pages to load)
Now bear in mind that these numbers are on dedicated machines, featuring the fastest disks on the market (ssd storage). I don’t want to imagine what the performance would be like on shared hosting…
Anyways would be great to hear from others to see how their experience of 3.1 is. In the mean time I’ll open a support ticket for Konrad so he can help improve our performance.
Thanks
Thanks for explaining this. Of course we want to help. I’ve asked Konrad to contact you and get the information. I hope that you can help us reproduce this and we’ll find a solution.
I had a similar experience with a 7 language site. I had to deactivate string translation – now things are working fine.
I have a similar problam and have got the most fanstastic responses from promises that a new version …… to totala idiotic, irrelevant, philosofic discussions and closed tickets and the problem’s still here. Have Litespeed too where they limit CPU all the time
To Martin: When you deactivate string translation doesn’t the site change to a bloody mess?
Ola
Would you like to give us more details, so that our developers can reproduce your site locally and check where the load is coming from?
Ask Konrad, he’s the one I have been in contact with. If you want more details why not open so I can submit website URL, FTP data and logins???
This seems to be something new from WPML to delay all support an extra day…
Hi, today I have actualiced the plugin and then n error message appeared:
Warning: Missing argument 2 for SitePress::terms_clauses() in /var/www/clients/client0/web3/web/wp-content/plugins/sitepress-multilingual-cms/sitepress.class.php on line 5548
Warning: Missing argument 2 for SitePress::terms_clauses() in /var/www/clients/client0/web3/web/wp-content/plugins/sitepress-multilingual-cms/sitepress.class.php on line 5548
What is going wrong with taxonomies? I had to recover the last version (3.0.2) that was working ok…
Tnahks a lot!!
This is data-dependent and we’re not seeing it in our testing. Can you please report in our forum and indicate that it’s for Konrad? He is working on WPML and is expecting your support thread.
I was pretty excited about the new performance.
The admin is still sluggish with string translation activated (it’s still a very notable difference – about +2.5 sec load time for every page). Server setup is good (ssd), sorry – but it’s WPML.
but frontend-performance of Wpml String Translation seems to be better.
v3
===========================================
Report date: 12. Februar 2014
Sitepress Multilingual Cms – 0.5916 sec – 26.85%
Woocommerce Multilingual – 0.1305 sec – 5.92%
Wpml Media – 0.0075 sec – 0.34%
Wpml String Translation – 1.0003 sec – 45.40%
Wpml Translation Management – 0.0052 sec – 0.24%
v3.1
===========================================
Report date: 13. Februar 2014
Sitepress Multilingual Cms – 0.5505 sec – 23.82%
Woocommerce Multilingual – 0.1395 sec – 6.04%
Wpml Media – 0.0069 sec – 0.30%
Wpml String Translation – 0.2831 sec – 12.25%
Wpml Translation Management – 0.0059 sec – 0.26%
I’m glad to hear that the String Translation is now down to reasonable. It’s not perfect, but better than before. Actually, the String Translation shouldn’t add much time for the backend. Can we contact you to get more information? We’ll need to replicate it locally and check what’s happening.
Hello,
I went through my CMS to Repositories and searched for WPML in the WPML.org repository. I clicked to update the first one that had an update available, and it broke the access to my CMS. My site looks the same, but the URL for my dashboard brings up a completely blank page.
This happened immediately after clicking to update this WPML add-on plugin. Please advise.
I believe I had clicked to update the WPML String Translation add-on, but I’m not positive. However, I do know that it was first on the repository’s list of ones to update. My WPML was up-to-date before today, so if you want to check the ones that were updated today and see which is first on the repository’s list, you’ll know for sure which one I updated.
OK, I didn’t think that I was updated WPML CMS Nav when this crashed, but perhaps I was. When I go to my FTP manager, I see that the plugin wpml-cms-nav was the only WPML one that was modified today. It was modified 35 minutes ago, so this is probably where the error came from.
My issue seems to be the same one that is discussed in this thread: http://wpml.org/forums/topic/extremly-urgent/
Our dev are away already. We’ll handle this first thing tomorrow morning. Did you update only the CMS nav, or everything? Might be a dependency problem, which we should fix.
Excellent, thanks for the response. I only updated one item from the WPML repository. I don’t recall positively which item it was. However, from the FTP records, it appears that /wpml-cms-nav was the only folder that was modified.
Makes sense. I mean, this shouldn’t have happened, but we tested a full update and not a single component, without the main plugin. If you update ALL WPML components, it will work fine. We’ll add a check in the CMS nav component to make sure that it doesn’t get updated before the main plugin. Again, sorry about that. I hope it didn’t cause too much trouble.
To be honest, I didn’t really plan it out and read every detail on the updates page. There were a lot of add-ons on that page, so I was just going in the order that y’all have them listed.
Also, when there is “CMS” in an add-on’s title, the instinctive response (when you’re skimming down a long page) is that the “CMS Nav” add-on is the main plugin. It is smart that you are planning to add a check for the main plugin’s version number.
Thanks again. Take care.
PS – I do not want to overwrite anything. Please confirm that content and styling for translated pages, etc. is in a separate database and not in these folders.
There shouldn’t have been any hard requirement for order of updates. It’s fixed now. We are closing a final version for this release, after complete testing. If you want to wait with updating WPML for another day, I think that it would be better. Then, you can get the automated updates, in whatever order they arrive and with a solid release.
Hi, Amir,
I have waited another day, but I am unclear on how to fix this. It is great that you put a safeguard in for future downloads, but what do I do about the fact that I already downloaded them out of order?
1) Are you recommending that I re-download my WPML Multilingual CMS now?
2) Would this overwrite any of my content or styling?
Thank you.
We’ll get it fixed today. The problem is, the new CMS Nav module depends on the new WPML core update. We’ll fix it so that this dependency doesn’t produce a fatal error. That should never happen.
Should I replace my CMS Nav with my backup folder of CMS Nav?
I assume all content and styling is in a database, and not in the /wpml-cms-nav folder. But, I wanted to check with you before I made this change.
You shouldn’t need to do this. We’ve updated the CMS Nav plugin, so that the order of updates doesn’t matter. On Monday, you can update all of WPML’s components and it should work fine. I suggest doing this on Monday, so that if you need some help, our developers are around.
To clarify:
Are you recommending that I re-download the CMS Nav folder from the My Account page of the WPML site and FTP it to my site? Or am I misunderstanding?
Thank you.
Or should I download and replace WPML Multilingual CMS first?
Dear Amir,
what’s happening with custom fields?!
After the update I stop working with Advanced Costume Fields 🙁
Best regards.
What problem are you having with WPML 3.1 and ACF?
I don’t know if I can really describe, but the fields doesn’t appear on the translation page.
I’ve set the group to appear under page X or page template Y. In the page X they appear and the page template Y they didn’t.
I had to delete the source page and the translation and start it all.
But it seems to be ok now. I don’t know if this was a bug or just a fault.
I also checked the plugin compatiblity and there’s also a vote making 0% incompatible WPML 3.1 with ACF.
Could you please check this situation?
BTW I’m loving WPML 😉
Best regards,
AMP.
We’ll need help reproducing this. If you can get us a DB dump that shows the problem, we can debug it. I understand what you’re saying that it worked before but doesn’t work now, but we still need a full setup to reproduce the problem.
To proceed, please open a support thread in our forum. Include screenshots of the admin, where you show how to setup the groups and their display logic. Then, show where they are supposed to show, but they don’t. The supporter working on this will need to contact you and get your DB, to debug the problem.
After you start that thread, please add another message here, with the link to it. I’ll follow up and see that it gets assigned correctly.
Will this be OK?
Dear Amir.
Thank you once again for your fantastic support.
Trully it feels good when the product is not only the product itself and we see the investement valued.
I don’t think I can reproduce what happened.
I’m not an expert that can reproduce exatly what generated that behaviour.
I will be carefull next time to do a more precise report.
I’m sorry if this contact took your precious time and maybe result in not such a good feedback from my side.
Nevertheless I would like to ask you that in next update to put information on the “View version 3.1.3 details.” since the changelog appears blank. Knowing what’s about to be updated is important for me.
Thank you once again.
Best regards,
AMP.
Sorry for the missing info. Our developers worked until the afternoon on this version and we forgot to write the changelog.
WPML 3.1.3 only fixes several issues that came up after the major 3.1 release:
* Prenvented the new fix for language tables from possibly overwriting custom languages.
* Fixed the default WordPress menu (list of pages) on secondary languages.
* Fixed output of string translation in certain cases, when default language is not English.
* Fixed potential compatibility problems with access management plugins.
* Fixed potential problems with custom category templates.
* Made sure that no matter in which order WPML components are updated, no errors are produced.
Does this help?
Thank you.
It does help.
I’ve done the update already.
This release is not just not ready.
WPML is great, but why rush into pushing an unstable update?
Had to revert to 3.0.1 and string translation 2.0.1 to get string translation to work again. Was simply not translating anymore.
+ white screen of death while updating extensions.
3.1.1 isn’t better on that matter.
This makes me think about your recommandation of using “Installer Extension”.
I relalize it is not suitable when you unfortunately launch a broken update.
Sorry if I sound disapointed about waisting hours of my time on that release.
(too used to opensource dev – way more reliable)
😉
But I am ready to pay for a nice extension and yours is really amazing.
Please do your homeworks next time…
We actually ran a ton of testing, but it seems that the problem you’re having isn’t covered. A white screen means a PHP error, happening sometime early during the render process. Will you have access to an error log file, so that we can tell what the error is?
Before any release, we test WPML on PHP 5.3, 5.4, Apache and Windows servers and different themes. We also limit the memory. However, it’s very difficult to cover every combination with everything else. We’ll do our best to fix it for you ASAP – we just need to know what’s actually happening.
Hi guys,
I too was running into the “white screen of death” after upgrading to 3.1.1.
WP debug showed an error message about the add_cap in line 396 of sitepress-schema.php
Instead of downgrading, I commented out line 396, restarted my browser, logged in again and found all was OK. I uncommented line 396, logged out, restarted my browser and found all was still OK.
I’m unclear as to the reason for this, running multisite 3.81 with modified admin login and a handful of basic plugins. I’m happy enough it all works again.
Thanks,
Hajo
Thanks. This gives us something to work with. That function adds caps to the database. Normally, it should pass without issues. Let me check what can possibly prevent capabilities from being added to admins. Can you give a list of the plugins you’re using? It’s probably a conflict with one of them, managing capabilities.
Hey I had white screen after one of WPML support teams opened and made changes in my live site instead of the sandbox I sent data about. No We are sorry, excuses or anything from WPML. Had to reload a backup and lost a couple of days.
This release has caused a huge number of problems:
Translated pages become unlinked, and the change in the interface for relinking is disturbingly unclear.
Custom fields (using advanced custom fields) do not save their data in the translated page (I have no idea if editing the original language will result in problems and I really don’t want to try).
WooCommerce was completely wrecked on a development site.
This release is completely not ready.
We’ll help you resolve all these issues. I’m not sure about ACF plugin, but we’ll do our best there. If this is running on your development server, I suggest to wait until Monday. Then, you can get the full attention of someone from our development team and get EVERYTHING running correctly. Will this be OK?
I sorted out the missing custom fields by deleting the translated page and recreating it. Not a useable solution for most. I’d also cleared transients etc, which made no difference.
Translated pages becoming delinked when saving. Besides being a bug in itself, the new translation linking interface provides no indication that’s actually what will happen. It’s very ambiguously worded and really not an improvement on having the drop-down list previously used.
WooCommerce I haven’t looked at again. Some of the errors are all orders vanished, despite remaining in the database and there being seven pages of orders. i.e. I can click to the next page but the orders themselves don’t show.
Checkout and cart page also threw errors.
I don’t have time to debug any of this for you any further.
Frances
Cool with an upgrade for 3.1.
I have purchased a lifetime upgrade and still I only see 3.02a upgrade at “my account”
When will I be able to download the latst version?
Thanks
There were a few nasty bugs in that release and we had to pull it down. Fixing them and it will be back, in good shape today (Monday) or, at the latest, tomorrow.
Where can I download the update? Both, the download section and the installer plugin shows me the 3.0.2-a as latest version…
Sorry, it’s our fault. WPML 3.1 had some problems and we had to take it down. I just added a note about it to the top of this post. We’re fixing these problems right now and will have a good version very soon.
Is there a built in way to downgrade from 3.1? We are experiencing some serious issues with 3.1 and have our newsletter in the pipe, but cannot pubish as only the default language is working as expected. We did not get any qualified response yet on our Support Ticket opened on Friday.
Please advise promptly.
Yes. We advised everyone who had problems to downgrade. Log in to your wpml.org account, click on Downloads and you will find the previous WPML version. You should re-download all WPML components which you are using. We already have fixes for all these issues and it will be released very soon. We just need a bit more time and we’ll release a fully tested fix.
We have taken your advise and downgraded to 3.0.2a (which is advertised as latest version). Unfortunately the downgrade broke the Dashboards, we are unable to access them at the moment. The frontend still works fortunately.
Is this a known problem?
Did you do that with ALL of WPML’s components? If you updated all and downgraded only the main WPML, it might do that. Use an FTP program and upload all of WPML’s components that you use, from our Downloads page.
There are no database changes between WPML 3.0.2 and 3.1, so upgrade / downgrade should go smoothly.
If you are still getting a PHP error, can you tell us what it is?
Thank you for your quick reply. I had to first uninstall(!), not just disable ALL WPML plugins and then install them again. Now backend is working smoothly again. Thank you for your support.
Amir, are you able to offer a git repository of your release zips? I’m not asking for your full code history, which is probably a competitive advantage, but just replacing the release zips. It’s painful tracking versions of all your components on my own. I think it’s obvious by now big f-ups are always bound to happen, where “git blame” is the first step back to sanity.
I’m not sure that we can do this. The mess that we have now with WPML 3.1 is not going to continue much longer. Right now, we have 6 developers working on the re-testing and bug fixes. We’ll handle this, as we should and there will not be a need to go back and forth between versions. Of course, I’m not very happy about the situation that we have now, but it’s a very temporary thing and it’s not what we’re used to. After this is done, we’ll have to check what went wrong in our normal QA process.
I’m not talking about just the 3.1 incident. You won’t be able avoid mistakes in the future, either. Nobody can.
As for git, can you give me any reasoning why your first instinct is “no”? Would you be open to posting a poll to find out how much interest for this is out there?
When will a stable update be released?
The current beta (3.1.4-b4) is fucking up my categories, when i save a post that should be duplicated in other languages. =(
Of course we want to resolve this. Did you report the details in our forum?
We need to know:
– What you are doing
– What you are seeing
– How it’s different than what you expect
I know that it sounds trivial, but our support people and developers are going through each and every problem report and handling it. If they get the complete description from you, they can reproduce it quickly and handle it. If you can prepare screenshots and include in the thread, it would be great.
In the title of the support thread, please indicate that it’s related to WPML 3.1.x, so that your support thread goes directly to our developers. You can paste here the link to this thread and I’ll follow up.
Hi Amir, thank you for your fast reply. Just realized there is a new blog entry regarding this topic.
Here is the link to my problem: http://wpml.org/forums/topic/wpml-3-4-1-losing-taxonomy-relationships-from-custom-post-types/
Even after the update (Version 3.1.6b2) of WPML I keep getting this error:
[Tue May 27 20:29:15 2014] [error] [client 178.117.41.160] PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 76 bytes) in /var/www/wp-content/plugins/sitepress-multilingual-cms/sitepress.class.php on line 10192
I’ve disabled the W3Tcache plugin already. I get the error when I try to translate a post or remove a post.
I’ve searched for days already on this bug. Any help is welcome.
The error that you are reporting appears to be memory exhaustion. You have quite a lot of memory on that server, so something is eating it up. I don’t think that it’s related to anything between WPML and W3TC.
Are you using a great number of other plugins also? I’m going to put you in contact with one of our developers, to see if something in WPML is responsible for this memory overflow.