Support » Plugin: Constant Contact Forms » Conflict on guzzlehttp library version

  • Resolved zudie


    WordPress and all plugins updated.
    When XCloner is activated we get a fatal error in the backend when we try to modify a certain Custom Post Type.
    Does not happen on regular Pages and Posts.
    Does not happen when XCloner deactivated.
    Does not happen when Constant Contact Plugin is deactivated while Xcloner is active.

    CC plugin is the official CC plugin: Constant Contact Forms for WordPress.

    This is the error message:

    Fatal error: Uncaught TypeError: Argument 3 passed to GuzzleHttp\Client::request() must be of the type array, string given, called in /home/…./wp-content/plugins/xcloner-backup-and-restore/vendor/guzzlehttp/guzzle/src/Client.php on line 87 and defined in /home/…./wp-content/plugins/xcloner-backup-and-restore/vendor/guzzlehttp/guzzle/src/Client.php:126 Stack trace: #0 /home/…./wp-content/plugins/xcloner-backup-and-restore/vendor/guzzlehttp/guzzle/src/Client.php(87): GuzzleHttp\Client->request(‘createRequest’, ‘GET’, ‘https://api.con…’) #1 /home/…./wp-content/plugins/constant-contact-forms/vendor/constantcontact/constantcontact/constantcontact/src/Ctct/Services/BaseService.php(69): GuzzleHttp\Client->__call(‘createRequest’, Array) #2 /home/…./wp-content/plugins/constant-contact-forms/vendor/constantcontact/constantcontact/constantcontact/src/Ctct/Services/ListService.php(31): Ctct\Services\BaseService->createBaseR in /home/…./wp-content/plugins/xcloner-backup-and-restore/vendor/guzzlehttp/guzzle/src/Client.php on line 126

    I reported this to developer of Xcloner and this was his reply:

    You will need to ask the Constant Contact Forms developers to update their code,xcloner uses version 6.x guzzlehttp library while they use version 5.x.

    Their code loader seems to load incorrectly the xcloner guzzle lib and not their plugin vendor one.

    Can you please fix this?

Viewing 12 replies - 1 through 12 (of 12 total)
  • Good day @zudie.

    Interesting situation overall. Looking things over, there are definitely some discrepancies as a whole here.

    Guzzle 5.x has PHP 5.4+ support still. Guzzles 6.x has PHP 5.5+ support.

    Because of this detail, we had opted to stick with the Guzzle 5.x branch, as we are opting to still support that level of PHP users.

    The curious thing is that XCloner states their minimum PHP version supported is also PHP 5.4, but they’ve opted for the Guzzle 6.x branch. Unsure if they’ve lucked out and just not had anyone encounter conflicts, or they’ve been lucky in that everyone has had PHP 5.5 or higher.

    Nonetheless, because of this detail, we’re a little hardpressed to upgrade our copy of the library at the moment.

    And what about this comment:
    Their code loader seems to load incorrectly the xcloner guzzle lib and not their plugin vendor one.

    I’m not very happy with my site giving fatal errors on conflicting libraries. Don’t even get why either of these plugins would want to load something if we just want to update a post in the backend.

    Understandable frustration by all means. Not faulting you at all for that part. The parts I’m trying to figure out is why the Xcloner guzzle client class is being loaded instead of the one we intend, for our needs, and how to potentially prevent it. That part I don’t have an answer for yet.

    I have noticed that XCloner’s WordPress plugin is available to download for free, which will definitely help with crafting possible solutions.

    Thanks for looking into that.

    Would you be willing to try a hotfixed version of the plugin? I juggled around some loading order for some details on our end, and at least from my bits of testing, the conflict is gone. However, you’re more integrated and set up with Xcloner than I am, so I don’t if this change flips the sources of breaking around or not.

    I have a dev environment that i can try it out on.

    Please try this version out:

    Should be able to be extracted directly into the plugins folder.

    Thanks for helping with testing/confirming.

    Put your plugin version on my dev environment and the error is gone.
    FYI: we got the error when opening a Custom Post Type (Tour Date) created by WP Types. Not sure if it is relevant, but someone else might experience the same error.

    Thanks for your help and quick fix!

    Can you test out the Xcloner functionality as well, if you haven’t much yet? That’s my main concern, where I’m wondering if we “flipped” things at all.

    To help explain, I moved when we loaded some of our libraries to a later point, and I believe this is putting things in a different order compared to what it was at. This is also why I’m wanting both plugins checked on. If our copy is now being loaded last, it’s possible that XCloner will try to use our Client class from Guzzle, instead of ours using theirs.

    We use XCloner only for a quick backup, not for scheduling or anyhting. I ran a full backup and that seems to go just fine.

    Noted. Thanks for all the help and sticking with us.

    Plugin Author Constant Contact


    Closing as changes that address the problem are known.

Viewing 12 replies - 1 through 12 (of 12 total)
  • The topic ‘Conflict on guzzlehttp library version’ is closed to new replies.