DiluxOne Offload – Media Storage

No. The stream wrapper intercepts filesystem calls transparently — your post content, the wp_posts table, and the wp_postmeta table are never rewritten.

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.

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. The one operation that writes to the server is Sync & Offloading → Disconnect from Cloud. It copies your media back from the container to the exact uploads-directory paths WordPress has on record (resolved at runtime with wp_upload_dir()), so the Media Library works again without the plugin. It restores only what sits under the uploads/ 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.

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.

Yes. Because the stream wrapper operates at the filesystem layer, any plugin that reads or writes files under /uploads/ using standard PHP functions works unchanged.

Only if you explicitly opt in. After a successful sync you can click Delete Local Files in Sync & Offloading › 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 leaves it alone.

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.

Deleting the plugin from the Plugins screen removes everything it created in your database: its options (all prefixed diluxone_offload_), its transients and its file-tracking table (diluxone_offload_files, with your table prefix) — on every site of a network. Deactivating alone keeps all of that, so you can deactivate and reactivate without losing your configuration. Your media files are never touched by uninstalling: whatever is in /wp-content/uploads/ 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 → Disconnect from Cloud, otherwise WordPress will be pointing at files that are no longer on the server.

Go to DiluxOne Offload → Settings → Enable detailed debug logging. Logs are written to the standard PHP error_log destination. Disable it in production unless you are actively troubleshooting — it may impact performance. With that setting off and WP_DEBUG off, the plugin writes nothing to the PHP error log at all, at any level. With WP_DEBUG on it writes errors and warnings; the setting adds the rest.

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 — or share one: a site's objects are stored under uploads/sites/<id>/ (the main site under uploads/), and each site only ever lists, syncs and restores its own prefix.

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 (AUTH_KEY / SECURE_AUTH_KEY and the corresponding salts in wp-config.php), so as long as those salts are defined in wp-config.php (as WordPress recommends) a database dump on its own is not enough to recover the credentials — the attacker also needs filesystem access to wp-config.php. 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 tab. There is intentionally no plaintext fallback. Requirements: PHP ext-openssl (enabled by default on virtually every host).