-
Notifications
You must be signed in to change notification settings - Fork 16
Is there a reason the Address field is double-encoding some of the JSON? #65
Comments
Hmm… I'll take a look. An update to NSM Fields is on the schedule for this week. |
@leevigraham - you're definitely stringifying it explicitly here:
The field input is expecting it to be a string:
But i assume you can de-stringify it on submit and re-stringify it as necessary? It would definitely make more sense to have the whole thing stored as actual JSON (as well as being less of a pain in my personal ass). |
I'm submitting a pull request with the absolute minimum possible fix: it stringifies any unencoded array data for the text field display, and otherwise leaves everything exactly as is. This avoids any weird behavior from front-end forms, while otherwise keeping everything identical, @leevigraham . |
I still think in the long run you should probably just not stringify it in the first place, but this is a minimal fix that doesn't affect any existing field behavior. |
@leevigraham bump (making sure you see this!) |
@leevigraham : When you save an address field, it saves as JSON, of course. But the
placeData
key, which is the part that gets pulled in wholesale from Google Places/Maps, is string-encoded inside the JSON, so you get something in the database that looks like this:Is there a reason why you're not just storing the returned JSON as subkeys of
placeData
rather than stringifying (and therefore double-encoding) it?(I discovered the problem via writing a front-end interface to the field so we can use it on a guest form. Storing it without double-encoding it causes the back-end edit interface to throw an error about array-to-string conversion.)
The text was updated successfully, but these errors were encountered: