What’s a Security Token?
Think of a security token like a secret handshake between your RepairPlugin on your website and your visitors. Each time someone lands on your site, the website generates a unique code just for them. This code ensures that any form submissions come from a trusted user—keeping your site safe from hackers or fake submissions (like CSRF attacks).
How Do Security Tokens Work?
Let’s break it down:
User Requests a Page: A visitor clicks on your site, and the website immediately creates a unique security token for them.
Token is Sent: This special token is embedded in the page the user sees and also gets saved in their session.
Form Submission: When they fill out and submit a form, the website checks to make sure the token in the form matches the one in their session.
Validation: If everything matches, the request goes through smoothly. If not, the form gets rejected—it’s a security block to protect your site.
But here’s where caching becomes a problem.
The Big Problem with Caching
Caching is great, it makes your site load faster, saves bandwidth, and helps serve pages instantly to new visitors. But when you throw security tokens into the mix, things can break. Badly.
Here’s why:
User 1 Visits Your Site: Your site generates a security token for User 1, and everything is great.
Cache Kicks In: The page, including User 1’s token, gets cached for future visitors.
User 2 Visits: The cached page is served to User 2—but it still contains User 1’s token.
Token Mismatch: When User 2 tries to book an appointment, they get an error because their session token doesn’t match the one stored on the cached page.
The Solution: Disable RepairPlugin from caching
Instead of turning off all caching, the best solution is to exclude RepairPlugin from being cached by your caching plugin. This way, your site stays fast, and you avoid token mismatches that cause form submission errors.
How to Exclude RepairPlugin from Caching on Popular WordPress Plugins:
1. WP Rocket
WP Rocket makes it super easy to exclude specific pages or plugins from caching.
Go to WP Rocket Settings → File Optimization.
Scroll to Never Cache URL(s).
Add the URL(s) of the pages where RepairPlugin is active (e.g., your booking or repair form page).
Click Save Changes.
2. W3 Total Cache
W3 Total Cache gives you control over what gets cached and what doesn’t.
Go to Performance → Page Cache.
Scroll to the Never Cache the Following Pages section.
Enter the URLs or paths where RepairPlugin runs (e.g.,
/repairor/booking).Click Save Settings & Purge Caches.
3. WP Super Cache
With WP Super Cache, you can easily exclude specific pages or content from being cached.
Go to Settings → WP Super Cache.
Click on the Advanced tab.
Under Accepted Filenames & Rejected URIs, find the Add here strings (not a filename) that forces a page not to be cached field.
Add the URLs where RepairPlugin is active (e.g.,
/repair-form/).Save your settings.
4. LiteSpeed Cache
LiteSpeed Cache gives you flexibility to exclude specific plugins like RepairPlugin from caching.
Go to LiteSpeed Cache → Cache → Excludes.
Under Do Not Cache URIs, add the paths or pages where RepairPlugin is running (e.g.,
/repair-quote/).Click Save Changes.
5. SG Optimizer (SiteGround)
If you're on SiteGround, their SG Optimizer plugin can easily exclude pages from caching.
Go to SG Optimizer → Caching → Exclude URLs from Caching.
Enter the RepairPlugin pages or URLs (e.g.,
/book-repair/).Click Save Changes.
Still Having Issues?
If you’re still experiencing caching problems, consider the following:
Disable CDN Caching: If you use a CDN like Cloudflare, you can adjust the caching settings to exclude RepairPlugin.
CSRF Protection Settings: You can also disable CSRF protection in RepairPlugin Pro → Settings → Front-End Steps → CSRF Protection for Front-End Forms. However, this can leave your site vulnerable to security risks, so proceed with caution.
Expiry when users wait too long
Another issue that can pop up is when a user opens your website, leaves it open for hours, and then comes back to submit a form. That long delay can cause the security token to expire. This creates the same kind of issue—form errors.
Here's how it plays out:
The "Wait Too Long" Scenario:
User opens the page: The security token is generated, and everything looks fine.
User gets distracted: They leave the page open for a few hours or even overnight.
User comes back to submit the form: The security token has expired because it’s tied to a session time limit.
Error message: The form submission fails because the token is no longer valid.