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
css/formidableforms.css was excluded from both .stylelintrc.json's ignoreFiles and .gitignore because it's rendered at runtime, not a build artifact — there was nothing on disk for stylelint to check.
What changed
Boot wp-env in the stylelint job and generate css/formidableforms.css via wp eval-file bin/generate-default-stylesheet.php, before stylelint runs. The script calls FrmStyle::save_settings() — the plugin's own static-file generator, the same method a real save of the Styles settings triggers — rather than reimplementing its render logic.
Drop **/css/formidableforms.css from .stylelintrc.json's ignoreFiles now that it has real content.
The generator script lives in bin/, not tests/: phpcs.xml, phpstan.neon, psalm.xml, and rector.php all skip bin/ entirely (and mago.toml too), while tests/ is in scope for at least mago/rector. Keeps this CI-only utility script out of analysis tools it isn't meant for, matching bin/set-php-version.php.
How it was verified
Confirmed via a local WordPress Playground instance (formidable-preview-env) that (new FrmStyle())->save_settings() produces a complete, well-formed css/formidableforms.css (43KB, no empty declarations or malformed values) on a fresh install with no saved customizations — matching what a real Styles-page save produces.
The wp-env/wp eval-file step itself, and stylelint's actual pass/fail against the generated file, are verified by this PR's own CI run (labeled run analysis) — no local install was run against the real workflow given this repo's own CI is the source of truth here.
Refs Strategy11/formidable-pro#6684 (closed manually once this merges — cross-repo closing keywords don't auto-close).
css/formidableforms.css was excluded from stylelint because it's rendered
at runtime (FrmStylesController::load_css()), not a build artifact -
there was nothing on disk to lint. Boot wp-env in the stylelint job and
generate it from the default style settings via `wp eval-file` before
linting, then drop the ignoreFiles exclusion.
wp eval-file avoids admin-ajax.php's one-time onboarding-wizard
admin_init redirect entirely (it's a CLI request, not an admin one). The
generator also sets $_GET['flat'], matching the one real caller of
load_css() (FrmStylesController::enqueue_css()) - without it,
FrmStylesHelper::get_settings_for_output() takes a different branch that
leaves several settings (e.g. text_color) unset, producing invalid CSS
like `color: ;`.
Refs Strategy11/formidable-pro#6684
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
We reviewed changes in 77c14e0...b0d9b32 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 previous version hand-rolled a render of _single_theme.css.php only
(the per-style block), which is missing the base stylesheet the issue
actually asked for and that stylelint needs to check
(custom_theme.css.php's own rules, floating labels, grids, media
queries). FrmStyle::save_settings() is the plugin's own static-file
generator for exactly this - the same method a real save of the Styles
settings triggers - so call that instead of reimplementing its render
path by hand.
Also move the script from tests/bin/ to bin/: phpcs.xml, phpstan.neon,
psalm.xml, rector.php, and mago.toml all skip bin/ entirely, while
tests/ is in scope for at least mago and rector. bin/ keeps this
CI-only utility script out of the analysis tools it isn't meant for,
matching how bin/set-php-version.php is already handled.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
wp eval-file bin/generate-default-stylesheet.php failed in CI ("does
not exist") - the cli container's working directory is the WordPress
root, not this plugin's checkout, so a checkout-relative path doesn't
resolve. Use `wp eval` with FrmAppHelper::plugin_path() (available once
WP-CLI bootstraps the active plugin) to locate the script instead of
guessing the mounted folder name.
Also verify save_settings() actually wrote the file where stylelint
will look before reporting success - it can resolve to the uploads dir
instead of the plugin's own css/ folder depending on file-mod
permissions, which would otherwise pass silently with nothing linted.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Checked the 400 stylelint errors from this run (job 105337363146): none are real CSS bugs. Every single one lands on line 2 because css/formidableforms.css (generated by FrmStyle::save_settings()) is one unbroken minified line, and the violations are all cosmetic notation rules that only fire because of that — length-zero-no-unit (0px vs 0), color-hex-length (6-digit vs 3-digit hex), rule-empty-line-before/at-rule-empty-line-before (blank-line convention), selector-attribute-quotes ([type=text] vs [type="text"]), selector-pseudo-element-colon-notation (:before vs ::before), font-weight-notation (normal/bold vs 400/700). One item worth a second look, not a confirmed bug: a block-no-empty hit at col 13626 (an empty rule block) — probably intentional generator output, but worth confirming it's not a stray/broken selector.
Since this file is only ever machine-generated, reformatting it before stylelint runs (whitespace only, no token changes) would make future runs attribute errors to real lines instead of one column offset into a wall of text — worth it purely for triage-ability, not to make this run pass. Suggested addition to .github/workflows/stylelint.yml, right after the "Generate default stylesheet for lint coverage" step:
- name: Reformat generated stylesheet for readable line numbersrun: npx prettier --parser css --write css/formidableforms.css
prettier isn't a declared dependency, but neither is stylelint itself in this same workflow (both resolve via npx on demand) — same pattern, no new dependency to add. Prettier only reflows whitespace/line breaks for CSS; it doesn't rewrite values, so none of the 400 findings above get silently fixed or hidden by this — they'd just each land on their own real line.
@vivi-the-going-merry — flagging since this PR is yours; happy to open a follow-up PR with this if useful 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.
![deepsource-io[bot]](https://avatars.githubusercontent.com/in/16372?s=60&v=4){kind=small}
What was broken
css/formidableforms.csswas excluded from both.stylelintrc.json'signoreFilesand.gitignorebecause it's rendered at runtime, not a build artifact — there was nothing on disk for stylelint to check.What changed
wp-envin the stylelint job and generatecss/formidableforms.cssviawp eval-file bin/generate-default-stylesheet.php, before stylelint runs. The script callsFrmStyle::save_settings()— the plugin's own static-file generator, the same method a real save of the Styles settings triggers — rather than reimplementing its render logic.**/css/formidableforms.cssfrom.stylelintrc.json'signoreFilesnow that it has real content.bin/, nottests/:phpcs.xml,phpstan.neon,psalm.xml, andrector.phpall skipbin/entirely (andmago.tomltoo), whiletests/is in scope for at leastmago/rector. Keeps this CI-only utility script out of analysis tools it isn't meant for, matchingbin/set-php-version.php.How it was verified
Confirmed via a local WordPress Playground instance (
formidable-preview-env) that(new FrmStyle())->save_settings()produces a complete, well-formedcss/formidableforms.css(43KB, no empty declarations or malformed values) on a fresh install with no saved customizations — matching what a real Styles-page save produces.The
wp-env/wp eval-filestep itself, and stylelint's actual pass/fail against the generated file, are verified by this PR's own CI run (labeledrun analysis) — no local install was run against the real workflow given this repo's own CI is the source of truth here.Refs Strategy11/formidable-pro#6684 (closed manually once this merges — cross-repo closing keywords don't auto-close).