I noticed when I uploaded Bricks 1.4 RC2 to WordPress to overwrite the 1.3.7 version, it prompts with a message afterwards on the Dashboard to regenerate the CSS. I started wondering why this isn’t done automatically. If one has updated to the newer version, I’d assume it’d be a better UX to have it auto-generate the inline CSS / external CSS files generated in Bricks.
19 Likes
Yes. I think it would be great. Later on, we can regenerate it when necessary.
3 Likes
Can we please have this added to Bricks soon, @thomas? This has become even more important with the more frequent weekly release cycles. Or is there a reason I’ve maybe overlooked that would discourage this improvement?
3 Likes
I’d really love to see this added sooner than later please, this is far more important now with the weekly/bi-weekly update schedule. 
2 Likes
Yes, this could be a problem. Especially if someone manages a lot of websites. At least there should be an option that we can choose to “easy update” and then regenerating CSS and maybe even flushing permalinks would be automatic (if necessary). Of course, having backups would be our responsibility and bricks can warn us before selecting this option.
Bricks could be the best “low maintenance builder” ever.
Would be great if it also works when moving a website to another host or changing domain.
1 Like
I’m surprised nobody has responded to this from the Bricks team yet, especially given how much more important this is given the more frequent update cycle (near-weekly). When admins have a dozen+ websites to update, it becomes an extra pain when needing to go update the CSS each time.
I know the Bricks team has more pressing priorities and everything, but I’d welcome the opportunity for this to be discussed further or to be added in the next few updates.
2 Likes
If auto CSS Regenerating is not doable, place a button next to the note. When clicking on it, the CSS regenerates without heading to the Bricks setting page(Zion did it this way now).
3 Likes
I wonder if there’s a hook I can utilize in the meantime to trigger a rebuild of the CSS…. ?
1 Like
Not sure. No idea about that.
Unfortunately this still hasn’t been implemented several months later. Seems like low-hanging fruit. Hoping this will be added soon. I’ve created a new feature request officially for it on the Ideas board, just pending approval. Will try to link it here when it’s published in the Ideas board.
1 Like
Would also love this added. Agencies have become accustomed to auto-updating plugins/themes in bulk using third-party software, so it would only make sense to allow css to be regenerated automatically, or at least give an option for us to choose if its automatically regenerated in settings.
We manage over 200 websites, and we are building all new clients on Bricks, while slowly transitioning older clients over to Bricks when we do design refreshes. This will quickly become a headache if we have to login and manually regenerate the css for each website.
4 Likes
On the idea board now for upvoting: https://bricksbuilder.io/ideas/#7195
I’d love to implement this but haven’t found a reliable way yet. Need to investigate more. Running it using the default WP hooks like upgrader_process_complete, doesn’t work as the new Bricks theme code is not yet available at that point in time (at least the last time I checked.
Next problem: Running into server timeout issues as generating the CSS for all posts, pages, theme styles, global elements, etc. easily takes longer than the server timeout.
2 Likes
Any word on this issue? It has almost been a year.
Have a few sites now using Bricks and I can’t update them through MainWP properly as I always have to go to the actual sites and regenerate the external css files.
1 Like
It’s not an ideal solution but could one possible solution be on a page load is adding a check to the external css files that will indicate the Bricks version they were last updated in.
If the version doesn’t match the current version then a updated css file can be generated.
Might I suggest looking for an option like WP-CLI command or setting up a CRON job?
After the plugin updates, or during the update cycle, it could make available a WP-CLI command or set up a CRON job. The CRON could help prevent timeout issues as it would simply run over and over and detect if the regeneration completed and continue on, and then delete itself when successful.
If there were a WP-CLI command, this could help bypass the timeouts and allows admins to run bulk commands across many sites if they have such tools. Or if there were a REST/API endpoint then we could custom script that in MainWP or other tools to call it after the bulk updates are done.
1 Like
For the time being, because it’s simply too much extra effort to regenerate manually after every update when managing a growing number of sites, I’ve tested with it being just inline, and honestly with inline and FlyingPress, the results are practically as good if not better in some cases.
With that said I know ideally it’d all be external files to help with the “remove unused css” recommendation, but that’s kind of where FlyingPress and WP Rocket can help too. And having seen a few bugs now that occur only when using external files, it makes me wonder if to some degree inline is the better option for now for users who also use something like FlyingPress or WP Rocket to remove unused CSS.
I still would like to see this improved though and hope that this comes soon as 1.8 or 1.8.1 
I am a user of MainWP for administrating my client sites in bulk and if it isn’t done automatically then I also vote with others above if there was somehow a way we can manually invoke it all from MainWP, that’d be ideal.
1 Like
@thomas how would I call that regeneration from a snippet for example? to play with myself to find limits and see how it goes if we can remotely call this function from a snippet we maybe able to do something
Check theme updates should work looking for the theme slug of bricks, is there a way to call this function remotely it wont fix the time out issue but will allow me to do some testing?
Yay!! Super happy to see that. I’ll have to slowly swap my client sites back to External Files now since that’s generally more performant than Inline.
1 Like
I’m happy to see that too. 