I’m in the process of moving a project from 8.5.12 to 9.2.1 and im running into a Problem with external libraries.
Here is what I did:
- Copy everything to local
- Replace /concrete directory with the one of 9.2.1
- replace composer.json / composer.lock
- run composer update
- Call the site to process the update
- Confirm success of update through Environment Info
Now the problem is:
When I access the “Extend concrete5” (Why is it called like that after all?), I get this error:
Declaration of Concrete\Core\Http\Client\Client::send(Psr\Http\Message\RequestInterface $request, array $options = ): Psr\Http\Message\ResponseInterface must be compatible with GuzzleHttp\Client::send(GuzzleHttp\Message\RequestInterface $request)
I’m pretty lost here, any ideas from the hivemind?
If you are installing using the zip file (replacing the core) you don’t need to do a composer update, skip from step 2 to step 5.
Ok understand… but how would that break anything?
Composer could be pulling in a later and incompatible version of a dependency than the zip was built with.
Sadly, the behavior is the same. I tried:
- Replacing the /concrete directory with the original file from zip
- Accessing “extend page” with the original composerlock/json files
- Accessing “extend page” with the composer.lock/json files from the original ZIP
- Accessing “extend page” with the composer.lock/json files from the original 8.5.12 installation
All gives me the same Error.
The error message could be a php8 issue. But 8.5.12 is only php7. If that is the case, you could try running the update in php7.
It could also be related to incompatible use of $app->make in custom code or an addon or theme. In v9 it has to use the named hash method of passing parameters.
My usual method is to disable and clear caches, set doctrine into development mode, replace the concrete directory with the new version, then run the update from the CLI.
Yes I have run the update on php7.4 then switched over to 8.1, beause I want to migrate all v8 projects to v9 soon.
I did not look into the controllers of those pages, but the error message only happens when concretecms wants to “phone home” = Extend-Install, Extend-Update, Concrete-Update Pages. Nowhere else. If the issue would be in a custom package, would it also trigger the error when I check the “Upgrade Concrete” page? I don’t think it would?
Just trying to narrow down the origin of this. But as I have changed the /concrete directory, AND the composer files, the options are geting few…
Ok, switched to php7.4, but same error. So I think this rules out all the “old themes/plugin” options and leaves with …?
php-curl is enabled… anybody have an idea? Because I don’t …
'marketplace' => [
'enabled' => false,
Fixed the problem forseeable, so I believe it is clear that the issue arises from the attempt to make the outside call. Question is how this can be fixed without disabling the marketplace.
Another project in my local environment that I started with 9.1.2 (not upgrade from…) works fine with the marketplace enabled. so somewhere in the upgrade process something went wonky.
So the solution… it actually was a package.
I couldn’t imagine that a packages vendor folder would override the concrete/vendor folder when not explicitly called but seems like it does.
So after uninstalling, Guzzle works fine. Thanks for pointing the way, John!