{
  "id": 17303135,
  "title": "The 1280 720 Lesson: Why a Zip Isn't Shippable Until It Has a Cover\"**",
  "url": "https://urgent.news/2026/10/30/the-1280-720-lesson-why-a-zip-isnt-shippable-until-it-has-a-cover",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-10-30T23:12:42.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/revanzart/the-1280-720-lesson-why-a-zip-isnt-shippable-until-it-has-a-cover-4mi8"
  },
  "original_language": "en",
  "account": "The 1280×720 Lesson: Why a Zip Isn't Shippable Until It Has a Cover\n\nZipping a product and uploading it felt incomplete. The listing lacked a cover, a thumbnail, and distinct images. The files themselves were fine. The problem lay in the absence of packaging. This realization led to a crucial rule: packaging must happen every time, automatically. This script, pack_product.py, zips files, renders a 1280×720 cover, and creates a 600×600 thumbnail, ensuring all three elements are present and consistent. The order of operations is important: the zip must be created first, followed by the images. This prevents any drift between the artifacts. Each time a product is edited, the entire process is repeated, ensuring a cover is always present. Metadata problems are often invisible until a rejection email arrives. To address this, make_metadata.py generates three separate CSV files based on the requirements of different channels. This ensures that each channel receives the correct header and format, preventing instant rejection due to metadata errors. Running the batch twice can lead to double-posting, which can result in an account being flagged. To prevent this, upload_tracker.py keeps a ledger of what has been uploaded and what is pending, allowing a retry after a crash to be safe rather than risky. The entire pipeline runs on a single core server, using 1 vCPU and 2 GB of RAM, thanks to rules such as running one process at a time, never parallelizing image jobs on one core, and measuring peak memory usage rather than average. The folder layout remains consistent, with assets in one directory, output in another, and metadata CSV files and finished zips in a third. This structure prevents a catalogue from turning into a \"junk drawer.\" The cover lesson applies beyond digital products. Every item in a catalogue should have a cover, a clean metadata row, and a note in the ledger indicating that it has been shipped. This ensures a catalogue is ready for sale, not just a folder of files. The digital asset factory is the kit built from this work, consisting of the four scripts, folder rules, and constraints enforced during the process. The result is a system that turns a collection of files into a shippable product line.",
  "summary": "The 1280×720 Lesson: Why a Zip Isn't Shippable Until It Has a Cover I zipped my first product and uploaded it. Then I looked at it in the store back end and felt something drop in my stomach. It was a bare archive. No cover, no thumbnail, no image on the listing at all. Just a title, a price, and an empty gray box where every competitor had a picture. The files inside were fine. That was the…",
  "key_points": [
    "Zipping and uploading products without cover is incomplete",
    "packproduct.py ensures zip, cover, and thumbnail are created together",
    "makemetadata.py generates correct CSV files for each channel"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}