The Case of the Uncooperative Import

🧱 The Setup

It started simply enough: turn a landing page mockup into a working page — a "V3" portfolio site with a hero section, an about block, a project grid, the usual. Nothing fancy. The twist was the destination: not a plain HTML file, but an Elementor v0.4 JSON template, built to spec against an existing internal guide (ELEMENTOR-V04-GUIDE.md) written from a previous, successful conversion.

The guide was detailed. Root-level content array, e-flexbox containers, html widgets instead of the broken e-heading type, a checklist, even a script-based validation step. Everything by the book.

It should have just worked.

❌ First Try, First Fail

Upload the file. Wait for the little success toast. Instead:

No line number. No stack trace. Just five words standing between a finished JSON file and an actual working page. Time to start guessing — carefully, and with receipts.

🕵️ Chasing Ghost #1: The Hex IDs

Dead end (but real)

The first real break came from a lucky find: a genuine Elementor export sitting in a project folder from an earlier, successful conversion. Diffing it against the failing file line by line turned up something interesting — every single id field in the real export was a lowercase hex string:

"id": "6770b6d"   ✅ real Elementor id
"id": "v3_header_section"   ❌ what the new file had

Readable, human-friendly ids like v3_header_section versus opaque hex like 6770b6d. It felt like the smoking gun — surely a strict importer would choke on IDs that don't match its own generator's format.

So: regenerate every id as 7-character hex, matching the working file exactly. Re-run the import.

Same error. Not it — or at least, not all of it. (Spoiler: it was still worth fixing. More on that below.)

👻 Chasing Ghost #2: The Widget Shape

Dead end (but also real)

Round two arrived with a second genuine export — this time a small "hero banner" template pulled straight from Elementor's editor, containing a tell no one would ever fake: an auto-injected internal default value, "_flex_align_self": "center", sitting quietly in a widget's settings. That's not something a human writes by hand. That's Elementor talking to itself.

Comparing widget shapes turned up a real discrepancy: the guide's own documented widget example carried four extra fields —

"styles": [],
"interactions": [],
"editor_settings": [],
"version": "0.0"

— and real widgets don't have any of them. Those fields belong only on the e-flexbox containers. Two independent genuine exports agreed on this. The guide itself had it wrong the whole time.

Stripped the four extra fields off every widget. Re-validated everything with a script (tag-nesting checks, structural assertions, the works). Re-ran the import.

Still. The. Same. Error.

💡 The Actual Culprit

The real fix

The breakthrough wasn't in the JSON at all. It was in a screenshot — a look at the actual browser window mid-import. The URL bar told the real story: post.php?post=291&action=elementor. This wasn't the plain wp-admin Templates screen. This was the in-editor "Add Template" flyout — the little folder icon inside the live Elementor page builder — and its dialog title read: "Import Template to Your Library."

That flyout has multiple tabs: My Templates, Cloud Templates, Blocks, Pages. It remembers whichever tab was open last. And critically — only the local My Templates tab actually implements import. Every other tab throws exactly the error seen here, word for word, regardless of what's inside the uploaded file.

It worked. First try. The JSON had been fine for at least one of the last two rounds — the UI was just pointed at the wrong shelf.

📜 The Timeline

• 🧱
  Built the JSON — followed the existing guide exactly. Looked correct.
• ❌
  Import #1 fails — "This source does not support import."
• 🔎
  Found a real working export — diffed it, found non-hex ids.
• 🔧
  Fixed the ids — re-ran import. Same error.
• 🔎
  Found a second real export — diffed it, found the widget-shape bug in the guide itself.
• 🔧
  Fixed the widget shape — re-ran import. Same error, again.
• 📸
  Got a screenshot of the actual dialog — spotted the "Your Library" flyout and the URL bar.
• 🎯
  Switched to the "My Templates" tab — import succeeded immediately.
• 🎉
  Shipped it — and rewrote the guide so the next person skips two of these three steps.

🎓 Lessons Learned

• 01
  An exact error string is a gift. "This source does not support import" is Elementor's own literal, hard-coded message — worth treating as a search query for the actual source, not just a vague symptom to reason around.
• 02
  A genuine, unedited export beats any written guide — including one written from a prior "successful" conversion. Look for tells like auto-injected default values that only the real tool would produce; that's how you know you're looking at ground truth and not someone's guess.
• 03
  Fixing a real bug doesn't mean you fixed the bug. Both structural corrections here were legitimate and worth keeping — neither was the actual cause of this specific error. Two things can be true: "this is wrong" and "this isn't why it's failing."
• 04
  Before assuming a file is corrupt, check where it's being dropped. A UI element remembering the wrong tab produced an error that looked, for two rounds, exactly like a content problem.
• 05
  A screenshot of the actual failure, at the actual moment, beats another round of guessing every time. It ended the debugging loop instantly.

🙋 FAQ — Installing a Template

The support questions that'll actually come up. Bookmark this bit.