Sage 9 Install - Type Error

I’m finding Sage 10 challenging with WSL etc, so I’ve reverted to Sage 9.

I’ve had Sage 9 working before.
Since the release of Sage 10, the advice is to run…
composer create-project roots/sage kwd-custom 9.x-dev

When I run this, I get…

D:\laragon\www\kwd-it-22\public\content\themes
λ composer create-project roots/sage kwd-custom 9.x-dev
Creating a "roots/sage" project at "./kwd-custom"
Info from https://repo.packagist.org: #StandWithUkraine
Installing roots/sage (9.x-dev 7e6d0671d3421acadb6e9b3d0bad2a9f54d62c67)
  - Installing roots/sage (9.x-dev 7e6d067): Extracting archive
Created project in D:\laragon\www\kwd-it-22\public\content\themes\kwd-custom
Installing dependencies from lock file (including require-dev)
Verifying lock file contents can be installed on current platform.
Package operations: 34 installs, 0 updates, 0 removals
  - Installing kylekatarnls/update-helper (1.2.1): Extracting archive
kylekatarnls/update-helper contains a Composer plugin which is currently not in your allow-plugins config. See https://getcomposer.org/allow-plugins
Do you trust "kylekatarnls/update-helper" to execute code and wish to enable it now? (writes "allow-plugins" to composer.json) [y,n,d,?] y
  - Installing composer/installers (v1.10.0): Extracting archive
composer/installers contains a Composer plugin which is currently not in your allow-plugins config. See https://getcomposer.org/allow-plugins
Do you trust "composer/installers" to execute code and wish to enable it now? (writes "allow-plugins" to composer.json) [y,n,d,?] y
  - Installing psr/log (1.1.3): Extracting archive
  - Installing filp/whoops (2.12.1): Extracting archive
  - Installing symfony/translation-contracts (v2.3.0): Extracting archive
  - Installing symfony/polyfill-mbstring (v1.22.0): Extracting archive
  - Installing symfony/translation (v4.4.19): Extracting archive
  - Installing nesbot/carbon (1.25.3): Extracting archive
  - Installing psr/simple-cache (1.0.1): Extracting archive
  - Installing psr/container (1.0.0): Extracting archive
  - Installing illuminate/contracts (v5.6.39): Extracting archive
  - Installing doctrine/inflector (1.4.3): Extracting archive
  - Installing illuminate/support (v5.6.39): Extracting archive
  - Installing illuminate/container (v5.6.39): Extracting archive
  - Installing illuminate/events (v5.6.39): Extracting archive
  - Installing paragonie/random_compat (v9.99.99): Extracting archive
  - Installing symfony/process (v3.4.47): Extracting archive
  - Installing symfony/polyfill-ctype (v1.22.0): Extracting archive
  - Installing ramsey/uuid (3.9.3): Extracting archive
  - Installing symfony/finder (v4.4.19): Extracting archive
  - Installing illuminate/filesystem (v5.6.39): Extracting archive
  - Installing symfony/service-contracts (v2.2.0): Extracting archive
  - Installing symfony/polyfill-php80 (v1.22.0): Extracting archive
  - Installing symfony/polyfill-php73 (v1.22.0): Extracting archive
  - Installing symfony/console (v4.4.19): Extracting archive
  - Installing illuminate/console (v5.6.39): Extracting archive
  - Installing roots/sage-installer (dev-webpack5 f4a07cb): Extracting archive
  - Installing symfony/debug (v4.4.19): Extracting archive
  - Installing illuminate/view (v5.6.39): Extracting archive
  - Installing illuminate/config (v5.6.39): Extracting archive
  - Installing roots/sage-lib (9.0.9): Extracting archive
  - Installing brain/hierarchy (2.5.0): Extracting archive
  - Installing soberwp/controller (2.1.2): Extracting archive
  - Installing squizlabs/php_codesniffer (2.9.2): Extracting archive
Generating autoload files
Carbon 1 is deprecated, see how to migrate to Carbon 2.
https://carbon.nesbot.com/docs/#api-carbon-2
    You can run ".\vendor\bin\upgrade-carbon" to get help in updating carbon and other frameworks and libraries that depend on it.
15 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
> Roots\Sage\Installer\ComposerScript::postCreateProject
TTY mode is not supported on Windows platform.

Some interactive parts of post-create-project routine might be skipped.

Running the sage cli tool manually should still work.

https://roots.io/sage/docs/

In Process.php line 143:

  [TypeError]
  Argument 1 passed to Symfony\Component\Process\Process::__construct() must be of the type array, string given, called in D:\laragon\www\kwd-it-22\public\content\themes\kwd-custom\vendor\roots\sage-installer\src\ComposerScript.php on
  line 26


Exception trace:
  at phar://C:/laragon/bin/composer/composer.phar/vendor/symfony/process/Process.php:143
 Symfony\Component\Process\Process->__construct() at D:\laragon\www\kwd-it-22\public\content\themes\kwd-custom\vendor\roots\sage-installer\src\ComposerScript.php:26
 Roots\Sage\Installer\ComposerScript::postCreateProject() at phar://C:/laragon/bin/composer/composer.phar/src/Composer/EventDispatcher/EventDispatcher.php:391
 Composer\EventDispatcher\EventDispatcher->executeEventPhpScript() at phar://C:/laragon/bin/composer/composer.phar/src/Composer/EventDispatcher/EventDispatcher.php:248
 Composer\EventDispatcher\EventDispatcher->doDispatch() at phar://C:/laragon/bin/composer/composer.phar/src/Composer/EventDispatcher/EventDispatcher.php:125
 Composer\EventDispatcher\EventDispatcher->dispatchScript() at phar://C:/laragon/bin/composer/composer.phar/src/Composer/Command/CreateProjectCommand.php:321
 Composer\Command\CreateProjectCommand->installProject() at phar://C:/laragon/bin/composer/composer.phar/src/Composer/Command/CreateProjectCommand.php:167
 Composer\Command\CreateProjectCommand->execute() at phar://C:/laragon/bin/composer/composer.phar/vendor/symfony/console/Command/Command.php:298
 Symfony\Component\Console\Command\Command->run() at phar://C:/laragon/bin/composer/composer.phar/vendor/symfony/console/Application.php:1015
 Symfony\Component\Console\Application->doRunCommand() at phar://C:/laragon/bin/composer/composer.phar/vendor/symfony/console/Application.php:299
 Symfony\Component\Console\Application->doRun() at phar://C:/laragon/bin/composer/composer.phar/src/Composer/Console/Application.php:334
 Composer\Console\Application->doRun() at phar://C:/laragon/bin/composer/composer.phar/vendor/symfony/console/Application.php:171
 Symfony\Component\Console\Application->run() at phar://C:/laragon/bin/composer/composer.phar/src/Composer/Console/Application.php:130
 Composer\Console\Application->run() at phar://C:/laragon/bin/composer/composer.phar/bin/composer:88
 require() at C:\laragon\bin\composer\composer.phar:29

create-project [-s|--stability STABILITY] [--prefer-source] [--prefer-dist] [--prefer-install PREFER-INSTALL] [--repository REPOSITORY] [--repository-url REPOSITORY-URL] [--add-repository] [--dev] [--no-dev] [--no-custom-installers] [--no-scripts] [--no-progress] [--no-secure-http] [--keep-vcs] [--remove-vcs] [--no-install] [--ignore-platform-req IGNORE-PLATFORM-REQ] [--ignore-platform-reqs] [--ask] [--] [<package> [<directory> [<version>]]]

I’ve installed the prerequisites, so I’m confused as to why I’m falling at the first hurdle.
Would anyone be able to give me some advice on the best way to resolve this issue?
It would be greatly appreciated.

This appears to be the same issue (and workaround for it):

@strarsis Many thanks for your reply.

I’ve deleted the theme directory.

I’ve added "symfony/process": "^4.0" to "require-dev" to composer.json.

I’ve ran composer update and could see… Installing symfony/process (v4.4.41)

I’ve then ran the following again…

composer create-project roots/sage kwd-custom 9.x-dev

I’m still getting the same error.

A short screen recording shows the steps taken…

Should I be picking this issue up on the link you’ve provided instead?

No, this issue was created for another project. But the root cause may have been the same (incompatible API call due to a changed version of a package (symfony/process).

The old sage-installer component uses the symfony/process constructor to create new Processes:

However, the symfony/process constructed here is of a version with a function signature that doesn’t support a string as argument (anymore), but an array instead, hence the fatal error.

The breaking change was introduced with symfony/process 4.2.0:

Currently the sage-installer package requires symfonfy/process versions ~3.3:

Is this version also installed in your case? Or is symfony/process globally installed maybe, superseeding the version that sage-installer requires?

@kwdit: So "symfony/process": "~3.3" should already be a require in the composer.json of a Sage 9 project.

@strarsis Thanks again for taking the time to review and respond to my post.

I’ve had Sage 9 working in the past, by following the simple instructions in the docs.
I therefore wasn’t expecting to need knowledge of what package versions the sage installer requires.
When Sage says it’s going to give me a 10,000 hour head start, I wrongly assumed this sort of stuff would be taken care of.

When I look at the composer.json file for Sage 9 on Git Hub, there’s no mention of symfony/process.

When I included "symfony/process": "^4.0", I’d included it in the composer.json file of my project (not the theme).
Considering my issue is occurring when I try and get the theme, I can’t really add stuff to it, before I’ve got it.
I did try changing this to "symfony/process": "~3.3" in my project root composer.json file to see if it helped, but no such luck.

I don’t appear to have symfony/process installed globally.

Now that I’m starting to face such issues with Sage 9, I’m starting to think I need to revisit Sage 10 again.

@kwdit: symfony/process is not directly required by the Sage 9 composer.json, but is a transitive dependency, required by sage-installer that is required by Sage 9.
When there is already a symfony/process package globally installed on your system, it may be used instead of the lower version, compatible one required by sage-installer:

Is the symfony/process package listed when you use the composer global show command to list all global installed packages (of the system + user that you are also using for installing the Sage 9 dependencies)?

Currently I can’t come up with another mechanism that causes your Sage 9 setup to use a newer, incompatible symfony/process package, so this may be worth a stab.

For isolating the issue: Can you install the Sage 9 theme using another user/inside a Docker container instance (e.g. bash with some apt installed stuff)/VM/other OS/other system/colleague system?

OK, so that’s cleared up some confusion.
I can see "symfony/process": "~3.3", in the composer.json file inside the sage-installer directory.

Yesterday morning, running composer create-project roots/sage kwd-custom 9.x-dev worked fine.
I had to enter the following to complete the setup…

vendor\bin\sage meta
vendor\bin\sage config
vendor\bin\sage preset

I compiled the assets and then activated the theme, but got a 500 error.
The errors in debug.log are as follows…

[06-May-2022 04:59:52 UTC] PHP Fatal error:  Uncaught Symfony\Component\Debug\Exception\FatalThrowableError: Call to undefined function array_except() in D:\laragon\www\kwd-it-22\public\content\uploads\cache\d8f65d37e4de77ddc1f389b4c9cc0da144a1548a.php:2
Stack trace:
#0 D:\laragon\www\kwd-it-22\public\content\themes\kwd-custom\vendor\illuminate\view\Engines\PhpEngine.php(43): include()
#1 D:\laragon\www\kwd-it-22\public\content\themes\kwd-custom\vendor\illuminate\view\Engines\CompilerEngine.php(59): Illuminate\View\Engines\PhpEngine->evaluatePath('D:\\laragon\\www\\...', Array)
#2 D:\laragon\www\kwd-it-22\public\content\themes\kwd-custom\vendor\illuminate\view\View.php(142): Illuminate\View\Engines\CompilerEngine->get('D:\\laragon\\www\\...', Array)
#3 D:\laragon\www\kwd-it-22\public\content\themes\kwd-custom\vendor\illuminate\view\View.php(125): Illuminate\View\View->getContents()
#4 D:\laragon\www\kwd-it-22\public\content\themes\kwd-custom\vendor\illuminate\view\View.php(90): Illuminate\View\View->renderContents()
#5 D:\laragon\www\kwd-it-22\public\co in D:\laragon\www\kwd-it-22\public\content\uploads\cache\d8f65d37e4de77ddc1f389b4c9cc0da144a1548a.php on line 2

I deleted my theme and repeated the process again.
This is the point in which the initial install stopped working.

If I run composer global show I get…

Changed current directory to C:/Users/kirkj/AppData/Roaming/Composer
Composer could not find a composer.json file in C:\Users\kirkj\AppData\Roaming\Composer
To initialize a project, please create a composer.json file. See https://getcomposer.org/basic-usage

A reminder that these commands are being ran within Cmder via Laragon.
I haven’t added anything to my Paths, so all the tools are inaccessible via the regular Windows terminal.

I’ve just setup a Docker container with the Official WordPress image and the Sage 9 install completed without errors.
I realise Docker is the way forward, but there are areas that I’m struggling with.
I think it’s time I deal with my Docker issues, rather than trying to find another way.

I have a tendency to provide too much information in my posts, so I’ve been trying to keep information to a minimum.
However, I’m now feeling like you’re getting half the story.
I’m going to cover what I’ve been trying so far below, but I’d totally understand if you ignore the following information.

I’ve been trying to use Docker to work with Sage 10 alongside WSL2.
The areas that I’ve found confusing are that I don’t want to use the Official WordPress image, because I’m using a Bedrock setup.
Although there are Bedrock images available, I’m using a SpinupWP alternative.

I therefore checked out the SpinupWP community to see if there were any suggestions, before I tried to create my own image, based on their Bedrock setup.
This led me to Devilbox, which seems great and worked well. However, I can’t figure out how to access the proxy URL on my host machine. My attempts at a reverse proxy failed.

Port forwarding from Docker to the Host seems way more straightforward, so I’ve been tempted to try and just use Docker.
This leads me back to whether I shouldn’t worry about Bedrock for local development of themes and just use the Official WordPress image.
I’m not keen on the idea of Bedrock being used remotely, but not locally.
I’m also not keen on using a regular Bedrock setup locally and the SpinupWP version remotely.
I feel that I’m struggling due to SpinupWP adding confusion to the matter.

I manage about 120 sites and a lot are basic brochure sites, so Roots Bedrock, Sage and Trellis for all of them, seems overkill.
I wouldn’t fancy having that many Docker Containers, let alone VM’s. Maybe I don’t know enough about Docker and I wouldn’t need containers for each site.
Only a handful would truly benefit from the Sage theme, so I’m starting to think stick with my custom theme and SpinupWP’s Bedrock setup for the majority of sites. This works fine with Laragon.
I can then look into using Roots Bedrock, Sage and Trellis for my larger sites, eliminating all of the complications that are making my scenario, different from the majority of Sage users.

@kwdit: You may want to try out my own variant of a Docker image and setup for Bedrock:

I am using this setup myself and it works quite well.

When I got more time I plan to write a guide about Docker + Bedrock and how to use this for development.

Thanks, I’ll take a look and give you an update on how I get on.
It’s probably going to be a day or so before I get change to give it the focus it needs.

OK, so I was a bit lost with those images, without a more detailed explanation.

I found this easier to follow…

However, this approach would still leave me confused when it comes to hosting.

I think that now I’ve established that Sage would be overkill for the majority of my sites, I don’t need to worry about running 100’s of VM’s on my machine. I should be OK following the Roots advice of Trellis and Vagrant.

Thanks again for your input though… It’s been useful.

By the way: This runtime error indicates that the illuminate\view expects an older laravel release. The array_except method was removed from the laravel/framework package (moved to laravel/helpers).

As the error is caused inside a cached (rendered) blade view (uploaded with the site), you may want to try to clean the Blade cache folder to regenerate those cached/rendered Blade view PHP files and see whether this fixes you problem:

With some luck this should fix the runtime issue.

Thanks for the update.

The fact that it’s looking for older versions, just reiterates the need to move to Sage 10 though.

I’ve had 5 new builds land this week, so Sage is on the back burner for a bit. I’ll try and revisit this when I get chance, but Sage 10 is definitely looking like the preferred option now.

For new projects I also use Sage 10 now. It offers a new build tool (bud) which is also from roots and is actively maintained.