Based on your suggestion, I disabled the caching option in our Pantheon hosting environment. After that, I edited the homepage title, saved the page, opened the German translation in the Advanced Translation Editor (ATE), updated the translated heading, and saved the translation.
However, the updated translation is still not reflected on the frontend. I’ve demonstrated the entire process in the video below.
- Please backup the site files and database before providing us access.
- If you have a staging site where the problem can be reproduced, it is better to share access to the staging site.
I can confirm that the translation for this specific page is not being saved. To compare, I tested both a newly created test page and a Home backup, and translations for those pages save correctly.
This suggests that something specific to this page may be causing the issue. Are you using any custom code, custom blocks, shortcodes, or other special elements on this page that differ from the others?
Any additional details about the page setup could help us narrow down the cause.
Thank you for the detailed explanation and the video.
I understand that the homepage is built using a combination of GreenShift Builder blocks, ACF blocks, and custom Gutenberg blocks developed specifically for your custom theme.
The reason I am asking about differences between the homepage and the backup page is that, from my testing, the issue does not occur when I create a new page or when I re-translate the backup homepage. This suggests that there is likely something specific to the original homepage causing the problem.
Since the site relies on custom-developed blocks and a custom theme, we are unfortunately limited in how much we can debug or support the custom code itself. However, I am trying to help narrow down the cause and identify what may be triggering the issue.
Please check and advise with your developers, whether there are any custom blocks, custom code, templates, or special configurations used on the original homepage that are not present on the backup homepage? Any difference, even a small one, could help you / us understand why one page works correctly while the other does not.
While debugging custom code falls outside the scope of our support, we do our best to direct you in correct direction and help as much we can from our side.
We totally understand your point. Yes, we built that page using a combination of GreenShift blocks, ACF blocks, and custom blocks from our custom theme. We will also investigate this on our end.
The reason we’re unsure about the root cause is that the translations were working correctly before. The translated content for both the custom blocks and the GreenShift blocks was reflected properly on the frontend, and this was still working as recently as last month. It only stopped working suddenly.
As you mentioned, if the issue were related to the custom blocks or the custom theme itself, we would expect it not to have worked from the beginning. Since it was functioning correctly before, we’re still not sure what might have caused this change.
We’ll continue to investigate on our side as well. In the meantime, could you please let us know if this behaviour could be caused by a WPML configuration or setting that may have changed?
From what I can see, the issue is actually not that the translated content is not being reflected on the frontend. The problem occurs earlier in the process the translation job itself is not being saved correctly. This is why the page remains with the cog icon instead of becoming fully translated / pencil icon.
In other words, the translated content is never successfully written to the database, so there is nothing for the frontend to display.
One thing worth checking is your server's error logs while saving the translation to see if any PHP errors, fatal errors, or database-related issues are being triggered.
If the logs don't reveal anything, I believe the issue is most likely caused by a specific block configuration or custom code. Since your homepage backup translates and saves successfully, while this page does not, the best approach would be to compare the two pages.
They appear to be very similar in structure, so there is likely one specific block, block setting, or custom implementation that differs between them and prevents the translation job from completing successfully.
Because the page contains many custom blocks and custom code, it is unfortunately very difficult for me to identify which specific component is responsible. As you know your implementation best, I would recommend comparing the working homepage backup with the affected page to identify what is unique to the failing page. That should help narrow down the source of the issue much more quickly.
Please let me know how it goes and if there is anything we can help with.
We are still debugging the issue. We've disabled most plugins and kept only WPML, ACF, and Greenshift active, since those are needed for page building and translation testing.
We then tested the translation by creating a new page and found that whenever we use the Link element from the Greenshift block, the WPML Advanced Translation Editor does not load.
As another test, we switched the site to a default WordPress theme. After doing that, the Advanced Translation Editor loaded properly, and we were able to translate the Link element from Greenshift Elements.
So at this point, We're not fully sure how our theme is connected to the issue, but we are continuing to debug it.
We wanted to share this update in case you have any thoughts or suggestions. Please let us know, as it may help us troubleshoot and resolve the issue more quickly.
Thank you for the detailed update and for taking the time to narrow the issue down. This is very helpful.
Based on your findings, it does appear that there is some custom code within your theme that is interfering with the interaction between WPML and the Greenshift Link block. Since the issue disappears when you switch to a default WordPress theme, the next step would be to identify which part of the custom theme is affecting this functionality.
I would recommend checking with your developers to see whether there is any custom code, filters, or modifications related to the Greenshift Link block or the way the editor loads. If possible, try temporarily removing or disabling those customizations one by one to identify the conflicting code.
Unfortunately, because the issue seems to be caused by custom theme code, there is not much more we can suggest from the WPML side. Once you have isolated the relevant code, or if your developers have any findings or specific questions, let us know.
Thank you for your response. It took us some time to investigate the issue thoroughly.
Based on my analysis, it appears that the problem occurs whenever a Greenshift Link element contains an absolute URL pointing to the production website. In that case, the translation can be completed in the Advanced Translation Editor, but it cannot be saved to the database.
Initially, I thought the issue might be related to our custom theme. However, after further testing, I realized that wasn’t the case. Even with our custom theme enabled, I was able to save translations successfully after removing the Greenshift Link element from the affected block.
To verify my findings, I cloned the production website into a separate development environment and repeated the same tests. The results were consistent, which strongly suggests that the issue is related to the Greenshift Link element when it contains an absolute production URL.
Thank you for the detailed investigation and for sharing the video.
I have a few suggestions and additional questions.
First, if you're still using the custom WPML XML configuration for the Greenshift Link element, could you please remove it and update Greenshift to the latest version? The XML workaround should no longer be necessary, as the related issue has been addressed.
After that, could you please check whether the issue still occurs under the following conditions?
- Using a default WordPress theme (such as Twenty Twenty-Six).
- With only the WPML plugins and Greenshift enabled.
- On a newly created test page.
I also tried to reproduce the behavior based on your description, testing both absolute URLs (e.g. `hidden link`) and relative URLs, but I was not able to reproduce the issue. The translation saved successfully in both cases.
It's possible I missed a specific step, so if the issue still occurs under the conditions above, could you also try to check and reproduce in this new website I created?
Based on your suggestion, I disabled all plugins except Greenshift and WPML, switched the active theme to the default WordPress Twenty Twenty-Five theme, and removed the custom WPML configuration that I had added previously.
After testing again, it appears that the issue occurs only when we use our primary domain URL in the Greenshift Link element. In that case, the translation is not saved to the database.
I tested the same Link element with other domain URLs, and those worked correctly. The issue seems to happen only when our primary domain is used in the link field.
I’ve demonstrated this in the video below. Please review it and let me know your thoughts on what might be causing this.
