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

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #729351

    Greg
    Participant

    Header 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.

    #729380

    Aizaz Imtiaz Awan
    Keymaster
    Xtemos team

    Hello,

    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.

    https://ibb.co/LzMPB5zx

    Best Regards.

    #729396

    Greg
    Participant

    Hi,

    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_header to 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_192474

    That 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_settings is 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_header from _elementor_page_settings on 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. ✌️

    #729431

    Aizaz Imtiaz Awan
    Keymaster
    Xtemos team

    Hello,

    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.

Viewing 4 posts - 1 through 4 (of 4 total)