Sage 10.0.0-beta.2 released

:eyes: What’s the path to the css file you’re modifying? Out of the box it should be working with app.css

Mmmh I didn’t move the css. I am trying things and it happens only inside a wp page, and the devTools says:

Using the css watch avoids this, but it seems like a dirty patch.

Another issue that I found:

In the wordpress backend, if you go to the widgets page, whoops throws an error of Wordpress:
wp_enqueue_script() has been called incorrectly. "wp-editor" script should not be enqueued together with the new widgets editor (wp-edit-widgets or wp-customize-widgets).

It seems that the editor enqueueing is the responsible (setup.php:26).

:+1: Thanks, filed a bug: Bug: Fatal error on wp-admin widgets · Issue #2919 · roots/sage · GitHub

:+1: Thanks, filed a bug for this as well! Bug: Bud HMR not working as expected outside of front page · Issue #2920 · roots/sage · GitHub

I love the new beta :slight_smile: It works nicely. Are the terminal notifications gone? I loved that a lot during development. I now miss the error push notifications and the compile complete push notifications. Is there a way to enable this?


With last version, i have not CSS loaded in my proxy link.
In normal it’s OK.

I can see an error when i’m refreshing url :

“cannot set header after they are send to the client”


Thanks for filing the bugs! I have another minor issue that I am not sure if it’s sage related or wordpress related but it affects the workflow.

When I filter the menu to use img instead of text, the asset()->uri gives me the proxy instead of the localhost:3000 address and this forces me to “unsafely” access the url to see the images. I don’t quite understand why this happens as outside of the filter it gives the localhost:3000 address.

add_filter( 'wp_nav_menu_items', function ( $items ) {
    $asset = asset('assets/images/profile.svg')->uri();
    echo $asset; //<- this returns http://localhost:3000/

    $items = str_replace(
        '<img class="h-7 w-auto ls:hidden" src="' . $asset . '" alt="">',
    ); //<- this returns https://proxy.test/

    return $items;

Can it be uri sanitization inside the navwalker?

I might have found another quirk. I’ve added the @roots/bud-sass package to, well, runs sass. I took me a while to notice it. Every now and then It renders a change, but the changes do not take place in the site. The console throws no errors. Say I have a red background for the body, and I change the css to a blue background. In the frontend it stays red in the inline styles. The terminal renders successful. Both on yarn dev and yarn build.

I’ve found a workaround for now. In the package.json I’ve changed the script to "dev": "yarn bud clean && bud dev", to clear the bud cache.

The problem is that I cannot re-create this behavior. For example, I did not got it to work for 3 hours yesterday, put the computer on sleep and re-opened it today and it rendered successfully, with no changes to the code. The browser is set to not cache items.

:purple_heart: thanks for the feedback! @kellymears has a better understanding of what’s going on with the desktop notifications, but I opened up an issue so we can at least track the bug over here:


  1. What’s your local development URL/hostname (not the proxy, your main hostname)?
  2. Have you made any changes to the Bud config?
  3. You said last version, but can you please confirm the specific version of Bud you’re using?

Do you mind creating a bug report or at least splitting this out into a new topic for discussion?

:thinking: this is odd. If you can figure out a way to reproduce it more often, then can you please either file a bug report or open a new topic for discussion?


  1. My local url is : (i’m using Lando)
  2. I just updated the URL for the proxy.
  3. Last version : 10.0.0-dev (when i made test yesterday, i had the last commit).

Precision : i’m using bedrock structure.

And command for install sage :

composer create-project roots/sage your-theme-name dev-main


Now I found a more critical one. The localization functions aren’t available to the pot file generator: Bug: blade files cannot be localized (Sage 10-beta.2) · Issue #2929 · roots/sage · GitHub

1 Like

One question, Ben, as I can see, most of the bugs from beta 2 come from bud. To keep posting bugs, but still use the theme in real projects, can I install laravel-mix too for stability?

I guess it only needs to be in package.json, and copy the same webpack config as in beta 1. Is there something more I have to take into consideration?


1 Like

Absolutely. Laravel Mix is still a great tool and this is the first time Bud has been seeing real world usage outside of a few folks, so the bugs are coming out and getting fixed :smiley:

Remember that Sage is a starter theme and meant to be modified to fit your needs, and if you need a stable build tool that doesn’t have a critical bug affecting your workflow, please use that instead

Most of the known Bud issues have been resolved as of Bud v5.1.0

Thanks everybody who has given things a shot so far! We’re trying to catch up to a couple more Sage bugs after the Acorn zero-config changes landed recently on the main branch, and then we’ll be cutting the next beta release.

I upgraded bud for the bug fixes. But now, when saving blade files with any change, the page is not being reloaded.

Before posting a new issue, can somebody try if this happens to you as well or did I miss something when upgrading?

To upgrade, I updated package.json, bud.config.js with the main branch files and updated the proxy. Then run yarn.


@SergiArias I’m also finding with the very latest dev-main of Sage, that neither auto-recompiling nor live-reloading via bud dev is happening when I make changes to any Blade or CSS file, even though I have this line in my bud.config.js:


Which means I just have to quit bud dev and restart it for things to just recompile, which basically defeats the purpose of bud dev. Not sure what’s up.

1 Like