First public release.<\/p>"},"ratings":[],"assets_icons":{"icon-128x128.png":{"filename":"icon-128x128.png","revision":3713296,"resolution":"128x128","location":"assets","locale":"","width":128,"height":128},"icon-256x256.png":{"filename":"icon-256x256.png","revision":3713296,"resolution":"256x256","location":"assets","locale":"","width":256,"height":256}},"assets_banners":{"banner-1544x500.png":{"filename":"banner-1544x500.png","revision":3713296,"resolution":"1544x500","location":"assets","locale":"","width":1544,"height":500},"banner-772x250.png":{"filename":"banner-772x250.png","revision":3713296,"resolution":"772x250","location":"assets","locale":"","width":772,"height":250}},"assets_blueprints":{},"all_blocks":[],"tagged_versions":["1.0.0","2.0.0"],"block_files":[],"assets_screenshots":{"screenshot-1.png":{"filename":"screenshot-1.png","revision":3716156,"resolution":"1","location":"assets","locale":"","width":1600,"height":900},"screenshot-10.png":{"filename":"screenshot-10.png","revision":3716156,"resolution":"10","location":"assets","locale":"","width":1600,"height":900},"screenshot-2.png":{"filename":"screenshot-2.png","revision":3716156,"resolution":"2","location":"assets","locale":"","width":1600,"height":900},"screenshot-3.png":{"filename":"screenshot-3.png","revision":3716156,"resolution":"3","location":"assets","locale":"","width":1600,"height":900},"screenshot-4.png":{"filename":"screenshot-4.png","revision":3716156,"resolution":"4","location":"assets","locale":"","width":1600,"height":900},"screenshot-5.png":{"filename":"screenshot-5.png","revision":3716156,"resolution":"5","location":"assets","locale":"","width":1600,"height":900},"screenshot-6.png":{"filename":"screenshot-6.png","revision":3716156,"resolution":"6","location":"assets","locale":"","width":1600,"height":900},"screenshot-7.png":{"filename":"screenshot-7.png","revision":3716156,"resolution":"7","location":"assets","locale":"","width":1600,"height":900},"screenshot-8.png":{"filename":"screenshot-8.png","revision":3716156,"resolution":"8","location":"assets","locale":"","width":1600,"height":900},"screenshot-9.png":{"filename":"screenshot-9.png","revision":3716156,"resolution":"9","location":"assets","locale":"","width":1600,"height":900}},"screenshots":{"1":"Overview: provider configured, media synced, offloading active.","2":"Cloud Provider \u203a Connection: choosing Azure Blob Storage.","3":"Cloud Provider \u203a Connection: entering the storage account, key and container, and testing the connection.","4":"Provider saved and ready to sync.","5":"Sync & Offloading \u203a Sync: the first sync, file by file, in the browser.","6":"Sync complete: enable offloading now or later.","7":"Sync & Offloading \u203a Offloading: offloading active, with the local copies to delete.","8":"Settings \u203a Transfers: file-size limit and transfer timeout.","9":"Status \u203a Health: plugin state and connection health at a glance.","10":"Cloud Provider \u203a Connection: S3-compatible storage, with the service filling in the endpoint and the public URL."}},"plugin_section":[],"plugin_tags":[13289,10725,46891,217,85],"plugin_category":[50],"plugin_contributors":[181787],"plugin_business_model":[],"class_list":["post-306382","plugin","type-plugin","status-publish","hentry","plugin_tags-azure","plugin_tags-cloud-storage","plugin_tags-offload","plugin_tags-s3","plugin_tags-uploads","plugin_category-media","plugin_contributors-pablodiloreto","plugin_committers-pablodiloreto"],"banners":{"banner":"https:\/\/ps.w.org\/diluxone-offload\/assets\/banner-772x250.png?rev=3713296","banner_2x":"https:\/\/ps.w.org\/diluxone-offload\/assets\/banner-1544x500.png?rev=3713296","banner_rtl":false,"banner_2x_rtl":false},"icons":{"svg":false,"icon":"https:\/\/ps.w.org\/diluxone-offload\/assets\/icon-128x128.png?rev=3713296","icon_2x":"https:\/\/ps.w.org\/diluxone-offload\/assets\/icon-256x256.png?rev=3713296","generated":false},"screenshots":[{"src":"https:\/\/ps.w.org\/diluxone-offload\/assets\/screenshot-1.png?rev=3716156","caption":"Overview: provider configured, media synced, offloading active."},{"src":"https:\/\/ps.w.org\/diluxone-offload\/assets\/screenshot-2.png?rev=3716156","caption":"Cloud Provider \u203a Connection: choosing Azure Blob Storage."},{"src":"https:\/\/ps.w.org\/diluxone-offload\/assets\/screenshot-3.png?rev=3716156","caption":"Cloud Provider \u203a Connection: entering the storage account, key and container, and testing the connection."},{"src":"https:\/\/ps.w.org\/diluxone-offload\/assets\/screenshot-4.png?rev=3716156","caption":"Provider saved and ready to sync."},{"src":"https:\/\/ps.w.org\/diluxone-offload\/assets\/screenshot-5.png?rev=3716156","caption":"Sync & Offloading \u203a Sync: the first sync, file by file, in the browser."},{"src":"https:\/\/ps.w.org\/diluxone-offload\/assets\/screenshot-6.png?rev=3716156","caption":"Sync complete: enable offloading now or later."},{"src":"https:\/\/ps.w.org\/diluxone-offload\/assets\/screenshot-7.png?rev=3716156","caption":"Sync & Offloading \u203a Offloading: offloading active, with the local copies to delete."},{"src":"https:\/\/ps.w.org\/diluxone-offload\/assets\/screenshot-8.png?rev=3716156","caption":"Settings \u203a Transfers: file-size limit and transfer timeout."},{"src":"https:\/\/ps.w.org\/diluxone-offload\/assets\/screenshot-9.png?rev=3716156","caption":"Status \u203a Health: plugin state and connection health at a glance."},{"src":"https:\/\/ps.w.org\/diluxone-offload\/assets\/screenshot-10.png?rev=3716156","caption":"Cloud Provider \u203a Connection: S3-compatible storage, with the service filling in the endpoint and the public URL."}],"raw_content":"\n
DiluxOne Offload moves your WordPress media library to Azure Blob Storage or to any S3-compatible service (Amazon S3, Cloudflare R2, Backblaze B2, DigitalOcean Spaces, Wasabi, Google Cloud Storage, MinIO) and serves files directly from the cloud \u2014 without breaking the Media Library UI, plugins, or existing content.<\/p>\n\n
The plugin uses a custom PHP stream wrapper to intercept every read and write to Most offload plugins rewrite media URLs in post content, which breaks when you switch providers, move domains, or restore from a backup. DiluxOne Offload leaves URLs alone and rewrites reads\/writes at the filesystem layer, so your content stays portable.<\/p>\n\n This plugin connects to one cloud storage service, the one you choose: Azure Blob Storage, or an S3-compatible service (Amazon S3, Cloudflare R2, Backblaze B2, DigitalOcean Spaces, Wasabi, Google Cloud Storage, or a server whose address you type). It uses it to store and serve your media files. Nothing is sent anywhere until you configure it yourself<\/strong> in the Cloud Provider<\/em> tab, with an account and credentials you supply. The plugin contacts no other service: it sends no telemetry, no usage data and no licence check to the author or to anyone else.<\/p>\n\n What it is used for: storing your WordPress media files outside your server and serving them from the cloud.<\/p>\n\n Where requests go: the Azure Blob REST API at blob.core.windows.net \u2014 specifically your own account's host, What data is sent: your media files themselves, together with their relative path, size and MIME type. The storage account key you entered never leaves your server \u2014 it is used locally to compute the signature that authenticates each request. No personal data about your visitors or your site's users is sent, and nothing at all about your site reaches the plugin's author.<\/p>\n\n When requests happen:<\/p>\n\n This is your own Azure account<\/strong>, under your own agreement with Microsoft. Neither DiluxOne nor the plugin's author is a party to it and neither has any access to your data. Your use of the service is subject to Microsoft's terms:<\/p>\n\n What it is used for: the same as above, on the S3-compatible service you choose.<\/p>\n\n Where requests go: the endpoint of the service you chose, which the form fills in for each service and you can change: Amazon S3 at What data is sent: your media files themselves, together with their relative path (the object key), size and MIME type, and a signature of each request computed from your secret access key. The secret itself never leaves your server. No personal data about your visitors or your site's users is sent, and nothing at all about your site reaches the plugin's author.<\/p>\n\n When requests happen: the same moments as for Azure above. The connection check is different: when you press Test Connection<\/strong>, and at most every five minutes while you browse the plugin's admin pages, the plugin writes a 32-byte probe object under your site's prefix, reads it back from the Public URL without credentials (to prove browsers can load your media) and deletes it.<\/p>\n\n This is your own account<\/strong> with that service, under your own agreement with its provider. Neither DiluxOne nor the plugin's author is a party to it and neither has any access to your data. Your use of the service is subject to its provider's terms:<\/p>\n\n Amazon S3:<\/p>\n\n Cloudflare R2:<\/p>\n\n Backblaze B2:<\/p>\n\n DigitalOcean Spaces:<\/p>\n\n Wasabi:<\/p>\n\n Google Cloud Storage:<\/p>\n\n Custom endpoint: the plugin talks only to the server whose address you typed (MinIO, Ceph or any other that speaks the S3 API). No third party is involved unless that server belongs to one you chose.<\/p>\n\n\n No. The stream wrapper intercepts filesystem calls transparently \u2014 your post content, the The plugin monitors connection health. While the cloud is unreachable, a new upload fails with WordPress's own \"could not be moved\" error and nothing is saved anywhere, so you never end up with a file that looks uploaded but isn't. A banner on the plugin's admin pages explains the failure. Files already in the cloud keep being served from the storage account URL. The plugin re-checks the connection at most every five minutes and uploads resume on their own once it is back.<\/p><\/dd>\n Not for itself: it has no cache, log or data files on disk; everything it needs lives in the WordPress options table and its own database table. Your media is written by WordPress core through the plugin's stream wrapper to the cloud, passing through a temporary file in the PHP temp directory that is deleted right after the upload.<\/p>\n\n The one operation that writes to the server is Sync & Offloading \u2192 Disconnect from Cloud<\/strong>. It copies your media back from the container to the exact uploads-directory paths WordPress has on record (resolved at runtime with Yes, including from Azure to an S3-compatible service or back. Remove the current provider configuration from the admin, enter the new account, container or bucket, run a full resync, and the plugin starts serving from the new location. No URL rewriting required.<\/p><\/dd>\n Yes. Because the stream wrapper operates at the filesystem layer, any plugin that reads or writes files under Only if you explicitly opt in. After a successful sync you can click Delete Local Files<\/strong> in Sync & Offloading \u203a Offloading. Until you do that, files are kept in both locations. A file that is empty (0 bytes) when the sync scans it is skipped: it is neither uploaded nor tracked, so Delete Local Files<\/strong> leaves it alone.<\/p><\/dd>\n Yes, while offloading is active: the stream wrapper turns the deletion into a delete on your container, thumbnails included. If you have synced but not yet enabled offloading, WordPress deletes only the local copy; the copy already in your container is not removed automatically.<\/p><\/dd>\n Deleting the plugin from the Plugins screen removes everything it created in your database: its options (all prefixed Your media files are never touched by uninstalling: whatever is in Go to DiluxOne Offload \u2192 Settings \u2192 Enable detailed debug logging<\/strong>. Logs are written to the standard PHP With that setting off and Yes. It can be network-activated; each site then has its own Cloud Provider configuration and its own file-tracking table, so different sites can use different providers, containers or buckets \u2014 or share one: a site's objects are stored under The Azure access key and the S3 secret access key are encrypted with AES-256-GCM before they are written to the WordPress options table (the S3 access key ID, like a user name, is not a secret and is stored as it is). The encryption key is derived from your site's WordPress salts ( If you ever rotate the WordPress salts, the existing encrypted credentials become unreadable; the plugin will surface the provider as \"not configured\" and you simply re-enter the credentials in the Cloud Provider<\/em> tab. There is intentionally no plaintext fallback.<\/p>\n\n Requirements: PHP First public release.<\/p>\n\n\/wp-content\/uploads\/<\/code>, so WordPress, WooCommerce, page builders, image editors, and any plugin that calls standard filesystem functions (fopen<\/code>, file_get_contents<\/code>, unlink<\/code>, etc.) keep working unchanged.<\/p>\n\nKey features<\/h4>\n\n
\n
memory_limit<\/code>.<\/li>\nuploads\/<\/code> for the main site, uploads\/sites\/<id>\/<\/code> for the others, the same layout WordPress uses on disk), so several sites can share one container or bucket without ever sharing a key.<\/li>\nWP_DEBUG<\/code> off and the Settings toggle off the plugin writes nothing to the PHP error log, at any level. WP_DEBUG<\/code> turns on errors and warnings; the toggle adds the informational lines.<\/li>\n<\/ul>\n\nWhy a stream wrapper instead of URL rewriting<\/h4>\n\n
Known limitations<\/h4>\n\n
\n
External services<\/h3>\n\n
Azure Blob Storage<\/h4>\n\n
https:\/\/ACCOUNT.blob.core.windows.net<\/code>, where ACCOUNT is the storage account name you enter in the settings.<\/p>\n\n\n
\/wp-content\/uploads\/<\/code> to your container.<\/li>\n\/uploads\/<\/code>, reads or deletes a file. This is also the only front-end traffic: a form or a review that uploads a file goes through the same stream wrapper.<\/li>\n\n
S3-compatible storage<\/h4>\n\n
https:\/\/s3.REGION.amazonaws.com<\/code> (requests address https:\/\/BUCKET.s3.REGION.amazonaws.com<\/code>), Cloudflare R2 at https:\/\/ACCOUNT_ID.r2.cloudflarestorage.com<\/code>, Backblaze B2 at https:\/\/s3.REGION.backblazeb2.com<\/code>, DigitalOcean Spaces at https:\/\/REGION.digitaloceanspaces.com<\/code>, Wasabi at https:\/\/s3.REGION.wasabisys.com<\/code>, Google Cloud Storage at https:\/\/storage.googleapis.com<\/code>, or the address you type under Custom. Browsers load your media from the Public URL you set, which can be the service's own address, a CDN or a custom domain.<\/p>\n\n\n
\n
\n
\n
\n
\n
\n
diluxone-offload<\/code> folder to \/wp-content\/plugins\/<\/code>, or install via the WordPress Plugins screen.<\/li>\nRequirements<\/h4>\n\n
\n
ext-curl<\/code> and ext-openssl<\/code> enabled.<\/li>\nuploads\/<\/code>.<\/li>\n\n
Does this plugin modify my existing media URLs in the database?<\/h3><\/dt>\n
wp_posts<\/code> table, and the wp_postmeta<\/code> table are never rewritten.<\/p><\/dd>\nWhat happens if the cloud is temporarily unreachable?<\/h3><\/dt>\n
Does the plugin write any files to my server?<\/h3><\/dt>\n
wp_upload_dir()<\/code>), so the Media Library works again without the plugin. It restores only what sits under the uploads\/<\/code> prefix of your own container, never a script or executable file name (PHP, JavaScript, HTML, shell or Windows executables) whatever put it there, and it runs only when you click it.<\/p><\/dd>\nCan I move to another storage account or bucket later?<\/h3><\/dt>\n
Will this work with WooCommerce \/ Elementor \/ image editors?<\/h3><\/dt>\n
\/uploads\/<\/code> using standard PHP functions works unchanged.<\/p><\/dd>\nDoes the plugin delete my local files automatically?<\/h3><\/dt>\n
If I delete a file from the Media Library, is it deleted from the cloud too?<\/h3><\/dt>\n
What happens when I uninstall the plugin?<\/h3><\/dt>\n
diluxone_offload_<\/code>), its transients and its file-tracking table (diluxone_offload_files<\/code>, with your table prefix) \u2014 on every site of a network. Deactivating alone keeps all of that, so you can deactivate and reactivate without losing your configuration.<\/p>\n\n\/wp-content\/uploads\/<\/code> stays there, and whatever is in your container stays in your container. If offloading was active and local copies had been deleted, download them first with Sync & Offloading \u2192 Disconnect from Cloud<\/strong>, otherwise WordPress will be pointing at files that are no longer on the server.<\/p><\/dd>\nHow do I enable verbose debug logging?<\/h3><\/dt>\n
error_log<\/code> destination. Disable it in production unless you are actively troubleshooting \u2014 it may impact performance.<\/p>\n\nWP_DEBUG<\/code> off, the plugin writes nothing to the PHP error log at all, at any level. With WP_DEBUG<\/code> on it writes errors and warnings; the setting adds the rest.<\/p><\/dd>\nIs the plugin multisite compatible?<\/h3><\/dt>\n
uploads\/sites\/<id>\/<\/code> (the main site under uploads\/<\/code>), and each site only ever lists, syncs and restores its own prefix.<\/p><\/dd>\nHow are my credentials stored?<\/h3><\/dt>\n
AUTH_KEY<\/code> \/ SECURE_AUTH_KEY<\/code> and the corresponding salts in wp-config.php<\/code>), so as long as those salts are defined in wp-config.php<\/code> (as WordPress recommends) a database dump on its own is not enough to recover the credentials \u2014 the attacker also needs filesystem access to wp-config.php<\/code>.<\/p>\n\next-openssl<\/code> (enabled by default on virtually every host).<\/p><\/dd>\n\n<\/dl>\n\n\n2.0.0<\/h4>\n\n
\n
1.0.0<\/h4>\n\n
\n
https:\/\/<account>.blob.core.windows.net<\/code>.<\/li>\n\/wp-content\/uploads\/<\/code>: no URL rewriting, no database migration.<\/li>\nWP_DEBUG<\/code> or the debug toggle is on.<\/li>\n