[Waiting for user feedback] "Custom Link" and "Post Type Archive" items in menus aren't being translated properly

Hi Andreas,

The pages are translated and published. I tried the WP Menus Sync option, but that showed no changes, and syncing didn't resolve it. Actually, having read that document you sent... it now appears that running the menu sync manually will disable the automatic WP menu creation. I did NOT want to disable that, but it appears I have done so by running that manually. How do I revert this back to fully automatic so WPML may create WP menus?

I increased the memory limit (to 256 instead of 128) before doing any of that, but that seems to have made no difference.

So it doesn't appear that the manual WP Menu Sync is the solution, and it has no disabled part of my automatic translations. Where do we go from here?

So what about the items that are "Post Type Archive" types? These are built-in (WordPress default) dynamic pages that are created for any registered post types that have "archives" enabled, so these ones should work just fine, right? It's just the custom links that require a manual "prod" via the string translation feature.

I did spend some time explicitly telling WPML to translate those custom link strings. I was able to find them when searching via the String Translation menu, and queued them all up for translation. However they still don't seem to be getting translated. They will show as "Translation in progress to [language]" in the String Translation page right after queueing them up, but if I view the "Translation Management" page and filter to in-progress items, I don't see any of those ones appearing there. In fact, I see a handful of items here that appear to be old content that's stuck. These items are all mostly translated, but they all have at least one language untranslated that's reporting "[language]: Waiting for translator" even though all of the translations are set to be automatic. Why would it be waiting for a human translator for just a random single language, while it translates all of the others just fine? It's set up to perform translations automatically so I have literally no clue why it would be holding up translations for content for random languages.

I think there might be multiple issues going on here, so if I could just hop on a quick call to walk through config settings, I think that would be beneficial to rule out any bugs. I have only used WMPL on a few sites so far so I'm still learning how to navigate these more complex issues, but it's sometimes hard to tell what is a bug vs what is officially supported for automatic translations vs what I need to do manually to accommodate the limitations.

Hi Andreas,

I don't see anything in the String Translation for those, so I think it must be something else going on, or I'm just doing it wrong.

Would you mind having a look and see if you can find out what is going on? I've set up a dev environment and some credentials for you. The dev site is configured to share the pay-as-you-go translation plan, so that shouldn't hinder you when troubleshooting.

***CREDENTIALS REMOVED BY SUPPORT AGENT***

Let me know if I can provide any further information to assist you.

Hi Andreas,

I was just trying to take another pass at this but I'm currently unable to even access the WP Menus Sync page in either the live or dev websites. It times out with a 502 error after a full minute. This is not intermittent, it happens every time. I can't visit the page to reconfigure anything.

I disabled all plugins aside from WPML and the WPML helper plugins, as well as the plugins they directly support. This means that WooCommerce and Gravity Forms, among others, remained enabled along with their companion WPML plugins. I also switched to a generic theme to rule that out as well.

No luck with any of that, so I queried WPengine support for some additional info, and it appears that WPML is hitting the database super hard and is somehow unable to complete the process before WPengine's long process killer kills the task. The limit is 60 seconds, which I believe is quite standard, so I assume this means that there may be a bug/issue with WPML.

I can share my chat transcript with support directly, if you have an email address that I could forward it to. In lieu of that though, I'll just copy/paste some key bits that I believe are relevant for you.

Image showing a big mysql spike correlating to the visit to the WP Menus Sync page.
hidden link

The query itself, plus some additional info that appears to be some mysql debug info that I'm not familiar with:

it.element_id, it.language_code FROM wp_icl_translations it JOIN wp_posts pt ON pt.ID = it.element_id AND pt.post_type = 'nav_menu_item' AND it.element_type = 'post_nav_menu_item' AND it.language_code NOT IN ('en','bg','zh-hans','zh-hant','hr','cs','da','nl','et','fi','fr','de','el','hu','ga','it','ja','ko','lv','lt','mt','pl','pt-pt','ro','sk','sl','es','sv') JOIN wp_icl_translations io ON io.element_id = 412 AND io.element_type = 'post_nav_menu_item' AND io.trid != it.trid JOIN wp_posts po ON po.ID = io.element_id AND po.post_type = 'nav_menu_item' JOIN wp_postmeta mo ON mo.post_id = po.ID AND mo.meta_key = '_menu_item_object_id' JOIN wp_postmeta mt ON mt.post_id = pt.ID AND mt.meta_key = '_menu_item_object_id' JOIN wp_icl_translations page_t ON mt.meta_value = page_t.element_id AND page_t.element_type = 'post_page' JOIN wp_icl_translations page_o ON mo.meta_value = page_o.element_id AND page_o.trid = page_t.trid WHERE ( SELECT COUNT(count.element_id) FROM wp_icl_translations count WHERE count.trid = it.trid ) = 1 /* From [akbiodev.wpenginepowered.com/wp-admin/admin.php?page=sitepress-multilingual-cms/menu/menu-sync/menus-sync.php] in [/nas/content/live/akbiodev/wp-content/plugins/sitepress-multilingual-cms/inc/wp-nav-menus/wpml-menu-sync-functionality.class.php:250] */:

*** row 1 ***
table: io
type: const
possible_keys: el_type_id,id_type_language
key: el_type_id
key_len: 251
ref: const,const
rows: 1
Extra: NULL
*** row 2 ***
table: po
type: const
possible_keys: PRIMARY,type_status_date
key: PRIMARY
key_len: 8
ref: const
rows: 1
Extra: NULL
*** row 3 ***
table: mo
type: ref
possible_keys: post_id,meta_key
key: post_id
key_len: 8
ref: const
rows: 10
Extra: Using index condition; Using where
*** row 4 ***
table: page_o
type: ref
possible_keys: trid_lang,trid,id_type_language
key: id_type_language
key_len: 9
ref: wp_akbiodev.mo.meta_value
rows: 1
Extra: Using index condition

Hopefully this is helpful to you and your team. This is presenting a hard barrier for me to proceed with troubleshooting the other menu issue.

Andreas,

Your last response wasn't exactly very helpful. The menus ARE managed via Appearance -> Menus. It seems like the WP Menu Sync feature is what is needed, but I don't know why that wasn't enabled and automatically translating WordPress menus already. When I originally configured the WPML plugin suite for this ite, I configured it to translate everything automatically, including menus. It worked fine until some items were updated... evidently this appears to be because the WP Menu Sync feature didn't REMAIN enabled after the initial configuration, so it needs to be run manually. Why? I don't know. I presumed it was enabled still based on my original setup.

I was able to verify the actual fix for my original issue through further testing on a local environment where the script was not running into max runtime errors. Just running the WP Menu Sync tool appears to resolve then issue (though I only tested this via the new 4.7 release candidate, but it does work on local).

I tried using the 4.7 release candidate on the WPengine-hosted dev site once again, to see if the runtime errors were resolved in a newer release, but it behaves the same. I cannot run the WP Menu Sync feature (which appears to resolve my original issue, if it could run successfully) simply because the script takes too long to run and the web host kills the process.

How can this be resolved? Everything I can see here points at a bug in WPML. As this same 502 error occurs even with ONLY the WPML plugins activated. If given enough time, it works... but maybe the sheer volume of translations it's trying to display is overwhelming the server? This isn't something I can fix on my end, your plugin's code is literally exceeding the maximum runtime capacity of my web host. If it's not batching this process somehow, it needs to be, as the WP Menu Sync tool is just completely unusable now.

So the feature that I need to use to resolve my original issue is broken. How do we proceed?