Appearance
The Drupal relationship
How nanawall.com content gets into NanaSelect — and why NanaSelect borrows from the legacy site instead of forking or replacing it.
What it is
NanaSelect is a standalone app that augments the legacy Drupal site (nanawall.com) rather than replacing any part of it. It owns its own selection-oriented product catalog and carries Drupal's richness — product data, projects, imagery, brochures, case studies — into that catalog's shape, one way.
Since #1094/#1099, the ingestion channel is a bulk load from a sanitized Drupal database dump: an offline pipeline (npm run drupal:extract → drupal:load) that maps Drupal's internal tables into NanaSelect's stores in one pass, at full catalog scale. The refresh model is re-dump cadence — obtain a newer dump, re-run ingest; the load is idempotent, so an unchanged dump converges to a no-op. Each load stamps every row with the dump's date as provenance and records a bulk-load event, so freshness reporting stays honest about how old the content actually is.
The earlier channel — per-entity JSON:API syncs triggered from the admin — was retired in #1099 once dump ingest demonstrably covered every store the syncs fed (the parity gate recorded on that issue). What survives of it: the provenance/freshness reporting, the mapping editors, the on-demand populate actions, and the audit history of past syncs. The /admin/drupal-sync screen ("Drupal data") is that reporting + configuration surface.
Nothing is ever written back to Drupal, and no content lands behind the admin's back — an operator runs the ingest and can see exactly what each load wrote.
Why it exists
The alternative architectures both fail. Building inside Drupal chains the selection experience to a legacy stack and a presentation-shaped data model — evolution at Drupal's pace, not the product's. Forking the data — retyping products into a disconnected app — goes stale the day marketing edits a PDP.
One-way bulk ingestion is the deliberate middle: nanawall.com stays the system of record for product marketing content (PDPs, projects, imagery, collateral), NanaSelect stays the system of record for selection logic (factors, rules, tiers, tracks), and the dump ingest carries the former into the latter's shape — the whole catalog at once, not one JSON:API contract at a time. Locally-edited values are held back as overrides rather than overwritten, held-back items are counted rather than silently skipped, and every load is auditable — content changes are deliberate, not ambient ("standalone, but connected" — see why it works).
The honest trade-off: a dump reads Drupal's internal schema, which can shift with core/module updates. That coupling is contained in one tested, versioned mapping module, and the extractor's whitelist keeps PII out by construction (see the dump extraction reference).
In the admin
| Screen | How-to |
|---|---|
| Drupal data | Managing Drupal data |
Learn more
- Extract a Drupal dump — the ingest procedure.
- Data provenance — which field comes from where.
- Drupal product contract — the field contract behind the attribute mappings.
- Drupal content registry — the content-source reporting registry.
- Running the Drupal sync (archived) — how the retired JSON:API sync channel worked.