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
Keep the Entry Key typed on an earlier page of a multi-page Add New - #3609
Broken: On Entries → Add New for a multi-page form, an Entry Key typed on page 1 is lost on Next. Page 2 shows an empty box and the entry saves with a random key. FrmEntriesHelper::setup_new_vars() always set item_key to ''.
Changed:setup_new_vars() now reads the posted item_key (same sanitize_title the edit path uses). A reset form ($reset = true, shown again after a submit) still starts empty.
Verified: New test_setup_new_vars_keeps_posted_item_key. Red on the test-only commit (the only PHPUnit failure, 1 of 950). Green on the fix commit on PHP 7.4, 8.0, 8.2 and 8.4. Not driven in a browser here; the issue reporter tested the same one-line change on the Add New screen. Psalm red is the existing MissingPureAnnotation set; none of it is in the touched lines.
We reviewed changes in a0b9742...067ac4c 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.
The reason will be displayed to describe this comment to others. Learn more.
Approving: the fix is correct and I reproduced the bug before and after on a live Formidable Pro admin. One non-blocking hardening note inline (array input).
Live repro (Lite master vs this PR, Pro active, Entries > Add New on a 3-field form text / page break / text): posted page 1 with item_key=My Typed Key and clicked Next.
Base: page 2 renders <input type="text" name="item_key" value="" />. The typed key is lost.
This PR: page 2 renders value="my-typed-key".
Direct FrmEntriesHelper::setup_new_vars() on both: with $_POST['item_key'] set, base returns '' and the PR returns my-typed-key. $reset = true returns '', and with no POST it returns ''.
Not verified live: I did not run the PHPUnit test myself (CI PHPUnit is green on 7.4, 8.0, 8.2 and 8.4, and the PR description says red on the test-only commit). I also did not confirm the final save on page 2 stores the typed key. My scripted final POST created no entry, so that result is inconclusive. Psalm and DeepSource PHP are red; I did not check them against the touched lines.
Considered and dismissed: the frm_setup_new_entry filter and the later array_merge with $form->options overwriting the key. The live run with Pro active shows the key survives both. The front-end hidden item_key input was already '', so reading the posted value back does not widen what a visitor can already post.
The reason will be displayed to describe this comment to others. Learn more.
Non-blocking: get_post_param() returns an array when item_key is posted as an array (sanitize_value() sanitizes each element and keeps the array). Posting item_key[]=x makes $values['item_key'] an array, and classes/views/frm-entries/form.php lines 87 and 92 then call esc_attr( $values['item_key'] ) on it, which raises an "Array to string conversion" warning. Before this PR the value was always the string ''. I traced this in source and did not run it. Any front-end visitor can post that field. A small guard keeps the value a string. Replace the $values array start with:
The reason will be displayed to describe this comment to others. Learn more.
Non-blocking: unset( $_POST['item_key'] ) only runs if both earlier assertSame calls pass. A failing assertion leaves $_POST['item_key'] set for later tests in the same process. Move the cleanup into tear_down() (unset( $_POST['item_key'] );) or wrap the assertions in try/finally.
setup_new_vars() reads the posted key once into $posted_key and only uses it when ! $reset && is_string( $posted_key ), so an array posted as item_key falls back to '' and no longer reaches esc_attr(). The ternary groups as (! $reset && is_string(...)) ? $posted_key : '', so reset behaviour is unchanged.
The test gets a tearDown() that unsets $_POST['item_key'], plus an assertion that an array key comes back as ''.
'fields' => array() moved into the initial array (file-length limit).
What I ran
php -l on both changed files: clean.
Diff against master for classes/: still only FrmEntriesHelper::setup_new_vars(). The reset path and the page-2 keep-the-typed-key path from my earlier live before/after (master drops the key, the PR keeps it) are untouched by these commits.
CI: PHPUnit and the other jobs show skipping on this head, so the new assertion was not run by CI. Psalm is red, and it is also red on master. I did not run the new test locally and did not re-run the live repro on this head.
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#6891
Broken: On Entries → Add New for a multi-page form, an Entry Key typed on page 1 is lost on Next. Page 2 shows an empty box and the entry saves with a random key.
FrmEntriesHelper::setup_new_vars()always setitem_keyto''.Changed:
setup_new_vars()now reads the posteditem_key(samesanitize_titlethe edit path uses). A reset form ($reset = true, shown again after a submit) still starts empty.Verified: New
test_setup_new_vars_keeps_posted_item_key. Red on the test-only commit (the only PHPUnit failure, 1 of 950). Green on the fix commit on PHP 7.4, 8.0, 8.2 and 8.4. Not driven in a browser here; the issue reporter tested the same one-line change on the Add New screen. Psalm red is the existingMissingPureAnnotationset; none of it is in the touched lines.