PayPal Standard communicates payment status changes to your site using IPN requests. To take custom actions based on the information reported by PayPal you will want to use the following hook gform_paypal_post_ipn - Gravity Forms Documentation
The $_POST variable gives you access to all the information received including the payment status.
I would recommend you to enable logging on the Forms > Settings page and then on the Forms > Settings > Logging page ensure that Gravity Forms Core and any add-ons are enabled and set to log all messages.
Then you can add custom logging statements to ensure your custom function is running when expected and dump information from key parts of your code to the log (that is way better than using var_dump() ), check instructions here: Custom Logging Statements - Gravity Forms Documentation
Regarding to the Auto Return feature, that’s controled by the PayPal site not by the add-on, you should find an Auto Return setting in your PayPal account. I’m sure PayPal support can help you further with this if you’re unable to find the setting.
So based on the reading I’ve turned on logging and i can generate logs. However, I have been completely unsuccessful at writing anything to the log. Tried the code below (in functions.php), checked the logs for Gravity Forms Core and for Gravity Forms PayPal Standard Add-On and nothing was written to the logs.
So I tried the exact same code on SiteGround (GrowBig) server and …FAIL!
So PayPal or not, I cant seem to write anything to the site while on SiteGround. To be clear, logs are generated on SiteGround, but custom logging -PayPal or Not- continuously FAILS to write to the log.
While I cannot test PayPal on LocalHost, I can confirm that custom logging does at least work …locally.
So if the lack of the string gform_paypal_post_ipn indicates that IPN is not working
That’s not correct, all the IPN stuff that you see on the log and the fact that you’re seeing the entry payment details being updated indicate the IPN handling is working.
The only issue here is that something on the SiteGround hosted site preventing your custom code from running. As pointed previously, I can’t replicate the issue you’re experiencing on a default WordPress installation, you have also confirmed the same basic logging code that is working on your localhost copy is not working on the SiteGround site, so the issue is tied to something on that site setup or the host.
I figured as much. Esp. since i’m seeing transactions. But that begs the question: so why no gform_paypal_post_ipn in the logs? …just curious.
Agreed. Local tests bear that out.
Will do. …more news as it happens.
Interesting plugin. …and by the great Otto, no less . But I already have starter plugin code. But does it matter that the tests are in functions.php? True, for best practices, I normally like to keep my functions.php file pretty clean. But now I’m curious as to why you are recommending a plugin? More for best practices (I assume), than for performance/functionality, correct? …or no?
Well, since its pretty much working locally, I will leave this as you have stated: last resort.
I’m gonna give the caching options a shot (thanks again for going the extra mile in providing the links ). If tweaking the cache fails, I’m off to SiteGround Support. I will report back.
The “something” in fact did turn out to be cache related. SiteGround is …well… “aggressive” with their caching (and their speedy sites show it). Also, they recently moved from Static Cache to NGINX Direct Delivery . Don’t know what role that may have played.
Their solution was to (temporarily) completely disable dynamic caching for the site. Then re-enable once testing is done. A bit draconian, maybe …but it worked. When time permits, I’m going to test whether I can be a bit more “strategic” using the SG Optimizer (I did exclude the form page, but it had no effect).