# Sage 9 Install - Type Error **URL:** https://discourse.roots.io/t/sage-9-install-type-error/23060 **Category:** sage **Tags:** sage9 **Created:** 2022-05-06T05:33:36Z **Posts:** 13 ## Post 1 by @kwdit — 2022-05-06T05:33:36Z 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] [--] [ [ []]] ``` 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. --- ## Post 2 by @strarsis — 2022-05-06T06:04:41Z This appears to be the same issue (and workaround for it): > > > Version: 0.17.0 > Bug: yes > Php Version: 7.3.5 > OS: Windows 10 > Symfony/Process V…ersion: 5.0 > > I get the following error whenever grumphp is installed. > > ``` > Fatal error: Uncaught TypeError: Argument 1 passed to Symfony\Component\Process\Process::__construct() must be of the type array, string given, called in C:\...\vendor\phpro\grumphp\src\Process\ProcessFactory.php on line 25 and defined in C:\...\vendor\symfony\process\Process.php:140 > Stack trace: > #0 C:\...\vendor\phpro\grumphp\src\Process\ProcessFactory.php(25): Symfony\Component\Process\Process->__construct('"C:\\Program Fil...') > #1 C:\...\vendor\phpro\grumphp\src\Locator\GitWorkingDirLocator.php(30): GrumPHP\Process\ProcessFactory::fromArguments(Object(GrumPHP\Collection\ProcessArgumentsCollection)) > #2 C:\...\vendor\phpro\grumphp\src\Locator\GuessedPathsLocator.php(153): GrumPHP\Locator\GitWorkingDirLocator->locate() > #3 C:\...\vendor\phpro\grumphp\src\Locator\GuessedPathsLocator.php(47): GrumPHP\Locator\GuessedPat in C:\...\vendor\symfony\process\Process.php on line 140 > GrumPHP can not sniff your commits! (invalid-exit-code) > ``` > > It happens when I run `composer install` in project that already has > > ``` > "require-dev": { > "phpro/grumphp": "^0.17.0" > }, > ``` > in the `composer.json`. > > It happens when I run `composer require --dev phpro/grumphp` on a project without grumphp installed. > > In general, it seems to happen whenever I run a grumphp command. > > I added the following composer script to `composer.json`: > > ``` > "scripts": { > "grumphp:git:init": "grumphp git:init" > } > ``` > and then ran `composer grumphp:git:init` > > The effect is that the git hooks are not installed. > > Based on the error and a comment I found in the code, it looks like Symfony's Process constructor is being called incorrectly. > > I have a PR almost ready to go. I'll associate it with this issue shortly. --- ## Post 3 by @kwdit — 2022-05-06T08:06:29Z @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… [https://dl.dropboxusercontent.com/s/hnfssua0dmca82v/Sage%209%20Failed%20Install.mp4?dl=0](https://dl.dropboxusercontent.com/s/hnfssua0dmca82v/Sage%209%20Failed%20Install.mp4?dl=0) Should I be picking this issue up on the link you’ve provided instead? --- ## Post 4 by @strarsis — 2022-05-06T19:12:51Z 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`](https://packagist.org/packages/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. --- ## Post 5 by @kwdit — 2022-05-07T10:50:45Z @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. --- ## Post 6 by @strarsis — 2022-05-07T14:41:53Z @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`: > **[Composer Global Require Considered Harmful? - SitePoint](https://www.sitepoint.com/composer-global-require-considered-harmful/)** > > Installing composer packages globally can cause some dependency conflicts. Here's how to get around it with the help of a new, alternative tool. 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? --- ## Post 7 by @kwdit — 2022-05-07T16:53:33Z 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. > **[GitHub - deliciousbrains/spinupwp-composer-site: A WordPress site setup using...](https://github.com/deliciousbrains/spinupwp-composer-site)** > > A WordPress site setup using Composer that is primed and ready to be hosted using SpinupWP. - GitHub - deliciousbrains/spinupwp-composer-site: A WordPress site setup using Composer that is primed a... 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. --- ## Post 8 by @strarsis — 2022-05-07T18:05:54Z @kwdit: You may want to try out my own variant of a Docker image and setup for Bedrock: > **[docker-php-bedrock/test/compose at php7 · strarsis/docker-php-bedrock](https://github.com/strarsis/docker-php-bedrock/tree/php7/test/compose)** > > php7/test/compose > **[docker-php-bedrock/test/compose at php8 · strarsis/docker-php-bedrock](https://github.com/strarsis/docker-php-bedrock/tree/php8/test/compose)** > > php8/test/compose 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. --- ## Post 9 by @kwdit — 2022-05-08T06:02:35Z 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. --- ## Post 10 by @kwdit — 2022-05-10T03:49:39Z OK, so I was a bit lost with those images, without a more detailed explanation. I found this easier to follow… > **[GitHub - urre/wordpress-nginx-docker-compose: Run WordPress with nginx using...](https://github.com/urre/wordpress-nginx-docker-compose)** > > Run WordPress with nginx using Docker Compose. . Contribute to urre/wordpress-nginx-docker-compose development by creating an account on GitHub. 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. --- ## Post 11 by @strarsis — 2022-05-10T14:39:05Z > [@kwdit](#): > > ``` > [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) > ``` 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`)](https://laravel.com/docs/5.8/upgrade#support). 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: > [@Deleting the cache for blade templates](https://discourse.roots.io/t/deleting-the-cache-for-blade-templates/11062/2): > > Deleting the upload/cache directory wipes out all your cached blades, which will cause them to be re-rendered. This can take a couple minutes (they seem to get kind of…cached somewhere else?) but it will work. If you deleted the cache folder a while ago, and you’re still seeing issues, I’d guess one of the following is happening: The error you were trying to correct in your templates is still there. If this site is on a live server, the files may still be cached elsewhere (by the server, depe… With some luck this should fix the runtime issue. --- ## Post 12 by @kwdit — 2022-05-11T03:20:53Z 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. --- ## Post 13 by @strarsis — 2022-05-11T16:26:18Z 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.