Skip Navigation

This is the technical support forum for WPML - the multilingual WordPress plugin.

Everyone can read, but only WPML clients can post here. WPML team is replying on the forum 6 days per week, 22 hours per day.

This topic contains 19 replies, has 2 voices.

Last updated by Ricardo Alday 1 year, 11 months ago.

Assigned support staff: Ricardo Alday.

Author Posts
August 2, 2018 at 9:15 am


This is a follow up to the thread as it was marked as "resolved" too soon (I was able to save 3 products, asked the person introducing this data to resume the woirk on it and she was able to do exactly 3 products before the issue came back).

As you are having problems replicating the issue we found the easier way was to make a video of it, you can find it here, freshly made this morning: hidden link

Ps.: we waited for 5 minutes and still not saved, we could have waited for 10 minutes.
Ps2.: The person working on this said the 3 1st fields are saved (title, slug and content description) even when the "save fails".
Ps3.: We dont have the alternative server available anymore, the admin access for is still available but we are actively working on it, is it posible to duplicate it on your side for testing purposes?

August 2, 2018 at 5:35 pm #2606484

Ricardo Alday


Thanks for getting in touch. This is an issue with the way that WP updates meta values (field values). Every update query for every field produces at a few DB queries. First WP checks to see if there is already a value for a field and then it updates the value for the field. Sometimes it then does a new query to get the new value and populate the cache, etc.
This is a limitation of WP because when updating it deals with one meta field at a time. If there are too many fields on a single update it is possible that the update will time out in the browser before it completes.

From your previous ticket, I can see that max_input_vars is already set to 10000. In theory, it means that PHP will accept a maximum of 10000 input fields to send to a single request (page load). In the case of WP admin that would likely be a POST request. WordPress per default already has quite a bit of fields for a standard edit screen. There’s a whole bunch of hidden fields as well as formats, categories, tags, featured image, title, editor, permalink, visibility, status etc. plus all product fields. It is possible that you're hitting the 10000 input vars limit.

Try increasing the values for max_execution_time and max_allowed_packet. max_allowed_packet is a variable for mySQL which basically limits how large of data chunk you may insert in one go. It’s much harder to hit but it’s possible.

You might also consider moving to a dedicated server or VPS.

Best regards,

August 3, 2018 at 7:14 am #2608007


That's the problem, the 1st thing we did, before opening the case, was to ask for a trial in a dedicated server to see if was a server problem: hidden link

Ps.: Monday will be the last day they will leave us this trial

I did adjusted those values (as well as increasing to 20000 impout fields)
Is there any way to be sure those values are accepted by the server? (I know some values cant be overrride by the php.ini)

Could you guys reproduce this problem in the duplicated page? It sounds really weird we are facing this problem in 2 different servers and you guys cant reproduce it.

Best Regards,

August 3, 2018 at 7:32 am #2608070


My PHP.ini looks like this:

max_input_vars = 20000; = 20000;
suhosin.request.max_vars = 20000;
max_execution_time = 999
max_allowed_packet = 16M
memory_limit = 768M
output_buffering = on
max_input_nesting_level = 128
hard_timeout = 20

August 3, 2018 at 7:52 am #2608147


Update: Made the same changes at the dedicated server at hidden link

We faced the same problem (actually the 1st try worked fine, the 2nd failed)

Ps.: There is any way to make the plugin ignore the other fields and translate just the product title / description? We would be OK with that, we mostly ignore the other fields anyways.

August 3, 2018 at 9:24 pm #2611762

Ricardo Alday

Use this test server and feel free to upload any plugins/themes relevant to your project.
Login: hidden link
Username: demo
Password: C3En9Wq0nE2y

All WPML plugins are already installed.

To prevent WPML from showing fields in the translation interface go to WPML -> Settings -> Custom Fields Translation (click Show system fields) and set any field that you want to remove from the translation interface to "Copy".

August 8, 2018 at 7:12 am #2623097


Hello, what we tried yesterday (our installation)

- Remove all the products from the trash bin (1600)
- Optimize the DB
- Set almost all custom fields as non-translateable
- Disabling all plugins except WPML and Woocommerce
- Disable WPML media translation (we suspected it wasthe image translation)

After all this, we made a backup (slimmed down DB, plugins disabled, most fields set as non translateable) that we would like to restore at the sandbox... how can we do it? I can send you a link to download it but how to make it private?

August 8, 2018 at 2:45 pm #2625294

Ricardo Alday

I have marked the next reply as private so you can post the download link in the Duplicator package field.
You can also use that plugin, Duplicator, to move your site to the sandbox.

August 8, 2018 at 2:52 pm
August 8, 2018 at 2:57 pm #2625353


The problem is that Duplicator doesnt work on our installation (just DB), so we would need the FTP to transfer the other files.

The plugin we used (Updraft plus) works like a charm... I can install it and restore the backup, the downside is that it doesnt replace the URLs so the website would became inaccesible and we would need to hardcode the correct URL in wp-config.php in order to access the backend again and do the search-replace.

What I havent thought of is to try to restore the files using updraftPlus and the DB using Duplicator, that could work.

August 11, 2018 at 1:30 am #2635559

Ricardo Alday

I created a Duplicator package of the database and downloaded the files via FTP. In my opinion, this is the fastest way.
I created a local copy and the original issue of saving translations does not happen anymore. So it would just be a matter of restoring the site.
If the sandbox location is the same, what you can do is simply install the new smaller database while keeping the current database (just in case). Then point your wp-config.php to read from the new database.

Hope that helps.

August 13, 2018 at 7:37 am #2639005


We actually found out WHAT products have problems and what products work fine... it has to do with categories!

Some products are in hundreds of categories, such as the 1222703... those are the ones that don't work!

So at least its easier to replicate the problem now... will try to import the duplicator package in the sandbox, but I have no FTP access.

August 13, 2018 at 7:49 am #2639079


Ok, now I want to try 2 or 3 specific products that fails 100% of the time (many categories), they are 122703, 1000 PTO (This on English US category) and 1217103, for example and see how it works.

I cant figure out how to upload the DB duplicator package I have here...

August 15, 2018 at 5:25 am #2645602

Ricardo Alday

You can upload it to Dropbox or Google Drive and paste the link in the next reply.

August 17, 2018 at 8:45 am #2652679


Ok, I have it, how can I mark the answer private?

The topic ‘[Closed] Cant save translations’ is closed to new replies.