I have conducted further investigation and verified the following (now Frontend Admin Free v3.28.15).
When “Save Form Submissions” is disabled in the Actions tab, forms fail to submit properly and display a generic error message instead of the configured success message, despite data being correctly saved to the post.
Bug Description
The form submission process fails when “Save Form Submissions” is disabled in the Actions tab settings, even though the form data is successfully saved to the target post. The user receives a generic error message (“An error occurred. Please try again later.”) instead of the custom success message configured in the Actions tab. Steps to Reproduce
- Create a form with Frontend Admin Free
- Configure the form to save custom fields to a Post
- In Actions tab: Set custom success message (“Dati salvati con successo.”)
- In Actions tab: Disable “Save Form Submissions” toggle
- In Submissions tab: Set “Save Custom Fields to…” to “Post”
- Submit the form from frontend
Expected Behavior
- Form should submit successfully
- Custom success message should be displayed
- Data should be saved to the post (without creating form submissions)
Actual Behavior
- Generic error message is displayed: “An error occurred. Please try again later.”
- Form data IS correctly saved to the post
- Browser console shows successful HTTP 200 response
- AJAX response contains conflicting data
Technical Details Console Response Analysis
The AJAX response shows two consecutive responses:
First response (successful):
{"success":true,"data":{"valid":1,"errors":0}}
Second response (problematic):
Form not found.Did you erase it?{
"success": true,
"data": {
"to_top": true,
"form_element": "form_6865a88f0607a",
"success_message": "Dati salvati con successo.",
"location": "current",
"submission": null,
"submission_title": "7ª Tappa Trofeo 4 Regioni Challenge Pony Mounted Games",
"close_modal": 1
}
}
The message “Form not found.Did you erase it?” appears between the two JSON responses, suggesting the plugin is attempting to process the form twice. Workaround Found
Temporary Solution: Enabling “Save Form Submissions” in the Actions tab resolves the issue and displays the correct success message. However, this creates unnecessary database overhead as form submissions are stored when not needed. Root Cause Analysis
The plugin appears to be attempting a double processing of the form:
- First processing: Successfully saves data to post
- Second processing: Attempts to handle form submission (despite being disabled) and fails with “Form not found” error
This suggests that the “Save Form Submissions” toggle is not properly respected when custom fields are being saved to posts. Impact
- User experience is degraded (error message instead of success message)
- Confusion for form users who don’t realize their submission was successful
- Forces users to enable unnecessary form submissions for proper functionality
Suggested Fix
The plugin should properly handle the case where “Save Form Submissions” is disabled while still allowing custom fields to be saved to posts, without attempting to process form submissions in the background. Additional Information
This issue appears to be specific to the interaction between:
- Actions tab: “Save Form Submissions” disabled
- Submissions tab: “Save Custom Fields to…” set to “Post”
The bug does not occur when both settings are aligned (both enabled or using different configurations).