smartEngin
Forum Replies Created
-
Thank you for taking the time to verify the fix on your real SiteGround environment – that closes the loop perfectly. Two reports, two fixes, both confirmed by you in production: reports of this quality are rare, and the plugin is better for every user because of them.
And please don’t stop here: if you ever have remarks, ideas or feature wishes for the plugin – anything you feel is missing or could work better – just open a topic in this forum. Feedback from someone using the plugin in production is exactly what shapes the roadmap.
If you feel like it and can spare two minutes, a short review of the plugin would mean a lot to a small project like this: https://wordpress.org/plugins/smartengin-forms/#reviews – but absolutely no obligation, you have helped more than enough already.
And I have another toppic for you:
While visiting your site, I ran it through Mozilla’s HTTP Observatory (developer.mozilla.org/en-US/observatory) out of curiosity, and I think the results deserve your attention before your launch – especially since your product is about digital security, so visitors will hold your own site to that standard.
The one thing I would fix first: the site does not redirect HTTP to HTTPS. Anyone who types your address without “https://” browses unencrypted – and an email address submitted to your signup form on that unencrypted page would travel in plain text. On SiteGround this is a one-click fix: Site Tools → Security → HTTPS Enforce.
Three smaller items, each a single response header (on SiteGround you can set them via the .htaccess file):
Header always set Strict-Transport-Security “max-age=31536000”
Header always set X-Frame-Options “SAMEORIGIN”
Header always set Referrer-Policy “strict-origin-when-cross-origin”
The first tells browsers to always use HTTPS in the future (enable it only after the redirect works), the second prevents your site from being embedded in a foreign frame (clickjacking), the third limits what other sites learn when visitors follow a link away from yours.
The biggest remaining scoring item, a Content Security Policy, is also the most work – I would leave it for later and start in report-only mode when you get to it. And for what it’s worth, some things already look good: no third-party scripts, nosniff is set, no stray cookies.
Rescan on the Observatory page afterwards and you should jump from an F to a solid grade with maybe half an hour of work.
Again: no criticism at all, just a thank-you in kind. And my offer from the forum stands – if you ever have wishes or ideas for the plugin, I’m all ears.
Best regards
Pierre (smartEngin)- This reply was modified 4 days, 11 hours ago by smartEngin.
- This reply was modified 4 days, 11 hours ago by smartEngin.
Hi @maestropratico,
thank you – once again – for an outstanding report. The controlled HIT/BYPASS test series with a clean incognito reproduction told us exactly where to look, and your analysis turned out to be precisely right. This is fixed in version 1.1.5, which is rolling out now.
To answer your three questions:
- Yes, your assumption was correct. The success/error message was rendered server-side on the GET after the redirect: the POST stores the result in a short-lived transient and hands the browser a one-time cookie, and the form shortcode consumes both while rendering the next page view (Submission_Handler::pop_result(), called from the form renderer). When that GET is served as a cache HIT, WordPress never runs, so the message was never injected – exactly the pattern you measured.
- The “redirect to a thank-you page” option is a plain redirect to that page’s normal, static content. It does not depend on the transient/cookie step, so it is immune to this issue (as long as the form itself is not embedded on the thank-you page). It was a valid workaround all along.
- There was no such hook or setting until now. Instead of emitting host-specific bypass signals – which an NGINX-level cache would not reliably honor from PHP, as you noted – 1.1.5 solves it on the client: alongside the existing HttpOnly result cookie, the plugin now sets a JS-visible flag cookie. On page load the bundled script checks: flag present, but no result box in the DOM (i.e. the page came from a cache)? Then it fetches the result exactly once via a POST to admin-ajax.php – a request no full-page cache answers – and renders the message in the browser: the success message replaces the form, and an error restores the visitor’s entered values and marks the affected fields, matching the server-rendered output. Freshly rendered pages are untouched (the message is already in the HTML, no extra request is made), and without JavaScript the behavior is exactly as before.
Once you have updated, I would genuinely appreciate hearing whether it behaves as expected on your SiteGround setup – and please do come back if anything does not work as described. Reports like yours are the kind every developer hopes for; you are credited in the changelog.
Thanks again!