NO BUG: Form Redirects Not Working - Just Reloads the Page

Bugs
1

Hi,

I’ve got a frustrating issue with form redirects on two sites I built for the same client. The forms are working fine for everything else (emails send, Slack notifications come through), but they just won’t redirect after submission - they just reload the current page instead.

The Sites

Where It’s Happening
Both the welcome forms and contact forms on both sites:

I’ve got a quick video showing the form settings and the actual bug happening, but basically when you submit the form it just refreshes instead of taking you to the thank you page.

What’s Working vs What’s Not

  • Email notifications: Working perfectly
  • Slack notifications via Zapier webhook: Working perfectly
  • Form redirects: Nope, just reloads the page

I’m testing in Safari, running Bricks 2.0.1 on Hostinger with LiteSpeed cache. Not sure if that’s relevant but figured I’d mention it.

My Setup
Running Bricks 2.0.1 (just updated to make sure), WordPress 6.7.3, hosted on Hostinger with LiteSpeed Cache enabled.

Active plugins:

  • ActiveCampaign (8.1.18)
  • Advanced Custom Fields PRO (6.3.12)
  • Hostinger Tools (3.0.44)
  • LiteSpeed Cache (7.3.0.1)
  • Site Kit by Google (1.157.0)
  • SmartCrawl Pro (3.14.1)
  • Wordfence Security (8.0.5)
  • WP Consent API (1.0.8)
  • WPMU DEV Dashboard (4.11.29)

System Info
Theme Information
Theme name: Bricks
Theme version: 2.0.1
Theme author: Bricks
Theme is child theme: No

WordPress Environment
Home URL: https://innstyle.co.uk
WP version: 6.7.3
WP memory limit: 40 MB
WP multisite: No

Server Environment
Server info: LiteSpeed
MySQL version: 10.11.10
PHP version: 8.2.28
PHP memory limit: 512M
PHP execution time limit: 300
PHP max input vars: 5000

The weird thing is this is happening on both sites (they’re basically identical), and it’s consistent - every form submission just reloads instead of redirecting. The redirect URLs are definitely set up correctly in the form settings.

Has anyone else run into this with similar hosting setups?

Any ideas would be really appreciated!

2

Hi Murray,
Thanks so much for your report!

Please try increasing the “Redirect after (ms)” setting. Currently it is 2 milliseconds, which is clearly too fast. Try 500, 1000 or 2000.

Best regards,
timmse

3

Thanks for coming back to me timmse. Haha I can’t believe I didn’t spot having 2 in the field thinking it was 2sec and not 2ms. I changed this to 1000ms and seems to have worked in a private Safari session.

I’ll have a few people on my end test this out to confirm it’s now resolved. Thanks for coming back so quickly and sorry I goofed on the milliseconds.

1 Like
4

Hi timmse, I’ve just had further feedback from various users testing. It seems that in a private Safari session the redirect is working fine but in a normal Safari session it’s still not redirecting.

Below is a video capturing a private safari submission which works: CleanShot 2025-08-18 at 20.18.12 · CleanShot Cloud

Then the 2nd video which shows a submission in a standard Safari session which just reloads the page but doesn’t actually show the form success message:

In Brave/Chrome this is working fine in a normal browser session so could it be something to do with Safari blocking like a Safari caching or cookies issue? I have set the redirect delay to 2000ms but that hasn’t helped it seems just in a private browser session on Safari.

5

Hi Murray,
It seems that the second form action from https://www.spectaclehq.com/ is responsible for this. Can you deactivate it and test again?

image
image1920×1200 252 KB

6

Thanks for checking into this again. I have since removed the 2nd form action which is a webhook but still getting a failure. What I have noticed is that in Safari I get a 500 for the admin-ajax.php request but in Brave/Chrome that is a 200 which could be stopping the redirect from happening because of the server error?

to confirm, the actions I have setup are just email and redirect with a redirect delay of 2000ms. I have then removed the webhook as per your suggestion. I have set this up on a duplicated version of the page Welcome to the Inn Style Family • Inn Style

7

I have gone down a rabbit hole with AI so please take this with a pinch of salt however implementing some Javascript on the same page as the form has fixed my Safari redirect so I think it could be onto something here.

Below is a summary of what it thinks the issue is:

Core Issue

Safari is not sending proper authentication when submitting Bricks forms, causing the form to be processed via the unauthenticated handler (wp_ajax_nopriv_bricks_form_submit) instead of the authenticated handler (wp_ajax_bricks_form_submit). This breaks the redirect functionality.

Technical Root Cause

What Should Happen:

  1. User submits form with proper nonce/authentication
  2. WordPress routes to wp_ajax_bricks_form_submit (authenticated)
  3. Form processes and redirects properly

What Actually Happens in Safari:

  1. User submits form but Safari doesn’t send authentication properly
  2. WordPress routes to wp_ajax_nopriv_bricks_form_submit (unauthenticated)
  3. Form processes but redirect logic fails in unauthenticated context

Evidence from Server Logs

Safari Request Processing:

[19-Aug-2025 13:46:07 UTC] AJAX Hook fired: wp_ajax_nopriv_bricks_form_submit
[19-Aug-2025 13:46:07 UTC] Bricks form handler triggered WITHOUT auth

Expected (Other Browsers):

AJAX Hook fired: wp_ajax_bricks_form_submit  
Bricks form handler triggered WITH auth

–

Here is the JS code I added to handle the redirect in Safari

(function() {
const REDIRECT_URL = ‘Account Next Steps • Inn Style’;
const REDIRECT_DELAY = 1500;

document.addEventListener('submit', function(e) {
    if (e.target.closest('.brxe-form, .bricks-form')) {
        console.log('Bricks form submitting...');
    }
}, true);

const originalFetch = window.fetch;
window.fetch = function(...args) {
    return originalFetch.apply(this, args).then(response => {
        // Only handle Bricks form submissions
        if (args[0]?.includes('bricks_form_submit') && response.ok) {
            console.log('Bricks form response:', response.status);
            
            // Safari gets 204 No Content on success - redirect manually
            if (response.status === 204) {
                setTimeout(() => window.location.href = REDIRECT_URL, REDIRECT_DELAY);
            }
            // Handle JSON responses (other browsers)
            else if (response.headers.get('content-type')?.includes('application/json')) {
                response.clone().json().then(data => {
                    if (data.success === true) {
                        setTimeout(() => window.location.href = REDIRECT_URL, REDIRECT_DELAY);
                    }
                }).catch(() => {
                    // If JSON parsing fails but status is successful, redirect anyway
                    setTimeout(() => window.location.href = REDIRECT_URL, REDIRECT_DELAY);
                });
            }
        }
        return response;
    });
};

})();

8

Hi @murrayw,

ok, so I see that the form works now, so my comments will be related to time before you implemented the fix:

It’s not about the second action (webhook), that you removed. The https://www.spectaclehq.com/ script is still loading, and it’s attaching an event on the form submit action.
If I disable it (uncheck the “enabled” toggle from Stefan screenshot), the form works also in Safari.

I suggest that you figure out which plugin or custom script is loading this and you disable it.

CleanShot 2025-08-20 at 15.15.14@2x
CleanShot 2025-08-20 at 15.15.14@2x1298×194 34.2 KB

That way, you will see where the problem is - because if it will work, when p.spectaclehq.js script is not loaded, you know exactly where the problem is.

Please let me know once you do that.
Thanks.
Matej