PLEASE NOTE: These forums are no longer utilized and are provided as an archive for informational purposes only. All support issues will be handled via email using our support ticket system. For more detailed information on this change, please see this blog post.

UserRegistration Plugin Rocks!

  1. First of all, I can't believe Gravity Forms - it has got to be the best money I've spent on a WP plugin! And the new User Registration plugin is total awesomeness.

    Couple of quick questions about the new plugin/version of GF::

    - Is there a way to not post a new post when a user is created? I'm creating a PODS data type on the back end and don't need a post created. Not a big deal since I can delete the empty posts, but it would be nice to have the option.

    - Password: I was creating accounts a different way before this plugin and had a "Password" field already established - really just a text field in password format. Is there a way to utilize this existing field instead of having WP create one automatic or use the new Password type where a confirmation is required? (Just like I could select the old Username field that existed in my form prior to this new plugin)

    - Image upload: If the user uploads an image, then adds a username that is already taken, then hits "submit" the page is redisplayed (with error message about username dupe) with the image name in place (like it is still good), then when you fix username and hit submit for the second time, it says that the image is missing. This is a little different behavior than 1.45 where the image was off the form on the redisplay, so it was more obvious to the user that they needed to re-add the image.

    Anyway, thanks for all the great stuff ya'll are doing!!!!! (And I apologize if these questions have already been asked, I searched the forum first, I promise)

    Posted 14 years ago on Friday December 24, 2010 | Permalink
  2. - Currently there is no way to prevent a post from being created without writing some custom code. It's possible to write custom code to use a hook to delete the entry that is created after the process is over. HOWEVER if you are using the PayPal Add-On with the User Registration Add-On we don't recommend this due to how they integrate.

    - Right now there is no way to use a different field other than an actual Gravity Forms Password field. This is due to validation that must take place, specifically with how WordPress handles passwords. It's all built in so right now it doesn't support using other fields.

    - Anytime you submit a form with a file upload field, once validation happens if there is an error the file upload field is going to have to be re-populated. There isn't much we can do about this as it's a browser security issue. You can't pre-populate file upload field values, the browser won't allow it. Otherwise you could have hidden upload fields that pre-populate to sensitive files on a users machine without their knowledge. It's an annoyance, but unfortunately it's how browsers handle the file upload input type.

    Posted 13 years ago on Monday December 27, 2010 | Permalink
  3. Hi Carl!

    Thank you for the timely reply to my queries. The first two make sense.

    The last one, regarding needing to reload the image, makes sense from a technical perspective, but I still feel that there is a usability issue at play. In the version prior - 1.4.5 - I believe that when the form reloaded after the error was displayed, the image area was blank, indicating to the user that they needed to reload. Now, in this version, when the page reloads, it still has the name of the image on the page (even with an x for delete) - which visually tells the user that the image is still loaded into the system. I think it would be more usable for the user to have a clear visual indicator that they need to reload the image. Maybe even, the image field could also become red with a message, "Please reload your image" - just a thought.

    The way that the current use case plays out, I think that what will end up happening, is that the user will always miss seeing that the image needs to be reloaded (because it still looks like it is loaded) and will have to submit a third time, which is another chance to loose the user for the webmaster. I'm wondering if there can be additional visual cues added for the user to know that he/she needs to reload that image.

    Thank you for your thoughts.

    Kirsten

    Posted 13 years ago on Monday December 27, 2010 | Permalink
  4. Is this a multi-page form? If so the file upload works differently.

    The upload actually occurs when they click "Next" and move to the next page. It has to occur at this point, because the field has to exist on the page in order for the browser to allow the upload. It doesn't happen at the final submit. So this could be a bug related to that.

    Is this a multi-page form or a form with AJAX enabled?

    Posted 13 years ago on Monday December 27, 2010 | Permalink
  5. It is a single page form. You can see the form on page: http://www.therapysprings.org/list-your-practice/

    You can see that the image has the name on the form and "delete" next to it. I have included a screenshot of the behavior here: http://www.therapysprings.org/gravity.jpg - but the form has been reloaded because of error. It visually appears to the user to still have the cache of the image loaded, even though the image is not loaded.

    Posted 13 years ago on Thursday December 30, 2010 | Permalink
  6. I understand now, I have replicated this issue locally and we will look into it. It is a bug.

    In multi-page forms the file upload occurs as soon as the user advances to the next page. So the upload has taken place, and exists which is why there is the file name and delete button instead of the upload field. BUT the form still thinks a file needs to be uploaded.

    The only resolution right now is to set the file upload field as not-required. We will correct this issue.

    Posted 13 years ago on Thursday December 30, 2010 | Permalink
  7. ah - makes sense, Carl - thank you for looking into this - you guys rock! Hava a great New Years!

    Posted 13 years ago on Thursday December 30, 2010 | Permalink