You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Restore hidden action field on the Global Settings form - #3598
Since 7.0, Global Settings for several add-ons don't save (Kit/ConvertKit, Constant Contact, Geo, Quizzes). Commit 04702c5 ("Fix e2e test") removed the hidden action=process-form field from the settings form. Lite's own FrmSettingsController::route() reads frm_action first, so Lite settings still saved. Those add-ons read only action, so they re-rendered the form and saved nothing.
What changed
Put the hidden action=process-form field back in classes/views/frm-settings/form.php. The MCP tab's download and revoke buttons use name="action". They come later in the form, so their value still wins, and admin-post.php still gets the right action.
A PHPUnit test renders the settings form and checks that both hidden fields are there.
How it was checked
CI PHPUnit (run tests), all four PHP jobs:
Test alone (cc53695): fails, 1 failure, the missing action field.
We reviewed changes in 4dfb036...a7243d2 on this pull request. Below is the summary for the review, and you can see the individual issues we found as inline review comments.
AI Review is run only on demand for your team. We're only showing results of static analysis review right now. To trigger AI Review, comment @deepsourcebot review on this thread.
Add-ons read 'action' (not 'frm_action') in their settings routes, so
removing it in 04702c5 stopped them from saving.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
The reason will be displayed to describe this comment to others. Learn more.
Approve. The one-line restore is correct and matches what the issue (formidable-pro#6851) describes.
Repro by HTTP fetch of the rendered settings page (Lite on a WordPress Playground env, base 1927ae3 vs PR head f276cb1). This was not exercised in a browser and there is no screenshot; the evidence is the rendered HTML only:
Base: the Global Settings form renders only <input type="hidden" name="frm_action" value="process-form"/>. No action field, so an add-on route that reads only action falls through to display_form().
PR: the form renders both frm_action and action hidden inputs.
The MCP tab's download/revoke buttons (name="action", formaction=admin-post.php) sit in the same form, after the hidden field (form.php:29 vs. mcp.php:155/:203), so their value is submitted last and still wins in PHP.
Test:test_display_form_includes_action_field_for_add_ons is not hollow. The author's linked CI run on the test-only commit cc53695 fails PHPUnit and the run on 851ba4e passes; I confirmed both runs exist at those SHAs. Current CI is green on PHPUnit 7.4/8.0/8.2/8.4 and Psalm. DeepSource's PHP check is failing; that is static analysis, not a required check.
Not verified (so this doesn't read as more than it is):
Not exercised in a browser: I did not click Update or the MCP buttons, and no screenshot was taken. The "last value wins" point comes from reading the markup and PHP's last-value rule, not from a captured submit.
I did not run any of the affected add-ons (Kit, Constant Contact, Geo, Quizzes, Salesforce). Their Update-saves-the-value path is traced from the issue, not clicked through. A human should confirm one of them saves after this lands.
The Cypress E2E job was skipping on this PR. 04702c59a ("Fix e2e test") removed this same line together with the wp_nonce_field(..., false) and autocomplete="off" changes, and neither the commit nor the PR says which e2e failure the removal fixed. The other two changes are untouched here and are the likelier fix for the HTML-validation/a11y specs on this page, but I could not confirm that. Worth letting the Cypress shards run once before release, especially admin-html-validation and admin-a11y for formidable-settings.
Ran the Cypress shards, as the review suggested. Shard 2 failed: admin-html-validation on the Global Settings page, form-dup-name "Duplicate form control name action". The restored hidden action field and the MCP buttons' action share a name. That is the clash 04702c59a removed the field for.
The names have to stay: admin-post reads action from the button, and the hidden field is what the add-ons read. Pushed a7243d2 turning off form-dup-name for that one page test, with a comment. All 4 shards, PHPUnit, and analysis jobs are now green. DeepSource PHP is still red, as before.
Not done: I did not click Update or the MCP buttons in a browser.
The reason will be displayed to describe this comment to others. Learn more.
Approve, re-review at a7243d2. The one-line fix and its test are unchanged from my earlier approval at f276cb1. The only new commit is the Cypress config change.
The gap I flagged last time is closed. The Cypress job was skipping then. It has now run: all four shards, including shard 2 (admin-html-validation), plus PHPUnit 7.4/8.0/8.2/8.4 and Psalm are green on this head. Shard 2 failing on form-dup-name ("Duplicate form control name action") is what I expected, since the MCP buttons and the restored hidden field both use action.
The form-dup-name opt-out is the right fix. It is scoped to the one Check the global settings page has valid HTML test and has a comment saying why. The shared name is required: the add-ons read action, and the MCP buttons' formaction=admin-post.php needs name="action". The buttons come later in the form, so their value is submitted last and wins.
Still not done, same as the author says: nobody has clicked Update or the MCP buttons in a browser, and I did not run an add-on's save path. A human should confirm that one add-on (Kit, Constant Contact, Salesforce, ...) saves its settings after this lands. DeepSource PHP is still red; it is static analysis and not a required check.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes Strategy11/formidable-pro#6851
What was broken
Since 7.0, Global Settings for several add-ons don't save (Kit/ConvertKit, Constant Contact, Geo, Quizzes). Commit 04702c5 ("Fix e2e test") removed the hidden
action=process-formfield from the settings form. Lite's ownFrmSettingsController::route()readsfrm_actionfirst, so Lite settings still saved. Those add-ons read onlyaction, so they re-rendered the form and saved nothing.What changed
Put the hidden
action=process-formfield back inclasses/views/frm-settings/form.php. The MCP tab's download and revoke buttons usename="action". They come later in the form, so their value still wins, andadmin-post.phpstill gets the right action.A PHPUnit test renders the settings form and checks that both hidden fields are there.
How it was checked
CI PHPUnit (
run tests), all four PHP jobs:actionfield.Not tried in a browser. The MCP-tab buttons still send their own
actionafter the hidden field, so the last value wins as before.🤖 Generated with Claude Code