[Resolved] Hi there, I am seeing a number of issues with WPML and ACF PRo.
This thread is resolved. Here is a description of the problem and solution.
Problem: The client is experiencing an issue where a random *__trashed* string is being added to the end of page slugs, which seems to prevent translations from working. Additionally, there is a PHP Fatal error related to the Advanced Custom Fields (ACF) plugin. Solution: We asked the client to provide a detailed description of what the code is intended to do, and when and where it should run. This information is crucial for us to troubleshoot the issue further. We also informed the client that
is_admin()
is not a reliable way to check if a site visitor is on the front end or back end, especially with the Gutenberg editor, as detailed in the WordPress core ticket: https://core.trac.wordpress.org/ticket/47394.
If you're experiencing a similar issue, we recommend providing as much detail as possible about your code's intentions and context. However, please note that this solution might be outdated or not applicable to your case. If the problem persists, we highly recommend checking the related known issues, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. If you still need assistance, please open a new support ticket with us.
For further assistance, please visit our support forum.
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.
Most notably, a random *__trashed* string that is being added to the end of page slugs, which then appears to stop the translation working?
"PHP message: PHP Fatal error: Uncaught TypeError: Cannot access offset of type array on array in /home/ploi/sysacc.kaluna.dev/wp-content/plugins/advanced-custom-fields-pro/pro/fields/class-acf-field-flexible-content.php:734"
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 duplicate the site and work in a separate, local development environment to avoid affecting the live site.
- 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
Thanks for providing access. Please update ACF Pro to the latest version, and let me know if it is okay to activate WPML String Translation, ACF Multilingual and update WPML plugins as well.
Thanks for allowing me some time to test. Here is what I have found so far. I went to WPML -> Settings and set the post URL to be translatable in the Translated Documents Options section. This way, when I load the translations, I could see the slug that was showing up.
I edited English first and changed the slug from partners_trashed to just partners. I refreshed the page and it remained just partners. I then edited the Dutch translation and could now see the slug in the advanced translation editor. I copied partners over to the Dutch translation and everything worked, both pages loaded correctly on the frontend with no error.
I then tried to copy the same steps for German translation. When I edited the German translation the English slug showed up in the Advanced Translation editor as partners_trashed again.
I repeated this a few times for testing and always got the same results. Unable to keep the slug as partners in the English page
I then switched to a default theme and retested these steps. This time, when I edited all of the translations, the English slug showed correctly as partners and I was able to translate it as partners. I saved the translations, edited the original page and translations and still the URL stayed as partners and not partners_trashed. So, there is something in your custom theme that is adding the _trashed ending to the URL in English once the translations are updated. Do you have any idea what it could be?
I also reactivated the custom theme and same as original test. Once I saved the German translation, the English slug changed again. It does not happen with the default theme.
Did you change the original language of a page? If it is only happening on this one page, are you able to duplicate the page and try to translate from scratch?
"So, there is something in your custom theme that is adding the _trashed ending to the URL in English once the translations are updated. Do you have any idea what it could be?"
Why would I add this function in, and then spend half a day asking why it's happening?
I'm not suggesting you added this intentionally. But if you follow my testing steps I'm certain you can confirm the behavior. Since the theme is custom, and the issue is not replicated in a default theme, there is something in your custom theme that is conflicting with WPML. Since I'm not familiar with your theme and it's not a commercial theme, the question to you is what could be in your custom coded theme that is causing this conflict.
If the issue was not related to your custom theme, then I would have been able to reproduce the issue with a default theme. I tried checking the functions.php file of your custom theme to see if anything stood out but there is not much there. Most themes have the custom functions in this file. So I wouldn't even know where to begin looking in your theme to try and find the issue, which is why I asked you if you had any idea what it could be.
Since this issue is coming from custom code, it is outside the scope of our general support. I can suggest you contact one of our recommended contractors that is familiar with WPML if you need further assistance: https://wpml.org/contractors/
I hope this helps to point you in the right direction.
But that wouldn't make sense? I'd only be adding the desired filter when there's a taxonomy query present, which isn't what I want.
It's custom code, for sure—but *your* advanced translation editor is bypassing some core WordPress functions, or at least, isn't completing the is_admin() check appropriately. So my function obviously skips the integral part to make sure the function isn't accessed in the dashboard.
I'm really, really disappointed by your replies. At no point have you sought to help me with my issue—just finger point and ultimately waste my time.
I'd like a refund, please can you organise this with whoever can make it happen.
I have tried to point you in the right direction, and clearly explained that the issue is related to the custom code in your theme. I proved this by showing that the issue is not happening when a default theme is active. It is against policy for me to provide a custom code solution for you.
If you would like to proceed with the refund request here is the link to process refund requests: https://wpml.org/purchase/refunds-policy/ and our administrative team will be in touch.
I'm not asking you to provide a custom code solution for me. I am proving that something that works on 99% of my WordPress websites, doesn't work when I am using your Advanced Translation Editor, because when you save the post data, it is accessing a hook, and then failing the is_admin check that my function (that is accessed via that hook) uses to literally avoid these types of issues.
But whatever. I shall be raising this with your admin team.
I have asked our second tier team to take a look and see if there is anything they can determine that we could change on our end to resolve the issue. I'll let you know once I hear back if they are able to find a solution.
My second tier support has asked you to describe in words what the code is intended to do, and when and where exactly it is intended to run. This will help us try and troubleshoot further if we can.
For the record, is_admin is not an accurate test of whether a site visitor is on the front end or back end; is_admin is not true when updating a page in the back end with the Gutenberg editor, for example: https://core.trac.wordpress.org/ticket/47394
The more information you can give us as to what you are aiming to do, the better chance we can try to help.
The function in question was added to make sure search results show "all results" I believe. The website has a job board, and although the jobs are categorised in the language of it's origin—all jobs need to be visible via the search.
I didn't know is_admin didn't work when using Gutenberg. But my theme doesn't use Gutenberg, so I have never encountered issues using that hook, hence not knowing.
That seems to have stopped happening however since I removed that function.
However, I think what has happened, is that while that __trashed error was happening, it now things the language variants of some of the pages are duplicates, not translations.
Eg, About Us is available in English, German, Dutch and French. The German, Dutch and French versions all show an error loading them up in the classic editor, saying they're "duplicates". I presume this was caused by the previous issue.
I have since reverted back to using the classic translation editor and we've had no problems since.
