Cloud storage, video, and the catch-up tools

Last updated July 10, 2026

Beyond upload optimization

SWPL Media Optimizer’s everyday job – pre-sizing new uploads and imports – needs no setup. This article covers the bigger tools: cloud storage, video, and the pre-fetch for slow supplier feeds. All of them are off or manual until you choose them, and the tools that change or delete files never run on their own.

Cloud storage (Cloudflare R2), tested small first

If you want images or videos stored in the cloud instead of on your own server, follow this order – it is the order the plugin’s own Help tab teaches:

1. Set up the bucket first. The Help tab contains a complete “Set up Cloudflare R2 storage” walkthrough: what to create on Cloudflare’s side and exactly which value goes in which field here.
2. Turn storage on for NEW files first. Add one new image and confirm it appears in the bucket and loads correctly on the site. Do not migrate anything yet.
3. Migrate existing files only once new files work: Settings tab > Image storage > Migrate. The migration is the one tool whose Live button is deliberately locked until a dry run has finished for you to review – it is the only operation that copies files to an outside service. The dry run only counts.
4. “Free local disk” comes last. It is the only tool that deletes anything: the local copies of images already safely in the bucket. It is dry-run-first too. The bucket copies are always kept, so freed images keep serving and can be restored by re-downloading.

Images keep loading on every theme and builder

Once an image is stored in the bucket and its local copy is freed, the plugin makes sure pages serve it from the bucket no matter how the page produced the image – WordPress’s normal image functions, or a fixed link written into a page builder (Oxygen, Elementor, Bricks, Divi, Beaver), a widget, the Customizer, or hand-written content. It rewrites those links to the bucket address before the visitor’s browser loads them, and as a backstop redirects a direct request for a freed image to the bucket. This only happens when image storage is set to the bucket with a public address configured, only for image files, and it never moves or deletes anything.

Video: own first, then compress

Supplier-hosted product videos can be slow for shoppers and can disappear when the supplier changes hosts. The video lane fixes both, in two deliberate steps:

1. Measure first (read-only): Video tab > “Measure supplier video sizes”. It reads each video’s size without downloading anything and reports how many videos there are, their total size, roughly what storing them would cost, and whether they are big enough that compressing is worth it.
2. Own the videos. Choose which supplier videos to copy into your own storage. Start with “Only the products I list” – not “All” – and note the safety step: the video switch only holds when the field-name confirmation above it is also ticked. That confirmation certifies a human looked at a real product on the live store and checked that the video field name is exactly right and what its value looks like. If your switch turns itself off after saving, that confirmation is what is missing.
3. Compress, if the measurement said it is worth it. Compression needs a separate small worker server that you run, because the compression tool cannot run inside WordPress – the Help tab’s “Set up the video compression worker” guide walks through it. Test on a single video before doing the rest.

A video that arrives before its product is normal: the Video tab lists it as “waiting for their product”, and it connects automatically on the first nightly run after the product appears. Until then the product page keeps playing the supplier’s copy.

Pre-fetching supplier images for WP All Import

If your WP All Import runs take forever or skip images because the supplier’s image server is slow, use Turn on WP All Import pre-fetch. Point it at the same feed file your import reads, name the image column or element, and run it before your import: it downloads the images into the Media Library ahead of time, under the file name WP All Import looks for, so the import finds them locally instead of fetching from the slow server. Start with “Count images (no download)”, then “Stage images now”. Re-running is cheap – it skips anything already collected.

Reading a feed report: “already collected” filling most of it is the healthy steady state – after the first night, a feed usually only picks up the handful of genuinely new pictures. A failure or two is normal (the run carries on and retries the next night), and “orphans flagged” means those pictures’ addresses left the supplier’s catalog, so they were marked discontinued for bookkeeping – nothing was deleted, and the mark is removed automatically if the address returns.

How the long jobs behave

Every long job – the background batch, the library repair, the feed pre-fetch, the storage migration – works in small steps in the background. The status line tells you the state: Queued means the job started and is waiting for the next step to be picked up (completely normal for a freshly started job, not stalled); Running shows live progress; Completed means done. The panel updates itself in place while a job runs, the status is read fresh from the server on every page load, and jobs continue whether or not your browser stays open. Dry-run reports end with a plain-language summary, a file-by-file list, and a spreadsheet download link.