Hi Christian
Thanks for the update, the website has been migrated. I think you´ll have to resave the permalinks and Avada optinos, as there are error on the Spanish and French versions on the frontend...
Good luck with the debugging!
I spent a lot of time and I could not replicate the issue that we encountered on the live website.
I tried ATE, CTE, with plugins, without plugins, with child theme, and without child theme and the menu is there all the time:
hidden link
Maybe there is something happening in your server environment? I am not sure honestly as I could not replicate the issue of MENU getting lost in Appearance > Menus.
Thanks for the update. Sorry to read you could not replicate the issue, though it´s real as you´ve seen it happen while we were chating, right?
Activating and deactivating ATE has consequences on the overall functioning of the website, where CTE and ATE coexist.
What could be wrong with my server environment?
If you gave me a clue I could ask Wpmudev hosting support to help you debug the problem.
Is it possible that patches/fixes provided by other Wpml supporters in the past (XML ones for e.g) could be afecting the website? I think you could search for that in my tickets history.
ATE automatic translation prepaid credits> On my Wpml.org account dashboard, the website is not listed in the Sites Using Prepaid Credits list... and it is, and I cannot add/remove credits.. I´ve tried unregistering/re-registering the website but still the same.. not sure if this also weird thing could have to do with a possible bug
Please kindly open up a new ticket for the question of the credit.
For the CTE/ATE one I do not think it is the suggested XML ones, as the same XML code is in the moved website isn't it? It is a clone of the website so it should be there by default then,
One thing that I have doubt about is the Must Use plugins that are activated on your website. Those might do some conflict.
Please contact the hosting service provider and ask them to give a version of the website that do not have those Must Use plugins.
You can go to WordPress Dashboard > Plugins and click the Must Use link to see them in the list.
Hello Christopher
Thanks for your suggestions, though for what I read it seems to me you are "guessing".
I´ve mentioned the credit issue not for you to solve it, but for you to see there are many problems happening at the same time, and maybe it can help you debug.
Avada supporters are also working on the website and some issues occurr only on the production site (and not on it´s clone on the staging one) so I´ve requested the environment information from the hosting (WPMUDEV, responsible for the mu-plugins) and they sent this, hope it´s useful >
/////////////
Because you're experiencing errors on Production & not on Staging, what I can share is the difference in configuration between these two environments (described in our documentation here):
- Production offers server static (FastCGI) caching, and Staging does not.
Currently, your server static cache is enabled. See Hub > site > Hosting > Tools > Static Server Cache > On (you can turn it off here too).
- Production offers object (Memcached) caching, and Staging does not.
For performance reasons, Production's object cache is enabled by default.
Object caching can only be disabled by adding this define to your wp-config.php :define( 'WPMUDEV_HOSTING_OBJECT_CACHE_ENABLED', false );
This line should be added above the /* That's all */ comment. Disabling object cache is not recommended in the long-term, as this impacts server performance; however, you may do so for testing purposes.
- Production offers WAF (firewall), and Staging does not.
I see that WAF has been disabled on Production, so this cannot be a cause of any issues.
- Production environments have more PHP workers than Staging environments.
Your Production environment will have an assigned number of PHP workers available, depending on the hosting plan (12 on Silver). All Staging environments (regardless of hosting plan) will have 2 PHP workers. This is unlikely to be the issue, as you report the issues are not on your Staging environment.
- To confirm, both your Production & Stating sites are using PHP 7.4 and WordPress 6.1.1, so we can eliminate the possibility of PHP or WP version 'mismatches' being the cause of the issue.
Because we don't yet know what the 'issues' are, it may be worth testing to see if disabling the server static cache and the server object cache (using the methods described above) helps in any way.
The developers of those plugins may find it helpful to know which constants, commands & functions are allowed/disallowed on our servers: hidden link. They may also use phpinfo.php to see which modules are installed on the server.
////////////////
Thank you for the information. I read all the details there and none of those caching systems mentioned is available on our server.
Please consider that we tested the issue on our server by duplicating your website.
Maybe it worths that you ask the WPMUDEV to give you a staging version of your website so that we can test the same thing there.
You can give us the login info of the staging, and we can check. (Make sure the next reply is private)
If it is not possible to replicate the issue on the staging, then you can follow the steps mentioned by the hosting to turn off the caching on production and see if it fixes the issue?
Thank you for the login information. I checked in details by changing the translation editor to CTE and checking the Appearance > Menus section.
No problem accessing the menus and the menu selecting box is ok.
As this is not possible to replicate the issue on even your staging website I can not help here.
The only thing I can think of is to check the live website on a day that is off and no one visits the website.
- Have a backup of the website and try the CTE change and see if the same issue happens.
- If not, then nothing to do more.
- If yes, please restore a backup and try to temporarily deactivate the machine of the server and test again.
Hello
Sorry for the late reply, I was waiting for a good time to test this.
I´ve just followed these steps>
WPML> Settings> Translation Editor > Editor for new translations > Changed to Classic Translation Editor
I check Appearence> Menues> in ENG, they are gone.
I ran WPML troubleshooting tools, problem persisted.
I ran a DB clean up with Hummingbird, problem persisted.
I cleared the cache with Hummingbird, the menus are visible again.
I´m sharing this same information with Wpmudev supporters to see if Hummingbird´s cache functionality could be causing problems with the server cache and with WPml/Avada as well.. is it possible?
Hello
Thanks for the link, I agree it´s not our case> we use directories for secondary languages and the problem occurrs on the main language.
It´s clear that it´s a WPML problem, as the menues vanish after switching from ATE to CTE, so there is sth wrong there.
But I have found this workaround on my own so far.
Thanks
