Support » Plugin: Constant Contact Forms » Admin page Crash (WSD) library conflict on GuzzleHttp

  • Resolved sjshaffer


    There is an apparent conflict with versions of GuzzleHttp used by this plug in and Dynamic Content for Elementor (DCE). After a recent upgrade to DCE the wp-admin page shows the white screen of death (blank). Disabling either plug-in restores access. Enabling debug and both plug-ins results in the dump below. Note that Constant contact Forms (CCF) is calling GuzzleHttp from DCE. Currently we have patched the site around DCE but this has resulted in significant loss of capability.

    Is it possible to place GuzzleHttp within a (the) class definition? This would insure that the version of GuzzleHttp in the CCF package is always called by CCF. Assuming DCE applied a newer version of GuzzleHttp then the CCF code will need to be updated to avoid the type mismatch before releasing CCF with a newer library revision.

    Dump (carriage returns added for clarity):
    Fatal error: Uncaught TypeError: Argument 3 passed to GuzzleHttp\Client::request() must be of the type array, string given, called in /home/sturdygi/public_html/ on line 95
    and defined in /home/sturdygi/public_html/
    Stack trace:
    #0 /home/sturdygi/public_html/ GuzzleHttp\Client->request(‘createRequest’, ‘GET’, ‘https://api.con…’)
    #1 /home/sturdygi/public_html/ GuzzleHttp\Client->__call(‘createRequest’, Array)
    #2 /home/sturdygi/public_html/ Ctct\Servic in /home/sturdygi/public_html/ on line 179

    Version Information:
    PHP Version: 7.4
    Wordpress:Current version: 5.6
    Constant Contact Forms for WordPress: Version 1.10.1 |
    Dynamic Content for Elementor Version 1.10.1
    elementor: Version 3.0.16
    Elementor Pro: Version 3.0.9

    • This topic was modified 9 months ago by sjshaffer.

    The page I need help with: [log in to see the link]

Viewing 5 replies - 1 through 5 (of 5 total)
  • Plugin Author Constant Contact


    Hi @sjshaffer

    Sorry to hear you’re experiencing this. Based on what I know from previous Guzzle conflicts, and as you’ve already noted, chances are that “Dynamic Content for Elementor” is using a more modern version of the library than we are.

    We haven’t completely found a way to get around this that we’re wanting to ship out to everyone. However, I also know that we’re looking at ways that we can release a newer version of our plugin that won’t rely on Guzzle at all. We’re just not there yet on either side of that coin.

    That doesn’t help your situation either. As is, are you technically up and running, in terms of the website not giving blank pages? Or is that still the case from time to time right now? I want to try and help get you back and going if needed.

    Thread Starter sjshaffer


    Yes, I’m up and have recoded everything around DCE, and disabled it, thus rendering the HttpGuzzle library they included unavailable. It has been a painful few days of work.
    I’m not a PHP expert by any stretch but is it possible in ListService.php to place the use statements in a method (probably a constructor) of ListService ? That way the functions are inside the class and not subject to being over written.

    • This reply was modified 8 months, 4 weeks ago by sjshaffer.
    Plugin Author Constant Contact


    If you’re referring to something like but inside the ListService class, then I think that’s going to end up failing more than anything.

    Glad to hear the site is up at least, and you’re not white screening or similar. I also wish we had a more immediate answer that could or would have alleviated much of the hassle you went through here.

    Thread Starter sjshaffer


    You are correct in that a namespace declaration can not be instantiated inside the class definition.
    Has the team checked to make sure that all class instantiations are within the namespace? There seems to be at least one instance outside the namespace.
    Alternately, including the files inside the class definition achieves the same goal but causes the libraries to be loaded for each new object instance.

    Plugin Author Constant Contact


    At present time, the plugin makes use of which is freely distributed. That’s what make use of the Guzzle dependency, and thus causes occasional cases of whose copy of Guzzle is loaded and thus used first. I’m personally hoping that a future update removes the reliance on Guzzle as a whole, and switches to the WordPress HTTP API for the communication, but we’re not there yet.

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘Admin page Crash (WSD) library conflict on GuzzleHttp’ is closed to new replies.