Gravity Forms 2.10.5 fixes a problem saving a mix of new and existing uploaded files. Entry editing, partial entries, save and continue, multi-file fields, private download filters, object storage, and notifications can each transform the collection differently.
Use this for application, claim, onboarding, quote, support, and document-collection forms where users or staff add files to an existing entry over time.
Quick answer
Create an entry with two existing files, edit it to retain one, remove one, and add two new files, then trace the collection from browser payload through temporary upload, entry value, storage, notification, API, export, and deletion. Repeat with retries and interrupted saves. Pass only when intended files appear once, removed files follow policy, and no temporary or private object becomes public.
What to check first
- Build fixtures for single and multi-file fields, images and documents, duplicate names, Unicode names, maximum count, rejected type, rejected size, and interrupted upload.
- Record existing entry value, retained file IDs, removed file IDs, new temporary IDs, display order, storage paths, object keys, private URL policy, and final serialized value.
- Test front-end entry edit, admin entry edit, save and continue, partial entry, REST or add-on update, validation failure, network retry, and double submit.
- Verify notifications, confirmations, merge tags, exports, feeds, signatures, PDFs, CRM records, and private download links use the final intended collection.
- Delete or trash the entry and reconcile local uploads, object storage, CDN, backups, temporary directories, and audit logs according to policy.
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 |
|---|
| Build the mixed-file fixture | Build fixtures for single and multi-file fields, images and documents, duplicate names, Unicode names, maximum count, rejected type, rejected size, and interrupted upload. | The final entry value exactly matches the intended ordered collection. |
| Capture each collection representation | Record existing entry value, retained file IDs, removed file IDs, new temporary IDs, display order, storage paths, object keys, private URL policy, and final serialized value. | Every final file exists at the expected storage layer and every removed file follows policy. |
| Update to 2.10.5 on staging | Test front-end entry edit, admin entry edit, save and continue, partial entry, REST or add-on update, validation failure, network retry, and double submit. | Notifications, exports, feeds, APIs, and private links reference the same collection. |
| Test retries and connected outputs | Verify notifications, confirmations, merge tags, exports, feeds, signatures, PDFs, CRM records, and private download links use the final intended collection. | Temporary files and failed-upload objects are cleaned without deleting retained files. |
Why this usually happens
- Existing and temporary uploads use different identifiers.
- Validation can rebuild the field value from a stale browser collection.
- Offload hooks can move new files before the entry value commits.
- Notification generation can read the entry before final file reconciliation.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
entry_id: 8201
existing_before: [a.pdf, b.jpg]
retain: [a.pdf]
remove: [b.jpg]
new_temp: [c.pdf, d.png]
final_order: [a.pdf, c.pdf, d.png]
missing: 0
duplicates: 0
private_urls: true
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.
- Build the mixed-file fixture
- Capture each collection representation
- Update to 2.10.5 on staging
- Test retries and connected outputs
- Reconcile removal and retention
Decision rule
Pass when retained files remain, removed files follow policy, new files appear once in the intended order, private access remains private, and retries cannot duplicate or orphan objects.
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 exactly matches the intended ordered collection.
- Every final file exists at the expected storage layer and every removed file follows policy.
- Notifications, exports, feeds, APIs, and private links reference the same collection.
- Temporary files and failed-upload objects are cleaned without deleting retained files.
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
Should removed files be deleted immediately?
That depends on retention, legal, backup, and audit policy. The entry should clearly stop referencing them, and every remaining copy needs an owner and expiry.
Why test order?
Document workflows and generated PDFs may rely on the user's intended sequence even when all file IDs are present.
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, test Gravity Forms file uploads.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Recover partial object-storage offload safely
For retained files and new uploads that finish in different storage states, use the Gravity Forms partial file offload recovery to reconcile hashes, object copies, entry commits, retries, access policy, and cleanup.
Helpful references