Hey we have the following Prolbem, if i want to do the menus-sync it doesnt work it give alsways a timeout if we also have a PHP and Ningx Timeout at 600 seconds.
I’m Prosenjit from the WPML Development Team, and I’ll be happy to assist you with this.
Normally, the menu sync process shouldn’t take that long. However, if another heavy PHP process runs at the same time (or if there’s a plugin/theme conflict), it could result in a timeout error.
Could you please confirm approximately how many menu items were being synced when you started the menu sync?
Also, have you tried creating a brand new menu and syncing that one instead?
If the issue happens even with a newly created menu, could you please do the following so we can investigate further:
- Open your browser’s Developer Tools (in Chrome you can press F12)
- Go to the Console tab
- Start the menu sync process
- As soon as the timeout happens, check if any errors appear in the Console
- If you see any errors, please copy and share them in your next reply
It would also be very helpful if you keep the Network tab open during the sync and check if any request/script fails. This information can help us identify exactly what’s causing the timeout.
One more suggestion: if your menu contains many custom links, it’s recommended to instead add links using the sidebar sections (Pages / Posts / Categories, etc.), save the menu, and then run the sync again.
Please let me know what you find, and I’ll be happy to guide you further.
By any chance, is Cloudflare enabled on your site? If yes, and you have any Firewall rules or custom security rules configured, could you please temporarily disable them and test again?
If possible, please disable Cloudflare entirely for a short time, wait a few minutes, and then check once more.
I’m asking because in your last response, the GET request shows a 524 status code, which usually points to Cloudflare timing out. So we just need to confirm whether Cloudflare (or a rule inside it) is preventing the request from completing properly.
Please try this and let me know how it goes.
If the issue still persists after disabling Cloudflare, we’ll need a closer inspection to identify the root cause. In that case, could you please share access to your site in your next reply so I can investigate further? If you can replicate the issue on a staging or development site, sharing access to that would be ideal. Otherwise, you can share the production site access, and we’ll be careful not to make any risky changes.
I’ve enabled the private reply box for you, so you can securely share the access details. You should see the fields to enter the access information in your next response. Just to clarify, the access information will only be visible to WPML supporters and me.
Since the developer also identified this as a Cloudflare-related error, may I ask if you’ve already tried temporarily disabling Cloudflare (or any active firewall/security rules) to see if the issue persists? If not, could you please try that and let me know the result?
I was able to log in using the credentials you shared, but it appears the account only has Subscriber/User privileges. Because of this, I can only access the profile section and cannot properly investigate the issue.
To proceed with a thorough investigation, could you please upgrade the shared account to the Administrator level? That will allow me to check the relevant settings and help you identify the root cause more effectively.
Looking forward to your response. I’m always here to help.
Hope you're doing well! Sorry for the delayed response over the weekend.
Thank you for granting Admin access. After reviewing the environment, I tried to access the Menu Sync page and immediately encountered a 504 Gateway Timeout error — triggered without performing any actions, simply by loading the page.
A 504 error of this nature typically indicates that the PHP process is taking too long to respond, causing Nginx to time out before receiving a reply from the server.
Based on my initial environment checks, my best assessment is that the Menu Sync page may be executing a high volume of database queries — potentially thousands — to verify menu integrity across your 7 languages. Since your database is hosted on a remote RDS instance, the cumulative network latency between the application server and the database could be pushing the request beyond Nginx's timeout threshold. That said, this remains a hypothesis at this stage and not a confirmed diagnosis.
To identify the root cause accurately, I'll need access to the Nginx and server error logs. Since the error originates at the server level, these logs are likely to contain detailed information that will guide the next steps of my investigation.
Could you please reach out to your server or hosting administrator and request the Nginx and server error logs covering the past 24 hours? Once you have those, kindly share them in your next reply.
This should give us the clarity needed to move the investigation forward in the right direction.
Thank you for your patience and cooperation — I truly appreciate it. Looking forward to your response.
After reviewing the logs you shared, I couldn’t find any referrer related to the WPML Menu Sync page. The timeline in the logs points to February 25, whereas I ran the Menu Sync on February 23.
Could you please check the logs specifically for February 23 and see if there is any referrer to the following URL?
- hidden link
If you find any related entry, kindly share it in your next reply.
Aside from this, depending on the severity and root cause of the issue, it may require a more in-depth investigation. For that, I would need your permission to create a copy of your website and set it up in my local development environment. The debugging process may involve extensive testing and could temporarily impact site behavior or content, so I would prefer not to run these tests directly on your live/production site.
With your approval, I will:
- Install the Duplicator plugin
- Create a package of your site (excluding media files, WooCommerce data, and other heavy components where possible)
- Install the package locally and perform a detailed investigation
Please let me know if you’re comfortable with this approach or if you have any questions. I’ll proceed once I receive your confirmation.
Thank you for sharing the logs and for granting permission to create a copy of the site.
The log you you shared comes from the Nginx error log, and it shows that the request to the WPML Menu Sync page timed out while Nginx was waiting for a response from PHP (PHP-FPM). In simple terms, the web server successfully forwarded the request, but PHP did not respond within the configured time limit, which usually results in a 502 Bad Gateway error.
That said, this single log entry only confirms that a timeout occurred — it does not explain why PHP stopped responding. To properly identify the root cause, we’ll need a few additional logs from the same timeframe (around 26 February, 08:37:05).
Could you please request and share the following logs from your hosting/server administrator?
Nginx Access Log
(Typically located at /var/log/nginx/access.log or within the vhost access logs)
→ This helps verify the response status, request duration, and upstream processing time.
PHP-FPM Error Log
(Common locations: /var/log/php*-fpm.log, /var/log/php*/fpm/error.log, or systemd journal logs)
→ This allows us to check whether PHP workers were exhausted, crashed, or encountered any fatal errors.
Sharing this message with your hosting provider should help them locate the required logs easily. Once we have these, we’ll be able to perform a deeper analysis and better understand the cause of the timeout.
In the meantime, I’ve successfully created a package for your site. I’ll set it up locally for further investigation and will keep you updated with any findings.
Hi There!
I hope you're doing well! Sorry for the delay in responding due to the weekend!
Thank you for sharing the logs. They confirm we’re looking in the right place.
What I can clearly see now is that the request to the WPML Menu Sync page is executed by PHP (/wp-admin/admin.php?...menus-sync.php) and it is being terminated by PHP-FPM after ~300 seconds:
execution timed out (300.216986 sec), terminating
So the 502/timeout is happening because PHP does not finish processing the Menu Sync request within the configured PHP-FPM timeout, and the worker gets killed before it can return a response to Nginx.
That said, these log entries still do not indicate what PHP was actually processing during those 300 seconds — for example, whether it was waiting on a slow database query, encountering a database lock, handling a large dataset, or being affected by a plugin or theme interaction.
To investigate this further and safely identify the root cause, I have already created a copy of the site using Duplicator. I’ve also prepared a local development environment where I will import the copy and continue the investigation without impacting the live website.
I’ll keep you informed as soon as I have any updates. Thank you very much for your patience and cooperation while I continue working on this.
I’ve set up the same Nginx-based development environment locally and imported the site copy there. The installation completed successfully, including all content and menu items. When I accessed the Menu Sync page in my environment, it loaded correctly without any timeout issues. The PHP timeout is also set to 300 seconds, just like on your server.
Since the Menu Sync works properly in my environment under the same timeout limit, this strongly suggests that the issue is environment-specific and occurring only on your server due to some specific configuration. That said, we still need to determine what exactly is triggering the timeout in your setup.
To investigate further on your production site, I began analyzing logs to identify any slow scripts or database queries that might be causing the delay. I did not deactivate any themes or plugins during this process.
As part of troubleshooting, I installed a small utility plugin to clear the PHP OPcache (bytecode cache). The goal was simply to ensure that cached compiled PHP files were not affecting the logging behavior. However, after clearing the OPcache, the site unexpectedly started showing an HTTP 500 Internal Server Error, which is unusual. This plugin is commonly used just to clear OPcache and typically does not trigger server errors.
I sincerely apologize for any inconvenience this may have caused.
If you have FTP access, you can resolve this quickly by either:
- Deleting the OPcache plugin folder from `wp-content/plugins`, or
- Renaming the plugin folder to deactivate it.
That should restore the site immediately. Additionally, your hosting provider may have more detailed server-level logs explaining the 500 error, which can help confirm the exact cause.
If you prefer, you can share FTP access via the private box, and I’ll take care of it for you.
Since this is a production site, continuing deep debugging there carries some risk, as we’ve just seen. Do you have a staging or development site where the Menu Sync issue can be reproduced? If so, please share access to that environment instead. I can then perform all further investigation there to ensure your live site remains unaffected.
I’ve enabled the private reply option so you can securely share any access details.
Once again, I truly apologize for the inconvenience during this investigation. I appreciate your patience and cooperation, and I’ll proceed very carefully from here.
Best regards,
Prosenjit
The topic ‘[Closed] menus-sync doesnt work’ is closed to new replies.
