Home Forums WoodMart support forum Duplicated Slides ignore Background Image update in Elementor Post Settings

Duplicated Slides ignore Background Image update in Elementor Post Settings

Viewing 1 post (of 1 total)
  • Author
    Posts
  • #725843

    Thanagor
    Participant

    Theme: WoodMart
    Theme Version: 8.5.7
    WordPress Version: 7.0.3
    Elementor Version: 4.2.2

    Description:

    When duplicating an existing slide (woodmart_slide post type) and then changing its Background Image through Elementor Post Settings, the change is reflected correctly in the Elementor editor and in the generated post-{ID}.css file — but the live front-end still renders the original (duplicated-from) slide’s background image. This does not happen when creating a brand-new slide from scratch.

    Root cause identified:

    The issue is caused by legacy postmeta keys that are not updated when Background Image is changed via Elementor Post Settings, but are copied over verbatim during the duplication process. Querying wp_postmeta for the affected slide’s post ID confirmed the following:

    meta_key: bg_image_desktop
    meta_value: a:2:{s:3:”url”;s:XX:”[OLD IMAGE URL]”;s:2:”id”;s:X:”[OLD ATTACHMENT ID]”;}

    meta_key: bg_image_mobile
    meta_value: a:2:{s:3:”url”;s:XX:”[OLD MOBILE IMAGE URL]”;s:2:”id”;s:X:”[OLD ATTACHMENT ID]”;}

    These serialized values still pointed to the original slide’s images, even though:

    Elementor Post Settings → Background showed the new image as selected and saved.
    The auto-generated post-{ID}.css file correctly contained the new image URL.

    The theme’s front-end render function appears to prioritize these legacy bg_image_desktop / bg_image_mobile postmeta values over the value saved through Elementor Post Settings, so the old image kept showing despite everything else being updated correctly.

    Steps to reproduce:

    Duplicate an existing slide that already has a background image set (via Elementor Post Settings, not the old classic metabox — note that on this slide type the classic metabox shows “Slide metaboxes moved to Elementor Post Settings”).
    Open the duplicated slide with Elementor → Post Settings → Background, and select a new image (desktop and mobile).
    Update/Publish.
    Visit the front-end page — the old (pre-duplication) background image is still shown.
    Confirm post-{ID}.css for that slide is correct (contains the new image URL) — the CSS file itself is fine.
    Query wp_postmeta for that post ID, filtering meta_key for bg_image_desktop / bg_image_mobile — these will still contain the old image’s URL/attachment ID, unchanged since the duplication.

    Workaround that resolved the issue for us:

    Manually deleting the bg_image_desktop and bg_image_mobile postmeta rows for the affected slide via phpMyAdmin, then re-selecting the images in Elementor Post Settings and updating — this correctly recreated the meta values and fixed the front-end display.

    Note: We also ruled out every caching layer before finding this (browser cache, LiteSpeed page cache, LiteSpeed CSS/JS cache, LiteSpeed Object Cache, Elementor’s own CSS regeneration, and CDN cache) — none of these were the cause. This is a data-sync issue between Elementor Post Settings and the legacy bg_image_desktop/bg_image_mobile postmeta fields specifically on duplicated slides.

    Request:

    Could you please fix the render/save logic so that:

    Saving the Background Image via Elementor Post Settings also updates (or clears) the legacy bg_image_desktop / bg_image_mobile postmeta keys, OR
    The front-end render function stops prioritizing the legacy postmeta over the Elementor Post Settings value.

    Also, ideally, the duplication process for this post type should not blindly copy these legacy meta keys without keeping them in sync with Elementor’s data.

    Happy to provide additional details, staging credentials, or a screen recording if needed.

    This issue was diagnosed and debugged in depth with the help of Claude (Anthropic), over the course of an extended back-and-forth troubleshooting session — including ruling out every caching layer before identifying the actual root cause in the postmeta data. This report was also written with Claude’s assistance.

Viewing 1 post (of 1 total)