CodeCanyon Leopard - WordPress Plugin

How to Set Up CodeCanyon Leopard to Offload WordPress Media to the Cloud

CodeCanyon Leopard is not for superficial media library tweaks. It changes where your images, documents, videos, and some site files are physically stored. This guide walks through a safe setup process: preparing storage, connecting a provider, enabling offload for new uploads, syncing your existing media library, verifying URL replacement, and deciding which settings are better left off at first.

This article is for a WordPress site owner, webmaster, or developer who has outgrown the standard wp-content/uploads folder. We will focus on practical decisions: when to keep local copies, when it is safe to remove files from the server, how to avoid breaking images in WooCommerce products, why CORS and Cache-Control matter for fonts and files, and how to troubleshoot blank images, access errors, and stalled sync jobs.

This guide does not cover purchasing, activating, or bypassing licensing. It focuses on safely configuring a plugin you already have, along with the infrastructure around it. Any features that may vary are described carefully: if a specific interface item looks different in your build, follow the logic of the section and the developer's documentation.

What Problem the Plugin Solves and Where It Fits in Your Site Stack

The standard WordPress media library is straightforward: a user uploads a file, WordPress creates an attachment record, generates image sizes, and stores the physical files in wp-content/uploads. That works well while the site is small. Problems start to show up in stores with thousands of products, publications with years of archived content, training sites with PDFs and videos, and BuddyBoss communities where users constantly upload avatars, covers, and attachments.

Leopard adds a layer between the media library and external storage. The file still appears in WordPress as an attachment, but it is copied to a cloud bucket. The plugin then rewrites the URL so the public site loads the file from your web server's S3-compatible storage, Google Cloud Storage, DigitalOcean Spaces, Bunny Storage, Cloudflare R2, Backblaze B2, Wasabi, MinIO, Contabo, or another supported option available in your version.

The real benefit is not just "the cloud." It is a clean separation of responsibilities. WordPress handles records, the editor, products, pages, attachment metadata, and content relationships. Object storage handles large files, static delivery, CORS, caching headers, and sometimes CDN delivery. If that boundary is configured carefully, your site depends less on hosting disk space and scales more gracefully as the media library grows.

The plugin is especially interesting because it goes beyond the basic "send new images to S3" use case. The product description mentions existing file migration, background auto-sync, custom bucket paths, Cache-Control and CORS management, WebP and AVIF in recent releases, WooCommerce and Easy Digital Downloads support for digital files, cloud file selection, BuddyBoss support, WP-CLI, Rclone, and migration from WP Offload Media. That makes CodeCanyon Leopard a more technical tool than many lightweight CDN URL plugins.

But that breadth also requires discipline. You cannot just enable everything and assume the site will get faster. You need to decide in advance which files are public, which should stay protected, who can access the settings, what the caching plugin is doing, how links are stored in older content, and whether you can quickly restore a local copy of a file.

Typical Use Cases

Most sites use Leopard in one of four ways. The first is a new project where offload is enabled before content uploads begin. That is the cleanest option: all new files get the correct path from the start, and there is less to test.

The second is an existing site with a large media library. Here, background sync, batch limits, keeping local copies during the first phase, and checking older pages all matter more. Mistakes are also more visible on a site like this: one incorrect setting can affect thousands of images.

The third is a store or catalog with digital files. In WooCommerce and Easy Digital Downloads, it is not enough to display the product image correctly. You also need to avoid exposing a private file that should only be available after purchase or login. Leopard advertises cloud-folder file selection for these products, including public and private modes, so access configuration becomes part of the user flow.

The fourth is optimization of theme, plugin, and WordPress core assets. The plugin can offload JS, CSS, fonts, SVGs, and other files from themes, plugins, and core, and can also rewrite asset URLs. That is not useful for every site: on a well-configured site with hosting-level CDN delivery, the effect may be modest, while on a complex theme with unusual fonts or Cloudflare R2, limitations need to be checked separately.

Who CodeCanyon Leopard Is For, and When Another Approach Makes More Sense

Leopard is worth considering when the media library has become an infrastructure problem. Typical signs include backups growing mostly because of images, site migrations taking hours, your host warning you about disk usage, and pages with many product cards pulling tens of megabytes from the same server that is supposed to handle PHP and the database.

The plugin is a good fit for sites that have someone ready to take responsibility for the bucket, access keys, file domain, and response header checks. That person does not need to be a DevOps-level engineer, but they do need to be a careful administrator. Cloud storage does not eliminate site maintenance. It shifts part of the responsibility from the hosting panel to the provider's panel.

For agencies, Leopard can be a convenient all-in-one tool for different clients because it supports multiple providers and workflows: traditional S3, R2, Spaces, Wasabi, Backblaze B2, MinIO, Bunny Storage, and migration between buckets. For WooCommerce and Easy Digital Downloads projects, the value is even higher if you genuinely need large digital files or separate access control for downloadable content.

The plugin may not be a good fit if the site is small, the media library takes up little space, and performance issues can be solved with standard image caching, modern image formats, and hosting-level CDN delivery. It can also be overkill if the team does not want to store cloud access keys in WordPress, is not willing to read provider documentation, or does not have a recovery plan for a failed sync.

When a Simpler Solution Is the Better Starting Point

If your main pain point is heavy images rather than disk space, start with image sizing, WebP/AVIF, lazy loading, and caching. Offload will not fix a 6000-pixel image placed inside a 600-pixel product card. It will serve that file from a different location, but the user will still download unnecessary weight.

If you want a fully managed service without setting up buckets, keys, and a CDN yourself, look at products where the infrastructure is built in. They usually cost more over time, but they remove part of the technical burden. If owning your own bucket and choosing your own provider matters, Leopard is the more logical fit.

If the site deals with gated content, memberships, training materials, or paid digital products, do not start with a public bucket. First, figure out which files should be public, which should be delivered through temporary URLs, where user permissions are checked, and whether your chosen provider supports the required setup.

What to Check Before Installation and the First Sync

Preparation matters more than installation. With a typical plugin, a setup mistake may affect one widget or form. With a media offload plugin, a mistake can affect images, styles, PDFs, digital downloads, and older posts. So before anything else, separate testing from production rollout.

The bare minimum before enabling offload is a fresh backup of the database and the uploads folder. You need the database because WordPress stores attachment records, size metadata, paths, and content relationships there. You need the uploads folder because during the first phase it is better to keep a local source you can fall back to without panic.

Make sure the site is not in the middle of another migration, a bulk product import, thumbnail regeneration, or background image optimization. If several processes are touching the media library at once, you will not be able to tell whether Leopard, the image optimizer, the importer, the cache, or the theme caused the problem.

Infrastructure Checklist Before You Start

Before opening the plugin settings, prepare the external side of the setup. With S3-compatible providers, you usually need a bucket, a region or endpoint, an access key, a secret key, a public file domain or CDN domain, and a clear decision on read permissions.

• Create the bucket in advance if you do not want the plugin to create it for you or if the provider requires a specific naming pattern.
• Limit the access key to the minimum permissions required: upload, read, delete, and bucket listing only where those permissions are actually needed.
• Choose the file domain before launch so you do not have to change URLs after the media library has already been synced.
• Configure CORS for your site if files will be used by the browser from another domain, especially fonts, videos, PDF viewers, and private links.
• Plan Cache-Control in advance: static images can usually be cached longer, while frequently updated files and private materials require more caution.
• Have a rollback plan: know where to disable URL rewriting, how to restore local copies, and where to review failed files.

Do not use the main administrative key for the entire cloud account if you can create a separate user or application key for only the required bucket. In Backblaze B2, for example, S3-compatible apps use an Application Key ID and Application Key, and a restricted key may still need bucket listing permission. AWS, Cloudflare, DigitalOcean, and Google use different terminology, but the principle is the same: fewer permissions mean fewer consequences if something goes wrong.

What to Check on the WordPress Side

On the WordPress side, the condition of the media library matters. Open a few older images in the admin area, look at thumbnails in different sizes, check a WooCommerce product, a blog post, a builder page, and a downloadable file if that workflow exists. This gives you a baseline sample set. After setup, you will compare the same pages again.

If the site uses Elementor, Divi, WPBakery, Gutenberg blocks, ACF fields, WPML, WP All Import, BuddyBoss, caching plugins, or image optimizers, do not enable the most aggressive settings right away. First verify standard images, then test files that go through each specific integration in a separate pass.

Practical rule of thumb: run your first test on a site copy or on a small batch of fresh files. Only do a full media-library migration after new uploads, URL rewriting, thumbnails, and cache clearing have all been verified on real pages.

Installing the Plugin and Performing the First Admin Check

Installing CodeCanyon Leopard is technically no different from installing any commercial ZIP plugin. In WordPress, go to Plugins, then Add New, use Upload Plugin, select the ZIP archive, and after installation click Activate Plugin. If the server will not accept the archive through the browser, the standard fallback is to upload the extracted folder via SFTP to wp-content/plugins and activate it from the plugin list.

After activation, do not jump straight into a full sync. First find the Leopard menu item or its settings page in the admin area. Tab names may change between releases, but based on the product description and changelog you should expect a provider connection area, media settings, a sync tab, advanced performance settings, data tools, and access settings for administrators.

How to Tell the Plugin Is Ready to Configure

The initial check has three levels. First, the plugin page should open without PHP errors or blank screens. Second, WordPress should still display the media library and existing images. Third, the browser console and server logs should not show recurring errors related to REST requests, AJAX, permissions, or JavaScript conflicts.

If the admin area becomes slower after activation, do not enable offload until you have diagnosed the cause. The issue may be a conflict with another plugin, an outdated PHP version, object caching, a memory limit, or a problem with scheduled tasks. Recent Leopard releases specifically mention optimizations for large sites, lazy-loaded integrations, and settings such as Batch Size, Chunk Size, Chunk Sleep, and Time Limit. Those options are useful, but they should not be used to hide a basic environment problem.

Why You Should Not Delete Local Files Right Away

The option to remove files from the server after copying saves disk space, but it also changes your recovery model. As long as a local copy exists, a mistake involving the bucket domain, CORS, the CDN, or access permissions can often be fixed through configuration. Once the local copy is gone, every incorrect URL becomes much more critical.

For the first rollout, it is better to keep local files, enable cloud copying and URL rewriting, test your pages, and only then decide whether disk cleanup is safe. This step is especially important for stores, sites with training materials, and projects with user uploads. Saving disk space should not be your first test of whether the plugin works.

Connecting Cloud Storage: Bucket, Domain, CORS, and Cache-Control

Provider setup is the core step. Leopard supports multiple targets, but the underlying pattern is similar: choose the storage type, enter keys, specify the bucket, region or endpoint, define the file delivery domain, and configure behavior settings. Do not try to copy every field from someone else's guide if you are using a different provider. For example, AWS S3 and Cloudflare R2 share a similar S3-compatible model, but their rules for public access, custom domains, and caching are different.

Start with the provider your team can support most easily. AWS S3 offers a mature permissions model and tight CloudFront integration, but it requires careful IAM setup, Block Public Access configuration, and bucket policies. Cloudflare R2 is often chosen alongside Cloudflare CDN and a custom domain, but for public cached delivery you need to understand that a custom domain makes the bucket available through a public URL, and CORS headers will only appear when the request includes the proper Origin. DigitalOcean Spaces is simpler for many site owners and includes a built-in CDN endpoint, but that CDN has its own TTL and separate cache purging. Backblaze B2 uses its own key terminology, and its S3 endpoint and region must be taken from the actual bucket panel.

Fields You Should Not Confuse

The most common storage setup mistake is mixing up the control panel URL, the API endpoint, and the public file domain. The API endpoint is what the plugin uses to write and read objects. The public domain is what the browser uses. The CDN domain may be a third address if files are served through a layer in front of the bucket.

How to Read the Main Connection Fields

Field	What It Means	How to Verify It
Access Key	The key identifier the plugin uses to authenticate with the provider API.	The connection test in Leopard should complete without an authorization error.
Secret Key	The secret part of the credentials. It should never be shared in plain text, included in unmasked support tickets, or committed to public repositories.	If the secret is wrong, the bucket often will not be selectable or the upload will fail.
Bucket	The container where media library files and, if enabled, assets will be copied.	After a test upload, the object should appear in the expected bucket folder.
Region or Endpoint	The API address and storage location. With S3-compatible services, the endpoint is especially important.	An incorrect endpoint often causes connection errors or an empty bucket list.
Custom Domain or CDN URL	The address that will appear in page HTML instead of the local uploads path.	Open the file in a new tab and check HTTPS, MIME type, and response codes.

After saving the fields, upload one test file to the media library. Do not use some random image from an older post. You need a fresh file that goes through the full WordPress - Leopard - bucket - public URL path. Then open the attachment details page and inspect the URL. If the plugin shows cloud status or a sync filter in the Media Library, use that as an extra indicator.

CORS for Fonts, Video, and Browser Requests

CORS is not required for every image, but it becomes important when the browser requests a file from another domain and needs to read response headers. Fonts, video, PDF viewers, canvas operations, temporary private links, and some assets run into this more often. The symptoms can be confusing: the file opens directly, but the font does not work on the page, the video player shows an error, or the browser console reports blocked access.

For public images, it is often enough to allow GET and HEAD from your site domain. For browser uploads or temporary links, the rules may need to be broader and match the actual methods in use. Do not use a wildcard just because it is faster. That can be acceptable as a temporary step in a test environment, but on a live site it is better to specify the exact origin.

A safe CORS pattern for publicly served static files looks like this. This is not a ready-to-run command for a specific provider, just a field layout you should adapt to your service's format:

{
  "AllowedOrigins": ["https://example.com"],
  "AllowedMethods": ["GET", "HEAD"],
  "AllowedHeaders": ["Content-Type"],
  "ExposeHeaders": ["ETag", "Content-Length"],
  "MaxAgeSeconds": 3600
}

After changing CORS, purge the CDN cache if files are already being served through a custom domain. Otherwise the older response may still be cached on an edge node, and you may end up blaming Leopard when the real issue is that the updated headers have not propagated yet.

Cache-Control and Object Versioning

Cache-Control determines how long browsers and intermediate caches consider a file fresh. For product images, illustrations, and static documents, longer caching is usually helpful. For files that are often replaced under the same name, a long max-age can cause users to see an outdated version.

Leopard advertises Cache-Control management and object versioning for the media library. The practical meaning is simple: if the URL changes when a file is updated, the CDN can more easily recognize it as a new object. If the URL stays the same, you need to think about cache purging after replacement. Do not enable aggressive caching until you have verified how image replacement behaves: upload a file, replace it, purge the cache according to the provider's instructions, and make sure the page shows the new version.

Media Settings After Installation: From New Uploads to Your Existing Archive

Once the bucket is connected, the main setup splits into two streams: what to do with new files and what to do with the existing media library. Mixing those tasks is risky. New uploads give you a fast plugin functionality test. The older archive creates load, depends on server limits, and may expose edge cases in paths, filenames, thumbnails, and old HTML.

Start with new uploads. Enable automatic cloud copying, keep the local copy, upload an image, a PDF, and, if the site uses video, a small test video file. Then check different contexts: the media library, a post page, a product page, an archive thumbnail, an image inside a page builder, and a file inside an email or a link if that workflow exists.

How to Choose the Bucket Path

Leopard supports a custom bucket folder path and a Year & Month Folders option. This is not just about keeping things tidy. The path affects migration, compatibility with existing files, cache purging, and future moves between providers.

If the site is new, you can use a clear prefix like media/ or uploads/ and keep the year-and-month structure if it helps with maintenance. If the site is older and already uses URLs like /wp-content/uploads/year/month/file.jpg, keeping the date-based folders helps preserve a predictable structure. If you are moving from another offload plugin, the path should account for the existing structure. Otherwise WordPress records may point to one location while the object actually lives in another.

Avoid overly complex prefixes: client name, environment, site type, language, and migration date all in one path may seem informative on day one, but after a few months it gets in the way of automation. It is better to separate environments with different buckets or clean top-level folders such as production/ and staging/ if your setup truly requires shared storage.

Should You Delete Files from the Local Server?

The option to remove local files after copying is the most appealing and the most risky. It makes sense when disk space is genuinely limited or the media library is too large for backups. But before turning it on, answer a few questions.

• Have all image sizes been uploaded to the cloud? WordPress creates multiple thumbnails, and pages often use an intermediate size rather than the original.
• What happens if thumbnails need to be regenerated? If the local original is gone, make sure your setup can rebuild safely.
• How do product imports behave? A bulk import may expect local files or may re-upload images.
• Do you have a bucket backup? Cloud storage is not the same as backup if deletion in WordPress is mirrored to storage.
• Can you quickly disable URL rewriting? If local files are gone, turning off URL replacement may not bring images back on the page.

A practical order looks like this: first sync with local copies kept, then test pages, then do selective cleanup on a test group, and only then perform large-scale cleanup if the recovery plan is clear. If the site is commercial, do this during a low-traffic window and have your hosting contact ready in advance.

Bulk Sync Without Overloading the Server

For an older media library, resilience matters as much as speed. Leopard's changelog specifically mentions improvements for large sites, a reworked Media Sync system, and advanced performance settings such as Batch Size, Chunk Size, Chunk Sleep, and Time Limit. Their purpose is to control batch size, pauses between batches, and execution time so the task does not run into PHP limits, memory issues, or server locks.

Do not choose the maximum values right away. Start with a moderate batch and watch for four signals: whether the number of synced files is rising, whether the error queue is growing, whether the admin area is slowing down, and whether server logs show timeouts. If everything stays stable, you can increase the batch size. If errors appear, reduce the batch and increase the pause.

Quick takeaway: a successful sync is not just a completion message. Check the actual object in the bucket, the URL on the page, the thumbnail in an archive view, the original in the Media Library, and cache behavior after purging.

Media Sync, Underground Sync, and Migration Between Storage Providers

One of Leopard's more distinctive features is its focus on syncing large media libraries and moving data between buckets or providers. The product description uses the term Underground and automatic synchronization: the idea is that long-running jobs can continue without requiring an administrator to keep a browser tab open. On large sites, that is a meaningful difference compared to simpler tools where a bulk operation depends on an active browser tab.

Recent releases also mention Storage Migration, including bucket-to-bucket copying and sync between providers. That is useful when a site has outgrown an older provider, needs a different region, is moving from S3 to R2, needs to split data across environments, or wants to bring an older bucket structure into a new scheme. But migration between storage systems requires even stricter validation than the first offload rollout.

How to Read Sync Status

In the sync interface, three groups usually matter most: synced files, pending files, and problem files. For the administrator, the key issue is not the absolute number but whether the status changes over time. If a counter does not move for a long time, check background jobs, PHP limits, bucket permissions, and API availability. If the number of errors keeps rising, stop the bulk process and inspect the first few problem files manually.

Syncing large videos, PDFs, and images should not compete with peak traffic. Even if the cloud storage can handle the load, WordPress is still processing records, metadata, database queries, and background calls. For large media libraries, it is better to run migration in batches and keep local copies until verification is complete.

Migrating from Another Offload Plugin

Leopard advertises migration support from WP Offload Media. That does not mean every third-party record format will be recognized automatically. Before migrating, you need to understand where the old plugin stores its data: in a dedicated table, in post meta, in its own option records, or only through on-the-fly URL rewriting. If that structure is not supported directly, you can end up in a state where the physical files are in the cloud but WordPress does not understand their new status.

A safe approach is to first disable automatic deletion of local files, then run a test migration on a small set, verify several attachments with different sizes, and only then continue. If the older plugin used a custom domain, do not change that domain at the same time as the record migration. First preserve file delivery, then change the domain or CDN separately.

Moving Between Buckets and Providers

When moving between buckets, it is not enough to copy objects. You also need to verify that the new URLs match what WordPress serves, that CORS and Cache-Control were migrated or reconfigured, that private files did not become public, and that public images did not become inaccessible.

Rclone can be useful as an external tool for copying and comparing directory trees between storage systems, but it should be used carefully. The official Rclone documentation recommends learning in interactive mode to avoid accidental data loss. In the context of Leopard, that means you should not replace the plugin's built-in migration with manual sync unless you clearly understand how the plugin stores object status in the WordPress database.

Theme Assets, WebP/AVIF, and Compatibility with Image Optimizers

Leopard can work not only with media library files, but also with assets: JS, CSS, fonts, SVGs, and files from themes, plugins, and WordPress core. This is a separate mode that should only be enabled after standard images are already working. The reason is simple: assets are part of page rendering. If a product image fails to load, the problem is obvious, but the page often remains readable. If CSS or a font fails because of CORS, the site's appearance can break completely.

The product description includes a specific limitation for Cloudflare R2: the plugin does not support fonts and icon fonts with offloaded CSS in the Asset function. That is an important example of why you should not carry settings over from AWS S3 to R2 without testing. If the theme uses woff2, woff, or ttf, test fonts on a separate page first and open the browser console.

How to Enable Asset Pull Without Breaking the Design

The correct order is this: first enable media library offload, then verify images, then enable assets only for one file type or on a staging copy. If the interface lets you limit asset types, start with lower-risk files that are easier to verify. After saving the settings, clear the WordPress cache, the optimization plugin cache, the CDN cache, and the browser cache.

Result checks should include the homepage, a post, a product page, the cart or checkout page if WooCommerce is active, and one builder page. Look not only at the page layout but also at the network requests. A 404 error usually points to a wrong path or missing object. A 403 error usually points to permissions. A CORS error will usually appear in the browser console and is especially common with fonts.

WebP and AVIF Alongside Image Optimizers

Leopard advertises WebP support, and the changelog notes that AVIF was added. The product page also says it is compatible with popular image optimizers, but with an important caveat: the comparisons with EWWW Image Optimizer, ShortPixel, TinyPNG, and Smush are marked as compatible when server-side file deletion is not being used. That makes sense, because an optimizer often needs the local original or access to intermediate files to rebuild variations.

If you use an optimizer, do not run large-scale optimization and large-scale offload at the same time. First make sure local format generation is stable, then verify that the new formats are being uploaded to the bucket, and only then consider deleting local copies if the optimizer and Leopard still leave you with a reliable recovery path.

To verify, open the page source and look for srcset, picture, or links to WebP/AVIF if your theme outputs them. Every size should point to the expected domain. If some links are still local, check the cache, attachment metadata, and the order in which the optimizer runs.

WooCommerce, Easy Digital Downloads, and Cloud-Based Files

An online store adds two different types of files to an offload setup: public product media and downloadable assets. Public images can usually be served through a CDN without special restrictions. Downloadable files require access control: the user should receive the file only under the store's rules, and a direct URL should not accidentally become a permanent public link if the product is restricted.

Leopard advertises integration with WooCommerce and Easy Digital Downloads, cloud-folder file selection for digital products, and support for both public and private modes. Older product changes also mentioned fixes for download links, shortcode insertion, and WooCommerce files. That makes stores one of the use cases where the plugin needs especially careful setup.

Product Images and Galleries

For product images, thumbnails matter most. WooCommerce creates its own sizes, the theme may add more, and the optimizer may generate alternative formats. After enabling Leopard, open the product page, the category archive, quick view, the recommended products block, and the cart if it displays thumbnails.

If the original shows on the product page but the archive thumbnail is blank, the issue is often not the main file but one of the generated sizes. Check whether that size was created before offload, whether it was copied to the bucket, and whether the local file was deleted before sync completed. If needed, regenerate thumbnails through the standard WordPress method or WP-CLI, but first make sure the plugin and optimizer understand the current storage model.

Downloadable Products and Private Files

For a digital product, seeing the link in the admin area is not enough. You need to run a test as a customer or administrator with valid access, and separately verify that a guest user cannot open the restricted file directly. If the provider and plugin use temporary URLs, test both the lifespan of the link and what happens after it expires.

Do not mix a public bucket for images with private files unless you have a clearly defined setup. For some projects, it is easier to keep the public media library and restricted downloads in separate buckets. That makes CORS, permissions, CDN rules, and cache purging easier to manage. If your Leopard version lets you choose a cloud file for WooCommerce or Easy Digital Downloads, use that as the controlled workflow instead of manually pasting direct URLs into the product description.

FTP Files and Cloud Folders

The product page includes an important limitation: the FTP feature is meant for uploading files to the cloud, but not for images, because images require multiple generated sizes. The practical conclusion is simple: FTP is better suited for large digital files, archives, PDFs, or other objects that will later be selected from the cloud for WooCommerce or Easy Digital Downloads. For standard images, use the WordPress media library so WordPress can generate all required sizes and metadata.

After selecting a file from the cloud, verify not only that it downloads, but also the response headers. For PDFs and archives, Content-Type, Content-Disposition, file size, partial download support, and correct CDN delivery often matter. If the browser tries to open the file instead of downloading it, or downloads it when it should open inline, the issue may be in the object metadata rather than WordPress.

BuddyBoss, WPML, Page Builders, and Other Integrations

Leopard lists support for Elementor, BuddyBoss, WPML, WP All Import, ACF PRO, and several other popular tools. In practice, that does not mean every workflow works automatically. It means the developer has taken these areas into account and has fixed at least some conflicts. You still need to test your own pages, because every theme, builder, and caching layer can retrieve attachment URLs in its own way.

For Elementor and other builders, the main test is images selected from the media library inside widgets. Create a page with an image, a section background, a gallery, and an icon if those elements are in use. After offload, verify that CSS background images also receive the correct URL and are not still being served locally from the builder cache.

BuddyBoss and User Uploads

BuddyBoss generates more user media than a standard blog: avatars, cover images, attachments, videos, and documents. Leopard's changelog mentions BuddyBoss support along with specific fixes for video, documents, previews, and performance. That means after setup, you need to test not only older content but also the real user upload flow.

Create a test member, upload an avatar, a profile cover, and a file in the activity stream if that feature is enabled. Then check the result as an administrator, as the member, and as a guest. If the object is supposed to be private, confirm that the direct URL does not expose it more broadly than intended. If the material is public, check both performance and thumbnail behavior.

WPML and Multilingual Attachments

With WPML, the important issue is not only the files themselves but also translation relationships. If the same file is used across multiple language versions, the URL should be rewritten consistently. If a translation has its own image, it should have its own object and metadata. After syncing, check pages in every language, media translations, and the sitemap if an SEO plugin includes image entries.

Leopard's changelog includes a fix related to wp_get_attachment_url calls in the Yoast sitemap. That is a good sign that attachment URLs can affect your SEO infrastructure. But the article should not promise automatic ranking improvements. The real goal is to make sure search engines can access valid images, do not receive broken URLs, and do not crawl restricted files.

WP All Import and Bulk Uploads

When importing products, posts, or catalogs through WP All Import, the main trap is concurrency. The importer creates attachments, WordPress generates image sizes, the optimizer may compress files, and Leopard copies them to the bucket. If the import is large, background queues can fall behind.

It is safer to split the process into stages: import a small batch first, wait for media generation to finish, verify offload, and only then scale up. If some images remain local after import, do not rerun the import over the same records until you understand why. Check the sync queue, batch limits, API errors, and the presence of files in the bucket.

Practical Example: Moving a Store Media Library to Cloudflare R2 or Another S3-Compatible Storage Service

Consider a concrete use case: a WordPress store running WooCommerce, with a large number of product images and a few digital files. The goal is to serve public images from a cloud domain, keep product pages working correctly, and prepare a separate validation path for downloadable materials. The provider could be Cloudflare R2, AWS S3, DigitalOcean Spaces, Backblaze B2, or another S3-compatible service, but the exact field values should always come from that provider's own panel.

Goal and Preparation

We want three outcomes. First, new media library images should automatically be copied to the bucket. Second, product pages should use URLs from the chosen file domain. Third, older images should be movable in batches without interrupting the store.

Before you begin, prepare a backup, a test product, a test post, one PDF file, access to the provider panel, and a low-traffic maintenance window. You usually do not need to take the store offline for this kind of test, but you should avoid running a bulk sync during an active import or marketing campaign.

Setup Steps

1. Create the bucket and choose the region or endpoint. For public images, configure the file delivery domain. For restricted materials, decide in advance whether they should use a separate bucket.
2. Create a restricted access key. Do not use the main account key if the provider allows you to grant bucket-specific permissions.
3. Open the Leopard settings and choose the provider. Enter the keys, bucket, region or endpoint, file delivery domain, and save the settings.
4. Run the connection test if your version includes that button. If it fails, do not continue until you fix the keys, region, endpoint, or permissions.
5. Enable offload for new uploads and keep local copies. Upload a new product image and verify that the object appears in the bucket.
6. Check the URL on the public site: the product page, the category archive, the cart thumbnail, and the file opened in a new tab.
7. Configure CORS and Cache-Control only after the basic check passes. If you use R2 with a custom domain, purge the cache after updating CORS.
8. Start syncing older files in a small batch. Watch for errors, speed, and load.
9. Test the digital file separately. Do not consider the product properly configured until you have verified access for an authorized user and denial for a guest if the file is restricted.

Expected Outcome and Verification

After a successful setup, the product image URL in the page HTML should point to your file domain or CDN domain. The bucket should contain the original image plus the generated sizes WordPress uses. The product page should look the same as it did before the move, but image requests should no longer go to /wp-content/uploads/ on the main domain. They should go to the new address instead.

Do not test only one page. Open a product, a category, a search result, the cart, an order email with an image if your setup includes one, and a builder page. If you use a WebP/AVIF optimizer, check both a browser that supports those formats and a browser or mode where the original format may still be served.

The Most Common Friction Point

The most frustrating failure is when a file looks synced in the admin area, but some public pages still show the old URL. Cache is often the culprit: page cache, builder cache, CDN cache, object cache, or static HTML generated by an optimizer. First clear all caches, then inspect the page source. If the HTML already contains the new URL but the browser still shows the old file, look at the CDN. If the HTML still contains the old URL, investigate the WordPress side: attachment metadata, a cached block, a template, or a plugin storing the URL separately.

Verifying the Outcome: How to Confirm the Site Is Really Running Through the Cloud

Verification should be repeatable. "The image opened" is not enough. You need to know which file opened, where it was served from, which headers came back, whether the thumbnail works, whether older content is intact, and whether a private file accidentally became public.

Baseline Page Set

Build a small page list before the bulk migration begins. For a standard site, that usually means the homepage, a post with an image, a page with a gallery, a category archive, and a page with a PDF. For a store, add a product page, a category page, the cart, and a downloadable product. For BuddyBoss, add a profile, an activity item, and an attachment. For a builder-based site, include a section with a background image and a widget that pulls media from the library.

Return to this same list after each stage. That makes it easier to see which setting changed the behavior. If you enable offload, asset rewriting, local file deletion, and aggressive caching all in one evening, troubleshooting turns into guesswork.

What to Check in the Browser

Open developer tools and the network tab. Make sure images and files are loading from the expected domain, returning 200 or valid redirect codes, using the correct Content-Type, and not being blocked by CORS. For fonts, verify that there are no console errors. For video or large PDFs, verify that the file does not cut off and is not downloaded as an empty file.

If a CDN is in use, look at the headers that indicate a cache hit. Different providers use different names, but the meaning is the same: after the first request, the CDN should usually serve the file from a nearby edge node instead of going back to the origin every time. Do not draw conclusions from a single request immediately after a cache purge.

What to Check in WordPress

In the media library, check sync status, offloaded/not offloaded filters, actions available for an individual attachment, and thumbnail display. On the attachment edit screen, pay attention to the file path, the image sizes, and whether image editing still works. Leopard advertises support for Scale, Crop, Rotate, and Flip on cloud-hosted images, but on your site this should be tested on a copy, especially if local originals have already been removed.

For SEO checks, open the sitemap if it includes images, and review a few public pages. The image link should return an accessible file without an authorization error. There is no need to expect an immediate indexing change. The purpose of the check is simply to confirm there are no broken URLs and no cache conflicts.

Performance, Security, and Risky Settings

Offload is often sold as a way to speed up a site, but the reality is more nuanced. If the page is slow because of a heavy theme, slow database queries, or third-party scripts, moving images to a bucket will not solve everything. It reduces load on the web server, helps with disk usage, and can improve file delivery through a CDN, but the real effect depends on media size, visitor geography, caching, image formats, and provider quality.

From a security perspective, the biggest risk is access control. Older Leopard releases had reported vulnerabilities related to permission checks and access to settings. Security sources mark those issues as fixed, and the product changelog includes security updates. So the practical recommendation is straightforward: use a current version, limit access to the settings, and do not leave older builds on a live site.

Access Control Inside Leopard

The changelog for the latest major branch mentions Access Control, which restricts which administrators can manage Leopard. For a product that stores cloud access keys and file visibility settings, that is not a small detail. Not every user with access to the WordPress admin should be able to change the bucket, enable local file deletion, or edit storage paths.

Review your user roles. If the site is maintained by an agency, content managers should not have access to offload settings. If the site includes a store, the shop manager and editor roles should not automatically gain the ability to modify infrastructure settings. Use Leopard's built-in access restrictions if they are available in your version, along with the standard WordPress principle of least privilege for everyday work.

Public Bucket or Private Delivery

For public blog or product images, open read-only access can be perfectly reasonable. For restricted materials, paid files, internal documents, and membership videos, it is not. AWS S3 offers Block Public Access and private content delivery through CloudFront. Cloudflare R2 buckets are private by default, while a custom domain makes files accessible through a public URL, so access control has to be designed separately.

Do not use the same path for public images and private files unless you are fully confident in the rules. It is better to spend extra time separating buckets or prefixes than to discover later that a restricted PDF is being indexed or opened without authorization.

Compatibility with Cache and Optimizers

WP Rocket, W3 Total Cache, LiteSpeed Cache, and other caching plugins can store HTML that already contains rewritten URLs. That is usually helpful because visitors receive ready-to-use CDN links. But when the file domain changes or offload is disabled, the cache may keep serving the outdated address. After changing Leopard settings, clear caches in layers: WordPress cache, optimizer cache, CDN cache, and only then the browser cache.

If you enable asset rewriting, temporarily disable CSS/JS combining and minification in the optimizer, verify that assets are being served from the bucket correctly, and only then turn optimization back on. That makes it much easier to determine whether Leopard, the minifier, or the CDN broke the path.

How to Build a URL Strategy You Will Not Need to Redo in a Month

The most expensive mistake in an offload project is starting a migration with a temporary domain and then deciding later that public files should load from a different address. Technically, URLs can be changed, but on a large site that affects caches, the sitemap, saved builder blocks, WooCommerce emails, external links, images in RSS feeds, and sometimes third-party channels that have already picked up the old addresses.

Before bulk sync begins, choose a clear URL strategy. There are three common options. The first is to serve files directly from the provider's domain. That is faster to launch, but it looks worse in analytics and is harder to migrate later. The second is to use a site subdomain such as media.example.com or static.example.com. This is usually better for branding, easier to route behind a CDN, and clearer to users. The third is to use the CDN domain issued by the provider. That can be fine for testing, but for a production site it is usually better to configure your own HTTPS domain.

This matters in Leopard because the plugin rewrites media and asset URLs. If you choose the wrong domain, the migration itself is not what you end up fighting. The real pain comes afterward: cached pages hold the old address, the SEO plugin serves images from one domain, the browser requests fonts from another, and users run into mixed errors.

File Path as Part of Future Migration Planning

The path inside the bucket should still make sense a year from now, not just today. If you use Leopard for a store, the path does not need to repeat the name of every catalog section. A product can move from one category to another, but the file should remain stable. If the site is multilingual, adding the language to the path is not always helpful: the same image may be used across multiple language versions, and an extra language prefix can create duplication.

A good path answers two questions: where WordPress files live and whether the production environment can be cleanly separated from staging. For most sites, a top-level prefix such as uploads/ or media/ plus the standard year/month structure is enough if that structure is enabled. For a staging copy, it is better to use a separate bucket or separate prefix so test uploads do not mix with production objects.

If you may switch providers in the future, do not tie the structure to the current service name. A path like r2-prod-images/ makes sense only while you are using R2. It looks odd after a move to S3 or Backblaze B2. A neutral path like site-media/ will hold up better over time.

URL Dependency Map

Before a large migration, it helps to build a small dependency map. You do not need to catalog every image. It is enough to list the places where a media URL may be stored or cached.

• WordPress content: posts, pages, blocks, HTML embeds, galleries, and older shortcodes.
• Page builder: section background images, global templates, generated CSS files, and the builder's own cache.
• WooCommerce: product galleries, archive thumbnails, emails, digital files, and product exports.
• SEO tools: sitemap, Open Graph images, schema, and images in indexable archives.
• CDN and cache: HTML cache, browser cache, edge cache, purge rules, and old redirects.
• External channels: newsletters, product feeds, marketplaces, social networks, and affiliate exports.

This map helps you choose the right testing order. For example, if the store publishes a product feed with images, it is not enough to visually inspect a product page. You need to wait for the feed to refresh and make sure it picked up the new domain instead of mixing local and cloud URLs.

Practical Ways to Use Leopard on Different Types of Sites

Leopard is not always used the same way. On one site, the priority is reducing disk pressure. On another, it is stabilizing large downloads. On a third, it is moving community uploads out of local hosting. Below are a few setups where the settings differ not by menu label, but by risk profile and verification logic.

Media Publication or Blog with a Large Archive

For a publication, the main goal is to move the historical image archive without breaking older posts. Start with new uploads, then sync older months in small batches. If the site has had years of external image links, do not change the domain and path structure multiple times. On this kind of site, it is often better to keep local copies at least until SEO checks and sitemap recrawling are complete.

Check category archives, related posts, AMP pages if they exist, Open Graph images, and RSS feeds. Some plugins do not get image URLs through the standard WordPress functions. They may store them in a saved field instead. If some links remain unchanged after offload, look not only at Leopard but also at the settings of the relevant SEO or social plugin.

WooCommerce Catalog with Thousands of Products

For a store, the most important chain is the product image, the catalog thumbnail, the cart image, and the downloadable file if the product includes one. Start with a new product, then test several older products with different image setups: one with a gallery, one with variations, one with a downloadable file, and one with an image imported through WP All Import.

If the store uses filters, quick view, or AJAX product loading, include those in your baseline test set as well. Those blocks often receive HTML from cache or their own request layer, which means they can keep older URLs longer than a normal page. After changing the file domain, clear the store cache and the CDN cache, not just the general WordPress cache.

Training Site, Membership Area, or Restricted Library

For gated content, the central question is not speed but access. A lesson cover image may be public, while the PDF, video, or archive should open only for a user with the correct permissions. In this kind of setup, do not use one shared public rule for every file. Split materials by type and verify exactly how the restricted link is delivered.

If the membership plugin or LMS stores the file in its own field, make sure it retrieves the link through WordPress or a supported integration, rather than saving the direct URL at upload time. After offload, test as a guest, a normal member, a member without course access, and an administrator. A successful download as an administrator does not prove that a restricted file is secure.

BuddyBoss Community Site

With BuddyBoss, the load does not come only from administrators. It comes from users too. That means the test needs to reflect real behavior: uploading an avatar, a profile cover, an activity attachment, a video, or a document if those modules are enabled. These files often have different visibility levels, and one incorrect bucket mode can expose them more broadly than intended.

In practice, it is useful to keep a log during the first week after launch: what types of user files were uploaded, how many sync errors appeared, which file extensions failed most often, and whether users reported slow loading. That gives you a way to tune limits, CORS, and permissions based on actual behavior rather than assumptions.

Safe Practical Improvements Without Editing the Plugin

With Leopard, do not invent PHP hooks unless the developer documents them. The product already has enough settings and external controls to improve stability without modifying plugin code. The most useful improvements usually live outside Leopard itself: in bucket rules, CORS, access permissions, task sequencing, and verification routines.

Minimal CORS for Public Static Files

If you use a separate file domain and the site loads fonts, a PDF viewer, or other browser-fetched resources from it, use a restricted CORS policy. This JSON belongs in the provider panel or its official tooling, not in WordPress. Replace the domain with your real production domain before applying it:

{
  "AllowedOrigins": ["https://example.com"],
  "AllowedMethods": ["GET", "HEAD"],
  "AllowedHeaders": ["Content-Type", "Range"],
  "ExposeHeaders": ["Content-Length", "Content-Range", "ETag"],
  "MaxAgeSeconds": 3600
}

Verification is simple: open a page that uses a font or file from the cloud domain and make sure there is no CORS error in the console. Rollback means removing or narrowing the rule in the provider panel and purging the CDN cache. Do not add * to origins on a production site without a clear reason.

Targeted CSS for a Layout Issue After a Domain Change

Sometimes after moving images, the problem is not the file itself but the theme's assumptions: the image loads from the new domain a little later, the product card shifts, and the gallery ends up with inconsistent height. That is not a Leopard storage problem, but the user still sees a design defect. A safe fix is to give product cards a stable aspect ratio if the theme does not already handle it.

The code below is not tied to Leopard's internal classes and does not modify the plugin. You can add it to a child theme or to the theme's custom CSS section if the selectors match your markup:

.woocommerce ul.products li.product img {
  aspect-ratio: 1 / 1;
  object-fit: cover;
}

.single-product .woocommerce-product-gallery__image img {
  height: auto;
  max-width: 100%;
}

Check the product archive and product page on mobile and desktop. If images are being cropped incorrectly, remove the first block or change the ratio to match what your theme uses. This is not a performance tweak or a cloud setting. It is simply a careful design stabilization step after changing the file source.

A Practical Workflow with WP-CLI and Thumbnail Regeneration

Leopard advertises WP-CLI support, and WP-CLI itself includes media-related commands such as thumbnail regeneration. Use that combination only if you understand the current storage model. If local originals have been deleted, regeneration may require extra checks. If local copies still exist, WP-CLI is a convenient way to rebuild sizes after changing the theme or WooCommerce image settings.

A safe workflow looks like this: create a backup, verify one attachment record, run regeneration on a limited scope or during a low-traffic window, then check whether the new sizes appeared in the bucket. Do not run mass regeneration at the same time as bulk offload and format optimization.

Troubleshooting Common Problems

Offload failures almost always look the same to visitors: a blank image, a file that will not download, a font that will not load, or pages that suddenly feel slower. But the causes are different. The diagnostic map below helps you move from symptom to verification instead of changing settings at random.

The Bucket Connects, but the Bucket List Is Empty or the Required Bucket Cannot Be Selected

Symptom: the connection test partly succeeds, the keys seem valid, but the plugin does not show any bucket or cannot select the one you need. Possible causes include an incorrect region, a wrong endpoint, a restricted key without permission to list buckets, or a provider-specific quirk in the S3-compatible API.

Make sure the endpoint was copied from the panel of the exact bucket, not from a generic documentation page. For Backblaze B2, the important values are Application Key ID, Application Key, and the S3 Endpoint. For R2, the account's S3 API endpoint and access to the selected bucket both matter. Even if a key is restricted to a single bucket, SDK compatibility may still require permission to list bucket names.

Fix: create a new restricted key with the required permissions, save the region and endpoint again, and rerun the test against an empty test bucket. If the live site is already using older settings, do not delete them until the test succeeds on a copy.

Images Exist in the Media Library, but the Site Displays Empty Placeholders

Symptom: the attachment opens in the admin area, but the public page shows an empty space or a broken-image icon. Possible causes include the object not being copied, the URL being rewritten to the wrong domain, the file being blocked by permissions, the CDN serving a cached error, or the theme requesting an image size that does not exist in the bucket.

Open the image URL from the HTML in a new tab. A 404 points to the path or the presence of the object. A 403 points to permissions or public visibility. If the original opens but the thumbnail does not, inspect WordPress image sizes. If the HTML still contains the older local URL, clear the cache and check whether the builder is storing pre-rendered HTML.

Fix: resync the affected attachment, lower the batch size for the bulk queue, verify thumbnail generation, and clear the cache. If local file deletion is enabled, turn it off temporarily until the diagnosis is complete.

Fonts or CSS Stop Working After Enabling the Asset Function

Symptom: images load, but the page styling changes, icons disappear, or the browser console shows CORS errors for woff2, woff, ttf, CSS, or JS. Possible causes include CORS not allowing requests from the site domain, an incorrect MIME type, the CDN caching an older response, or the documented Cloudflare R2 limitation for fonts and icon fonts when CSS is offloaded through the Asset function.

Fix: disable asset offload while keeping media library offload active. Configure CORS at the provider level, purge the cache, and test the font separately. If you are using R2 and the issue involves fonts referenced from CSS, do not try to force your way around the limitation. Keep those files local or deliver them through another supported method.

Bulk Sync Stalls or Runs Too Slowly

Symptom: the file counter does not move for a long time, some tasks repeat, the server becomes slow, or timeouts appear. Possible causes include a batch that is too large, insufficient memory, PHP limits, a slow provider API, a conflict with an image optimizer, or a parallel import.

Fix: reduce Batch Size and Chunk Size, increase the pause between batches, run the process during a quieter period, and temporarily disable large-scale optimization. If the queue already contains errors, inspect the first problem files manually: filenames with spaces, unusual extensions, missing local originals, or provider restrictions are often obvious right away.

Thumbnails Cannot Be Regenerated After Local Files Are Deleted

Symptom: the site still shows older images, but a new theme requires different sizes and thumbnail regeneration fails. A likely cause is that the local original has already been removed, and the current setup cannot automatically restore it for processing.

Fix: before deleting local files in bulk, test the recovery workflow on a single image. If the problem has already happened, restore the originals from backup or from the bucket, then rerun regeneration. Going forward, do not remove local originals while the site is still actively changing themes, WooCommerce image sizes, or image optimizer behavior.

A Downloadable Product Opens for the Wrong Users

Symptom: a digital file opens through a direct link without the expected restrictions, or a valid buyer is denied access. Possible causes include a public bucket being used for a private file, an incorrect temporary-link scheme, an overly strict access policy, a wrong Content-Disposition, or the use of a direct cloud URL instead of a controlled file-selection workflow in the store.

Fix: separate public images and restricted files, verify the cloud file selection mode in WooCommerce or Easy Digital Downloads, and test as both a guest and an authenticated user. If the access model is unclear, roll back to local delivery for restricted files until the private bucket or CDN setup is fully understood.

When It Helps to Watch a Product-Specific Leopard Video

The product has a focused video associated with its CodeCanyon page, and it can help you see the overall Leopard workflow rather than just reading a list of settings. The best time to watch it is after you already understand the basics of buckets, URL rewriting, and result verification. At that point, the interface steps feel like confirmation rather than a series of random clicks.

The video is useful for queries such as "how to use CodeCanyon Leopard," "Leopard WordPress Offload Media setup," and "how to verify automatic WebP sync to the cloud." While watching, pay attention to the sequence: connect the provider, upload a file, confirm the object appears in storage, verify the URL change, and check the result in the media library.

Questions to Resolve Before a Full Rollout

Can I Enable CodeCanyon Leopard Directly on a Live Site?

Technically, the plugin installs like any standard ZIP plugin, but bulk offload should not begin without testing. First connect the bucket, upload a new file, verify the URL, thumbnails, and cache behavior, and only then migrate the older media library in batches. For a store or a site with restricted materials, a staging copy is close to mandatory.

Do I Need to Delete Local Files After Copying Them to the Cloud?

Not in the first phase. Deleting local files saves disk space, but it makes recovery, thumbnail regeneration, and optimizer workflows more difficult. First verify that URL rewriting is stable, that every image size exists in the bucket, and that you have a reliable file recovery path. If everything works, cleanup can be enabled carefully and not necessarily for every file type at once.

Why Does the Image Open Directly but Still Not Work on the Page?

If the file opens by URL but the page still shows an error, check CORS, cache, the wrong image size, mixed content, MIME type, and HTML that may still contain the old link. For fonts and video, CORS is especially important: opening the file directly does not prove the browser will allow it to be used inside the page.

Is Leopard Suitable for WooCommerce Downloadable Products?

Yes, the product advertises support for WooCommerce digital/downloadable products and cloud-folder file selection, including both public and private modes. But this must be tested separately from product images. Verify the buyer workflow, guest access denial, link expiration behavior, and the actual visibility of the object inside the bucket.

Can I Use Cloudflare R2 for All Site Assets?

For media, R2 is one of the supported options. For assets, the product page includes an important caveat: Leopard does not support fonts and icon fonts with offloaded CSS in the Asset function for Cloudflare R2. That means images and documents can be tested separately, while fonts and CSS need to be handled with that limitation in mind.

What Should I Do If Older Plugin Versions Were Listed in Security Databases?

Use a current build, review the changelog, and restrict access to the settings. Security sources note fixed vulnerabilities in older branches, and the product later received security updates and Access Control. Do not keep outdated versions on a live site, especially if lower-privileged users have access to the admin area.

Can I Migrate from WP Offload Media to Leopard Safely?

Leopard advertises support for that migration, but the risk depends on the structure of the existing bucket, the delivery domain, and the records stored in the database. Test with a small group of attachments, do not change the domain and provider at the same time, keep local copies until verification is complete, and maintain a rollback plan.

When CodeCanyon Leopard Is the Right Choice

Leopard makes sense when the media library has already become part of your site's infrastructure: lots of images, large documents, digital products, BuddyBoss attachments, the need to move files out of hosting storage, bucket-to-bucket migration, or work across multiple providers. Its strengths include broad cloud storage support, automatic and background synchronization, performance settings for large sites, WooCommerce and Easy Digital Downloads support, asset pull, the WebP/AVIF direction, and access control for plugin management.

But this plugin should not be your first optimization step on a small site. If images are not compressed, the theme is overloaded, caching is not configured, and the site owner does not understand the difference between a bucket endpoint and a CDN URL, fix the basics first. Offload works best when you are ready to manage file storage as a system: keys, permissions, CORS, Cache-Control, URL rewriting, local copies, troubleshooting, and recovery.

Before a full rollout, go through a short checklist: fresh backup, separate bucket, restricted key, test new upload, inspect HTML and headers, sync a small batch, verify products and restricted files, then expand gradually. If that path works cleanly, you can get the CodeCanyon Leopard file and prepare deployment on your site copy.

The main selection criterion is simple: if you want more than just "faster images" and instead want a manageable WordPress cloud media library with clear migration, verification, and troubleshooting, Leopard is worth testing. If you would rather use a service that does not require you to manage providers and keys yourself, compare it with managed alternatives before deploying.