Sage "9.1": Please test

Just discovered that the Soil plugin (4.0.5) doesn’t seem to be working with 9.1. Works fine with Sage 10. Using Local by Flywheel running Apache with PHP 7.4.1 and MySQL 5.7.28 and WordPress 5.8 - any clues/suggestions??

The soil plugin has to be enabled by theme features.
However, this is the case for Sage 9 (and the update branch), too:

What exactly isn’t working? Plugin activation or runtime error? Are parts of the HTML not cleaned up?

Hi @strarsis - yep, plugin installed and activated and features enabled in setup.php. HTML isn’t cleaned up and nice search not activated. Has worked on previous instals with same process. Only noticed when I tried to pass in analytics via Soil.

Just tried a fresh install of 9.1 and same problem.

Hmmm - so I deleted 4.0.5 and tried 4.0.4 and same issue - then tried 3.9.0 and it works. So something within the Soil plugin itself? Works in Sage 10 so guessing something is optimised in newer versions for Sage 10.

Alright, your observation is indeed correct. Soil now uses a different theme support key and an array for the options:

You have to replace the existing Soil-related lines in Sage 9.x (and currently 9.1, I plan to fix that):

    /**
     * Enable features from Soil when plugin is activated
     * for Soil 3.x
     * @link https://roots.io/plugins/soil/
     */
    add_theme_support('soil-clean-up');
    add_theme_support('soil-jquery-cdn');
    add_theme_support('soil-nav-walker');
    add_theme_support('soil-nice-search');
    add_theme_support('soil-relative-urls');

    /**
     * Enable features from Soil when plugin is activated
     * for Soil 4.x
     * @link https://roots.io/plugins/soil/
     */
    add_theme_support('soil', [
        'clean-up',
        'disable-rest-api',
        'disable-asset-versioning',
        'disable-trackbacks',
        // 'google-analytics' => 'UA-XXXXX-Y', // @TODO: Add Google Analytics site key
        'js-to-footer',
        'nav-walker',
        'nice-search',
        'relative-urls',
    ]);
1 Like

Hi @strarsis - thanks, that works.

Hi @strarsis!

Just followed the instructions in the original post setting up with Bootstrap 4. On running yarn build I get the math division errors already noted above, but I’m also getting

99% done plugins FriendlyErrorsWebpackPlugin

 ERROR  Failed to compile with 1 error                                              15:07:10

 error  in ./resources/assets/styles/main.scss

SassError: 0.25rem and 0 are incompatible.
  ╷
9 │       $return: append($return, max($value, 0));
  │                                    ^^^^^^ 0.25rem
  │                                            ━ 0
  ╵
  node_modules/bootstrap/scss/mixins/_border-radius.scss 9:36   valid-radius()
  node_modules/bootstrap/scss/mixins/_border-radius.scss 19:20  border-radius()
  node_modules/bootstrap/scss/_images.scss 18:3                 @import
  node_modules/bootstrap/scss/bootstrap.scss 14:9               @import
  resources/assets/styles/autoload/_bootstrap.scss 4:9          @import
  resources/assets/styles/main.scss 4:9                         root stylesheet


asset scripts/main.js 241 KiB [emitted] (name: main) 1 related asset
asset scripts/customizer.js 3.76 KiB [emitted] (name: customizer) 1 related asset
webpack compiled with 2 errors
error Command failed with exit code 1.

This is without any other customisations, straight from the repo.

So far I haven’t been able to track down a fix and will come back if and when I do, but posting here to see if anyone has any suggestions.

EDIT: this is something introduced with dart-sass 1.40.0. "sass": ">=1.32.0 <=1.39.2", in package.json works as expected.

Yes, this also seemed to me as a bug, as 0 should match any unit.
So after updating dart-sass the issue was fixed? Then I should check and update it in update branch, too.

The issue is with version 1.40.0. Downgrading from that worked. 1.41.0 has now been released which also works, so for future readers, just make sure you’re not using 1.40.0 and you’ll be fine. @strarsis that probably means using "sass": "^1.41.0", in package.json instead of my earlier suggestion.

Why not use Sage 10 now?

IMHO there are two primary reasons why developers decide to still use Sage 9.x:

  1. A legacy Sage 9.x-based project that doesn’t build anymore because of dependency rot/node incompatibilities.
  2. Being very familiar with Sage 9.x and webpack. Sage 10 uses laravel-mix that generates webpack 5 configuration, so it can add a new layer of complexity and issues. Learning a new Sage can take time, hence using a familiar release that got most bugs ironed out can be a good idea sometimes.

I still have some Sage 8.x based sites - and they work fine. Migrating these to Sage 10 would cost time that I currently can’t afford. And also those themes tend to get improved over time, migrating to a completely new base theme can introduce new bugs.

4 Likes

@AurelianSpodarec @strarsis

In addition to these reasons, I’m also waiting for a new theme development guide/pdf as was released with previous editions. :crossed_fingers:

I’ve found there is usually a lot of really useful information in the guides that would otherwise get overlooked.

2 Likes

If you haven’t noticed it yet, the webpack 5 PR was merged into Sage upstream 9.x branch:

So you can now install Sage 9.x as usual, no extra steps required for the fixes.

Addendum: In the meantime lots of webpack tooling changes again… There is an additional branch that tracks changes for the latest changes, but there is no PR yet (GitHub - strarsis/sage at webpack5-url-update).

1 Like

Overlooking the other major reason, the install commands on the homepage, the documentation and default options all install Sage 9, and not even the latest version of 9!

That’s a pretty good indication for someone new to the project that Sage 9 is what to do. I didn’t even think sage 10 was ready. Now running into all these issues with sage 9, seems I’d have been better investing my time learning / installing sage 10. Maybe it’s time to update the homepage and docs?

They install the latest published release of Sage 9 :sweat_smile: We’ve been focused on getting Sage 10 out the door and haven’t circled back to Sage 9 yet to give it another release after recent updates from the 9.x. branch.

The advice of a lot of folks on here has been “just use it” for a couple years now. But it’s also pretty well documented, which I hope isn’t a secret? Sage 10 also recently has gotten additional beta releases, Bud is out, Acorn is no longer in beta, and we’re ready to ship. It’s happening any day now. :slight_smile:

Sage 10’s final release will end any confusion about what version should be used.

1 Like

This also fixes the image path issue in 9.0.10: Error: Can’t resolve images/stylesheet (Sage 9.0.10)

As a side effect of using webpack 5 and associated loaders/plugins that correctly work, the paths aren’t relative to the using SCSS files anymore in the latest Sage 9.x release, changelog:

While I migrated everything to webpack 5 I noticed that again lots of stuff changed again and updating/replacing these would result in the previous behavior…

Well, the JavaScript ecosystem, especially the build/bundler tooling is still changing very quickly and is quite unstable with lots of module rot. In an ideal world one would just define a working version of node (using a .nvmrc file and a tool like nvm), and years later (as an extreme example), everything would still install and build fine.
But this isn’t and hadn’t been the case sadly: Just getting the node version right proved to be basically impossible, older node versions do simply not install on newer distribution releases, run or their npm can’t be used, even self-updating npm to a newer, working version is often impossible. This is further exacerbated by the need to use some non-JS libraries, which involves building and linking code. This also simply doesn’t want to work in older node versions. One is simply forced to use a newer node version. And with a newer node version everything else breaks down: The packages aren’t compatible anymore, either formally or simply because of different node ABIs/APIs.
Updating the packages also doesn’t work because of incompatibilities between major releases (and sometimes even between small releases). In the end the whole tooling has to be updated. Getting the associated plumbing stuff right and fixing all the little errors, strangeness and quirks requires a large amount of time. In an ideal world one would simply follow that guide, then some others and the thing just builds. But in the real world the 2nd loader probably already breaks the whole thing.
Even a Vagrant VM with the whole OS and packages may not work, I had so many issues with Vagrant and VirtualBox and bootstrapping the thing. Many Vagrant plugins hadn’t been updated for years.

The latest Sage 10 uses bud that abstracts the plumbing away (similar to laravel-mix, whose development also stalled) which hopefully adds some stability.

Where do I set quietDeps: true to get rid of the warnings?

quietDeps can be set in the sassOptions in the base webpack.config.js of the Sage 9 project:

quietDeps was added about a year ago, and early adopters initially had issues enabling this option by the way, but that would be actually an underlying issue with the dart-sass implementation: