Forum Replies Created

Viewing 15 replies - 46 through 60 (of 201 total)
  • Plugin Author Chris Lagasse

    (@soben)

    Resolved through Big Sea support tickets, and Conditionals are now possible in 4.0

    Plugin Author Chris Lagasse

    (@soben)

    Well, that is a ridiculous solution.

    I encountered something similar recently on a separate project (user registration triggering redirect, so ajax calls were failing)…

    Good to know, and I’ll try to figure out a way to add a warning in the Feed setup if the form is set to have a redirect (or at least a general notice to make sure it doesn’t) if I can’t figure a way around.

    -Chris.

    Plugin Author Chris Lagasse

    (@soben)

    Hey Mellissa,

    Have you updated your domain’s SSL as well in the interim? It seems weird that my code would be stopped because of HubSpot having a new domain associated with it on their end.

    However, the error from Guzzle (which handles the call to HubSpot) implies that the SSL certificate at HubSpot is no longer valid for the domain that it is expecting.

    I know on our end we aren’t storing the SSL verification or even domain, from the HubSpot side of things… all we keep is the auth token, and the token for renewal.

    A preliminary search seems to imply that you want to enable the VERIFYPEERS setopt call for cURL, but I’m not overly familiar (or trusting) of the idea of just disabling what is essentially a security check.

    Plugin Author Chris Lagasse

    (@soben)

    Hey Thad,

    I’ll have to check on my end, but I do believe I include a certificate set that is valid at this time, and there have been no issues on my end.

    Can you confirm that cURL works fine for you outside of our plugin?

    I tested on my command line (testing locally) like so:

    ~ curl -H --url https://google.com
    <HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
    <TITLE>301 Moved</TITLE></HEAD><BODY>
    <H1>301 Moved</H1>
    The document has moved
    <A HREF="http://www.google.com/">here</A>.
    </BODY></HTML>

    But that doesn’t check for ssl certificate as far as I know.

    • This reply was modified 8 years, 2 months ago by Chris Lagasse.
    Plugin Author Chris Lagasse

    (@soben)

    hey ncp562, I’ll work on getting a fix up for this this week.

    -Chris.

    Plugin Author Chris Lagasse

    (@soben)

    Hey slmnm,

    Sorry for the delay on this, We have been busy.

    Are you able to check the code and confirm that cURL indeed has the curl_reset function available, and what the constant “PHP_VERSION” contains?

    As I mentioned in my response, those are the two things I check to make sure you’re using the right version of PHP and cURL… and are the only two things that can stop you from using the plugin with the error message described.

    Thanks,
    -Chris.

    Plugin Author Chris Lagasse

    (@soben)

    Hey rawbstone,

    In order to check for both of those pieces of system configuration, I check for the specific components that I need in order to run.

    if (version_compare(PHP_VERSION, '5.5.0', "<")) {
        return false;
    }
    
    if (!function_exists('curl_reset')) {
        return false;
    }
    
    return true;

    curl_reset is found only in PHP 5.5 and higher that includes cURL… Have you confirmed, via Gravity Forms’s “System Status” (Forms > System Status) that WordPress (and especially GF) recognizes your PHP7?

    I’ve had another thread on here before in which someone believed they had PHP7, but turned out they didn’t. Not saying that’s your case too, but just wanted to confirm, before continuing working to resolve.

    Thanks,
    -Chris.

    • This reply was modified 8 years, 3 months ago by Chris Lagasse.
    Plugin Author Chris Lagasse

    (@soben)

    Hey Scott,

    What version of PHP are you running? Are you using the latest Gravity Forms plugin?

    Only time I’ve seen any kind of bugs such as things, it’s always fallen on:

    1) PHP Version
    2) Another plugin conflicting with the Vendor library (Guzzle), in which the other plugin is using a much older version of the Guzzle library.

    I’d love to dig into this further, but more information is definitely needed.

    Thanks,
    -Chris.

    Plugin Author Chris Lagasse

    (@soben)

    Hey ivdimova,

    I’m working on the plugin this week, so I’ll add that for you, and get back to you here 🙂

    -Chris.

    Plugin Author Chris Lagasse

    (@soben)

    Hey Nick!

    Glad that it was fixed! And absolutely no worries about “bothering” me, as it helps me know of common, potential, issues and can more quickly resolve problems in the future.

    Thanks for keeping me updated, and have a great weekend!
    -Chris.

    Plugin Author Chris Lagasse

    (@soben)

    Hey Nick,

    This is curious and unfortunately I do not have any immediate information for you. I will have to dig deeper and get a multisite configuration going to test.

    But two things I’d immediately note:

    Do you have any other “feed”-based plugins set up for GravityForms (such as Stripe?), and do those work fine? This error text is from GravityForms itself and is a default… I don’t even modify the standard save feature beyond default GF FeedAPI handling.

    I’m curious if its the special character sets (as you’re using German) that could be affecting things. Does your first site use the German character set as well in the form fields names/values?

    -Chris.

    Plugin Author Chris Lagasse

    (@soben)

    Hey magnetiknyc,

    Sorry for the delay, I was gone for the holidays…

    When I generate the page data to send out to HubSpot, I call out for third parties (such as your site/theme/plugin) to modify the data…

    However, it seems that you’re not talking about the hubspot contextual data but data specific to your form?

    You can modify the pageURL, pageName, and any context via programming,

    'pageUrl'   => apply_filters( 'gf_hubspot_context_url', site_url() ),
    'pageName'  => apply_filters( 'gf_hubspot_context_name', rgars($form, 'title') ),

    For pageURL and PageName, or any of the remaining data on the outgoing call:

    apply_filters( 'gf_hubspot_data_outgoing', $data_to_hubspot, $form, $feed );

    Hope this helps.

    Plugin Author Chris Lagasse

    (@soben)

    Hey Dustin,

    Possibly. The issue is that Guzzle has been updated, and W3 is loading before our plugin, so it’s loading their version of Guzzle. I’m assuming all of your plugins are up to date?

    We do not have any sites that run W3 Total Cache, in preference for other caching solutions (especially ones provided by our host at WPEngine)… so I’ll need to get that plugin installed locally and check for conflicts.

    I may look into a “dev-specific” version of our plugin that won’t be updated here, but accomplishes the same thing, that runs an earlier version of Guzzle. I will have to tinker with that. We have another client who has problems due to PHP versioning, and both problems may be solved in the same situation.

    Plugin Author Chris Lagasse

    (@soben)

    Hey Victor,

    Have you confirmed that your form still exists on HubSpot? That’s the most common cause of the 404.

    My first suggestion would be to recreate the Feed in Forms > Form In Question > Settings > HubSpot…. delete the current feed, and create a new feed.

    If this does not work, I have seen other solutions in which people recreated their form in hubspot. I’m not entirely sure why that makes a difference, though, and I have not been able to replicate the bug in which that is the solution.

    Plugin Author Chris Lagasse

    (@soben)

    Hey dustingtaylor,

    I’ve encountered this once before, and it’s because there’s another plugin also using Guzzle, and unfortunately using an outdated version.

    I will try to provide an additional check to make sure that method exists, but you still would require to update the Guzzle on a different plugin/theme in order to use our plugin, unfortunately.

Viewing 15 replies - 46 through 60 (of 201 total)