DreamJeans Autopilot
The DreamJeans store receives hundreds of new products from wholesalers every day โ each size as a separate, "raw" item, with no photos or descriptions. Getting it ready for sale by hand would take long hours every single day. We built the client a bespoke system that does it all on its own, at night. In the morning the owner opens a single email and knows in 30 seconds what appeared in the store and whether anything needs attention. It is a solution tailored to this store and its integrations.
How it works โ step by step
New stock from wholesalers
Products flow in automatically from the warehouse and Baselinker โ for now as individual sizes, with no photos or descriptions.
Merging sizes
The system merges all sizes of one model into a single product with a convenient size selector.
Product photos
It automatically fetches the official manufacturer photos and attaches them to the right products and galleries.
Descriptions and categories (AI)
AI writes unique descriptions, assigns categories and tags โ consistently and for SEO.
Quality control
A product without a photo or description does not go live โ it waits and is finished the next night.
Publishing
Finished, complete products appear in the store โ ready to sell right away.
Summary email
In the morning the owner gets one clear report: what was added, what needs attention, the health of the store.
What you get
Hours of work every day
Hundreds of products a month prepared without manual clicking โ that time goes back to the business.
Works while the store sleeps
The whole process happens at night. In the morning the range is ready, with no morning bottleneck.
Consistent, high quality
Every product with a description, photo and category. Nothing unfinished lands in the store.
Tailor-made
Built for this specific store and its integrations (Baselinker, wholesaler, manufacturer).
Full control and safeguards
An emergency switch, no overlapping runs and an error report โ the system stays under control.
Faster to sale
New stock reaches the store the next day, not after weeks of manual processing.
Details
What exactly happens every night
At a set time the system starts on its own and walks new stock through consecutive stages: first it merges loose sizes into a single product, then fetches photos from the manufacturer, then has AI write the descriptions and pick categories and tags, and finally publishes only the products that are complete. Everything happens in small portions so that nothing gets overloaded โ the process is resumable and keeps the order on its own.
What the system is built from
It is a set of cooperating modules, each responsible for one stage: merging variants, fetching photos, generating descriptions with AI, a quality gate (hides incomplete products) and a store-health monitor. Overseeing it all is a "conductor" โ Autopilot โ which runs them in the right order and gathers the results into a single report. Because the modules are independent, the system is stable and easy to extend.
Safety and control
The owner has full control: there is an emergency switch (kill-switch), protection against two processes overlapping and a test mode on demand. An error on one product (e.g. a photo missing at the manufacturer) does not interrupt the whole night โ it is recorded in the report, and the product returns to the queue next time. Every morning email also includes a short "health status" of the store.
For the curious โ how it looks under the hood. Autopilot is a separate orchestrator plugin that does not duplicate logic but conducts existing, independent engines. It keeps the process state in the database (a state machine) and spreads the work across many short Action Scheduler queue jobs โ no stage is a single long process the host could kill. It is triggered by a real system cron via WP-CLI at a fixed time (not WP-Cron, which only fires on traffic).
Architecture: orchestrator + independent engines
Autopilot calls four engines headlessly (no nonce and no logged-in admin context): wc-variant-linker (scan_new โ create_variants), bs-image-linker (cdn_prepare โ fetch_batch with a ~60 s budget and resumption via next_offset), woo-ai-generator (get_products โ generate_product with retry and language validation) and hide-products-no-image (a passive gate reading _wag_status, the photo and the description length). The engines are independent and tied together by _GLOBAL / _wag_status meta keys โ the whole thing is stable and easy to extend.
State machine and job queue
The process is a hard sequence of stages: variants โ photos โ descriptions โ visibility. Each call processes one batch and reschedules itself (as_enqueue_async_action) until the stage queue empties โ then it transitions to the next stage. On top of that, per-product gating: the AI stage skips a product without a photo, which comes back the next night. This keeps us within the host time limits and makes the process fully resumable.
Fault tolerance and telemetry
Every batch item is in try/catch โ an error (e.g. a missing photo on the manufacturer CDN or a transient network error) goes to stats.errors[] with context (product, stage, message), and the loop carries on instead of taking down the whole night. Telemetry distinguishes "not on the CDN" (placeholder) from a real network error. Safeguards: a kill-switch, a lock against overlapping runs and a dry-run mode on demand.
Data, grouping and reporting
We group product families by the first token of the name (a stable HEAD), because the integration started pushing EAN-13 as the SKU and broke grouping by SKU โ a bespoke workaround fitted to the store's reality. Sizes are recognized by 5 variant-linker patterns. The report is an HTML email (wp_mail) to multiple recipients, with a database-health snapshot (db-health) in the footer; the run history lands in the wp_djap_runs table.