Forum Replies Created
I see the S3 plugin 5.0.0 update came out but I do not see in the notes that URL encoding is included. Can you please confirm if I can update my plugin?
Also, can I update my WPDM – I am on 7.2.1?
Thanks – did you install that site-wide? And will that be effected by future updates to plugin?
Hello – checking in to see what “updating the plugin” means so I can replicate the fix and close out this conversation.
Thanks it does seem to be working. Can I ask what you did so I can replicate it on my other sites?
Hi, following up because I am still unable to activate this product on my website and I opened this chain on 12/23.
Correct, the files currently on my site that I am autosyncing using WPDM to my S3 bucket. New uploads do not have the NoSuchKey
Also I am now getting invalid License key when trying to use the same license on some of my multi site. I have two of the sites attached to the key but the other ones key saying invalid key. This was not a problem before.
Post 4.0.2 Update: I’ve confirmed this is not an AWS connectivity issue. Uploading via the S3 picker syncs to the bucket successfully (credentials/region/IAM OK). However, autosync/batch sync is not running at all:
__wpdm_s3_autosync=1 with bucket/folder configured.
Hitting ?wpdm_cron=1 on both the subsite and main site (with correct __wpdm_cron_key) returns “complete” but does not sync even a newly uploaded local file.
WP-Cron shows only WPDM__CronJobs->clearTempData(); no autosync cron registered.
Action Scheduler tables exist, but contain 0 rows for hooks matching %wpdm%, %s3%, %aws% on both wp_35_actionscheduler_actions and wp_actionscheduler_actions.
This indicates autosync is neither scheduled via WP-Cron nor queued via Action Scheduler, so no backend sync pipeline exists for local/Asset Manager files in this version. Can you confirm whether autosync is intended to support batch syncing existing local/Asset Manager files, and if so what mechanism is supposed to enqueue/run those jobs?
Additional Findings (Related JavaScript Error Impacting Upload Context)
While investigating the autosync issue, we identified a separate but related JavaScript error on the standard post edit screen (/wp-admin/post.php?action=edit) where WPDM packages are edited. The WPDM Amazon S3 add-on script picker-controllers.js throws a fatal error (Uncaught ReferenceError: ajaxurl is not defined), which prevents the S3 picker and upload logic from executing on that screen. Uploads work correctly on the WPDM S3 admin page (edit.php?post_type=wpdmpro&page=wpdm-aws), where ajaxurl is properly defined. This indicates the add-on is relying on ajaxurl being globally available, but it is not defined in all admin contexts (notably post edit screens in multisite). As a result, uploads initiated from the post editor never complete, and therefore never enter the autosync pipeline, which may partially explain why autosync appears nonfunctional for new uploads despite working credentials and UI connectivity.
I also confirmed that the test site had been autosyncing when I tested it October 25, 2025. Previously I had reached out about the S3 bucket not showing through the plugin, though the objects were syncing. Now the opposite is true.
System Environment
WPDM Core: 7.0.0
WPDM Amazon S3 Add-on: 4.0.1
WordPress: 6.9 (Multisite)
PHP Version: 8.2 (WP Engine environment)
Hosting: WP Engine
Issue Summary
The Amazon S3 add-on connects successfully to S3, but autosync does not execute on a multisite subsite.
This affects new uploads as well as existing files.
The S3 browser UI and folder listing now function correctly.
The issue is limited to autosync execution, not UI rendering.
Expected Behavior
New uploads added to WPDM should automatically sync to S3.
Existing documents already present in the Asset Manager should be eligible for autosync (or at least for a one-time sync operation).
Actual Behavior
Files remain local after upload
Autosync never completes
No visible WordPress or WPDM errors
Manual uploads to S3 from WPDM work
Steps Taken to Isolate the Issue
1. Verified AWS Credentials & IAM Permissions
IAM user has full s3:* permissions
Bucket listing and manual uploads work correctly
Conclusion: AWS configuration is correct.
2. Verified Multisite Activation Scope
Tested WPDM and the S3 add-on:
network-activated
locally activated on the subsite
Re-saved S3 settings after each change
Result: No change in autosync behavior.
3. Verified WP-Cron
Confirmed the cron endpoint returns HTTP 200
WP-Cron is not blocked
Conclusion: Cron is functioning.
4. Tested Forced Blog Context
Added a must-use plugin to force switch_to_blog() during cron execution
Retested autosync on a new upload
Result: Autosync still did not run.
5. Analyzed Background Execution
Server logs consistently show background requests related to async queue processing being terminated before completion (HTTP 499 / client connection closed).
The autosync process appears to start but does not finish.
Questions for Clarification
Is autosync officially supported on multisite subsites?
Does autosync rely on long-running admin-ajax.php background requests?
Is there a supported way to:
run autosync via WP-CLI?
chunk or resume sync operations?
If autosync is not supported in this scenario, can that be documented clearly?
Thank you – also is there a location to set the AWS region within the plugin?
WP Crontrol
Is there any assistance if you don’t use Cpanel or Plesk? Or do you have to use those for this plugin to work?
Okay I got it fixed but now the Cron job has stopped working. I am using https://website.url/?s3sync=1. It worked last week.
The File Browser Root did fix when I updated that. Thank you.
I am putting in my request for a refund right now, within my 14 day window. I have tried to get support and it takes 24 hours to hear back. I need quicker support to work through a myriad of problems.
Order ID# WPDM68E96573ED123
Also when I moved from the free version to pro, the download manager picked up a bunch of documents and files from the website that I had not saved in there previously.
Here you can see the free download manager version with our files:
And here you can see the same asset manager after we uploaded the pro version:
All of our documents were moved into an interior files, which makes it harder for my users to find what they need.
I can’t rename any of the folders or reorangize them in the asset manager. So the asset manager does none of the file organizing I need it to do.