Media & storage
Photos are most of what a classifieds site serves, and most of what it stores. Two admin screens cover them: Media → Settings for how images are processed, and Settings → Storage for where they live.
Image sizes
Section titled “Image sizes”Media → Settings → Image sizes defines the three sizes ShopClass generates from every upload:
| Size | Used for |
|---|---|
| Thumbnail size | Listing grids and search results |
| Preview size | The gallery strip on a listing page |
| Normal size | The full view a visitor opens |
Sizes are entered as dimensions. Bigger is not better here: thumbnails are what a browse page loads dozens of at once, and they set how fast the page feels.
Photo shape → Keep each photo’s own shape (on for new sites) only makes photos smaller, so a tall or wide photo keeps its shape and the theme frames it. When it is off, every photo is filled out to the exact size: with white in JPEG, see-through in PNG and WebP. Regenerate after changing it.
Regenerating
Section titled “Regenerating”Changing a size does not touch images that already exist. Under Regenerate images, the Regenerate button rebuilds them from the originals.
On a large site this is slow and heavy. Run it when traffic is low, and take a backup first.
Browser resize
Section titled “Browser resize”Browser resize (on by default) shrinks a photo to the normal size in the visitor’s browser before it is uploaded. A large phone photo then uploads fast and stays under the maximum size. The browser applies the camera’s rotation and drops the photo’s location data. JPEG, PNG and WebP keep their format.
While Original size is on, only photos over the maximum size are shrunk.
A theme can turn it off with data-osc-resize="off" on the uploader.
While Browser resize is on, the listing form also takes HEIC photos, the iPhone’s format. The browser turns them into JPEG before upload, so the server never sees HEIC. Safari can do this; a browser that cannot read HEIC says so and uploads nothing.
Photo format
Section titled “Photo format”Photo format says how new photos are saved:
- Keep the original format (default): JPEG, PNG, GIF and WebP stay as they are.
- Save as JPEG: the smallest choice for old browsers. Transparent parts turn white.
- Save as WebP: about a third smaller than JPEG, and keeps transparency. Shown only when your server’s PHP can write WebP.
Photos already uploaded keep their format.
Upload restrictions
Section titled “Upload restrictions”Maximum size caps what a visitor may upload, in KB. The screen shows the ceiling PHP itself imposes (Maximum size PHP configuration allows: n KB), and your setting cannot exceed it.
If you need a higher limit than PHP allows, raise upload_max_filesize,
post_max_size and memory_limit in PHP’s configuration first; the ShopClass
setting will not override them. It uses whichever of the three gives the
lowest number. A too-low PHP limit shows up as an upload that silently fails on
large photos. See debugging PHP errors.
The photo count per listing is set separately, in Listings → Settings.
Watermarks
Section titled “Watermarks”ShopClass can watermark uploaded images with text or with an image, configured separately.
Watermarking is applied as images are processed, so it affects new uploads. Existing images take it on when they are regenerated.
A watermark discourages your listings being scraped and re-posted elsewhere. Keep it small and in a corner: a watermark across the middle of the photo devalues the listing for the seller who posted it.
Offloading to S3-compatible storage
Section titled “Offloading to S3-compatible storage”Settings → Storage. By default images are written to oc-content/uploads/
on the web server. That is fine for one server and becomes a problem the moment
you want two, or when uploads outgrow the disk.
Storage offload moves them to an S3-compatible bucket (cloud storage that speaks the same protocol as Amazon S3, which most storage providers support), served directly to visitors.
Turn it on from the Active storage field: switch it from Local disk to Amazon S3-compatible, then fill in the connection below.
Providers
Section titled “Providers”The provider dropdown prefills the connection fields for:
- Amazon S3
- Cloudflare R2
- DigitalOcean Spaces
- Wasabi
- Backblaze B2
- MinIO / self-hosted
- Custom S3-compatible
Anything speaking the S3 API works through the custom option.
Connecting
Section titled “Connecting”Fill in the credentials and bucket, then press Test connection before saving anything. It confirms the credentials, the bucket and the permissions in one step, which is much easier to debug than a failed upload later.
Two fields deserve attention:
- Public URL: the hostname visitors will load images from. Set this to your CDN (a content delivery network: servers that cache and serve files closer to visitors) or custom domain if the bucket is behind one, not the raw endpoint.
- Local copies: Keep local copies or Delete after upload. Keeping a copy costs disk, and buys you a working site if the bucket becomes unreachable.
- Backups bucket and Backups kept: where backups saved to S3 go, and how many are kept.
Migrating existing images
Section titled “Migrating existing images”Turning offload on affects new uploads. Everything already on disk stays there until you move it, and the migration tools do that:
| Action | What it does |
|---|---|
| Offload all local images to remote storage | Queues every local image for upload. |
| Download all remote images back to local (offline copy) | Pulls everything back: an offline copy, and the way out if you change your mind. |
| Adopt existing Better S3 images | Takes over images already in a bucket from the Better S3 plugin, rather than re-uploading them. |
The queue
Section titled “The queue”Migration does not happen inside your request. It is queued and processed in the background, which is the only way it can survive a site with tens of thousands of images.
The screen shows pending jobs and failed jobs, with Process queue now to run it immediately rather than waiting for cron.
Watch the failed count. A handful of failures is usually a permissions problem on the bucket; a rising count means the credentials or the bucket policy are wrong and every job is failing the same way.
Before you offload
Section titled “Before you offload”- Take a backup: this rewrites where every image on the site is served from.
- Set a bucket lifecycle policy if your provider charges for storage you forget about.
- Make the bucket’s objects publicly readable, or serve them through a CDN that can read them. For a private bucket, turn on Serve files through time-limited signed URLs: each image link then carries its own time-limited access code, so visitors are not shown broken images.
- Test with a single new listing before migrating the whole library.