What happens
The master gulpfile's minifyCss task reads config.css.src (for Page Builder: css/**/*.css) from the plugin working tree. Compiled CSS files are gitignored in the plugin repos; they only exist locally after a dev has run build:dev (or the standalone less/sass tasks), whose dev-mode dest is the working tree.
On a fresh clone those files do not exist, so minifyCss finds only pre-minified vendor files (for Page Builder: css/lib/select2.min.css and one other), and build:release completes without error while producing a zip missing nearly all .min.css files.
Release builds stamp SITEORIGIN_PANELS_CSS_SUFFIX (and equivalents) to .min, so the shipped plugin enqueues admin.min.css, dashboard.min.css, front-flex.min.css and so on, which 404. Symptoms: the Page Builder admin editor renders unstyled (bare links, no panels UI) and front-end layout CSS is missing.
The less task is not a substitute inside build:release: in release mode its dest is tmp/ only, and minifyCss never looks in tmp/, so the compiled files are copied into the zip unminified while the .min variants the PHP requests are absent.
How this was found
Building siteorigin-panels 2.36.1-beta.1. The first beta zip built from a fresh clone had 2 .min.css files instead of 8, and the Page Builder admin editor rendered unstyled. Rebuilding after a one-off gulp less produced a correct zip — all 8 .min.css present, zero asset 404s across the front end and wp-admin, confirmed by a scripted audit of every suffix-generated asset reference against disk.
Why it matters
The failure is silent. build:release exits 0 and the zip looks plausible. Any release built from CI or a fresh checkout would ship broken styling.
Workaround
Run gulp less (and gulp sass where applicable) before gulp build:release on a fresh clone. Verified.
Suggested fix directions
- Make
minifyCss depend on the less/sass output in release mode, reading from tmp/ where the release-mode less task writes, instead of the working tree.
- Or have
build:release fail loudly when config.css.src matches fewer files than the LESS/SASS sources imply — a sanity count check.
- Or document and enforce that
build:release runs the dev-mode compile first.
Environment
Node 10.24.1 (nvm, x64 under Rosetta), plugin-build master, siteorigin-panels develop on a fresh clone. Reproduced deterministically; not machine-specific.
Scope note
Observed on the master branch (the gulp 3 build used by Page Builder). The feature/gulp5-update branch was not checked and should be verified before assuming it is affected — a companion build on that branch produced all 124 minified assets correctly from a fresh clone, which suggests gulp 5 may not be affected, but this was not explicitly audited.
What happens
The master gulpfile's
minifyCsstask readsconfig.css.src(for Page Builder:css/**/*.css) from the plugin working tree. Compiled CSS files are gitignored in the plugin repos; they only exist locally after a dev has runbuild:dev(or the standaloneless/sasstasks), whose dev-mode dest is the working tree.On a fresh clone those files do not exist, so
minifyCssfinds only pre-minified vendor files (for Page Builder:css/lib/select2.min.cssand one other), andbuild:releasecompletes without error while producing a zip missing nearly all.min.cssfiles.Release builds stamp
SITEORIGIN_PANELS_CSS_SUFFIX(and equivalents) to.min, so the shipped plugin enqueuesadmin.min.css,dashboard.min.css,front-flex.min.cssand so on, which 404. Symptoms: the Page Builder admin editor renders unstyled (bare links, no panels UI) and front-end layout CSS is missing.The
lesstask is not a substitute insidebuild:release: in release mode its dest istmp/only, andminifyCssnever looks intmp/, so the compiled files are copied into the zip unminified while the.minvariants the PHP requests are absent.How this was found
Building
siteorigin-panels2.36.1-beta.1. The first beta zip built from a fresh clone had 2.min.cssfiles instead of 8, and the Page Builder admin editor rendered unstyled. Rebuilding after a one-offgulp lessproduced a correct zip — all 8.min.csspresent, zero asset 404s across the front end and wp-admin, confirmed by a scripted audit of every suffix-generated asset reference against disk.Why it matters
The failure is silent.
build:releaseexits 0 and the zip looks plausible. Any release built from CI or a fresh checkout would ship broken styling.Workaround
Run
gulp less(andgulp sasswhere applicable) beforegulp build:releaseon a fresh clone. Verified.Suggested fix directions
minifyCssdepend on theless/sassoutput in release mode, reading fromtmp/where the release-modelesstask writes, instead of the working tree.build:releasefail loudly whenconfig.css.srcmatches fewer files than the LESS/SASS sources imply — a sanity count check.build:releaseruns the dev-mode compile first.Environment
Node 10.24.1 (nvm, x64 under Rosetta),
plugin-buildmaster,siteorigin-panelsdevelop on a fresh clone. Reproduced deterministically; not machine-specific.Scope note
Observed on the master branch (the gulp 3 build used by Page Builder). The
feature/gulp5-updatebranch was not checked and should be verified before assuming it is affected — a companion build on that branch produced all 124 minified assets correctly from a fresh clone, which suggests gulp 5 may not be affected, but this was not explicitly audited.