Fix rejected Drecha Forms submissions and file uploads

First confirm whether an entry was stored

Do not ask the visitor to submit repeatedly until you know what happened.

1. Open Drecha Forms → Entries.
2. Filter by the form and the approximate submission time.
3. Check the normal entries and the Spam status.
4. If an entry exists, preserve it and troubleshoot confirmation or notification separately.
5. If no entry exists, reproduce once while watching the browser Network panel.

A successful entry is committed before notification jobs are queued. Email failure therefore does not remove an accepted entry. Validation, security-token, request-size, upload, and obvious-bot failures happen before the entry is stored.

Interpret the public error

“Refresh the page before submitting this form”

The signed form token or its matching idempotency key is missing, changed, or older than 24 hours.

1. Reload the page without restoring an old browser tab.
2. Purge full-page, host, and CDN caches.
3. Keep interactive form pages out of cache lifetimes longer than 24 hours.
4. Confirm that HTML optimization does not remove hidden Drecha fields.
5. Submit once from a private browser window.

“This submission origin is not allowed”

When the browser sends an Origin header, Drecha Forms compares its hostname with the WordPress Home URL.

1. Check the final page URL after redirects.
2. Check Settings → General for the configured site hostname.
3. Make www versus non-www and proxy/CDN host handling consistent.
4. Do not solve the problem by removing the same-origin check.

“Please wait before submitting again”

The public endpoint allows up to 20 attempts per form and visitor fingerprint in a five-minute bucket. Shared office or school networks can reach that limit when many retries happen quickly.

Wait for the window to pass, correct the original validation problem, and submit once. Do not automate immediate retries. If legitimate traffic repeatedly reaches the limit, collect timestamps and hosting/proxy details so the actual visitor IP handling can be reviewed.

“The submission is too large”

The whole HTTP request exceeds 30 MB. Multiple files can each satisfy a field's per-file limit while their combined request exceeds this boundary.

Reduce the number or size of files. Also check the web server and PHP post_max_size and upload_max_filesize: a lower server limit can reject the request before WordPress or Drecha Forms receives it.

“The submission could not be accepted”

The anti-bot honeypot may have been filled by an automated agent or an aggressive browser autofill tool. Reload the form and submit normally. Do not expose or remove the hidden field in the page template.

Resolve field validation errors

1. Read the summary and the message beside each field.
2. Complete every currently visible required field.
3. Check the required format for email, URL, phone, number, date, time, range, and consent fields.
4. For conditional required fields, reproduce the controlling answers and confirm that the required field is actually visible.
5. If the schema changed while the page was open, reload before trying again.

Server-side validation is authoritative. Removing an HTML required attribute or changing browser-side JavaScript does not bypass the saved field rules.

Understand Spam entries

Drecha Forms uses local signals such as submission speed, missing browser identity, excessive links, and common spam phrases. The default threshold is 60. A submission at or above the configured threshold is stored with Spam status and does not queue notifications.

If a legitimate entry is in Spam:

1. Review its content for many links or phrases that resemble bulk promotion.
2. Confirm that a cache or custom embed did not submit immediately after an old token was issued.
3. Adjust the form's spam threshold cautiously only after reviewing several real examples. A higher threshold is more permissive.
4. Test again with a new entry and verify both its status and notification job.

An obvious honeypot submission is rejected before storage and will not appear in Spam.

Diagnose a file upload failure

“This file type is not allowed”

Open the field settings and compare the filename extension with the configured allowed extensions. Executable and active-content extensions—including PHP variants, scripts, HTML, SVG, and executable files—remain blocked even if someone tries to add them to the field configuration.

“The uploaded file contents do not match its extension”

WordPress checked the actual file type and it did not match the filename extension. Obtain a correctly exported file from the source application. Renaming the extension is not a fix.

“The uploaded file is empty or too large”

Check the field's per-file limit, which defaults to 10 MB when no other value is saved. Then check PHP and server upload limits. An empty temporary upload can also indicate that the server rejected the body before WordPress processed it.

“Too many files were uploaded”

A single-file field accepts one file. A multiple-file field uses its configured maximum, five by default. Remove extra files or deliberately change the field setting and republish the form.

“Private upload storage” is unsafe or not writable

Drecha Forms stores uploads outside the public document root and never treats a hard-to-guess public URL as access control.

1. Ask the host for an absolute, non-public, writable directory.
2. Define DRECHA_FORMS_PRIVATE_DIR in server configuration or wp-config.php with that absolute path.
3. Ensure the PHP process can create directories and files there.
4. Do not place the directory under public_html, htdocs, or the WordPress document root.
5. Submit a harmless allowed test file and open it through the protected entry download action while signed in as an authorized administrator.

Do not broaden web-server permissions to 777 or move private files into the Media Library as a workaround.

If security or cache software blocks the request

Use the browser Network response and the security product's log to identify the exact rule. The public route is under /wp-json/drecha-forms/v1/forms/. Create the narrowest route-specific exception supported by that product, retain request-size protection, and test invalid submissions again. Never allow arbitrary PHP uploads or bypass Drecha's own validation.