SAM
Menu

Feature

SAM ships 5000-pixel photos. Your media library doesn't have to suffer.

SAM photographs artworks at archival quality — 3000-5000 pixels per side, 4-8 MB per JPEG. Beautiful for the catalogue; vast overkill for a storefront. Defyn SAM resizes oversized images on import to a width you set (default 1500px, retina-grade for any product page) and cleans up the files cleanly when products leave SAM.

Works on Shopify and WordPress / WooCommerce.

The pain

Catalogue connectors don't know how big SAM photos are.

Most plugins sideload whatever SAM hands them, store the original at full resolution, and never clean up. Over months of sync cycles the consequences add up.

  • /wp-content/uploads/ grows by gigabytes per month. Hosts charge for storage; backups slow down; CDN cache hit rates drop because variants are huge.
  • Product page load times suffer — even with WordPress's image-srcset, browsers download multi-megabyte source images for thumbnails before the resize kicks in.
  • When a product leaves SAM and gets deleted, its attached image files stay on disk forever. Pre-v1.14 sync cycles silently leaked one orphan attachment per product per delete — measured in tens of thousands at long-running centres.
What it does

Resize on sideload. Cascade-delete on removal. Sweep the orphans.

Three coordinated mechanisms, each scoped tightly so nothing manually uploaded is ever touched.

  • Every image sideloaded from SAM is checked against a configurable max width (default 1500px). If wider, the original file is resized in place; WordPress regenerates all thumbnail variants from the resized source. Typical 70-80% disk savings per image with no visible quality difference at any storefront display size.
  • When a SAM product or artist is removed by the stale-cleanup or factory-reset job, its sideloaded attachments are deleted alongside — DB row and file on disk, in one call. Only attachments tagged with _sam_image_id (which only the plugin sets) are eligible.
  • A one-shot "Clean up orphan media" admin button sweeps pre-v1.14 attachments whose parent post no longer exists. Safe to re-run; on a freshly-cascaded site it finds zero matches.
How it works

Three guard rails, all gated on _sam_image_id.

  1. 01

    Tag at import

    ImageSideloader sets _sam_image_id post meta on every attachment it creates. That meta is the safety boundary — manually-uploaded featured images and unrelated media don't carry it and are never touched.

  2. 02

    Resize after sideload

    Once media_sideload_image returns the new attachment ID, the plugin checks the source width via wp_get_image_editor. If wider than max_image_width, it resizes in place keeping aspect ratio, then regenerates the thumbnail variants from the resized source.

  3. 03

    Cascade-delete on removal

    Stale-cleanup, factory reset, and any future deletion path call MediaCleanup::deleteSamMediaForPost(postId). Only attachments matching post_parent AND carrying _sam_image_id are eligible. wp_delete_attachment with force=true removes both the row and the file.

  4. 04

    Orphan sweep on demand

    Sync Dashboard → Maintenance → Clean up orphan media runs MediaCleanup::findAndDeleteOrphanSamMedia which finds attachments whose parent post is missing or zero. Catches up pre-v1.14 leaks and is safe to re-run on a clean site.

Where it kicks in

What this saved real centres.

Scenario: Hermannsburg had three years of catalogue churn before v1.14 landed. Their /wp-content/uploads/ had grown to 14 GB.

Result: Running the orphan-media sweep deleted ~6,200 attachments left behind by old SAM removals. Storage usage dropped to 4.8 GB without losing a single live product image.

Scenario: A centre kept hitting WP Engine's storage limit during seasonal sync bursts (Christmas, NAIDOC).

Result: Setting max_image_width to 1500 on a fresh sync brought average image size from 4.2 MB to 0.9 MB. Subsequent sync cycles stayed well under the storage quota.

Scenario: A centre needed full-resolution images preserved for in-gallery print sales but resized photos for the web.

Result: max_image_width is per-centre configurable. They set it to 0 (disable resize) and kept the originals. Cascade-delete still applied — they got the cleanup behaviour without the resize.

Questions

Frequently asked.

Will the resize affect existing images that synced before I upgraded?

No — the resize only applies to images going forward. To resize the existing library, either run Sync All with cleanup enabled (the SAM original re-imports and the resize applies to the new copy), or use the WP-CLI `wp media regenerate` command alongside the new setting.

Can I keep some images at full resolution and resize others?

The max_image_width setting is global per site rather than per product. For mixed needs, set the cap high (e.g. 3000) so most photos are kept large but truly oversized ones get capped, or set to 0 to disable entirely.

What if my server runs PHP-GD instead of Imagick?

Both work. The plugin uses WordPress's wp_get_image_editor which auto-selects whichever's available. If neither is present (extremely rare), the resize step logs a warning and skips — the image still imports at full resolution.

Is the cascade-delete safe with manually uploaded featured images?

Yes. Every delete is gated on _sam_image_id post meta, which is only ever set by the plugin's own ImageSideloader. Manually-uploaded featured images don't carry it and are never touched, even by the orphan sweep.

What does the "Clean up orphan media" button do on a freshly-installed site?

Nothing destructive. It scans every SAM-origin attachment and only deletes ones whose parent post is missing. On a clean site it finds zero matches and reports "Nothing to clean up — Media Library is already orphan-free." Safe to run any time.

See it in your tenant.

Want a 15-minute screenshare against your actual SAM data? Send us a quick note or call — we’ll line up a walkthrough at a time that suits.