Initial assessment without passwords Quote before intervention One accountable specialist from start to finish

Wordpress Form Behaviour

A WordPress Form Loses Uploaded Attachments

Trace missing WordPress form attachments through browser upload limits, temporary files, mail tags, SMTP size limits and safe file delivery.

An attachment passes through more stages than an ordinary field: the browser uploads it, PHP stores a temporary file, the form validates and moves it, the notification references it, and several mail systems enforce size and file-type policies.

First determine whether the file disappeared before the entry was saved or only from the delivered email.

Use a safe test file

Create a small, harmless document with a unique filename and no personal data. Record its exact size, extension, submission time, form ID and expected recipient.

Do not test with executable files, confidential customer uploads or disguised extensions. If the site accepts images from phones, later repeat with a realistic permitted format after the basic path works.

Keep the page open until the server returns a genuine result.

Confirm the browser transmitted the file

Inspect the form request in browser developer tools. Check that it uses the expected multipart upload and that the file field is present, without sharing its raw contents.

A JavaScript error, mobile picker issue or client-side size rule may stop the upload before WordPress receives it. The visible filename alone is not proof that bytes were sent.

Test logged out, on a real mobile device if relevant, and without an extension that modifies requests.

Compare PHP and form limits

PHP’s upload_max_filesize and post_max_size must accommodate the complete request, not only the file. The web server, proxy, Cloudflare plan or ModSecurity can impose another limit.

Check the form plugin’s own maximum size and allowed extensions. Use a smaller test to distinguish a size limit from a general attachment fault.

Increase limits only to the documented business requirement; accepting unnecessarily large uploads increases resource and abuse risk.

Check temporary storage

PHP needs a writable temporary upload directory and enough disk space. Review PHP and server logs for upload error codes, permission problems and full disks at the timestamp.

Security hardening or cleanup jobs can remove a temporary file before an asynchronous notification reads it. Record the expected lifecycle and never make a public upload directory broadly writable as a shortcut.

If the plugin stores files permanently, verify access controls and retention rather than exposing direct predictable URLs.

Match the file field to the mail action

Many form plugins require the upload field or mail tag to be explicitly added to the notification’s attachment setting. A renamed field can leave an obsolete reference while text fields continue to work.

Compare the exact field ID with the notification configuration. Check conditional notifications separately because one department’s email may omit the attachment setting.

Do not paste a filesystem path into the email body as a substitute for a valid attachment.

Trace mail size and provider policy

Find the message in the WordPress mail and SMTP provider logs. A base64-encoded attachment makes the email larger than the original file, so a file just below an advertised limit may still exceed the provider’s message limit.

Record any bounce or rejection code. Recipient gateways may block archives, macros, password-protected files or particular MIME types even after the sending provider accepts the message.

Never evade security filtering by renaming a prohibited file.

Prefer secure links for sensitive or large files

Email attachments create copies across servers and mailboxes. For identity documents, large media or other sensitive uploads, consider an access-controlled storage workflow with expiring links, authentication and an explicit retention policy.

Do not place uploads in a publicly enumerable media directory. Verify that links cannot be guessed and that deleted submissions remove associated files when policy requires it.

Document who can access the file and for how long.

Verify upload, storage and delivery

After fixing the failed handoff, submit a new small test. Confirm browser upload, successful validation, expected storage, one notification and final attachment integrity. Download it as the authorised recipient and compare filename, type and size.

Then test the maximum approved size and a rejected type, ensuring the visitor receives a clear error rather than false success. Confirm cleanup and deletion behaviour.

Request urgent repair if uploads contain sensitive data, disappear from stored entries or trigger mail rejection. Share error codes, sizes and synthetic filenames—never customer files or server credentials.

BEFORE YOU SEND THE REQUEST

Frequently asked questions.

Do you ask for passwords in the form?+

No. The public form never requests access. Secure credentials are requested only after the scope and quote are approved.

Who reviews the incident?+

The request goes to Jordi Ensenyat, founder of Code Barcelona and a WordPress specialist with more than 15 years of experience.

Is anything changed before the quote?+

No. Visible symptoms and scope are reviewed first. Intervention begins after approval and with a rollback path prepared.

Do you work internationally?+

Yes. WP Repair handles WordPress and WooCommerce incidents in English and Spanish through a remote service.

Assess my incident