CodeCanyon Cloudfiles - WordPress Plugin

Guide to Setting Up CodeCanyon Cloudfiles for the WordPress Media Library and Cloud Folders

CodeCanyon Cloudfiles is one of those WordPress plugins that is best evaluated through a real workflow rather than a feature checklist: how quickly an editor can find the right file, where a new document ends up, what happens during cloud sync, and whether existing site content stays intact. This guide focuses on the practical side: preparing the site, installation, folder structure, connecting cloud storage, verifying the result, common issues, and alternatives.

Based on the available description, the plugin combines folder management inside the WordPress media library, drag-and-drop file handling, filters, list view support, uploading into a folder or cloud subfolder, synchronization with Google Drive, Dropbox, Amazon S3, OneDrive, and OneDrive Business, plus viewing popular document types such as PDF, Word, PowerPoint, and Excel files. Those features are useful, but each one needs careful setup: cloud files, user permissions, cache, WooCommerce, and page builders can behave differently from one site to another.

This article does not replace the documentation included in the plugin archive and does not cover purchasing or activating a license. It helps you safely test an existing installation ZIP file on a staging copy of the site, understand which settings to enable first, where problems usually appear, and when it makes more sense to choose another solution.

What problem the plugin solves and where it is genuinely useful

The standard WordPress media library can upload files, search them, filter by type and date, show attachment details, and delete items. For a small site, that is usually enough. The problem starts when the library grows to thousands of images, PDF manuals, presentations, price lists, product files, banners, and assets from different departments. Searching by filename only helps when the team follows strict naming rules. In real editorial workflows, files are often named inconsistently, uploaded by different authors, and duplicated across multiple versions.

CodeCanyon Cloudfiles adds folder-based organization to that setup. Instead of just a flat list of attachments, users see a structure: for example, Products, Brand, Documents, Landing Pages, Seasonal Campaigns. According to the product description, folders can be created, renamed, deleted, and moved, while files can be dragged and dropped between them. For a content team, that is often more valuable than one more filter: a folder reflects the meaning of the project, not just the technical file type.

The second task is integration with cloud storage. If your team already keeps source assets in Google Drive, Dropbox, OneDrive, or S3-compatible storage, constantly downloading files and uploading them back into WordPress quickly becomes a weak point in the workflow. Cloudfiles is presented as a tool for syncing the media library with several cloud services. That does not mean you should turn everything on without testing. But it does create a workflow where WordPress becomes a convenient publishing point while the cloud remains the place where files are stored and shared.

The main practical value of the plugin is that it connects media library organization with a cloud-based file structure. If all you need is five folders for blog images, a simpler media folder manager is enough. But if the site regularly uses documents, product images, marketing assets, and files from external storage, Cloudfiles deserves a closer look.

Who CodeCanyon Cloudfiles is a good fit for, and who should not rush into it

The plugin is worth testing on sites where the media library has become an operational hub rather than just a place to upload images. Typical examples include an online store with a large number of product images and PDF files, a training center website with course materials, a corporate portal with client documents, an agency site with multiple editors, or a catalog with files from different suppliers. On projects like these, the payoff does not happen at the moment of installation, but a few weeks later: editors find the right file faster, administrators see a clearer structure, and the team duplicates attachments less often.

Cloudfiles can also be useful for WooCommerce site owners if the media library is used for product images, manuals, spec sheets, and marketing materials. Available descriptions mention compatibility with WooCommerce and third-party plugins, but that should be interpreted carefully: compatibility does not mean every custom importer, theme, or gallery module will automatically understand folders and cloud links. Testing on a sample product is essential.

You should not start with Cloudfiles if the site is small, the file volume is low, cloud storage is not part of the workflow, and only one editor handles content. In that situation, the extra configuration layer may be heavier than the problem itself. The plugin can also be unnecessary if all you need is CDN-based file delivery or full media offloading to S3 without a folder interface. There are specialized tools for that, and a separate section below covers them.

There is one more important case: a site where stability is critical and the media library is tied to checkout, a restricted area, paid downloads, or automated imports. In that scenario, Cloudfiles can still be tested, but only after creating a backup and only on a staging copy. Any plugin that changes how media and external storage work needs to be validated against real workflows: uploading, inserting into a post, rendering on the front end, generating thumbnails, deleting, searching, editor behavior, caching, and access permissions.

What to check before installing it on a live site

Preparation matters more than installation itself. Cloudfiles operates around the media library, which means it touches files, database records, user permissions, cloud accounts, and sometimes public URLs. If you enable synchronization without understanding the current state of the site, the result may not be a visible site break, but a more frustrating problem: file chaos, duplicates, and unclear origins for the same image.

The state of the media library and your backup

Before installation, check how many files are already in the media library, which file types are being used, and how often editors delete or replace attachments. WordPress shows attachment data in the Attachment Details window: filename, type, size, upload date, author, related post, and URL. This is a useful control point because after setting up Cloudfiles, you can compare whether files still open correctly, attachment data is preserved, and links in published content do not change unexpectedly.

You need a backup of more than just the wp-content/uploads folder. Folder structure and plugin settings are usually stored in the database, and cloud sync may create additional records. So before testing, back up the database, the uploads folder, and the list of active plugins. If WooCommerce is in use, also check products with galleries, downloadable files, and variations separately.

A safe test does not start with the Install button. It starts with the ability to roll back. If you do not know how to restore the media library and database, set up backups first and test Cloudfiles afterward.

WordPress version, PHP version, and conflict-prone areas

The available Cloudfiles changelog mentions WordPress 5.x compatibility, drag-and-drop fixes, and PHP 8.0 compatibility. That is useful information, but it is not enough to confidently promise that the plugin will work on any modern stack. If your site uses a newer WordPress core version, a newer PHP version, the block editor with nonstandard blocks, WooCommerce, WPML, or page builders, test on a site copy first.

Pay especially close attention to plugins that also interact with the media library: image optimizers, offload plugins, galleries, product importers, file replacement plugins, WebP generators, media cleanup tools, and security extensions. They may not conflict directly, but the order in which they act matters. For example, one plugin generates thumbnails, another rewrites URLs, a third syncs to the cloud, and the theme requests the image in a nonstandard way.

User permissions and cloud access

WordPress uses roles and capabilities, including the ability to upload files. If an editor is allowed to add media, that does not automatically mean they should also be allowed to manage the cloud structure. Decide before installation who will create folders, who can move files, who connects cloud accounts, and who is responsible for deletion. On a team site, it is usually better to start with a minimal number of administrators and let editors work with ready-made folders.

For cloud storage, prepare separate folders or buckets for the site. Do not connect the root of a personal drive that contains documents unrelated to publishing. The narrower the sync scope, the easier it is to diagnose issues and the lower the risk of accidentally exposing unnecessary files on the site.

Installation and the first validation without risking the media library

Commercial CodeCanyon plugins are usually installed from a ZIP archive: in the WordPress admin panel, go to Plugins - Add New - Upload Plugin, choose the archive, and click Install Now, then Activate. If the downloaded package includes documentation and a separate installable ZIP, use the actual plugin ZIP file, not the full package that also contains docs, license files, and supporting assets.

After activation, do not connect the cloud right away. First open Media - Library and make sure the standard media library loads correctly in both grid and list view. Then test the basics: search for an existing file, open Attachment Details, upload a small image, insert it into a test post, and delete the test file. This gives you a clean comparison point before turning synchronization on.

A safe order for the first launch

1. Install the plugin on a staging copy or on a separate test site with a similar plugin stack.
2. Open the media library in both grid and list view to make sure the interface does not freeze.
3. Create one test folder, for example Cloudfiles Test, and upload several files of different types into it.
4. Test dragging a file from one folder to another and then moving it back.
5. Insert an image from that folder into a draft post and open the preview.
6. Delete the test file only after confirming that it is not used anywhere else.

At this stage, the goal is not to configure everything at once. The goal is to see whether the site preserves normal media library behavior. If you already see JavaScript errors, an empty file grid, an inability to upload an attachment, or a conflict with the editor modal here, it is too early to enable cloud synchronization.

A settings map for after installation

Cloudfiles has several distinct configuration areas, and it is better to work through them not in tab order, but by dependency: first local folder structure, then upload rules, then the cloud connection, then integrations with editors and WooCommerce, and only after that bulk operations. This approach reduces risk: if something goes wrong, you know which configuration layer changed last.

Local folders and naming rules

Start with a structure that reflects the site's real tasks. A bad approach is creating folders based on mood: New, Old, Files, Other. A month later, that structure becomes another layer of clutter. A better approach is to create folders by type of work and site section: Products, Blog Illustrations, PDF Documents, Brand Assets, Landing Campaigns. For WooCommerce, you can separate Product Photos, Size Charts, Manuals, and Promo Banners.

If, in your version of Cloudfiles, folders are just a logical structure inside the media library rather than a physical file move on the server, that is usually safer for published URLs. But do not assume that by eye. Test a single file: move it into another folder, open an older post where it is inserted, and confirm that the image or document still opens correctly.

Minimal structure for the first test

• Working Assets - files that editors frequently insert into posts and pages.
• Downloadable Documents - PDFs, presentations, spreadsheets, and manuals if they are published on the site.
• Product Files - WooCommerce images and documents if the store actively uses the media library.
• Archive - assets that cannot be deleted without verification but do not need to appear first for editors.

This is not the perfect starting point for every project, but it helps you see how the system works without dozens of nested folders. After validation, you can expand the tree, add subfolders, and agree on rules with the team.

Uploading directly into a folder and a cloud subfolder

One of the advertised Cloudfiles features is uploading files directly into a folder and into a cloud subfolder. The practical benefit is simple: an editor does not upload a file into the general pile, but places it into the right context immediately. For a team, that reduces the number of lost assets and duplicates. But there is a nuance: if a file is needed in several places, do not upload copies into different folders just for convenience. It is better to find the original, confirm its purpose, and reuse it.

For the initial setup, choose one default folder for test uploads and verify whether the file appears where expected. If a cloud subfolder is enabled, check both sides: the file is visible in WordPress, the file appears in cloud storage, the public site URL opens correctly, thumbnails are generated, and the block editor inserts the correct attachment.

Filters, sorting, and list view

Advanced filters and sorting become useful when the library is large. But at the beginning, they are better used as a diagnostic tool. Test filtering by file type, searching by name, and sorting by date or size if your version includes it. Then compare grid view and list view. According to the description, Cloudfiles works in list mode as well, which matters for administrators: the list makes it easier to see filenames, dates, authors, and bulk actions.

If grid view freezes on a large library while list view remains stable, that is a sign to roll the plugin out gradually: first organize the folder structure and test the filters, then connect the cloud, and leave bulk operations until the final stage.

Cloud synchronization: how not to turn order into chaos

The advertised sync with Google Drive, Dropbox, Amazon S3, OneDrive, and OneDrive Business is the most visible part of Cloudfiles. But it is also the part that demands the most discipline. Cloud storage has its own rules: files have owners, permissions, API limits, shared folders, trash, versions, file-type restrictions, and sometimes sync delays. WordPress, meanwhile, expects a clear URL, an attachment record in the database, and an accessible file when a page request is made.

That is why synchronization should be introduced as a project, not as a checkbox. First decide what exactly should enter the media library: all files from the cloud, only images, only documents, a specific project folder, or a folder with product assets. The smaller the sync scope, the easier it is to support.

Connecting Google Drive, Dropbox, and OneDrive

For drive-based services, the main issue is not just authorization, but access scope. Do not connect the root of a personal drive. Create a dedicated folder for the site and subfolders for sections within it. If the service uses a team folder, check who can delete and rename files. Deletion in the cloud may affect WordPress if synchronization treats the cloud as the source of truth.

After connecting, run a small-folder test: one JPG, one PDF, one DOCX or XLSX if those formats matter for the site. Check whether the items appear in the media library, whether they open from the editor, and whether the link changes after renaming the folder. For Office files and PDFs, also test the viewer or embedder separately, because document rendering on the site depends not only on the file being present, but also on the browser, MIME type, permissions, and insertion method.

Amazon S3 and the cloud subfolder

S3-compatible storage is usually used not for a prettier folder structure, but for disk space, scalability, and file delivery. If your actual goal is media offloading, compare Cloudfiles with a specialized offload plugin in your own workflow. According to the description, Cloudfiles can connect to and synchronize with AWS S3 and can also upload into a cloud subfolder. But this article should not promise specific URL behavior, CDN behavior, bucket permissions, or deletion of local copies without verifying your version first.

The minimum S3 test is this: upload one image into a test folder, insert it into a draft, open the page in incognito mode, check the file response code in browser tools, then clear the site cache and open the page again. If the file is supposed to be public, it should be served reliably without authentication. If the file is private, do not insert it as a normal public image.

When it is better to stop synchronization

• Files appear in the media library without thumbnails or with the wrong type.
• Renaming a folder in the cloud creates duplicates instead of updating the structure.
• The editor can see the file, but the public page returns an access error.
• Deleting a test file behaves unpredictably: it disappears only in WordPress or only in the cloud.
• The site starts making too many background requests on weak hosting.

In those cases, go back to local folders, disable the cloud layer, and review the documentation from the plugin archive. Do not try to fix bulk synchronization in a live media library until the cause is clear.

Working with editors, WooCommerce, and multilingual sites

Cloudfiles is presented as compatible with Gutenberg, Elementor, Visual Composer/WPBakery, WooCommerce, third-party plugins, multisite, and WPML. Those claims are useful as a general reference, but practical testing should be based on specific user actions. Media library compatibility is not a single test. You need to verify the file selection modal, image insertion, gallery selection, featured image behavior, product files, reopening an already saved page, and public rendering.

The block editor and page builders

In the block editor, test three actions: insert an image from a folder, replace that image with another one from the same folder, and reopen the post after saving to confirm that the block has not lost its link. In Elementor or WPBakery, test a similar path inside the image widget, gallery, PDF download button, and section background image. If folders are visible only in the standard media library but not in the builder's modal window, that is not always critical, but it does affect editor usability.

On cached sites, also clear the builder cache and the page cache. Sometimes it looks as if the file was not replaced, when in fact the editor is showing an older generated version. For checks like this, use a draft or a restricted test page, not a published commercial landing page.

WooCommerce: product images and downloadable files

For WooCommerce, test both a simple product and a variable product. The goal is to confirm that the product image, gallery, catalog thumbnails, and downloadable files still work after moving attachments between folders. If cloud sync is enabled, check not only the product admin screen, but also the public product page, the cart, the order email, and the downloads page in the customer account if that workflow exists.

Do not confuse folder convenience with access control. A folder in the media library does not replace a permission system for paid files. If a document should only be available to a customer, validate the WooCommerce mechanism or a dedicated protected-download plugin. Cloudfiles can help organize files, but it should not automatically be treated as a content protection system.

WPML, translations, and multisite

On a multilingual site, check how the same file is used across different language versions. If the image is shared, do not create copies just for language reasons unless that is necessary for alt text or a localized banner. If the document must differ by language, it is better to split folders from the start: Documents EN, Documents RU, Documents DE, or clearer names that match your editorial workflow.

For multisite, separate two things: technical support for a WordPress network and the licensing right to use the plugin on multiple domains. The available Cloudfiles description mentions multisite support, but that is not the same as unrestricted use of one license on any number of sites. Check licensing questions on the CodeCanyon page and in Envato's rules, and validate the technical side on a test subsite or a separate site within the network.

Practical example: a document library for a store and editorial team

Let's walk through a scenario that shows Cloudfiles at its best: the site has a store, a blog, and a support section. The team regularly uploads product images, PDF manuals, spec tables, and banners. Some files are stored in the cloud by the marketing team, while others are uploaded directly into WordPress. The goal is to make it easy for editors to find assets quickly while giving the administrator a clear way to verify where a file came from and where it is used.

Goal and preparation

The goal is to create a clear media library structure and validate one complete path: cloud folder or local upload - media library - product or page - public view - repeat editing. Before you begin, WordPress, WooCommerce if needed, Cloudfiles, a test page, and a backup should already be in place. For the cloud, create a dedicated folder such as site-media-test and do not put real private documents into it.

Setup steps

1. In the media library, create the top-level folders Products, Documents, Editorial, and Archive.
2. Inside Products, create the subfolders Photos, Manuals, and Size Charts.
3. Upload one product image into Products - Photos and one PDF into Products - Manuals.
4. If you connect the cloud, synchronize only the test cloud folder, not the entire drive.
5. Open a test product, choose the image from the correct folder, and add the PDF as an extra document or link if that workflow is used on the site.
6. Create a test blog post and insert the same PDF as a document link to verify file reuse without duplication.
7. Open the public product page and the post in incognito mode, then check whether the image and document open correctly.

What the result should look like

After completing this scenario, the editor should see the file in the expected folder, the product should display the image, the PDF should open or download from a clear link, and reopening the product in the admin panel should not lose the selected attachment. If cloud sync is enabled, also verify that the connection is preserved after updating the folder in the cloud.

Quick takeaway from the practical test: if one product, one post, one image, and one document make it through the full workflow without errors, you can expand the structure. If the basic path breaks, do not start a bulk file migration.

A detail people often miss

Do not delete the test file immediately after moving it between folders. First check where it is used. WordPress may store the URL in post content, product meta fields, builder settings, or custom fields. If the file is used in several places, deleting it from the media library may affect more pages than the folder view suggests.

How to verify the result after setup

Verification needs to be repeatable. It is not enough to see that a file appeared in a folder. You need to check the admin panel, the public site, cache, access permissions, different file types, and editor workflows. For Cloudfiles, the most important chain is "folder - cloud - attachment - public URL" because each part may work separately while breaking in combination.

A short admin checklist

• The media library opens in both grid and list view without browser console errors.
• A file can be uploaded directly into the selected folder, found through search, and opened in Attachment Details.
• Dragging between folders does not change the public output of an image that has already been inserted.
• PDF, DOCX, XLSX, or PPTX files open in the expected way if those formats are used on the site.
• A file from a cloud folder is visible in WordPress and publicly accessible only when that is intended.
• Clearing the cache does not bring back an old image or hide a new file.
• An editor without admin privileges can only see the actions they actually need.

Checking speed and load

Folders by themselves usually affect admin usability, not front-end speed. But cloud sync, document previews, thumbnail generation, and background requests can add load. Check the time it takes to open the media library before and after enabling Cloudfiles, file upload time, behavior on a weak connection, and how background tasks perform. If the site runs on inexpensive shared hosting, do not start bulk synchronization during working hours.

For the public side, use a simple check: open a page with an image, a document, and a product in incognito mode, then inspect browser tools to see which URLs are requested and which response codes are returned. Access errors, redirects to the login page, overly slow responses, or mixed HTTP/HTTPS need to be fixed before publishing changes.

How to move an existing media library into folders without creating duplicates

The most common mistake when introducing media folders is trying to reorganize the entire library at once. On a large site, that almost always leads to confusion: editors see old images, administrators create new folders, cloud sync pulls in similar files, and the end result is multiple copies with the same meaning under different names. Cloudfiles works better as a gradual system for creating order, not as a one-time deep cleanup.

Classification first, moving second

Before moving files, create a simple map: which media library sections the team actually needs, which assets are published, which files belong to products, which documents can be archived, and which ones must not be touched without approval. For the first iteration, choose one small area, such as PDF manuals or banners for one product category. That lets you test the rules on a manageable file group without affecting the whole site.

Do not start with deletion. Even if a file looks old, it may still be used in a post, custom field, builder template, WooCommerce email, or an older landing page. WordPress does not show attachment relationships in every nonstandard workflow, so deletion requires extra verification. It is safer to move questionable files into the Archive folder, leave them unchanged from the URL perspective, and decide whether they are needed only after several checks.

Rules to prevent duplicates

• Before uploading a new file, search for an existing one by part of the name, type, and size.
• Do not create a copy of a document just because it is needed in another folder.
• For updated documents, use a clear name that reflects the purpose instead of a pile of words like final and new.
• Separate team source files from the files that are actually published on the site.
• Check the cloud folder before syncing so you do not import working drafts.

If the team uses a shared cloud drive, agree that WordPress should sync only the publication folder. Internal mockups, unfinished documents, large source files, and temporary assets should stay outside that area. Otherwise, the media library will quickly become a mirror of work-in-progress chaos rather than a clean site library.

A step-by-step plan for a large library

1. Build a list of the highest-traffic pages, products, and documents where media errors would be most noticeable.
2. Create top-level folders, but do not go deeper than two levels in the first iteration.
3. Move only one file group and verify the public pages where those files are used.
4. Document a naming rule and show it to editors using a real example.
5. After a few working days, check whether duplicates have appeared and which actions are causing confusion.
6. Only then expand the folder structure to the next group of materials.

A good media library migration is measured not by the number of folders created, but by a reduction in editor mistakes. If the team finds files faster, uploads fewer duplicates, and better understands which documents are published after the rollout, Cloudfiles is doing its job. If there are simply more folders but no new rules, the problem has only changed shape.

Troubleshooting: symptoms, causes, and safe actions

Media library issues rarely look the same. Sometimes the user sees an empty grid, sometimes a file uploads but does not appear in the folder, and sometimes a document opens for the administrator but not for a visitor. The key is not to guess, but to move from symptom to cause. Below is a troubleshooting map for typical situations related to media folders, cloud synchronization, and editor integrations.

Typical issues when working with folders and cloud files

Symptom	Possible cause	What to check	Safe action
The media library does not load or freezes.	A JavaScript conflict, a folder that is too large, or incompatibility with another media plugin.	The browser console, list view, temporary admin cache disabling, and a staging test.	Disable newly enabled Cloudfiles features one by one, keep only local folders, and consult the plugin documentation.
A file is moved into a folder but disappears from the expected location.	The user is looking at a different filter, the folder is hidden, or the file was moved within a logical structure.	Search by name, the All media items filter, attachment details, and list view.	Do not upload a copy right away. First find the original and confirm whether it is already used in a post.
The document is visible to the administrator but does not open for a visitor.	The file is in a private cloud folder, the URL requires authorization, the MIME type is incorrect, or the storage layer is blocking access.	Opening the file in incognito mode, the file response code, cloud folder permissions, and the document insertion method.	Separate public and private documents and do not insert protected files as regular media.
Duplicates appear after synchronization.	A rename in the cloud is treated as a new file, or different sources are importing the same document.	Filename, size, modification date, sync source, and cloud folder rules.	Stop bulk synchronization, clear the test folder, and configure a single source of truth.
The page builder cannot see folders or shows an outdated file.	The builder's modal window uses its own cache or does not support the folder interface.	The standard WordPress editor, clearing the builder cache, and reopening the page.	Use the standard media library to select the file, or keep folders as an admin-side organizational tool.
Drag-and-drop works inconsistently.	A script conflict, an outdated browser, a large file set, or an issue similar to one already fixed in the changelog.	Another browser, list view, a small test folder, and disabling unnecessary browser extensions.	Do not perform bulk moves until basic drag-and-drop is stable with test files.

When it is better to roll back a setting

A rollback is not only needed when the entire site breaks. If editors start uploading duplicates, the cloud folder becomes a source of unexplained files, documents open with inconsistent permissions, or WooCommerce products lose images, it is better to stop. Disable cloud synchronization, keep only local folders, restore the test structure, and repeat the validation on a smaller set of files.

Do not try to repair a large media library manually through the database unless you understand the plugin's storage schema. It is safer to restore a backup of the test environment, clarify the expected behavior in the documentation, and only then apply the working rules to the live site.

Useful rules for speed, SEO, and media library maintenance

Cloudfiles is not an SEO plugin or an image optimization tool, but an organized media library improves content operations. When an editor can quickly find the right file, they are less likely to insert duplicates, less likely to leave random filenames in place, and more likely to keep documents current. That is an indirect benefit, not a promise of better rankings.

Filenames and metadata

Folders do not replace good filenames. A file named IMG_4588.jpg inside the Products folder is still hard to search. Before a broad rollout, agree on a pattern: a short product or section name, the asset type, the variant, and the language if needed. For example, chair-model-a-manual-ru.pdf is much clearer than final-new2.pdf. In WordPress, also review the title, alt text, and description for images that appear on the site.

Formats and upload limits

WordPress supports a wide range of common formats, but a specific hosting environment may limit file size, MIME types, and upload duration. If Cloudfiles is used for PDF documents, presentations, and spreadsheets, test not only uploading but also viewing. Do not enable support for nonstandard formats without a reason: every new file type raises questions of security, compatibility, and maintenance.

Team discipline

The most useful media folder setting is not technical, but organizational. Assign one administrator to own the structure, do not let editors create top-level folders without approval, and keep a folder for temporary assets. Once a month, review the archive, duplicates, and outdated documents. If the team uses the cloud, agree on where source files are updated: in WordPress, in the cloud, or in a separate preparation folder.

When CodeCanyon Cloudfiles is a good choice

CodeCanyon Cloudfiles is worth considering when the media library has already become a working repository for the team and files come not only from WordPress, but also from cloud services. The plugin is especially interesting where you need folders, drag-and-drop, uploads into a selected folder, filters, document viewing, and integration with Google Drive, Dropbox, OneDrive, or S3. It should not be introduced just for a nicer interface. Use it when there is a clear goal: find files faster, reduce media duplication, connect the editorial workflow to cloud folders, and safely validate document delivery on the site.

Before going live, walk through a short chain: backup, staging, local folders, test upload, test synchronization, editor check, WooCommerce or builder check, public view, and cache clearing. If every step works smoothly, you can expand the structure. If one step fails, roll back to the last known-good configuration and do not start bulk synchronization.

Once the preparation is complete and you understand which parts of the media library you want to organize, you can download the ZIP archive, install it on a test copy, and follow the workflow described above without putting the live media library at risk. That approach will give you far more value than a quick installation directly on the main site.