Site does not show translated footer

This thread is resolved. Here is a description of the problem and solution.

Problem:
The client's site does not display the translated footer despite attempts including a full WPML reset, making minor changes in the footer template, and re-adding the footer to the translation queue. The site is built using Full Site Editing (FSE).
Solution:
We recommend applying a workaround suggested by our second-tier support. for more details: WPML forum discussion on FSE template issues.
Please test this solution and let us know if it resolves the issue.

If this solution does not apply to your case, or if it seems outdated, we highly recommend checking related known issues at https://wpml.org/known-issues/, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. If the problem persists, please do not hesitate to open a new support ticket at WPML support forum for further assistance.

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.

Tagged: Exception

This topic contains 12 replies, has 0 voices.

Last updated by justusR 1 week, 4 days ago.

Assisted by: Shekhar Bhandari.

Author	Posts
January 8, 2026 at 12:18 pm #17712722
justusR	Site does not show translated footer. Already tried: - Full WPML reset - Making small changes in footer template and re-adding footer to translation queue - Smashing keyboard very hard with my fists ;D Important note: site is built using FSE Please SKIP AI, straight to HUMAN SUPPORT
January 8, 2026 at 2:47 pm #17713375
Shekhar Bhandari WPML Supporter since 03/2015 Languages: English (English ) Timezone: Asia/Kathmandu (GMT+05:45)	Hello there, The issue is happening as footer and header slug translations is saved as footer-2 and header-2 for translations so the template goes missing and shows the default one from theme templates. Please follow the below steps to fix the issue: - Go to WPML->Settings->Translated documents options->Page URL - Set Translate (this will include the slug in the translation and not create it automatically from the title) - Now go to WPML->Translation Dashboard and send header and footer for translations - On the translations make sure the slug is same as default language, "header" and footer. This will fix the issue. Look forward to your reply. Thanks
January 8, 2026 at 6:41 pm #17714079
justusR	Hi Shekhar, Thanks for your support. Unfortunately the problems are not solved yet. 1) I took the steps you described on my production environment (which was the same as the staging environment). Changing the settings and updating the translations had no effect. 2) Did you try it on the staging environment? The header there is still the wrong one. 3) Another issue that keeps re-appearing is when translating the footer, it seems it does not save the translations correctly. See screenshot. I remove the "flag for later", but they are back every time I edit the footer translations. 4) You write "On the translations make sure the slug is same as default language, "header" and footer.", where can I see this slug? 5) Are there more people reporting problems with FSE / Header + Footers ? My website is quite simple, I do not understand why I am spending 2 days on only this part. What is so different about my website than others...? Looking forward to your reply, I hope we can solve this. Kind regards, Justus
January 8, 2026 at 7:04 pm #17714100
Shekhar Bhandari WPML Supporter since 03/2015 Languages: English (English ) Timezone: Asia/Kathmandu (GMT+05:45)	Hello, I tested this on both the staging site and my local setup before sharing the details with you, and it was working as expected. It’s still working for me locally using the same steps. Could you please try clearing all caches on the sites and check if that resolves the issue? Also, let me know if any changes were made recently on the staging site. Regarding the slug, please refer to the screenshot I shared, the URL shown is the slug, and it must match exactly. Additionally, please follow the steps outlined here and see if it helps. https://wpml.org/errata/template-is-not-applied-to-translated-page/ As for the new issue, I’m not able to reproduce it on the staging site at the moment. Could you temporarily remove the review and test again to see if that helps? If the issue persists, I recommend opening a new chat so we can debug it more efficiently. We’ve received a few similar reports, and in most cases, the problem was caused by incorrect template assignments or slug translations. I look forward to your response. Thanks
January 9, 2026 at 7:20 am #17714922
justusR	Hi Shekhar, 1) I did not make any changes on staging. I've disabled WP Rocket and re-opened the site in private browsing so I assume caching should not be an issue. 2) I found the slug setting. I changed this on my production site (where the translated URL field was empty). Entering the url seemed to fix the "flag for later" issue with the footer, but not 100% sure yet (only tried this once). But it had no effect on the front-end. 3) Regarding the link with the "fix": I am not comfortable hacking PHP files for a bug that was reported 2 years ago and is not fixed by WPML in the mean time, clearly frustrating people (looking at the responses to that ticket). If this is required, I'll stop using WPML (I don't want to build a site on top of a house of cards). 4) On staging, both the header and footer are displayed wrong when German is selected. You can tell the header is wrong if it shows an old (no longer working) shortcode (see screenshot) and there is no search bar like in the orignal Dutch version. The footer is still the Dutch version. Can you share screenshots of the site as it shows on your end? Please share screenshots privately, I do not want to share site details in public.
January 9, 2026 at 12:25 pm #17715973
justusR	Hi, The copy of the site was from the production environment, directly after I updated the staging environment; so these are exact copies (except for the URL's). It's unclear to me what is the correct fix to apply: on your local setup, the fix was to update the translation (which we've both done multiple times on staging and production, to no avail), and on staging you also switched to the classic editor (so, not using ATE any longer). Updating the translation never worked for me on staging, so I tested the classic editor fix on staging. I took the following steps: - updated the staging environment (to have the same starting point as you) - switched frontend to German and confirmed that the header was still incorrect (old version), and the footer was not translated - switched to the classic editor - updated the translation of the header, at which point I noticed the header was reported to be 92% complete (ATE shows 100%). Added the missing translations. - checked the frontend: header is now correct! footer not - updated the translation of the footer, at which point I noticed the footer was reported to be 86% complete (ATE shows 100%): 2 whole paragraphs were not translated. Added the missing translations. Conclusion: it seems ATE has bugs that break footer/header template translations in miscellaneous ways (not able to translate everything, flags that cannot be unflagged, showing old versions of headers of the pre-FSE site). I feel it has something to do with using FSE. I am comfortable using the Classic Translation Editor for now, however WPML states: """ Can I use my free automatic translation quota with the Classic Translation Editor? No. Automatic translation is only available via WPML’s Advanced Translator Editor, so you can only use your free quota using it. When should I use WPML’s Classic Translation Editor? We maintain WPML’s Classic Translation Editor as part of WPML for backward compatibility. You should only use it if you’ve started with the Classic Editor and are concerned about losing the translation history. """ So now I have two "future problems": - We have a huge translation quota that cannot be used now - WPML will probably not invest in the classic editor and deprecate it some time in the future, possibly breaking my site suddenly (after updating the WPML plugin). Curious on your thoughts / advice.
January 9, 2026 at 12:42 pm #17716000
Shekhar Bhandari WPML Supporter since 03/2015 Languages: English (English ) Timezone: Asia/Kathmandu (GMT+05:45)	Hello, As mentioned earlier, the Classic Editor is only a temporary workaround. Since the local and production copies are identical, I will escalate this issue to our second-tier support team for further review and feedback. I’ll keep you informed as soon as I receive an update from them. Thank you.
January 9, 2026 at 2:56 pm #17716384
justusR	Ok thanks, shall I continue with translating my website with the classic editor or is it better to wait for the 2nd tier support team?
January 12, 2026 at 2:46 am #17719859
Shekhar Bhandari WPML Supporter since 03/2015 Languages: English (English ) Timezone: Asia/Kathmandu (GMT+05:45)	Hello there, Our 2nd tier suggested the following workaround: https://wpml.org/forums/topic/fse-template-not-applied-to-tanslated-pages-posts/?paged=2#post-17657064 You can add this code, translate it once by Classic translation editor and switch to Advanced Translation editor, I tried to test this on staging but the logins are not working, so can you please test this and let me know if this helps. Look forward to your reply. Thanks
January 12, 2026 at 3:16 pm #17722118
justusR	Hi Shekhar. The current production site has no issues, other than the fact that it is still using the Classic Translation Editor. I have created a new staging environment based on the current production environment to continue troubleshooting. I first tried to see if the issue could be replicated (even though the Classic Editor was already in use) by following these steps (on staging, before adding PHP code): - switched the translation method to the Advanced Translation Editor (ATE). - checked the header and footer; they appear to be okay, so the issue is not currently visible. - sent the header and footer for translation, but when I went to edit them, the Classic Editor opened instead of the ATE. Because I cannot get the ATE to trigger, I am unable to replicate the issue or validate if your proposed fix works. I have updated the login credentials so you can access the staging site again. A kind request: please be very concise when asking me to perform specific actions. For example, when you wrote "translate it once by Classic translation editor," I don't know what "it" referred to. When writing instructions, please treat me as a noob and guide me through the process step-by-step 😅
January 12, 2026 at 3:23 pm #17722120
Shekhar Bhandari WPML Supporter since 03/2015 Languages: English (English ) Timezone: Asia/Kathmandu (GMT+05:45)	Hello there, Go to WPML->Settings->Translation Editor and check "Also use for old translations made with the classic editor" to make sure it's opened in ATE. I have attached the screenshot. Thanks
January 12, 2026 at 4:04 pm #17722471
justusR	Thank you for the quick reply. Checking the "Also use for old translations..." box worked. I have now tested the workaround: - switched to ATE and translated the header/footer; the issue reappeared as expected. - switched back to the Classic Editor and added the provided PHP code. - translated the header/footer again, then switched back to ATE. I can confirm that the header and footer are now working correctly. I performed a second translation as a sanity check, and it is still OK. The workaround works! Before I apply this to the production site, are there any potential downsides or side effects I should be aware of when using the workaround?
January 13, 2026 at 5:06 am #17723528
Shekhar Bhandari WPML Supporter since 03/2015 Languages: English (English ) Timezone: Asia/Kathmandu (GMT+05:45)	Hello there, are there any potential downsides or side effects I should be aware of when using the workaround? No, there shouldn’t be any side effects. The workaround is to make sure the slugs match across template translations. Thanks
January 13, 2026 at 8:06 am #17723832
justusR	Ok thank you for the support and (if possible) let me know once the software is fixed so we can remove the workaround.