FvRE v3.0 — DB source-of-truth vs scanner

Comparing what the scanner finds by rendering the live HTML vs. what Elementor actually wrote to the database. The DB is the source of truth; the scanner is reading the rendered output.

The Oscar home page (post 76)

Source of truth — _elementor_data in the DB

{
  "top_level_sections": 6,
  "total_widgets": 28,
  "widget_type_counts": {
    "heading": 8,
    "text-editor": 5,
    "image": 5,
    "eael-testimonial": 5,
    "button": 2,
    "animated-headline": 1,
    "eael-post-carousel": 1,
    "shortcode": 1
  }
}

Elementor Pro + Essential Addons for Elementor (eael-*) + Premium Addons Pro. 6 top-level sections, 28 widgets total.

What the scanner would see — by widget class

If the scanner ran on the live HTML, here's the class-by-class signal it would pick up:

DB widgetType	CSS class signal	Scanner role
heading	.elementor-widget-heading	text-heading
text-editor	.elementor-widget-text-editor	content / rich-text
image	.elementor-widget-image	image
button	.elementor-widget-button	button
animated-headline	.elementor-widget-animated-headline	hero (with animation)
eael-testimonial	.eael-testimonial	testimonial
eael-post-carousel	.eael-post-carousel	carousel
shortcode	.elementor-widget-shortcode	shortcode (pass-through)

Comparison: 28 widgets in DB → likely ~28 widgets in scanner

Source	Count	Notes
DB _elementor_data	28 widgets	Exact count of widget nodes in the Elementor JSON
Rendered HTML	~28 widget elements	One .elementor-widget per widget, plus inner DOM nodes
Scanner's role_count	~28 role:<type> nodes	After role-mapping, the scanner should see ~28 distinct blocks

What the scanner would miss (or get wrong)

1. Exact widget counts — the scanner counts visible DOM nodes, not the source widgets. If a widget renders 3 things (heading + description + button), the scanner sees 3 nodes. The DB sees 1 widget.
2. Container structure — the DB knows that the hero is a container > container > 3 widgets. The scanner sees a flat list of nodes.
3. Settings — colors, typography, animations, etc. are in the DB settings object. The scanner sees the rendered CSS.
4. Dynamic content — eael-post-carousel pulls posts dynamically. The scanner sees N carousels, not "post carousel with template X".

What the scanner does better

1. Works without DB access — no need to dump Elementor data, no need to know the WPRESS prefix.
2. Detects the page builder — by class signals, the scanner identifies Elementor, Bricks, Divi, etc. without the DB.
3. Captures the visual structure — actual rendered layout, not the source-of-truth tree.
4. Detects interactions — modals, accordions, sliders, carousels, popups from JS event handlers and class patterns.

The "honest recipe"

An FVS recipe derived from the scanner is a "best effort" reconstruction. A recipe derived from the DB is the ground truth. The CMS should know which is which.

For the FVS CMS prototype, this is a useful distinction:

• DB-sourced recipes (when we have access) → confidence: 1.0, every widget gets an editable block
• Scanned recipes (from public HTML) → confidence: 0.6-0.8, scanner-best-guess blocks that may need operator review
• Static mirror recipes (Mode A output) → confidence: 0.4, treated as a snapshot, not editable until re-scanned

← back to v3 design · ← back to index