Gravity Forms documents that generic WordPress upload-offload plugins are not officially supported and may not work as expected. A mixed entry edit is especially risky when retained files already point to object storage, new temporary files copy only partly, the entry commit fails, or a retry repeats a successful copy.
Use this for Gravity Forms 2.10.5 sites with multi-file fields, entry editing, private downloads, Dropbox, S3-compatible custom storage, asynchronous feeds, media-offload plugins, or cleanup jobs.
Quick answer
Freeze cleanup, export the entry value, and build a ledger for every retained, removed, temporary, copied, committed, and orphaned file. Treat object copy and entry update as separate idempotent steps keyed by entry, field, temporary identity, and content hash. Repair references only after object size and checksum verify, then rerun notifications, exports, and cleanup in a controlled order.
What to check first
- Record Gravity Forms and offload integration versions, form and field IDs, single or multi-file mode, entry edit path, storage type, private-download policy, asynchronous feeds, notifications, exports, retention, and cleanup jobs.
- For each file capture original name, safe stored name, temporary path, entry URL, object key, content hash, byte size, MIME type, copy attempt, copy result, access policy, commit state, and deletion state.
- Reproduce retained plus removed plus new files with one successful copy, one failed copy, a database timeout before commit, a retry after success, a concurrent cleanup run, and an entry save from a second browser.
- Compare the final entry JSON, local filesystem, object inventory, private access checks, notifications, merge tags, exports, add-on feeds, backups, logs, and user-visible file order.
- Repair from the ledger by verifying existing objects, copying only missing content hashes, committing one final ordered collection, then quarantining or deleting orphans after the rollback window.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Pause cleanup and preserve state | Record Gravity Forms and offload integration versions, form and field IDs, single or multi-file mode, entry edit path, storage type, private-download policy, asynchronous feeds, notifications, exports, retention, and cleanup jobs. | The final entry value contains only intended files in the intended order. |
| Build a per-file ledger | For each file capture original name, safe stored name, temporary path, entry URL, object key, content hash, byte size, MIME type, copy attempt, copy result, access policy, commit state, and deletion state. | Each referenced object has the expected hash, size, MIME type, encryption, and access policy. |
| Verify object bytes and policy | Reproduce retained plus removed plus new files with one successful copy, one failed copy, a database timeout before commit, a retry after success, a concurrent cleanup run, and an entry save from a second browser. | Replaying the failed copy and entry commit creates no duplicate object, notification, feed, or export row. |
| Commit one ordered collection | Compare the final entry JSON, local filesystem, object inventory, private access checks, notifications, merge tags, exports, add-on feeds, backups, logs, and user-visible file order. | Local files, temporary files, object storage, backups, notifications, and cleanup logs reconcile to the ledger. |
Why this usually happens
- File copy and entry update are separate operations without one shared transaction.
- A retry can repeat the object copy after the first request timed out following success.
- Cleanup can remove a temporary or local file before the final entry reference is durable.
- Private download authorization can break when an entry URL is replaced with a raw object URL.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
entry_id: 84021
field_id: 7
retained: [obj/a-1.pdf]
removed: [obj/old-2.pdf]
new_temp: [tmp/c-3.pdf, tmp/d-4.pdf]
copy_results: [c-3=verified, d-4=timeout]
entry_commit: not_started
retry_key: 84021:7:sha256-d4
cleanup_hold_until: 2026-08-06
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Pause cleanup and preserve state
- Build a per-file ledger
- Verify object bytes and policy
- Commit one ordered collection
- Quarantine orphans before deletion
Decision rule
Pass when every intended file appears once in the entry and approved storage, removed files follow written retention policy, retries create no duplicate object, private access remains enforced, and no unreferenced object is deleted before the recovery window closes.
What to tell the client or owner
Give the owner the affected versions, exact workflow, observed result, business impact, evidence location, temporary control, named owner, and next review time. Remove credentials and personal data from shared screenshots and logs.
Production verification checklist
- The final entry value contains only intended files in the intended order.
- Each referenced object has the expected hash, size, MIME type, encryption, and access policy.
- Replaying the failed copy and entry commit creates no duplicate object, notification, feed, or export row.
- Local files, temporary files, object storage, backups, notifications, and cleanup logs reconcile to the ledger.
Mistakes to avoid
- Do not change several plugins, cache rules, or infrastructure settings before preserving a baseline.
- Do not treat one successful test as proof for retries, alternate clients, background work, or mixed-version fleets.
- Do not paste secrets, personal data, complete production payloads, or customer files into tickets or screenshots.
- Do not close the test until the final user-visible state and the server-side evidence agree.
Questions teams ask during testing
Does Gravity Forms officially support generic media-offload plugins?
Its file upload documentation says those plugins are not officially supported and uploads may not work as expected, so test the exact integration.
Should an orphan object be deleted immediately?
Quarantine it through a documented recovery window unless it creates an active security or privacy exposure.
When HandL WP should help
Bring in HandL WP when a production checkout, form, editor, security gate, media pipeline, or paid lead workflow is at risk. We can preserve evidence, isolate the failing layer, make the smallest corrective change, and verify the result across WordPress, connected services, logs, and the user journey.
If this is active on a production site, recover Gravity Forms file uploads safely.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Preserve private download authorization after offload
Once storage reconciliation is complete, use the Gravity Forms private object URL authorization test to prove anonymous users cannot bypass entry ownership, capability checks, signed URL scope, expiry, logging, deletion, or backup controls.
Helpful references