Hi Charlie,
On a client site, standard CS Forms contact forms (non-AJAX, Email and Redirect actions) appeared to hang after submission. The entry was sent, but the redirect took 10-25 seconds (some last night looked to get into a very long loop), which let visitors click submit several times. I traced it to the Form Submissions option.
Environment
- Cornerstone/CS Forms: Latest versions
- WordPress [version], PHP 8.3, 1024M memory, LiteSpeed, no caching plugin
- Server cron in use (WP-Cron disabled)
Symptoms
- The POST to the form page returned a 303 (the code set in the form) in about 2.6s.
- The following GET of the plain
/thank-you/URL took 10-24s. Loaded directly, the same page took about 1.4s. - Sampling the page with curl every few seconds showed the stall hit all visitors, not only the submitter, then cleared by itself. A plain PHP file and static files stayed fast during the stall, so it was not a server resource or hosting limit.
- Disabling the Email action made no real difference (the POST dropped by about 0.85s).
Cause
cs_component_cache in wp_options is about 1.46 MB. Checking it before and after a submission showed the same size and the same MD5 hash, but a new option_id (306372 to 306389), so the row had been deleted and re-inserted with identical content. A logger on delete_option_cs_component_cache produced this backtrace on the form POST (trimmed):
Cornerstone\Forms\Actions\PostInsertAction\render
do_action('cs_purge_tmp')
Themeco\Cornerstone\Services\Components->purge_cache
delete_option
So with Form Submissions enabled, each submission runs the Post Insert action, which fires cs_purge_tmp and empties the entire component cache. The next request then re-renders every component and rewrites the 1.4 MB option, which took about 10s here, and it affects whichever visitor loads a page next.
Confirmation
With Form Submissions switched off and everything else unchanged, the cs_purge_tmp / purge_cache logging stopped appearing on form POSTs. The POST then took 2.42s and the thank-you GET 1.91s.
Questions
- Is it intended that saving a submission purges the full component cache? Could the purge be limited to what the new post actually affects, or skipped for the submissions post type?
- Is there a supported filter or setting to stop
cs_purge_tmpfiring on front-end form submissions?
An extra question / feature request
Given the situation encountered, is there a way to add a Loading Area to a standard (non-Ajax) contact form in CS Forms, so multiple submissions can never happen and that submitters can see that the form is working away?
Thanks,
Christopher