[Clifford Paulick]

I tested and version 2.0 beta 7’s Auto-Locator works.

Thank you.

[Clifford Paulick]

With version 2.0-beta-7

Screenshots attached.

The data is not “coming through” to the Profile Update gravity form.

I did not attempt submitting the Profile Update gravity form to see if the data would get cleared out.

Here’s how I’d expect it to work if data was already in user profile (as in my screenshots):

1) profile update gravity form would pull in user’s current information (currently it doesn’t and is just blank). This includes mapping the lat/long.

2) if profile data is present (#1) and user deletes all fields (i.e. clears out data) and submits form (assuming field isn’t required), then “blank” data should overwrite current profile data (i.e. clear out data).

 

The current workaround is to require the field, which means to overwrite the existing data each form submission. (I guess *technically* for #1, above, if data was pulled into the form and user never touches the field, it would be re-saving back to user’s profile data.)

 

Thanks for working hard on this issue. I see it has the potential to go a couple different directions / preferences.

[Clifford Paulick]

1) The form field is present but left completely blank. Thus, it acts inconsistently. Either it should blank everything out (as if BLANK was entered, although I think this is wrong) or it should leave all data untouched (i.e. not overwrite existing data with BLANK)

2) I was referring to using your GF add-on alongside https://wordpress.org/plugins/gravity-forms-post-updates/

[Clifford Paulick]

Could you please elaborate on this?

Otherwise, the location will be saved in the custom fields by default.

Do you have any insight to how the geo_public field would be used? Is it something to maybe incorporate into this plugin or would you recommend just using an additional GF form field (radio or checkbox)?

In your opinion, do you think the ‘full address’ or the ‘formatted address’ is be the proper choice for the geo_address field?

tyvm for the insights.

[Clifford Paulick]

Doh! Thanks!!! 🙂

[Clifford Paulick]

Ok, weird. The site I was working on (the one I previously said drag-and-drop worked as expected) and on a local dev site — both with GF 1.9.9 and this plugin Beta 5 — there aren’t ANY geo field types (see screenshot)… UNLESS you go to edit a form that ALREADY had geo fields added to the form!

Same issue for Beta 4 and Beta 3 and v1.5 (non-Beta) — all fresh downloads from today.

In other words, no version was able to make the fields show up on a form that didn’t already have geo fields. Which confuses me because how did one of those fields get there in the first place then? Maybe when you logged into my site and fixed some things to get it working in the first place?

FYI: activating v1.5 resulted in a WP_DEBUG message:

Warning: include(includes/ggf-front-end-classes.php): failed to open stream: No such file or directory in /wp-content/plugins/gravity-forms-geo-fields/geo-fields.php on line 88

[Clifford Paulick]

I can confirm Beta 5 worked with drag-and-drop form fields. It also detected a duplicate (Address) field type and said something like “only 1 Address field can be used per form” — nice that that message didn’t say “only 1 Untitled field can be used per form.” 😉

 

Heads up: plugin folder name changed from ‘gravity-forms-geo-fields’ to ‘gravityforms-geolocation’

That’s fine for beta, but it may cause issues for people who auto-update.

[Clifford Paulick]

Not referring to any specific/existing field. Just saying that if you add a “timezone” field, you could at least narrow it down to the correct country (USA) and pick from one of those timezones (Hawaii, Alaska, Pacific, Mountain, Central, Eastern) and try to auto-select one for them (Central).

Another thing I thought of is that some places don’t observe Daylight Savings Time, so you could add a checkbox as part of the timezone field(s) that the user can specify “Central – Yes” or “Mountain – No”. Reference: http://en.wikipedia.org/wiki/Daylight_saving_time_in_the_United_States

Yes, I know geo via IP isn’t perfectly accurate (if going through a VPN or detecting someone on a border, etc), but it can make answering the question of “what’s your timezone” DRASTICALLY better than WordPress’ General Settings picklist that includes many duplicates (e.g. Chicago and Dallas) and can’t be narrowed down/sorted.

[Clifford Paulick]

Additional reference (and additional field types that could be added!): http://gf19.chrishajer.com/capture-geolocation-information/

And there are many other JS solutions out there for detecting a browser’s timezone (example use case: setting it per user in their user profile).

[Clifford Paulick]

Glad to hear you tracked down the issue! Thanks for your hard work!

[Clifford Paulick]

I have only tried dragging

[Clifford Paulick]

I tested and the 3 fields worked together as desired. Thank you.

However, the “untitled” issue for new fields is still happening.

So I deleted the auto-locator field, saved, and re-added it. It’s still doing the thing where the field isn’t usable (see screenshot).

Maybe it’s a browser issue. I’m on iMac 5K, OS X Yosemite 10.10.3, Chrome version 42.0.2311.152 (64-bit).

What browser are you using where adding new fields is working properly?

[Clifford Paulick]

Gotcha. No biggie to me because I just started using your add-on.

However, v1.5’s personal locator + address autocomplete + map fields worked together.

Beta 3 and 4’s personal locator + address autocomplete + map fields do not. Just the locator + map work together. This is after removing the v1.5 “text” field and adding the Beta 3/4 Address field.

[Clifford Paulick]

This reply has been marked as private.

[Clifford Paulick]

This reply has been marked as private.

[Author]

Posts