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
Fix inline Submit button sitting below the inputs with frm_flex submit HTML - #3613
With Submit Button Position set to Inline and top labels, the Submit button sat 17px below the inputs when the form used the default submit HTML (<div class="frm_submit frm_flex">). Forms with the old <div class="frm_submit"> lined up fine.
The hidden ::before spacer is a flex item in the wrapping frm_flex row, so it no longer sits above the button. align-items: center then centers the button against the spacer.
What changed
css/custom_theme.css.php: for an inline submit that uses frm_flex, the spacer takes a full row and the items start at the top with no row gap. order: -2 keeps the spacer first when Pro puts Previous (order: -1) in the same row.
How it was verified
Lite + Pro in a local preview env, forms with two frm4 fields and the inline submit. Button top minus input top:
before
after
default HTML, 1400px
17.05px
0px
default HTML, 700px
17.05px
0px
old HTML (frm_submit)
0px
0px
Before:
After:
Multi-page form, page 2 (Previous + Submit), top offset from the input top. Before: Previous -26px, Submit 37.8px. After: Previous 0px, Submit 34px. They stack because the cell is narrow; that is the same before and after.
No automated test: frm_flex only becomes a flex row with Pro active, and Lite's CI has no Pro.
The ::before spacer was a flex item in the wrapping row and the button was
centered against it. Make the spacer a full row and pin items to the top.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.
Use the checkbox below for a quick retry:
Trigger review
Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Tip
🎯 Customize your risk assessments
Guide how CodeRabbit assesses merge risk and security architecture risk. Highlight sensitive changes and explain your security boundaries using Merge Risk Instructions and Security Risk Instructions in your review settings. Security architecture risk assessments require the Advanced plan or above.
✅ Automatic approvals, with your rules
Let CodeRabbit approve pull requests once required threads are resolved, pre-merge checks pass, and your risk limits are met. Enable Automatic approvals in review settings, with overrides for teams or file paths.
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
We reviewed changes in d31ea91...64497ad on this pull request. Below is the summary for the review, and you can see the individual issues we found as inline review comments.
Some issues found as part of this review are outside of the diff in this pull request and aren't shown in the inline review comments due to GitHub's API limitations. You can see those issues on the DeepSource dashboard.
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 works and I reproduced it live. One small non-blocking note on row-gap: 0, inline below.
Repro (Lite master vs. this PR, Pro active, two frm4 fields, top labels, inline submit, default frm_submit frm_flex HTML): button top minus input top was 17.05px on master and is 0px on this branch. At 1400px and 700px wide. The old frm_submit markup stays at ~0px both before and after. Computed styles on the branch: spacer flex-basis: 100%, order: -2; wrapper align-items: flex-start, row-gap: 0.
After, single page:
After, multi-page form page 2 (Previous top 0px, Submit 34px; they stack because the cell is narrow, same as before the PR):
Not exercised: the second selector (frm_inline_submit in the submit HTML without frm_inline_top), and non-default Style settings. Checked by reading it, not rendering it. Psalm is red, but master's last two runs are red too (stripe/ files, nothing in this diff).
The reason will be displayed to describe this comment to others. Learn more.
Non-blocking. row-gap: 0 also removes the ~1.9px gap that used to separate Previous and Submit when they wrap onto two rows. On page 2 of a multi-page form I measured the stacked buttons as 0px apart after this PR (the screenshot above shows them touching). The 0 is needed to keep the spacer from pushing the buttons down, so if you want the separation back, put it on the buttons instead, for example a small margin-bottom on .frm_prev_page inside this selector scope. Fine to leave if you'd rather not touch it.
The reason will be displayed to describe this comment to others. Learn more.
Leaving it. A margin-bottom on the Previous button would also grow the row in the common side-by-side layout, and the 2px only showed up when the buttons wrap, which is the narrow-cell case that stacked before too.
Agreed, leaving row-gap: 0 as is. The 2px only appears when the buttons wrap in a narrow cell, which already stacked before this PR, and a margin on Previous would grow the common side-by-side row. My Approve at df6754b stands.
Added a PHPUnit test, test_FrmStyle::test_generated_css_aligns_inline_flex_submit_with_inputs (commit e404c85). The layout itself needs Pro to render, but the generated stylesheet does not: the test renders custom_theme.css.php through FrmStyle::get_css_content() and asserts the inline frm_flex submit row gets align-items: flex-start and the ::before spacer gets flex-basis: 100%; order: -2. It fails against master CSS and passes on this branch.
Also merged master. test_FrmStyle passes (29 tests) and phpcs (Lite ruleset) is clean.
With inside (floating) labels the input is offset by the container's padding-top, not a label's height, so the hidden ::before spacer pushed the Submit button about 8px below the inputs. Add a frm_inline_inside class when the last input field uses an inside label and size the spacer to that padding.
Refs Strategy11/formidable-pro#6894
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
@garretlaxton thanks. I reproduced your second screenshot (placeholder/inside labels): the button sat 8px below the inputs (19px on master). Inside labels have no label above the input, just padding-top: 0.5 × field height, so the label-sized spacer was too tall. d71c44c adds a frm_inline_inside class and sizes the spacer to that padding. Measured at 1400px and 700px, button top minus input top is now 0px for both top labels and inside labels.
I could not reproduce your first screenshot (top labels, white pill button, button about 10px above the input). Top labels measure 0px here with the default style. To track it down, could you tell me:
which style the form uses (or the label/field font size, line height and button size in it), and whether the page was the front end or the admin preview
whether you re-saved a style after switching to this branch. The generated formidableforms.css is only rebuilt on a style save or plugin update, so stale CSS gives misleading results.
Not run locally: the two new PHPUnit assertions (the shared harness had another PHPUnit run in progress). CI will be the first run. Hidden labels (frm_inline_top, no label rendered) are untested.
CI on 64497ad: analysis jobs pass. PHPUnit jobs fail at "sudo /etc/init.d/mysql start: command not found" (runner setup, before any test runs), so the two new assertions are still unverified by CI. DeepSource's "method not defined" notes on the assert calls are false positives, same as on the existing test.
The reason will be displayed to describe this comment to others. Learn more.
Approving at 64497ad. I re-ran the whole PR live, and the new inside-labels fix works.
Repro (Lite master vs. this PR, Pro active, two frm4 fields, inline submit, default frm_submit frm_flex HTML, generated CSS rebuilt for each checkout, fresh browser session each time). Button top minus input top:
Label position
master
this PR
top
17.05px
0px
inside
19px
0px
hidden
17.05px
0px
After, top labels:
After, inside labels:
Same numbers at 1400px and 700px wide. On the PR, form classes are frm_inline_top for top and hidden, and frm_inline_top frm_inline_inside for inside only. The inside spacer is 18px against 21px for the others.
Non-blocking: the spacer's line-height is not tied to the label's._single_theme.css.php:325 sizes the ::before spacer from --font-size and --label-padding, but its line-height is inherited from .frm_submit, not from .frm_primary_label. If a style or theme gives the label a different line-height from the form container, the button lands off the input. I forced it in the browser on the top-label form: label line-height: 1.8 with the form at 1.3 put the button 7.5px above the input; a shorter label line-height than the form's (with a 20px font) put it 10px below. The first screenshot from @garretlaxton (button about 10px above, top labels) fits that pattern. I could not confirm it is their cause, and Vivi's question about their style is still open. The mechanism was already there before this PR and the default style is fine.
Not verified: the new PHPUnit assertions. CI's PHPUnit jobs fail at runner setup (sudo /etc/init.d/mysql start) and I did not run them locally. The form class output they cover was checked live above. The second selector (frm_inline_submit in custom submit HTML without frm_inline_top) and non-default styles were not rendered. Review skills not run (small CSS/helper diff, measured live instead).
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#6894
What was broken
With Submit Button Position set to Inline and top labels, the Submit button sat 17px below the inputs when the form used the default submit HTML (
<div class="frm_submit frm_flex">). Forms with the old<div class="frm_submit">lined up fine.The hidden
::beforespacer is a flex item in the wrappingfrm_flexrow, so it no longer sits above the button.align-items: centerthen centers the button against the spacer.What changed
css/custom_theme.css.php: for an inline submit that usesfrm_flex, the spacer takes a full row and the items start at the top with no row gap.order: -2keeps the spacer first when Pro puts Previous (order: -1) in the same row.How it was verified
Lite + Pro in a local preview env, forms with two
frm4fields and the inline submit. Button top minus input top:frm_submit)Before:
After:
Multi-page form, page 2 (Previous + Submit), top offset from the input top. Before: Previous -26px, Submit 37.8px. After: Previous 0px, Submit 34px. They stack because the cell is narrow; that is the same before and after.
No automated test:
frm_flexonly becomes a flex row with Pro active, and Lite's CI has no Pro.🤖 Generated with Claude Code