Are you referring to manually setting the Address field in the Database accessible via the Dashboard? If so, we are aware of the fact that Address is not yet supported there. I updated the team responsible for it that this feature will soon become critical for users of the Address Input.
As for binding to a Text element: what parts of the address would you like to display? In what format? Would you like to display it in languages other than English? Any other requirements?
I am afraid I am not allowed to give any estimates on when we will re-open the Beta, but can tell you that we are actively working on it with the intention of re-opening soon.
“Are you referring to manually setting the Address field in the Database accessible via the Dashboard?”
Yes i was
“As for binding to a Text element: what parts of the address would you like to display? In what format? Would you like to display it in languages other than English? Any other requirements?”
I would like to display the full address for starters, but it would be amazing to have format options to display only the Postal Code, or Street Name or Number or City/County.
Hi, Maybe I’m doing something wrong but I cannot find the Address Input. Code menu is open. I have databases. I click add, and I don’t see anything that looks like Address Input. Am I doing something wrong or is it my Dutch language-setting? I’m open to suggestions.
It is with the utmost pleasure that I wish to inform you of the grand re-opening of the Address Input beta. OK, perhaps not utmost pleasure, but I sure am pleased by it.
Based on your excellent feedback (keep it coming!) we’ve made inherent changes to the way the element works.
Fixes & Updates:
The Address Input now works in Firefox.
The Address Input now works when you restrict the usage of your Google Maps API key to your website using Google’s HTTP Referrers mechanism. In fact, we argue that you should use this mechanism to protect your key from use in other websites.
We have rewritten the help article on how to generate and secure your Google Maps API key . Would very much appreciate feedback on it. Are the instructions simple and easy to follow?
All Address Input elements on your website must now share that same API key. We understand that the current need to paste the same key over and over makes little sense, and plan to move this key management logic to the site Dashboard. However, we decided not to delay the re-opening of the beta until we do this as it may take us some time.
We removed the option to set a Display Language per Address Input. We may re-introduce this feature when we move the key management logic to the Dashboard. The same language will apply to all Address Input elements though. Currently the language will always be English. You can still filter the search results by country per Address Input.
Known Issues:
If you change your Google Maps API key you have to refresh the Editor before the new key can be used in Preview mode. We are looking into fixes but it may be that we will not be able to remedy this before we move to site-level management of the API key.
Keyboard navigation doesn’t work for the box itself (it does work for the auto-complete results). We are working to fix this.
Address field type is not yet supported in the Dashboard’s Database view. We are working to support this.
Cannot connect the Address Input to a dataset with Read permissions (only “Write only” permissions). We are working to fix this.
@shantanukumar847 Per your concern about the API key showing up in the error presented to visitors: as you’ve mentioned you can restrict use of the key to your websites only via the HTTP Referrers mechanism in the Google Maps Platform dashboard. In fact, we think you should do this to protect your key.
Catching all error messages reported by Google and removing your key from them may be possible, but it doesn’t guarantee your safety. This type of key is designed for client-side use and it can be retrieved by users inspecting your website.
@naimibaby We have decided to remove Display Language altogether for now. We may re-introduce it (with all the languages supported by Google) when we move the entire key management logic to the Dashboard (more details in my post below on the re-opening of the beta).
Wanted to ask you about your use case.
Do you need the Display Language in addition to the Filter By Country feature?
If so, how do you decide what language to set the Address Input to? Should it match the Wix Multilingual language? Should it match the browser language? Do you wish to set it manually based on other considerations?
@roberthamilton Well, the team developing the new data manager is currently working on adding support for the Address field type, so if all goes according to plan you expect it in the near future.
@eyalc Hi,
i’m actually want it to manual case that i want customers enter their city or street in Hebrew and get list of the addresses to chose from and then save the city name or street name in the database in Hebrew
if you need better explanation please contact me
i also find some bugs in the editor that really annoying
@naimibaby Your explanation is clear - keeping the addresses in Hebrew in the Data Collection has clear benefits for users. I wanted to understand whether setting “Filter by country” to Israel would be good enough for your use case, and now it is evident it isn’t.
The next question that comes to my mind is based on what do you decide to display the addresses in Hebrew or in English. Should you always use Hebrew for Hebrew sites and English for English ones? Will you ever want English addresses in a Hebrew site, or Hebrew addresses in an English site?
The reason I am asking is because it can take us a while to add manual language support again.
The Google Maps API supports a single language for addresses across your website, so one language for all Address Inputs.
This means the address language settings belong at the website level, for example: in the Dashboard. We also want to move the API key management to the Dashboard, so you wouldn’t have to go through the error-prone routine of pasting it in every Address Input - but as I mentioned this could take a while.
So in the meantime I are trying to figure out if we can provide a good strategy for choosing the address language, something better than the current “always use English” strategy.
Will call you in a few minutes to hear all about the Editor bugs. Thanks!
@naimibaby We changed the way the Address Input language is determined.
Whereas we do not support manually selecting the Address Inputs language from a list yet**, we did implement the same strategy as the reCAPTCHA Element. Namely:
If the site is Multilingual use the active Multilingual language
Otherwise use the language set in the Dashboard under Settings > General Info > Regional Settings
Note that the language under Regional Settings defaults to the language of your account at the time the website was created.
** The Google Maps API language needs to be set at the website level. We are working on a mechanism that will let each Address Input retrieve site-level settings.
Example scenarios:
You are building a Multilingual website with English and Hebrew :
In the English version of the website your Address Inputs will suggest addresses in English, and the Hebrew version they will suggest addresses in Hebrew
You are building a Hebrew website while your account language is set to Hebrew (your Dashboard and Editor are in Hebrew)
Address Inputs will suggest addresses in Hebrew (because your Regional Settings > Language is set to Hebrew)
You are building a Hebrew website while your account language is set to English (your Dashboard and Editor are in English)
Address Inputs will suggest addresses in English. If you want them to do so in Hebrew instead, change your Regional Settings > Language to Hebrew.
Hi I am trying to use this for a new client who is setting up a website for students to review their accommodation. I have set up the address fields in the database and I can see how it pulls the address from google when I input directly into the database. I will have a stab at connecting the google api and keep you posted.
I see this is a great input feature but does this help me search or filter data better? Sorry if this seems the most basis of questions but trying to work out if this will benefit the site from a search and or filtering perspective… Thanks
