Drupal 9 requires Guzzle 6. Guzzle 6 now is in security support only. In particular, they are not adding compliance with PHP 8.1 to Guzzle 6, which creates issues for Drupal 9's own PHP 8.1 compatibility.
Guzzle 7 includes breaking changes from Guzzle 6, so we should not force sites to update to Guzzle 7 until the next major release (D10). However, we could also allow sites that want to use Guzzle 7 and PHP 8.1 to do so.
Even though we've managed to make Drupal 9 not trigger any deprecations from Guzzle 6 or skip some, there are other deprecations that Guzzle 6 will trigger when it's used by contrib projects. Such deprecations are not user deprecations but they are language level deprecations. For example:
Return type of GuzzleHttp\Command\Command::count() should either be compatible with Countable::count(): int, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice
Sites exposing this error cannot update to PHP 8.1, so they cannot prepare for Drupal 10.
"guzzlehttp/guzzle": "^6.5.2 || ^7.4.1"
core-recommended and the composer.lock for tarballs pinned to the Guzzle 6 version.
Ensure HEAD remains compatible with Guzzle 7 with #3104353: Upgrade to Guzzle 7 → .
N/A
Not in core itself.
N/A
Sites are able to install Guzzle 7 due to a widening of Drupal core's composer constraints. This allows for more complete PHP 8.1 support.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
The above patch in #86 works for me using `drupal/core-recommended` version 9.5.11 on PHP 8.1.11, thanks.
The interesting part: when we remove the package "drupal/core-recommended", the site is running fine with out any issue with Guzzle 7.
As, the package drupal/core-composer-scaffold and drupal/core-project-message is having a dependency of drupal/core.
anyone think, there might be an issue when we remove the package "drupal/core-recommended" completely ?