Odd behavior in GF 1.5 RC4 re admin labels etc

Gravity Support Forums » Plugin Support » Gravity Forms

John Murray
Member

I downloaded GF 1.5 RC4 and noticed a few oddities.

1) The Admin label isn't working for checkbox form fields. (It did work for a phone number field, and those were the only 2 types I tested.) For a checkbox field, the entry in the Admin label is ignored and the first checkbox value is used. Clarification: the Admin label is not shown on column view, but it is shown when viewing an individual form submission. When you edit the columns to appear in the Admin panel, the field name is not shown for a checkbox field. Instead, each of the checkbox values is shown.

2) When attempting to re-arrange the columns in the Admin panel, the Edit window comes up and the functionality works, but it takes a portion of the background image from the site. What I see is the top part white, and the bottom portion the site background, which makes it difficult to use. The site is running W3 Total Cache and this problem goes away when that is deactivated, but I was under the impression that plugin didn't cache admin pages.

3) I also set up the PayPal add-on. On the mapping of the PayPal fields to the Form fields, the width of the drop down extends well outside the viewport. I think that is because I have some long text in checkbox values, so that when you populate the list, you accommodate the longest value. I think it would be better if you shortened that and added an ellipsis if it were longer than some value. I didn't even realize there were drop downs until I finished my morning coffee :)

The forms for this are on draft pages, so if you wanted to see this live I'd have to email you login credentials. Just let me know if you want them.

Hope this helps.

Posted 13 years ago on Saturday February 12, 2011 | Permalink
John Murray
Member

Update: since too much time has passed, I can't edit my original post, so here's some additional info.

1) My error, sorry! I didn't appreciate the difference between the checkbox and multiple choice field types. I see the approach of putting the checkbox value as the admin label followed by a checkmark in the column display if that checkbox was selected. A reasonable approach, just not what I expected.

Additional items:

4) Conditional logic: After swapping some checkbox fields for multiple choice fields, I have 3 uses of conditional logic on a form. 2 work, the 3rd doesn't. It seems that you have to save the fields containing the values that will make up the condition before enabling conditional logic on a field, but even after doing that, for 1 of the 3 fields, conditional logic doesn't work.

5) I enabled values on a multiple choice field after there were a few form entries, all of which had a selection on the multiple choice field. I then proceeded to edit the entries, and upon edit, the selection of the multiple choice wasn't shown even though it was stored.

6) Using the PayPal addon (lastest RC or beta of GF and addon), I have IPN enabled and ran a live test of a payment. I received a message "Sorry - your last action could not be completed". I haven't had a chance to check PayPal, but I did receive an email that the payment was received. The record is marked with a status of "Processing".

As before, happy to supply login if that helps to solve my problems.

Posted 13 years ago on Sunday February 13, 2011 | Permalink
Carl Hancock
Administrator

1) Admin Labels aren't used for Checkbox items. Checkboxes function differently than Radio Buttons and Drop Downs. With checkboxes, each individual checkbox IS it's own field. Admin Labels only work with Checkboxes on the Entry Detail page itself where the checkboxes are grouped together. On the entry list page, the individual Checkboxes themselves are shown.

2) W3 Total Cache shouldn't cache admin pages. So for it to be causing this issue, there must be something W3 Total Cache is doing to cause this.

3) We will look into this. We aren't currently truncating the values, but it's certainly possible for us to do so.

4) If you have made any changes to fields being used for conditional logic you will have to re-configure the conditional logic. Changes to fields do not cascade down to conditional logic fields where that field name/value may have been used. You have to make sure if you made changes that you have adjusted your conditional logic accordingly. Conditional logic issues are typically related to making changes tot he field but not updating the conditional logic OR setting up rules that never actually occur. It's easy to overlook.

5) We will look into this. I know whats going on, if you remove the value from a drop down/radio button/checkbox field it's not going to appear when that field is displayed. When you edit an entry, it uses the form field data. But it should be retaining the existing value(s) also.

6) You would have to check your PayPal IPN history logs to see what happened and see if the IPN message was sent. If IPN did not update the entry that means it couldn't communicate with your site. Something on your site may have prevented it from communicating back. If you are using the Maintenance Mode plugin, for instance, this can prevent IPN from communicating with your site.

Posted 13 years ago on Monday February 14, 2011 | Permalink
John Murray
Member

Carl, Thanks for the replies. The one issue that remains in PayPal notifications.

On #6 (PayPal), I checked PayPal and the funds were received and messages were attempted but got HTTP 403 errors.

We're not running Maintenance Mode or any other plugin which would have blocked access to the site, but the page the form is on is a DRAFT page. Is that a problem? The form page is not the same as the notification page, is it? The notification URL shown in PayPal is simply the ?page=gf_paypal_ipn.

Posted 13 years ago on Monday February 14, 2011 | Permalink
Carl Hancock
Administrator

That could be why. Something had to have returned the 403 error to PayPal. Gravity Forms can't do that so something else returned the 403 error to PayPal which prevented the IPN from communicating with your site. It's possible that it was due to the page being a Draft, but the IPN URL is different than the form page itself. But then again, Maintenance Mode also can cause this issue so i'd never rule anything out.

Posted 13 years ago on Monday February 14, 2011 | Permalink
John Murray
Member

I made the page public then ran another test and still got back this message:

Sorry — your last action could not be completed

In PayPal, it shows a 403 error and the form submission is showing as processing.

The notifcation URL in PayPal is /?page=gf_paypal_ipn and that URL loads in my browser but takes me to the home page - is that where it is supposed to go?

I'm not running any plugins that should block access (like Maintenance Mode). I am, however, running W3 Total Cache, but I don't see how that would affect this. Any thoughts?

Posted 13 years ago on Tuesday February 15, 2011 | Permalink
Carl Hancock
Administrator

Yes, if you go to ?page=gf_paypal_ipn you aren't going to see anything yourself. It's listening for PayPal to pass data to it.

It's possible W3 Total Cache could be interfering, but typically if it's setup to ignore Gravity Forms queries (which it does by default usually) it's not a problem.

BUT do this, deactivate W3 Total Cache and then test again.

If it continues to happen we would need access to your site in order to debug the issue.

Posted 13 years ago on Tuesday February 15, 2011 | Permalink
John Murray
Member

I tried deactivating W3 Total Cache and re-did a payment 2X with the same result each time: namely that the form submission shows "Processing" and PayPal reports a 403 error.

To speed things up, I sent credentials + info sent via contact form.

Posted 13 years ago on Tuesday February 15, 2011 | Permalink
Chris Hajer
Key Master

I think the issue is the fact that the page is a draft. You can see the page and form because you are logged in. Paypal cannot. So, if the IPN URL is just the page where the form resides, plus ?page=gf_paypal_ipn then this will fail I think.

If the IPN url is different than the URL of the form page, plus that ?page=gf_paypal_ipn - then I'm unsure what's going on.

Is this where the IPN goes?

http://www.example.com/my-page-slug/?page=gf_paypal_ipn ? If "my-page-slug" is a draft, I think this will fail.

I have this issue sometimes when validating pages with the W3C before I publish. If I try to do it by URL, it errors out, because the validator.w3c.org site is not a logged in user on my site. So, I need to grab the source of the draft page and validate by direct input.

Hopefully that's all it is John, just the fact that it's a draft page.

Posted 13 years ago on Wednesday February 16, 2011 | Permalink
Carl Hancock
Administrator

Actually the IPN url doesn't include the page name. It is simply http://www.yourdomain.com?page=gf_paypal_ipn. The page doesn't exist, but Gravity Forms can detect when that URL is used and then execute the IPN handler.

When PayPal hits that page it actually posts to that page and it posts A LOT of data. All the transaction data, which is then parsed by Gravity Forms.

The problem in this case is PayPal is reporting they are receiving a 403 Forbidden error by his site. We are already in communication with John via email on this issue to determine why his server is returning a 403 error. It's possible the IPN post is triggering a firewall on his server to return a 403 Forbidden error because it thinks it's under attack due to the data IPN is posting to that URL. That is what we think is happening in this situation.

Posted 13 years ago on Wednesday February 16, 2011 | Permalink
Chris Hajer
Key Master

Thanks for the update Carl.

Posted 13 years ago on Wednesday February 16, 2011 | Permalink
John Murray
Member

Carl, I followed up with an email, but your suspicion that it was security-software related was on the right track.

Getting data back from PayPal was being blocked by the Bad Behavior plugin because PayPal's IPN wasn't supplying a user agent and, when activated, Bad Behavior requires one as part of its checking method. I've sent an email to the developer of Bad Behavior and will let you know what I hear.

After deactivating Bad Behavior, form submissions now are properly marked as "Approved".

The only thing that remains is that users still see the "Sorry- your last action could not be completed", even though all of the payment went through. In PayPal's IPN, the entry has a status code of 200 and "Sent". Is it possible that users are not clicking on "Continue" after making the payment? Do you have any idea what they could be clicking on to get that error?

Posted 13 years ago on Wednesday February 16, 2011 | Permalink
Carl Hancock
Administrator

Good to hear we were on the right track, we figured there was something blocking the request and what you described makes sense. Hopefully there is a way to configure the Bad Behavior plugin to ignore these requests.

Have you been able to recreate this "Sorry - your last action could not be completed" issue?

In order to return to your site the user has to click on the "Continue" button in PayPal after they make their payment. It should then redirect the user to your site and show your form confirmation message.

Where is this "Sorry..." message appearing?

Posted 13 years ago on Wednesday February 16, 2011 | Permalink
John Murray
Member

Carl - Thanks for the quick response. I'm not actually doing the test, but reporting the feedback I get from our tester. I think I have to do a submission on my own and complete the payment to figure out where the message is coming from.

On Bad Behavior, Michael Hampton gave me a very fast reply, which included in part:

"As for PayPal, this issue is their fault and they have known about it for years but refused to fix it. I suggest you send (yet another) complaint to them."

To get around Bad Behavior's block, you can whitelist the URL of the IPN endpoint by looking at about line 50 of plugins/bad-behavior/bad-behavior/whitelist.inc.php and adding a RELATIVE URL to the IPN endpoint like:

/?page=gf_paypal_ipn

You have to follow the syntax of the BB examples, and enclose the URL in quotes.

That will stop BB from blocking anyone to that URL.

Hope that helps the next person with a similar issue.

Posted 13 years ago on Wednesday February 16, 2011 | Permalink
Carl Hancock
Administrator

We'll make a note of this and include it on the new documentation for the PayPal plugin that will be launching when we launch our new site and the final 1.5 release at the end of this month.

Posted 13 years ago on Wednesday February 16, 2011 | Permalink
John Murray
Member

Carl - A couple of things...

First, I need to amend the instructions above for modifying Bad Behavior's whitelist.inc.php file. Whitelisting a URL doesn't work because of the way Bad Behavior processes the URL. It starts with the / after the domain and stops with the first ?, resulting in nothing being whitelisted. Instead, the correct approach, which I just tested several times, is to whitelist the IP address of notify.paypal.com, which is 66.211.170.66. IP's are whitelisted in the /whitelist.inc.php file around line 13. If a user is running BB and the GF PayPal Add On and suspects that IPN is being blocked, he should check the BB log file (accessible on the Plugins page), which shows the IP address of what was blocked. That covers the prospect that PayPal changes its IP.

Second, I just tested several payments myself, and after pressing Continue, I didn't make it back to my GF form page. I still get "Sorry - your last action could not be completed".

For my GF PayPal Transaction Settings, my Page Style is blank. Is that ok? Are there any settings I need to make in my PayPal account? It seems on the GF form side, the only setting is to check off that IPN is enabled, which I've done. Could it be because I am making a payment with a credit card associated with a PayPal account, even though I am selecting not to make that payment using my account?

Any thoughts on why PayPal isn't sending me back to the form page?

Posted 13 years ago on Saturday February 19, 2011 | Permalink
Carl Hancock
Administrator

The PayPal options for things such as Page Style are optional, they aren't required. Page Style has to do with a custom page template that you can setup in PayPal. None of these extra options are required.

We haven't had any other reports of PayPal not passing the user back to the site after they click continue. This "Sorry your last action could not be completed" is a PayPal error, it's not coming from Gravity Forms.

It's possible it is because you are making a payment with a credit card associated with a PayPal account but you aren't doing it via your PayPal account although typically PayPal will give an error saying that card is already associated with a PayPal account. Can you try doing the checkout using an actual PayPal account rather than credit card not through PayPal?

There is no reason why PayPal shouldn't be sending you back to your site.

Posted 13 years ago on Saturday February 19, 2011 | Permalink
Dewey Bushaw
Member

I know this thread is a year old but I was just having this issue out of the blue on http://casabettingbythebay.org/ We were taking payments fine until yesterday.

Error Screenshot: http://casabettingbythebay.org/paypal-error.png

To fix it we had to edit the paypal form and not sned the Email under the "Customer" form PayPal Fields. Hope this help anyone who may run into this.

Posted 12 years ago on Friday July 20, 2012 | Permalink
growthspark
Member

I was having the same issue as inkdevs, so I removed "Email" field under PayPal Transaction Settings at Forms -> PayPal. This solved the problem. Not sure why that particular field is causing a conflict with PayPal, but the plugin developers should definitely be aware of this.

Posted 12 years ago on Monday July 23, 2012 | Permalink
Chris Hajer
Key Master

The developers have been made aware of the issue. Thank you for bringing it to our attention.

Posted 12 years ago on Monday July 23, 2012 | Permalink

This topic has been resolved and has been closed to new replies.