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 6 replies, has 2 voices.

Last updated by patrizio-romanoD 3 years, 10 months ago.

Assigned support staff: Tia.

Author Posts
September 19, 2016 at 8:31 am #1086887


I am trying to:
translate in two languages a big website, yet with about 400 custom posts, most of which with tens of ACF custom fields active, including repeaters.

URL of (my) website where problem appears:
here's a staging copy - hidden link

Steps to duplicate the issue:

Please note: you need admin access to reproduce the issues, I will send any information privately ASAP.
After login, reach for any custom post type under SUNCOLOR menu;
edit, then change values in one of the many custom fields you find under the box named 'tende da sole';
save the post;
Note: randomly, you'll find it working, issues show up about 50% of the times, so please make some try; you will also note the saving time became really slow in all the cases, around 20 seconds.

Please note that:

I studied other issues like this, and yet tried improving the performance as follows:
- via database optimization plugin
- incrementing variables on php.ini like: memory_limit - 720M, max_input_vars - 10000, max_input_nesting_levels - 256, max_execution_time - 120
- using ACF local json solution (hidden link)
This changes only mitigated the problem, as it now happens 50% of the times while it looked totally broken, before;

the issue apparently showed right after we completed duplication for translation purpose, all the 27 ACF field groups in the two new languages, while working just with some ACF field groups duplicated didn't caused any problem.

I strongly need your experience for checking and improvements on WPML side, in order to find a solution.

September 19, 2016 at 3:33 pm #1087881


Thank you for contacting WPML Support. I am happy to help you with this.

Can you tell me if you already checked the following?

** IMPORTANT ** Please backup a working copy of site files and database before continuing.

A. Update all WPML plugins & WordPress core.

B. Minimal Set Up:
1. All plugins except WPML disabled
2. Temporarily change the theme to a default WordPress theme (TwentySixteen)

C. If the issue is gone after Minimal Set Up steps above, activate each plugin one by one to find out which plugin is causing the issue.

Does the issue still persist when you do each step above?

September 19, 2016 at 10:36 pm #1088438


Hi Tia, thanks for your reply.

A. done.
B. 1 - not feasible, as I need some to reproduce the environment where the issue happens, CPT UI, ACF and WPML, as it happened only into some custom post types, in particular those where there many fields. Infact, apparently no issues occurred in the same website when updating default wp posts.
I have deactivated all plugins with exception of these.
B. 2 - also here, I need some php templates I built for my child theme in order to serve for singular custom post types showing the problem. So I did not change the theme in my tests.

C. So and so. With only those three plugins, I experienced no issue at all. While activating one by one the issue showed back again, but apparently in a "slow and random" way: one time in ten tests, in the beginning, then slowly incrementing but without any precise relation with each single plugin I reactivated.

Please consider that the issue, in the beginning, was happening almost all the times we tried and update one of those posts.
After upgrading server performance using php.ini and ACF local json, the issue was showing about 50% of the times.

Please consider also that, while reactivating plugins, each update became death slow as before - about more than 20 seconds every time, with or without 504 issue - and this happens only with those custom posts, not with the others.
I'm sorry but I wasn't able to detect a very moment when, as I reactivated one plugin, thing got slowing down; it felt a bit more like "progressive".

Finally, I could say it looks only like there were a little more issues when I reactivated Tablepress plugin, but, as am writing, I just completed a row of five tests of saving posts without seeing the issue, with ALL plugins finally reactivated.

Long story short: deactivating almost all plugin looks like resolving.
Not a single plugin appears to cause the problem by itself.
At the moment, after hours of tests and reactivation, issue still appears but significantly less than before - I would say, one out of six times updating.

September 21, 2016 at 6:31 am #1091310


We have released 3.5.2 that address this issue. Please update via the dashboard or manually and let me know your results.

** IMPORTANT ** Please backup a working copy of site files and database before continuing.

Manual Installation:

1. Deactivate the existing WPML plugin.

2. Delete the plugin files – this does not delete your translations. You will simply delete the plugin files from your "wp-content/plugins" folder NOT the database records.

3. Download the updated plugins from our servers and upload them to the plugin directory:

4. Activate the WPML plugin.

See: Updating WPML manually

September 21, 2016 at 9:51 am #1092206


Hi Tia,

I followed your instruction and made the complete update for all the WPML plugins.
At the moment I keep seeing the 504 happening; not as bad as when I opened this ticket, but still there some times, apparently not at all on some posts, more frequently on others - I keep making a lot of tries.
One thing I forgot: even if the post returns 504, it actually looks updated when you open it back again.



September 22, 2016 at 3:28 am #1093672


I would like to request temporary access (wp-admin and FTP) to your site to take better look at the issue. You will find the needed fields for this below the comment area when you log in to leave your next reply. The information you will enter is private which means only you and I can see and have access to it.

Our Debugging Procedures

I will be checking various settings in the backend to see if the issue can be resolved. Although I won't be making changes that affect the live site, it is still good practice to backup the site before providing us access. In the event that we do need to debug the site further, I will request to duplicate the site and work in a separate, local development environment to avoid affecting the live site.

Privacy and Security Policy

We have strict policies regarding privacy and access to your information. Please see:


- Please make a backup of site files and database before providing us access.

- If you do not see the wp-admin/FTP fields this means your post & website login details will be made PUBLIC. DO NOT post your website details unless you see the required wp-admin/FTP fields. If you do not, please ask me to enable the private box. The private box looks like this:

hidden link

September 28, 2016 at 11:45 am #1103632


Dear Tia,

after some days and a couple of staging website's copies, despite initially the 504 glitch was still there, I can now say that the latest WPML release solved that issue.
Thank you very much for your help.