4.7.0 Guzzle dependency breaks sites using different versions

[xipasduarte]

Confirmation

• My issue isn't already found on the issue tracker.
• I have replicated my issue using the latest version of the plugin and it is still present.

WordPress version

5.7.3

Cloudflare-WordPress version

4.7.0

PHP version

7.4.22

Expected result

Guzzle versions shouldn't collide when using Composer to manage PHP dependencies. If a site is using guzzle, maybe Cloudflare should suggest that its plugin requires it and let the user install the dependency on his own.

Actual result

Due to the way autoloading is done, the guzzle version from Cloudlare's plugin is the one that is left available for all code to use, leading to issues on how other plugins use it.

Steps to reproduce

1. Add a custom dependency to Composer that requires Guzzle
2. Use something in the dependency that requires code not present in version ~5.0 (~7.0, for example)
3. Require Cloudflare's plugin
4. Check if the feature dependency in 1. is working

Additional factoids

It's already mentioned, but it might be important to point out again. We're using Composer to manage our dependencies, both internal/custom and external (packgist and wpackagist).

References

No response

[billinghamj]

I've found the same. Even for non-plugin/non-WP-related Composer dependencies, they're getting Guzzle v5, where our composer.lock only mentions Guzzle v7

[billinghamj]

I've set up a quick repo to diff between v4.6.0 and v4.7.0 - billinghamj/cf-wp@8d1ae51

This is a direct comparison between the ZIPs each version:

• https://downloads.wordpress.org/plugin/cloudflare.4.6.0.zip
• https://downloads.wordpress.org/plugin/cloudflare.4.7.0.zip

It appears that v4.6.0 simply didn't include Guzzle at all? Perhaps because it was only in the require-dev part, rather than the require bit?

[billinghamj]

ie

before: https://github.com/cloudflare/cloudflare-plugin-backend/blob/master/composer.json#L14-L18

after: https://github.com/cloudflare/Cloudflare-WordPress/blob/master/composer.json#L11-L16

Perhaps when the dependencies were moved, they were accidentally put in the wrong section? Would they work if only in the dev bit?

[ethanclevenger91]

The plugin should probably leverage the WordPress core request functions.

Alternatively, PHP-Scoper can prevent this as well by wrapping the plugin's version of Guzzle into its own namespace.

[billinghamj]

@jacobbednarz Tagging as you released v4.7.0 - are you aware of this, and is this thought to be a problem or more something we'll need to find a way around etc?

[jafowler]

@ethanclevenger91 Thanks for the PR! I'll see about getting it tested and run it through the team.

For context this is the PR that ultimately caused issues: #441.

It seems it was just an oversight when merging in the cloudflare-plugin-backend.

[charlesroper]

Hello - I was kindly directed here from the CF community forum. I had assumed there was only a trac/svn repo for this plugin otherwise would have come here first! Probably worth adding a link here to the development page?

I've just added a post to the plugin's support forum about this issue

Looks like there are a fair few people reporting similar issues on the support forum, but these are going unanswered, which makes it look like the plugin might be unmaintained.

[jordantrizz]

Hello - I was kindly directed here from the CF community forum. I had assumed there was only a trac/svn repo for this plugin otherwise would have come here first! Probably worth adding a link here to the development page?

I've just added a post to the plugin's support forum about this issue

Looks like there are a fair few people reporting similar issues on the support forum, but these are going unanswered, which makes it look like the plugin might be unmaintained.

Good luck, there's lots of dust around here. I think Cloudflare has abandoned this plugin, there are quite a few issues racked up.

[charlesroper]

@jordantrizz According to a reply from yevgen on the Cloudflare forum, this issue has been reported to the API team who are responsible for the plugin.

APO for WordPress is a flagship feature, and WordPress drives 43% of all websites, which is a huge potential customer base, so I would be surprised if it has been abandoned. According to Craft, there are currently 787 (!) job openings at Cloudflare, so it could be that current teams are stretched.

[pentatonicfunk]

im +1 for migrating to wp_remote_* from @ethanclevenger91 in #446. It would solve the issue, and its more appropriate in WP context, also resulting this plugin having less dependency to be maintained.

[jordantrizz]

APO for WordPress is a flagship feature, and WordPress drives 43% of all websites, which is a huge potential customer base, so I would be surprised if it has been abandoned. According to Craft, there are currently 787 (!) job openings at Cloudflare, so it could be that current teams are stretched.

It was a flagship feature, when it stops being updated or maintained then perhaps it's not? WordPress does drive a lot of websites, but how many actually use CloudFlare APO? There are alternatives out there. That's quite a few jobs, and I'm sure they're stretched since the IPO, acquisitions, and some of the recent product releases. Just seems like they need a dedicated person to commit to it.

[firatcf]

Hi folks. The fix should be out now, thank you for your patience.