|
| 1 | +--- |
| 2 | +layout: post |
| 3 | +title: "Breaking Change in V9 Guzzle removal, what are the alternatives?" |
| 4 | +subtitle: "You are using Guzzle in your module, starting from PrestaShop V9 the library is not available by default any more, how can you adapt your module?" |
| 5 | +date: 2025-03-17 |
| 6 | +authors: [ JonathanLelievre ] |
| 7 | +icon: icon-code |
| 8 | +tags: [autoupgrade, module, beta, releases, community, contribution, development, qa] |
| 9 | +--- |
| 10 | + |
| 11 | +The PrestaShop V9 version is a major version, as such it comes with breaking changes among which some removed dependencies, you can find more details about those changes on the [developer documentation](https://devdocs.prestashop-project.org/9/modules/core-updates/9.0/), but in this article we're going to focus on one in particular the removal of Guzzle and how to adapt your module using it. |
| 12 | + |
| 13 | +## Why remove Guzzle in the first place? |
| 14 | + |
| 15 | +Guzzle has been one of the many dependencies included in the PrestaShop core for many years, as such modules were used to have it available and depended on it to make external HTTP requests. |
| 16 | + |
| 17 | +But this library has been replaced over the years by other tools in the core, most the Symfony HTTP Client. The core itself no longer had needs for this dependency, so we decided it was time to make the core lighter and remove guzzle along with other unused libraries. |
| 18 | + |
| 19 | +The weight of the build is not the only reason, in PrestaShop 8 we had to update Guzzle from version 5 to 7, this already created some incompatibilities at the time because of the breaking changes from Guzzle itself and modules struggled to maintain a cross compatibility between PrestaShop versions. |
| 20 | +One of the solution was to forcefully include Guzzle in the module dependencies, but when two modules do this with different Guzzle versions it creates some conflicts, and of course it could also have conflicts with the version from the core. |
| 21 | + |
| 22 | +To make things clear, at least from the core perspective, we made the drastic decision to remove Guzzle completely from our dependencies because we no longer use it so there's no point in integrating it and to prevent a nightmare of conflicts between the core and the modules. |
| 23 | + |
| 24 | +## How can I adapt my module? |
| 25 | + |
| 26 | +There are multiple solutions to overcome this missing library, here are a few examples. |
| 27 | + |
| 28 | +### Use Symfony HTTP Client (recommended) |
| 29 | + |
| 30 | +The best way to avoid conflicts is not to add a custom library and rely on the core ones as much as possible. As such Symfony is the core framework of PrestaShop and will remain it in the future, so it's a safe dependency that is sure never to disappear. |
| 31 | +It includes an HTTP client component which has been integrated in PrestaShop since the version 1.7.7 so if your module only targets this version and upper you can safely use the Symfony HTTP client, you can find details on how to use it on the [Symfony documentation page](https://symfony.com/doc/current/http_client.html). |
| 32 | + |
| 33 | +```php |
| 34 | +use Symfony\Component\HttpClient\HttpClient; |
| 35 | + |
| 36 | +$client = HttpClient::create(); |
| 37 | +$response = $client->request('GET', 'https://api.domain.com'); |
| 38 | +``` |
| 39 | + |
| 40 | +### Use a custom HTTP client implementation |
| 41 | + |
| 42 | +You can create your own HTTP client, the advantage is that you are sure never to have conflicts with other modules that would use different library versions. |
| 43 | + |
| 44 | +The drawback is that you need to maintain it yourself and you re-invent the wheel. |
| 45 | + |
| 46 | +Here's an example of the client used in the `PrestaShop EventBus` module https://github.com/PrestaShopCorp/ps_eventbus/blob/27ca0e360d88345e57e945ad6369a215f4e615d0/src/Api/HttpClient.php |
| 47 | + |
| 48 | +### Forcefully include Guzzle in my module's vendors (not recommended) |
| 49 | + |
| 50 | +That's the quick and dirty solution, this way you don't need to adapt the code. But for reasons mentioned earlier we highly discourage it as your module is likely not to work with other modules because of potential conflicts. |
| 51 | + |
| 52 | +If you develop a specific module for a specific shop with a restricted list of modules it may be a quick solution, but if you sell your modules for multiple shops do not use this solution. |
| 53 | + |
| 54 | +## What if I want my module to keep working on a wide range of PrestaShop versions? |
| 55 | + |
| 56 | +Since the Symfony HTTP Client is not available in version prior to 1.7.7, you will need to adapt the code based on the current PrestaShop version your module is running under. |
| 57 | + |
| 58 | +Here's a quick example: |
| 59 | + |
| 60 | +```php |
| 61 | +if (version_compare(_PS_VERSION_, '1.7.7', '>=')) { |
| 62 | + $clientOptions = []; |
| 63 | + $client = call_user_func('Symfony\\Component\\HttpClient\\HttpClient::create', $clientOptions); |
| 64 | + $response = $client->request('GET', 'https://api.domain.com'); |
| 65 | +} else { |
| 66 | + $client = new GuzzleHttp\Client(); |
| 67 | + $response = $client->get('https://api.domain.com'); |
| 68 | +} |
| 69 | +``` |
0 commit comments