Layout grid: Please update wordpress plugin?

[keeslina]

When looking in the repository, i see the Layout Grid block uses a constants.scss file to dynamically set grid columns (desk,tablet,mobile) and breakpoints. When will this be integrated in the Wordpress plugin that is published on wordpress.org?

For now i tweaked the style.css, doesn't seem like the right way.

[KZeni]

Hmm... https://github.com/Automattic/block-experiments/tree/master/blocks/layout-grid shows the last update to the files was on June 14th. Meanwhile, https://wordpress.org/plugins/layout-grid/ shows the last update to the plugin was June 16th. So it's not like any more recent changes have been made here on GH that aren't then on the WP.org plugin (with the WP.org plugin being the most recent thing to be updated.)

At that point, these SCSS files are all that's used to generate the final style.css & editor.css files that are actually what's used as the styles for the block for the public page & in the editor, respectively.

What benefit would there be in having the SCSS files (you'd need them all; not just constants.scss) in the public plugin? It's not like web browsers interface with the SCSS files directly or anything... they need to be compiled and saved out as the CSS (which has been done & is what's in the plugin now.) It's like asking for development files that are then not used by the plugin at that point to be included in the plugin... it just adds unnecessary bloat (again, we want the final output/production file that's generated from the development files while the dev files aren't needed at that point). Similar to how this GH repo doesn't have the CSS files present since we only care about the development files (SCSS) that are used to generate the output for the final plugin.

If you're wanting to change the breakpoint of columns by manually editing a plugin file (ex. edit the SCSS to have new breakpoints to then generate new style.css & editor.css files)... just know you're kinda breaking a major rule of working with WordPress... you should never edit the WP core, plugins, themes, etc. that you aren't the owner/maintainer on that isn't something like a fix/enhancement/patch that's then relayed to the original developer to then implement officially in the next version (definitely when it's something specific to your own site where others might want something different). That's due to the fact that any future updates (you should always keep everything up-to-date for security & other reasons) will overwrite your change so you're either needing to re-implement your edit every time a plugin update is made or you're needing to keep that plugin out-of-date so it retains the edits made to it (again, neither are ideal while changing the breakpoints other than what the defaults are [when the defaults meet the majority of people's needs] isn't something the future plugin update will want to implement.) That's definitely a request/behavior that plugin devs won't ever support as it's something that really shouldn't be done.

What it seems like you should be asking for instead

It seems like you should actually be asking for there to be a setting in the site admin (be it site-wide or for each individual layout grid block) which lets you set these breakpoints. At that point, the plugin actually just has the SCSS files in it while anytime these breakpoint settings are changed it ends up re-compiling the resulting CSS file (you still won't ever interact with the SCSS files directly; this is something the plugin would do) that's used to have the updated breakpoint values (resulting CSS file then likely better off to be located somewhere in wp-content/uploads as plugin files should ideally be kept static [updating the plugin shouldn't mean losing the CSS output file among other reasons] while it seems the best practice is to then just have the compiled CSS output files be in the uploads folder somewhere [probably in a folder of its own since there's style.css and editor.css that would need to be generated.])

This is entirely different (and, again, seems to be what you actually want; keeping your goal in mind of being able to change the breakpoints for specific site needs) when compared to "Please update wordpress plugin?" (which should probably look to be more descriptive in the future... any/all requests can be titled something to the effect of "make an update to the plugin" which makes this title effectively give no details regarding the actual request) and what appears to be asking for the development files to be included in the production files so you can make manual edits to the plugin files on your site (which, again, shouldn't be something that's ever done per the WordPress ecosystem best practice [especially when it's just to customize things specific to your site.])

Alternatively / in the meantime, it could be possible to have your own custom theme CSS (or via some other way you might be managing/updating your site's custom CSS [ex. Appearance => Customize => Additional CSS]; again, since you shouldn't edit themes you don't own/maintain [hence why child themes & everything are a thing when using someone else's theme]) where that custom CSS is made so it then overwrites all the various places the breakpoints are used by using selectors that take priority by being more specific than what's in this plugin's CSS (or use !important, if in a pinch [while this should generally be kept to a minimum when possible.]) Now, this does result in more code being used by the site, but it's worth it to be able to keep your plugins up-to-date & not need to re-apply edits made to a plugin's files (while then not having a better way of doing so for now [eventually having this added as a setting in the site admin as described above, ideally.]) Also, using a performance plugin that minifies/combines CSS files on your site could potentially identify which selector takes priority and make it so the actual code given to the visitor is nearly the same & it just uses what you provided to overwrite the default breakpoints.