I am working with a nonprofit managing their existing sites. Two of them are using Sage and Wordpress.
Site 1: is using Sage 9.0.10 Nodes 8.0.0
Site 2: is using Sage 8.4.2 Nodes 0.12.0
I am concerned about Site 2 and should Sage and Nodes be updated? What are the security concerns if any on the older version of Sage. Are there any tutorials out there for updating Sage/Nodes etc. I do realize using terminal is the way to update packags etc. I’m still trying to wrap my head around how Sage is different or additional then Wordpress with Gutenberg environment. Can both be used together if I wanted to use Gutenberg blocks? I maintain the plugins and Wordpress core updates so wondering about Sage related updates. Thanks in advance.
The build dependencies are only used on a workstation/CI-server/build-server to build the theme from its assets (images, styles, scripts, …). The build artifacts are usually transferred to the site where they most are served as static files. Depending on the version, a manifest file is also generated that is used by the theme runtime to resolve URLs to assets (notably using a hash for cache-busting).
The server shouldn’t install these build dependencies or run the build (it is technically possible), but rather the build happens once and then the build artifacts are transferred to the server where they stay as static files. So as those build dependencies don’t run on the server and are not exposed to the outside world, there are no real security concerns here (besides for the build system in hypotheticals where npm packages being compromised and such).
Legacy build dependencies can cause issues with being able to build the theme on another workstation, as packages “rot”, become incompatible with newer node versions (that are needed for more modern OS/WSL (1/2)).
The theme runtime is written in PHP as WordPress and adds extra functionality, like Blade-Template support and asset resolution (Sage 8 has standalone code; Sage 9roots/sage-lib and some other libraries; Sage 10 roots/acorn (as library or (mu-)plugin)). This runtime runs on the server is used on each render. This runtime indeed interacts with the outside world, hence can be a security concern.
Each major version has its own runtime. I (from what I know and have seen over the years I am using the roots.io ecosystem) am not aware of security issues/CVEs with the theme runtimes.
IMHO keeping WordPress core and its plugins up-to-date and keeping backups is even more important.
Newer composer releases (v2) and PHP versions (8) may require an update of Sage to a newer major version (including the build dependencies and runtime) to ensure compatibility.
The build dependencies, as they are node-based reside in node_modules/ in theme directory.
Those shouldn’t be listed via SFTP though, as it is bad practice (as aforementioned) to have build dependencies on the server. But if they are listed, don’t just delete them, as there may be the rare but possible case (of even worse practice) that the theme includes files from node_modules/.
The runtime dependencies (if the Sage version uses them, Sage 8 doesn’t require runtime libraries via composer), managed by composer, reside in vendor/ in theme directory. There is an exception for Sage 10 though where the acorn runtime alternatively may also be added as a WordPress mu-plugin or a plugin instead as a composer library of the theme.
If you plan to develop on the themes, don’t do this on the production system. Download everything (including the data/uploads and database dumps) and either use something like Trellis VM feature or a Docker container or other development system locally on your workstation.
And put everything into version control (git) first. Ideally you can contact the original developers and get the repository with full history. I also encountered sites where the .git directory was also on the server (which is also bad practice, as the released app/theme should be just the workspace with as little files as possible).
If you want to update your Sage9 theme, you may be interested in this update guide for Sage9:
Edit: The build dependencies can be (re)installed just from the package.json; package-lock.json/yarn.lock (by npm install/yarn install), the runtime dependencies from composer.json; composer.lock (by composer install). The npm and composer dependencies are downloaded by their respective package managers.
For Sage itself there are unlikely to be any security concerns. Beyond that, there’s no way we could know, since we have no idea what development may have been done on that theme, but generally nothing Sage does has security ramifications.
Sage is a starter theme, and itself should not be updated. Unless Node is being run on your server (this is unlikely, and Sage does not do this on its own) there’s no need to update it unless you
a) need to run the build process, and
b) the build process fails
Sage is not “different” from WordPress or Gutenberg. It is a set of tools for building themes for WordPress. Whether or not you can use Gutenberg well with your specific theme is not a question we can answer, as it will depend on what the previous developer did with Sage.