Home / Forums / WoodMart support forum / Header stored inside _elementor_page_settings breaks WPML per-page assignment
Home › Forums › WoodMart support forum › Header stored inside _elementor_page_settings breaks WPML per-page assignment
Header stored inside _elementor_page_settings breaks WPML per-page assignment
- This topic has 3 replies, 2 voices, and was last updated 1 month, 1 week ago by
Aizaz Imtiaz Awan.
-
AuthorPosts
-
September 17, 2026 at 12:04 pm #729351
GregParticipantHeader Builder: no language condition + header stored inside _elementor_page_settings breaks WPML per-page assignment
Hi,
I’m running Woodmart 8.5.7 with Elementor (free), WPML, and a bilingual site (Greek default, English secondary). I need different headers per language and ran into two blockers.
1. No language condition in Header Builder
The Header Builder conditions don’t expose language as an option. On a WPML site this is the natural place to assign a Greek header to Greek pages and an English header to English pages. Without it, the only route left is per-page assignment, which leads to the second problem.
2. Per-page header assignment doesn’t survive WPML translation sync
The header choice is stored inside the serialized _elementor_page_settings meta as:
wd__woodmart_whb_header => header_192474
Because it lives inside that array rather than in its own meta key, WPML can only treat the entire array as one unit. Its custom-field translation settings work per key, so there’s no way to tell WPML “copy the Elementor page settings but leave the header alone.”
The result: every time I set the English header on the translated page and hit Save, WPML copies the whole array back from the original and the header reverts to the Greek one. It’s not a one-off; it happens on every save.
Workaround I’m using
A get_post_metadata filter that intercepts _elementor_page_settings on the frontend, checks the current WPML language, and overwrites wd__woodmart_whb_header with the English header ID. It works, but it’s a filter running on every page load for something the theme should handle.
What would fix this
Either of these solves it:
Add a language condition to Header Builder conditions (WPML-aware). This is the better fix and matches how Elementor Pro’s Theme Builder handles it.
Or store the header in its own meta key instead of inside _elementor_page_settings, so it can be set to “Do not translate” in WPML → Settings → Custom Fields Translation.The second is presumably the smaller change on your side and would unblock per-page assignment immediately.
Two questions:
1. Is there an officially supported way to serve a different header per language in 8.5.7 that I’ve missed? If there’s a hook or a setting I’ve overlooked, I’d rather use that than my own filter.
2. If not, is either of the fixes above on your roadmap, and is there a rough timeline? I need to know whether to keep the filter as a permanent part of this build or treat it as temporary until a theme update lands.Environment: Woodmart 8.5.7, Elementor free, WPML (String Translation + Multilingual CMS), WordPress on shared hosting, PHP 8.x.
Happy to share the filter code or test a patch.
Thanks.
September 17, 2026 at 3:08 pm #729380Hello,
Please read and follow the instructions here:
https://xtemos.com/docs-topic/how-to-make-woodmart-multilingual-with-wpml/If a language requires a separate header structure, register the
default_headerTheme Settings field for translation and assign the required header ID to that language.Best Regards.
September 17, 2026 at 3:53 pm #729396
GregParticipantHi,
Thanks, that pointed me in the right direction. It’s working now, but there was a step missing from the documentation that I think is worth adding.
Following the guide, I registered default_header for translation under WPML → Settings → Admin Texts Translation, then set the English translation of
[xts-woodmart-options]default_headerto my English header ID via String Translation. That part worked as documented.It had no effect, though, and it took a debug filter to see why. Both the Greek page and its English translation had a per-page header override stored inside
_elementor_page_settings:wd__woodmart_whb_header => header_192474That override takes precedence over the theme default, so the translated default_header value was never read. I could confirm the translation itself was fine,
woodmart_get_opt( 'default_header' )correctly returned the English header ID on English pages, but the rendered header stayed Greek.The override had been set through the Elementor Page Settings metabox earlier, before I found your documentation. Since
_elementor_page_settingsis set to Copy once in WPML’s custom field settings (and locked), the value had been carried into the translation when it was created, and it persisted there.I cleared
wd__woodmart_whb_headerfrom_elementor_page_settingson both the original and the translation, flushed Elementor’s cache and the page cache, and the correct header now renders in each language.Suggestion for the docs: in the “Use a different header for a language” section, add a note that any per-page header override set in Elementor Page Settings will override the translated default_header, and must be cleared on both the original and the translated page for this method to take effect. Without that, the String Translation step looks like it silently does nothing, and there’s no indication in the UI as to why.
Thanks for the help. ✌️
September 18, 2026 at 9:38 am #729431Hello,
Ok, noted. Thanks for the suggestion.
Let us know if there’s anything else we can do for you! You can always reach us at any time. We are always here to help you.
Have a wonderful day.
Best Regards.
-
AuthorPosts
Tagged: header, page-settings, Wpml
- You must be logged in to create new topics. Login / Register