Troubleshoot a Drecha form that is blank or not working

Match the symptom to the first check

• Nothing appears for visitors: confirm that the form is published and the embed points to the correct form.
• An administrator sees “not published,” but visitors see a blank area: publish the form. This difference is intentional and avoids exposing draft details publicly.
• The fields appear, but Submit or Next does nothing: check JavaScript and REST requests.
• The form worked before a page or cache change: purge cached HTML and verify that the shortcode or dynamic block still renders.
• The form submits on one URL but not another: check the WordPress Home URL and the page's hostname.

Verify the form and embed

1. Open Drecha Forms → Forms.
2. Confirm that the intended form still exists and its status is Published, not Draft or Archived.
3. Open the form and note its numeric ID.
4. Edit the WordPress page containing the form.
5. For a shortcode, use [drecha_form id="123"] with the actual numeric form ID.
6. For the Drecha Forms block, select the intended published form again and save the page.
7. View the public page while signed out.

The block's selector lists published forms. The shortcode renderer also looks up a published form. A deleted, draft, archived, or mistyped ID therefore cannot render a public form.

Some page builders display shortcode text without executing it in every widget type. Use a widget that explicitly supports WordPress shortcodes, or use the native Drecha Forms block in the block editor.

Check whether the page contains the live form

Open the public page source and search for drecha-form. If no form markup exists, the problem is publication, the embed, or cached page content. If markup exists, continue with the browser checks below.

Drecha Forms loads its public CSS and JavaScript when a form is rendered. A cache or optimization layer that removes, delays, or combines those assets incorrectly can leave visible fields without working multi-step navigation, conditions, calculations, or submission behavior.

1. Purge WordPress, hosting, and CDN caches.
2. Temporarily disable JavaScript delay or combination for the affected page on staging.
3. Reload in a private window.
4. Re-enable optimization settings one at a time to identify the specific transformation.

Inspect the browser request

1. Open the browser developer tools.
2. Select Console, reload the page, and look for the first JavaScript error.
3. Select Network, submit the form once, and find the request to /wp-json/drecha-forms/v1/forms/.../submissions.
4. Record its HTTP status and response message.

Use the response to choose the next step:

• 404 or “form is not available”: the form is not published, the embed is stale, or the form identifier no longer exists.
• 403 “Refresh the page”: purge the page cache and reload to receive a new signed form token. Form tokens are valid for 24 hours.
• 403 origin error: make the public page hostname match the WordPress Home URL. A mixed www and non-www configuration can fail the same-origin check.
• A security-plugin block page: allow only the exact Drecha Forms public REST route after confirming the security rule responsible. Do not disable the firewall globally.
• No request at all: fix the first JavaScript error or asset-loading failure.

Check caching and URL configuration

Full-page caches can retain a rendered security token after it expires. Exclude pages containing active forms from cache lifetimes longer than the form token, or configure the cache to refresh those pages more frequently. Purge existing HTML after changing the rule.

In Settings → General, check that WordPress Address and Site Address intentionally use the same public hostname scheme. Redirecting between www.example.com and example.com after the page has loaded can make the browser's Origin header differ from the configured Home URL.

Troubleshoot special display cases

Multi-step navigation is hidden or stuck

Confirm that the page loads the Drecha Forms script without a Console error. Then inspect the form schema in the builder: each step needs reachable fields, and conditional page transitions must have a valid destination. Test with conditions temporarily simplified on a duplicate draft, not by editing the live form without review.

Conditional fields never appear

Confirm that the controlling field is present on the same current schema and that its option values still match the condition. Renaming a visible option label is different from changing its stored value. Use the builder's dependency warnings to resolve circular conditions.

The form looks correct in the editor but not on the website

The editor preview does not include every theme rule. Inspect the public page for theme CSS that hides inputs, buttons, or containers. Test with a standard theme on staging, then narrow the conflicting selector rather than applying a global CSS reset.

The block says no form is selected

Edit the page, choose a published form in the block settings, and save. If the previous form was deleted or changed to Draft, the saved block ID no longer resolves publicly.