D
P
0
← All articlesBaca dalam Bahasa Indonesia

WordPress & Elementor

Deploying an Elementor Page to Production Randomizes Every Element ID and Kills Custom CSS? The Template Library Import Trap

July 19, 2026·4 min read
Deploying an Elementor Page to Production Randomizes Every Element ID and Kills Custom CSS? The Template Library Import Trap

This was my first time deploying an Elementor page from a local clone up to a client site's production. The flow looked safe and textbook: open the page in local, Save as Template, export the JSON, then on production just Import Template and Insert. The page showed up, every section and widget looked complete, and I figured I was done. Then I opened the production page with my own eyes, and the whole thing was wrecked.

The hero title wrapped in the wrong place, cards lost their halo shadows, buttons lost their icon sizing, and strangest of all: a big <h1 class="entry-title"> heading appeared at the very top that I never placed. In local the page was clean. The structure was intact, but the entire visual skin was gone.

The symptoms

I inspected the elements one by one. Every custom element ID I had set in local, say heroouter, had turned into a random hash like 166157ad in production. That was fatal, because this page's custom CSS, roughly 2198 characters, was written with selectors scoped to the page ID plus the element ID. Once the IDs changed, every selector pointed at an element whose name no longer existed.

But there was something more fundamental underneath: the custom CSS itself did not even come across in the import. Neither did hide_title, the option I had enabled locally so the theme would not render the post title. With hide_title gone, the theme fell back to its default and printed that <h1 class="entry-title">. Two symptoms that looked unrelated turned out to share one root.

The dead ends

First idea: maybe I picked the wrong tool. Elementor has a Kit Export feature meant for site-to-site migration. The plan was a selective export, just this one page. It turned out selective kit export is locked behind the Expert plan in Elementor v4 Free/Pro. The only free path was a full-kit import, which would overwrite all 16+ pages already live in production. Clearly not an option.

So both "official" candidates fell: Template Library import breaks the page, and the correct Kit Export is either paywalled or too destructive.

The root cause

Once I stopped blaming the CSS and started reading how Template Library actually behaves, it all made sense. Insert Template is designed to regenerate element IDs. That is a feature, not a bug: it lets you drop the same template onto one page multiple times without ID collisions. The side effect is that the local IDs I relied on for CSS scoping are guaranteed to be scrambled.

Second, and this is the part that trips most people: Template Library only carries the elementor_data payload, the tree of sections, widgets, and their content. It does not carry _elementor_page_settings at all. Yet that is exactly where custom_css, hide_title, and page-level layout options live. This has been documented behavior since Elementor v3.x. So two failures happen in a single import: IDs get scrambled, and page settings never make the trip.

The fix

The conclusion: for a page like this, use neither Template Library nor Kit Import. I deployed through a precise database injection. Instead of letting Elementor rewrite everything, I wrote the meta myself with update_post_meta, keeping every element ID exactly as it was in local, then rewriting the selectors in custom_css, and remapping the image attachment IDs.

First key: write _elementor_data verbatim so not a single ID changes.

// keep element IDs exactly as they are in local
update_post_meta( $target_id, '_elementor_data', wp_slash( $elementor_data_json ) );

Second key: bring _elementor_page_settings across, and since the local page ID differs from the production page ID, rewrite the selector portion scoped to the page ID.

$page_settings['custom_css'] = str_replace(
    '.elementor-' . $source_page_id,
    '.elementor-' . $target_page_id,
    $page_settings['custom_css']
);
update_post_meta( $target_id, '_elementor_page_settings', wp_slash( $page_settings ) );

Because I keep the element IDs verbatim, only the page-ID part of each selector needs swapping. hide_title rides along inside the same page settings, so that unwanted <h1 class="entry-title"> disappears on its own. Last step: remap the attachment IDs, since image IDs in the production media library are almost certainly different from local, so the images do not break.

A decision tree before you deploy

Before you reach for a Template Library import to deploy a page, ask three things. Does this page have any page settings? Is there custom CSS scoped to IDs? Are any element IDs referenced from outside, for example through custom JS or an animation hook? If any answer is yes, Template Library import will break it. Deploy at the database level instead.

Takeaways

  • Insert Template regenerates element IDs on purpose; do not use it to deploy a page that has ID-scoped CSS or JS.
  • custom_css and hide_title live in _elementor_page_settings, and a Template import never brings them along.
  • Selective Kit Export is locked to the Expert plan (Elementor v4 Free/Pro), while a full-kit import overwrites every production page.
  • For a precise deploy: write _elementor_data verbatim via update_post_meta, rewrite the custom_css selectors, then remap attachment IDs.
  • Quick rule: if a page has page settings, ID-scoped custom CSS, or IDs referenced from outside, Template Library import will break it.