WooCommerce Catalog Import from Drivingi.com
The full drivingi.com product catalog imported into WooCommerce with every variation, stock availability, pricing and all images. It runs on the same engine as the Smartlink ASI sync, behind a source adapter.
- Client
- Drivingi.com (drivingi.com)
- My role
- WordPress / WooCommerce integration developer
- WooCommerce
- PHP
- WP-CLI
- Action Scheduler
- Source adapters
- Product variations
- catalog imported, ready to sell
- Full
- shared with the Smartlink ASI sync
- 1 engine
- needed to add a new source
- 1 class
- pricing and markup rules
- Per source
catalog imported, ready to sell
shared with the Smartlink ASI sync
needed to add a new source
pricing and markup rules
The challenge
The store needed the entire drivingi.com catalog in WooCommerce: every product with all its variations, stock availability, pricing and images, ready to sell.
A second importer would have meant duplicating variation handling, image sideloading, pricing and logging that already existed for the Smartlink ASI sync. The two sources also do not share a schema, so a straight copy of the first importer would not have worked.
What I built
- 01
One engine, two feeds
The sync engine was abstracted behind a source adapter. Each source implements fetch(), normalize() and key(), and the rest of the pipeline (markup, variation expansion, image handling, upsert, logging) is shared. Drivingi was added as a new adapter rather than a second importer.
- 02
Adapter interface
The My_Source_Adapter interface defines fetch_batch( $offset, $limit ), normalize( $row ): array and unique_key( $row ): string. Adding a third supplier later is a single class, not a fork of the importer.
- 03
Field mapping stays in the adapter
Sources rarely share a schema: one uses sku, the other product_code; one nests variations as child rows, the other as JSON. Mapping lives in the adapter, never in the pipeline.
- 04
Per-source pricing rules
Different suppliers carry different commission tiers, so markup config is keyed by source, not global. A single global multiplier is the fast path to margin loss.
- 05
Rate limits and retries
When a source is fetched over HTTP rather than a file drop, the adapter honours its rate limit and backs off with exponential retry.
- 06
Shared delta cache
Row hashes are keyed on (source, unique_key), so the two catalogs cannot collide even when SKUs overlap.
Gotchas and how I fixed them
Namespace the delta-hash table by source and key
Without the source in the key, overlapping SKUs from two suppliers would overwrite each other's hashes.
Log the source name on every row error
With two feeds in one pipeline, an error without a source name makes debugging guesswork.
Version the adapter's normalize()
Changing the normalized output shape of an adapter affects the shared pipeline, so changes to normalize() are versioned.
Results
- The entire drivingi.com catalog is in WooCommerce with every variation, stock level, price and image.
- Drivingi was added as one adapter with no changes to the core pipeline.
- Both catalogs run through one sync engine, each with its own pricing rules.
- A third source can be added as a single class.
Questions people ask
Can I import a whole product catalog from another website into WooCommerce?
Yes. For drivingi.com the full catalog was imported with every variation, stock availability, pricing and all images, ready to sell.
How do you import products from two suppliers with different data formats?
Each source gets an adapter that fetches rows, normalizes them to a common shape and provides a unique key. Field mapping stays in the adapter, and the markup, variations, images and logging are shared.
Should each supplier have its own pricing markup?
Yes. Suppliers carry different commission tiers, so markup is configured per source. One global multiplier leads to lost margin.
How hard is it to add another supplier later?
With the adapter design it is one new class implementing fetch, normalize and key, not a new importer.