Gravity Forms Address Autocomplete - WordPress Plugin

Guide to Configuring and Testing Gravity Forms Address Autocomplete

Gravity Forms Address Autocomplete is not about making a form look nicer. It is about reducing address errors: the user starts typing a street or place, picks a Google suggestion, and the plugin fills the standard Gravity Forms address field. This guide focuses on the practical side: what to prepare before installation, where to enable suggestions, how to set country restrictions, when to add a map, how to verify coordinates, and what to do if suggestions do not appear.

This material is intended for a site owner, webmaster, or developer who already uses Gravity Forms and wants to add address autocomplete cleanly to a request form, registration form, service booking form, delivery form, listing directory, or local community form. It does not cover purchasing or license activation - only working with the installed product, WordPress settings, Google Maps Platform, and the form itself.

Special attention is given to limitations. The plugin depends on the Google Places API and Maps JavaScript API, uses a Google key, sends the typed address to an external service, and runs through JavaScript on the public-facing site. That is why proper testing matters more than simply checking a box in the field editor.

What Problem Address Autocomplete Solves in Forms

The standard address field in Gravity Forms is useful because it is already split into street, city, state or region, ZIP code, and country. But the user still has to type everything manually. On mobile, that turns into a long text entry, and submitted forms often end up with typos, inconsistent city formats, missing ZIP codes, or the wrong country.

Gravity Forms Address Autocomplete adds a Google Places suggestion layer to the standard Address field. The user types a few characters, sees a list of matching places, selects the right option, and the address is distributed across the form subfields. For the form, it remains a regular Address field. For the visitor, it becomes a faster, more familiar way to enter an address.

In practice, the plugin is especially useful when the address affects the next step:

• A request for an onsite technician, delivery, property appraisal, or another local service.
• An event registration form where the organizer needs participant location data.
• A directory of properties, locations, offices, events, or listings where the address is later mapped into custom fields.
• A contact form for a multi-location company where it is important to identify the lead's city, district, or region.
• A multi-step application where the user should not get stuck on a long address section.

That said, autocomplete does not replace data verification. If the user picks a similar but incorrect address, the form will accept exactly that location. For important workflows, it is worth adding an explicit verification step: show the completed subfields, display a map, or ask for a short confirmation before submission.

When the Plugin Fits, and When Another Approach Makes More Sense

Gravity Forms Address Autocomplete works well on sites where the workflow is already built around Gravity Forms. It does not require switching to another form builder, does not force you to create a separate field from scratch, and uses the standard Address field. That is the main difference from more generic solutions that add separate geolocation fields but fit less neatly into existing Gravity Forms notifications, confirmations, and entries.

Who the Product Usually Fits

The plugin is a good choice if you want to keep the familiar Gravity Forms editor and improve only address entry. This matters most on projects where forms are already tied to notifications, CRM workflows, WordPress post creation, user roles, or manual lead processing.

• The site already uses Gravity Forms as its primary form builder.
• You need the address in a structured format, not just as a single line.
• You need latitude and longitude for a map, directory, or later filtering.
• Addresses are entered frequently, and manual entry errors genuinely interfere with processing submissions.
• You are prepared to configure and restrict a Google Maps Platform key.

When It Is Worth Pausing and Reconsidering

Not every address workflow needs this kind of plugin. If the form collects an address once a month and a manager reviews the data manually anyway, Google integration may be more than you need. If the site serves an audience for whom sending typed addresses to Google is undesirable under internal rules, it is better to align the privacy policy and legal text first.

The plugin may also be the wrong fit if you need a map point picker, route building, nearest-location search, hard geofence boundaries, or advanced address validation. Gravity Forms Address Autocomplete helps users select and structure an address, but it does not turn a form into a full logistics system.

Practical rule of thumb: if the main pain point is "users type addresses slowly and inaccurately in Gravity Forms," the plugin is a good fit. If the real issue is "we need to validate delivery areas, build routes, calculate distance, and verify addresses against postal rules," autocomplete alone will not be enough.

What to Check Before Installation and Enablement

The most common mistake with address suggestions is assuming that installing a WordPress plugin is enough. In reality, the product works at the intersection of three layers: Gravity Forms, the Gravity Wiz perk, and Google Maps Platform. If one layer is not ready, the field may look correct while suggestions never appear.

Basic Site Readiness

Start by checking the form and page without autocomplete. The Address field should render, submit, and save entries correctly. If the standard form already conflicts with the theme, cache, popup, or page builder, adding Google Places will only make diagnosis harder.

• Gravity Forms is installed, and the form with the Address field works without JavaScript errors.
• The page does not contain two identical inserts of the same form.
• The theme does not hide address subfields through custom CSS.
• Optimization plugins are not combining or deferring critical Gravity Forms scripts without testing.
• You have access to Google Cloud Console to create a project, enable APIs, and restrict the key.

Google API: What You Need in Advance

According to Gravity Wiz documentation, this product requires two services: Places API and Maps JavaScript API. It is important not to enable only one of them by mistake. Places provides suggestions, while Maps JavaScript API loads the client-side library on the page. If you enable the wrong service or restrict the key too aggressively, the field may quietly remain a regular address field.

The Google key will be visible in the page source because Maps JavaScript API runs in the browser. That is normal for this kind of integration, but it requires proper restrictions: allow the key only for the domains you need and only for the APIs you need. Do not use one shared key for your site, mobile app, server-side requests, and test experiments.

Legal and User Context

When a user types an address, the request is sent to Google to fetch suggestions. For most commercial sites, that is a standard integration, but it is still worth reflecting in the privacy policy or in a short note next to the form if the address is a sensitive part of the submission. Be especially careful in healthcare, social services, government, and local service scenarios where an address may reveal someone's personal circumstances.

Installation and Initial Testing Without Unnecessary Risk

Installation starts like any regular WordPress plugin: upload the archive, activate it, make sure Gravity Forms detects the new perk, and open the settings. But the initial test is better done on a copy of the form or on a private test page, not on the main form with live traffic.

A Safe Rollout Sequence

1. Create a copy of the form or a temporary test form with a single Address field.
2. Make sure the standard form submission works without autocomplete.
3. Add the Google key under Forms - Settings - Autocomplete.
4. Open the Address field in the form editor and enable Enable Google Address Autocomplete in the field settings.
5. Save the form and insert it on a test page only once.
6. Open the page in a regular browser window and in private mode, start typing an address, and choose a suggestion.
7. Submit a test entry and check the record in the Gravity Forms admin area.

If everything works on the test form, move the configuration to the live form. This approach takes a little more time, but it immediately narrows down where to look if something breaks: the Google key, the Gravity Forms field, the page containing the form, or an optimization conflict.

What Counts as a Successful First Launch

After selecting a suggestion, the main address subfields should populate: address line, city, region, ZIP code, and country, as long as those data points are available for the selected place and field format. If a map field is added, it should center on the selected address and show a marker. The form entry should save not only the visible address subfields but also the coordinates, if you plan to use them later.

Post-Install Configuration: Key, Countries, Field, and Map

The main Gravity Forms Address Autocomplete setting lives at the Gravity Forms level, while enablement happens at the individual Address field level. That is convenient: you can set one Google key for the site without automatically enabling autocomplete on every address field. You choose only the forms where suggestions genuinely improve data entry.

Google API Key

In Forms - Settings - Autocomplete, enter the key created for this site. For a typical WordPress site, use HTTP referrer restrictions: the primary domain, the technical domain if needed, and the staging domain if testing will happen there. In API restrictions, leave only the services required by the product.

Do not leave the key unrestricted. A visible key in page source does not automatically mean a leak, but an unrestricted key can be used outside your site. If you tested without restrictions first, go back to Google Cloud Console after verification, add the restrictions, and test the form again.

Country Restrictions

The perk settings let you choose countries to limit suggestions. This is useful for local businesses, delivery services, onsite requests, and services that operate only in a few countries. If the Address field is configured as United States or Canadian, the product may automatically restrict suggestions to the matching format. For an international country field, it is better to set countries explicitly if your business logic requires it.

There is one practical nuance here: the Google API supports only a limited set of countries in a single request. So do not turn the country setting into a long list of target markets "just in case." If the site genuinely serves a global audience, leave search global and refine the address at the next form step or during submission processing.

Enablement on a Specific Address Field

In the form editor, open the Address field and find the perk section. The Enable Google Address Autocomplete checkbox should be enabled only where autocomplete is actually useful to the user. If the form includes both a registration address and a delivery address, decide whether suggestions are needed on both fields. In some cases, it is enough to enable suggestions on one field and use standard value-copying for the second address.

How to Choose the Address Field Format

The field format affects how the data is split after a suggestion is selected. For a single-country site, it is better to use the matching address type because the region and ZIP subfields will align more closely with the expected format. For an international site, keep a more flexible structure and add guidance in the field description so the user understands what kind of address is expected.

Map Field as a Result Check

A Map field is useful when the user should visually confirm that the correct address was selected: an onsite visit request, event location, community map point, or property listing. After adding a Map field to the form, you need to choose the Attached Address Field - the address field the map is tied to. Once an address is selected, the map should move to that location and display a marker.

Do not add a map to every form by default. A map increases visual load and depends on Google scripts loading correctly. If the address is needed only in an email to a manager, the map may be unnecessary. If the address becomes part of a public listing or geographic search, the map helps catch a wrong selection immediately.

The short version is simple: configure the key first, enable suggestions on the specific field next, and only then add a map where it actually helps verify the address.

How Google Places, the Address Field, and Coordinates Work Together

To diagnose issues correctly, it helps to understand the mechanics. Gravity Forms renders the Address field as a set of subfields. Gravity Forms Address Autocomplete attaches Google Places JavaScript autocomplete to it. When the user selects an option from the dropdown, Google returns place data, and the plugin maps the required components into the Gravity Forms subfields.

On the form entry side, the plugin also saves the latitude and longitude of the selected place in entry meta. Those coordinates can be used in notifications, confirmations, feeds, custom fields, or external integrations. Gravity Wiz documentation uses merge tags such as {entry:gpaa_lat_FIELDID} and {entry:gpaa_lng_FIELDID} for coordinates, where FIELDID must be replaced with the ID of the address field.

Why This Is More Than a Nice-Looking Dropdown

Address suggestions change data quality. If a manager receives "5 Main Street" with no city, that is almost useless for automation. If the form stores city, region, country, and coordinates, the data can be used in a directory, filter, map, lead routing workflow, or analytics. That is why you should check not only the dropdown itself but also the saved entry after submission.

Where Mismatches Usually Happen

Google Places returns a place structure, and address formats vary by country. One address may include a district, another an administrative area, and another a ZIP code that does not fully match what the user expects. In most forms that is fine, but for stricter business processes you should decide in advance which subfields are required and what to do if Google does not return a needed component.

Practical Scenario: An Onsite Service Request Form

Let us look at a concrete example. Suppose the site accepts requests for an onsite specialist within several countries or regions. The manager needs an accurate address, the user needs to complete the form quickly, and the site owner wants coordinates for mapping or sorting requests by service area.

Goal

Build a form where the visitor selects an address from suggestions, sees the populated subfields, optionally confirms the marker on a map, and submits the request. The Gravity Forms entry should retain both the address components and the coordinates so they can be used in a notification, internal report, or later integration.

Preparation

• A Gravity Forms form has been created with name, phone or email fields, an Address field, and a short description of the request.
• The required APIs are enabled in Google Cloud Console, and the key has been added to the autocomplete settings.
• The form is not inserted twice on the same page.
• You have already decided which countries or regions should appear in suggestions.

Configuration Steps

1. Open the form in the Gravity Forms editor.
2. Add an Address field or open the existing address field.
3. Enable Enable Google Address Autocomplete in the field settings.
4. If the request requires visual location confirmation, add a Map field from Advanced Fields.
5. In the Map field settings, choose the Attached Address Field - the same Address field where autocomplete is enabled.
6. Save the form and insert it on a test page.
7. Enter a partial address, choose a suggestion, and verify both the populated subfields and the map marker.
8. Submit a test request and open the entry in Gravity Forms.

Expected Result

The user does not have to type the entire address manually. After selecting a suggestion, they can still review the subfields and, if a map has been added, see the marker. The manager receives cleaner data, and the site stores coordinates for further processing.

A Note About Apartment, Suite, and Building Details

Google often identifies the street, city, and ZIP code well, but it does not always know the apartment number, suite, or internal building section. If that information is critical, keep Address Line 2 visible and label it clearly for apartment, suite, or additional details. Do not expect autocomplete to provide what the user still needs to enter manually.

Result check: after a test submission, open the entry and confirm that the visible address matches what the user selected and that the coordinates are available through entry meta or merge tags for the required field.

Scenarios Where Coordinates and a Map Add More Value

Address autocomplete is useful by itself, but the real value appears when the address becomes part of a larger workflow. Gravity Forms Address Autocomplete stores coordinates, which means the form can be used for more than address text in an email. It can support geographic workflows as well.

Directory of Events, Locations, or Requests

If the form creates WordPress posts or passes data into custom fields, the coordinates can be stored separately from the text address. That is useful for event directories, local initiatives, property listings, pickup points, or onsite service requests. In this type of setup, decide in advance which values need to be stored: city, country, full address, latitude, and longitude.

Routing Requests by Geography

Even without complex distance calculations, an address helps route submissions. For example, a manager may see the city and region directly in the entries list or notification. If additional tools are connected, the coordinates can become the basis for a map, filter, or internal logic.

Forms for Local Communities

For communities, volunteer projects, and local services, a map next to the address lowers the risk of mistakes. The user can see that the selected place really matches their district or event location. This is especially helpful when different cities have streets with the same name.

Restricting Suggestions by Country, Radius, and Search Type

Country settings cover most use cases, but local services often need more precise rules. For example, delivery may be limited to one city, an application may accept only regional addresses, or a booking form may need to search by place name rather than only by street. Gravity Wiz documentation uses filters and snippets for these cases, but they should be applied carefully.

Countries in the Perk Settings

Start with the Countries setting. It is the safest level because it lives in the product interface and does not require code. If the business operates in only one country, the restriction reduces irrelevant suggestions and lowers the chance of selecting a similar address abroad.

Radius and City Through Filters

For more granular restrictions, Gravity Wiz shows how to use the gpaa_autocomplete_options filter. It lets you change Google Places Autocomplete parameters before initialization. For example, you can define bounds, a strict radius, or a custom search type. But this is already a developer-level setting: you need to know the form ID and field ID, understand where the snippet belongs, and retest the result after updates.

Do not add a complex snippet just because it looks useful. If choosing a country in the settings is enough, use the interface. Code makes sense when suggestions must be tightly tied to a service area or when the user is searching for a place name rather than a full address.

Searching by Place Name

For bookings, pickup points, public places, and events, users often remember the place name rather than the exact address. Gravity Wiz documentation includes approaches for searching and displaying by Place Name. That can be a strong fit, but it needs to be tested in real forms: the selected place should populate the address clearly enough for the manager to understand the result, while still allowing the user to specify a suite, entrance, or building section if needed.

When Not to Overcomplicate It

If the site serves a broad region and the manager reviews the address manually anyway, a strict radius may do more harm than good. The user may not see the place they need, assume the form is broken, and leave. In those cases, it is better to keep search broad and add clear text under the field explaining which addresses are accepted and what to do if a suggestion does not appear.

Checking the Result Before Publishing the Form

After configuration, it is easy to stop after the first successful address entry. For a live form, that is not enough. You should test several address types, different devices, post-submission behavior, and how the data looks in the saved entry. This kind of validation takes less time than dealing with real submissions that contain the wrong city, an empty ZIP code, or a marker in the wrong country.

Test Address Set

Prepare a small set of addresses before launch. It should include one address in your main region, one near the edge of the service area, one with an apartment or suite, one with a similar street name in another city, and one that a user might search by place name. For an international site, add one sample from each key country.

Check more than whether suggestions appear. Verify the final subfields too. Make sure the city goes into the city field, the ZIP code goes into the ZIP field, and the country matches the selected Address field format. If the region or ZIP sometimes stays empty, decide in advance whether that field will be required and how the user will know it needs to be completed manually.

Testing on Mobile

Autocomplete is especially helpful on mobile, but that is also where issues with the dropdown, field focus, and the on-screen keyboard covering suggestions are most noticeable. Test the form on a real phone or at least in your browser's mobile view. Enter the address slowly, then quickly, choose a suggestion, go back, edit the address, and submit the form.

If the suggestion list opens but is hard to tap, the problem may be the block height, a sticky header, a popup window, or the theme's z-index. Do not fix it with a random massive z-index applied site-wide. First identify which container is covering the suggestion list, then adjust only the page or form where it is actually needed.

Checking the Entry and Notifications

After a test submission, open the Gravity Forms entry. The address should make sense to a manager without needing to inspect the form page. If a notification email is sent, make sure it does not contain only the first address line when the manager actually needs the city, ZIP code, or country. For coordinates, add merge tags to a test notification or temporary admin output so you can confirm that latitude and longitude are really being saved.

Also test the scenario where the user does not select a suggestion and types the address manually. In some projects that is acceptable, in others it is not. If your business process specifically requires a selected Google Place, use documented Gravity Wiz approaches or separate validation, but do not block submission with a rigid homemade rule that has not been tested against real addresses.

Publishing Without Surprises

Before publishing, clear the page cache, open the page without the WordPress admin bar, and run a short test again. If you use a CDN or a separate optimization plugin, check the page after all optimizations are turned on, not only in admin mode. Many JavaScript issues are invisible to administrators because of disabled caching or elevated privileges.

Minimum pre-launch test: three addresses, one mobile entry, one form submission, one entry review, one notification review, and one post-cache page check. If all six pass, the risk of a messy launch is much lower.

How to Add the Plugin to an Existing Form Without Losing Data

If the form is already receiving real submissions, it is better to roll out changes gradually. Do not change the field structure, notifications, integrations, design, and autocomplete all at once. The more changes you make in one day, the harder it becomes to understand what actually broke submission processing.

Copy First, Live Form Second

Create a copy of the form and reproduce the current structure there. Enable autocomplete only on the copy, verify entries and notifications, and then compare the data with the original form. If the form is tied to a CRM, webhooks, post creation, or manual exports, confirm that the new values do not change the format expected by the external system.

Once testing is complete, move the setting to the live form during a low-activity period. Right after publishing, send one internal test submission with an obvious test name and remove it from processing if it reaches the managers. This simple step confirms that the public page, cache, and notifications work correctly in the actual production environment.

Do Not Break Older Submissions

Enabling autocomplete should not rewrite old entries. But if you change the form structure, hide subfields, rename fields, or add required rules, check how that affects exports and integrations. Older submissions may contain the address in a different format, and reports need to work correctly with both versions.

For analytics, it is useful to add an internal note marking when addresses started being collected through suggestions. You do not need to put the date in the article or public form, but inside the project it will help explain why address data quality changed.

Rollback Plan

Your rollback plan should be ready before launch. In the simplest case, remove the Enable Google Address Autocomplete checkbox from the Address field and clear the page cache. If you added a Map field, CSS, or snippets, document where they live and how to disable them. Do not delete the address field or change the field ID unless absolutely necessary, because that can affect old entries, notifications, and merge tags.

If the problem appears only for some users, first disable script optimization on the form page and verify the Google key. A full plugin rollback is rarely necessary. More often, it is enough to return the form to a standard Address field, preserve the data, and investigate the cause calmly.

Working With Coordinates, Merge Tags, and Custom Fields

The visible address matters to the user, but coordinates matter to the system. Gravity Forms Address Autocomplete stores the latitude and longitude of the selected Address field in entry metadata. That opens several practical workflows: include coordinates in a notification, pass them into a feed, write them into post custom fields, or use them in a directory.

Merge Tags for Coordinates

The coordinate tag format depends on the ID of the address field. If the field ID is 3, latitude will be available as {entry:gpaa_lat_3} and longitude as {entry:gpaa_lng_3}. These values can be inserted anywhere Gravity Forms supports merge tags, provided the relevant add-on or setting accepts that data.

Writing Them Into WordPress Custom Fields

If the form creates a WordPress post, coordinates can be mapped into Post Custom Field values or ACF fields. The idea is that external tools should receive not just the address string but separate values for mapping or filtering. In the simplest setup, you add a Post Custom Field, enable Create Content Template, and insert the required merge tag into the value.

For more advanced directories, it is better to design the data structure in advance: one field for the full address, separate fields for city, country, latitude, and longitude. That way, a future map, filter, or import process will not depend on one long string.

Why You Should Not Rely on the Address Line Alone

A single line is convenient for a person but awkward for automation. "Main Street" may exist in dozens of cities, and different users write the same address in different ways. Coordinates provide a more stable basis for maps and distance logic, but they still need verification: for some places, Google may return the center of a building, complex, or street rather than the exact entrance.

Compatibility With the Theme, Cache, Popup, and Page Builders

Address suggestions run in the browser, so any interference with JavaScript loading can affect the result. Usually, problems are not caused by the field itself but by how the page renders the form: inside a popup, in a lazy-loaded tab, as a repeated insert, through AJAX re-rendering, or with aggressive script optimization.

One Form on a Page Means One HTML ID

Gravity Forms does not support inserting the same form multiple times on one page. The reason is technical: the form has unique HTML IDs, and repeated IDs confuse the browser and the scripts. This is especially noticeable with Address Autocomplete, because the JavaScript needs to find a specific field and attach Google Autocomplete to it. If the same form appears both in the content and in a popup, suggestions may work only in one place or fail to initialize correctly.

If you need to display a similar form in two places, create a copy of the form with a different ID and insert each form only once. Then test autocomplete separately in each copy.

Cache and JavaScript Optimization

Caching and optimization plugins may combine, move, or defer scripts. With a standard form that may go unnoticed, but for Google Places Autocomplete it is critical: if the Google library or Gravity Wiz script loads in the wrong order, suggestions will not appear. If a problem occurs, temporarily disable script combining and deferred loading for the form page, then re-enable optimization one setting at a time.

Popup and Dynamic Form Loading

If the form opens in a popup, accordion, or tab, check whether the field initializes after the form becomes visible. Gravity Wiz changelog notes have included fixes related to modal windows and dropdown positioning, so when you see symptoms like that, it is important to use a current product version rather than leaving an outdated build in place.

Safely Improving the Look of the Address Field

Sometimes the field works correctly but gets visually lost on the page: the subfields are packed too tightly, the description is hard to notice, and the user does not understand that they need to choose an item from the suggestion list. The safest type of refinement here is CSS through your theme settings, child theme, or a snippets plugin. You are not modifying WordPress core, Gravity Forms, or Gravity Forms Address Autocomplete. You are simply highlighting the address block more clearly.

The example below is based on public CSS selectors for the Gravity Forms Address field. Before pasting it in, replace 15922 and 4 in the selector with your own form and field IDs if you want the style to affect only one address field. If you want to apply the style to all Address fields, use a general selector without the form ID.

.gform-theme--framework#gform_wrapper_15922 #field_15922_4.gfield--type-address {
  --gf-ctrl-border-color: #2563eb;
  --gf-ctrl-border-color-hover: #1d4ed8;
  --gf-ctrl-radius: 8px;
  --gf-ctrl-desc-color: #475569;
}

.gform-theme--framework#gform_wrapper_15922 #field_15922_4 .address_line_1 input {
  background: #f8fafc;
}

After adding the CSS, open the form on the public page and check three states: the default view, focus in the first address line, and the validation message when a required field is left empty. If the style conflicts with the theme or reduces contrast, remove the snippet or restore the previous CSS version. Rollback should be as simple as enablement: one CSS block, one insertion point, no edits to plugin files.

Troubleshooting: Why Address Suggestions Do Not Work or Populate Incorrectly

Autocomplete issues are best analyzed in sequence: Google API, key, perk settings, the specific field, the output page, JavaScript conflict, and address format. Do not start by reinstalling the plugin. Most often, the cause is the key, its restrictions, a disabled API, or the same form being inserted twice.

Suggestions Do Not Appear at All

Symptom: the field looks like a regular Address field, but no address list opens while typing. Possible causes include a missing key, Places API or Maps JavaScript API not enabled, the key restricted to the wrong domain, the field not enabled in the perk settings, or Google scripts blocked by optimization.

Check Forms - Settings - Autocomplete, then open Google Cloud Console and verify that the required APIs are enabled. After that, temporarily disable deferred JavaScript loading on the form page. If suggestions appear, configure exclusions in the optimization plugin.

Suggestions Appear, but the Address Is Split Incorrectly

Symptom: the user selects a suggestion, but the city, region, ZIP code, or country lands in the wrong subfields or stays empty. The reason is often the address format, the specifics of the selected country, or the place type returned by Google. Make sure the Address field uses the correct Address Type and that the user is selecting a full address rather than an overly generic location.

If you need a non-standard format, review the gpaa_values filter. It lets you adjust formatted values after a place is selected. But do not invent custom logic without testing: first collect a few real addresses from the target region and confirm which components are returned consistently.

The Map Does Not Move After an Address Is Selected

Symptom: the address populates, but the Map field stays in the same place. Check whether a Map field has been added and whether the correct Attached Address Field is selected in its settings. If the map field sits inside a hidden tab, popup, or conditional block, test the scenario where the form opens after the page has loaded.

For deeper map customization, the documentation includes filters such as gpaa_map_options and gpaa_marker_options. Use them only after the basic field connection is already working.

It Works on the Test Page but Breaks on the Live One

Symptom: suggestions appear on a simple page but not on the real landing page. Look for the difference: popup, repeated form, cache, minification, page builder, conditional tab loading, or a theme conflict. The fastest check is to insert the same form once on an empty test page with the same theme. If it works there, the issue is not the plugin but the rendering environment.

The User Selects an Address, but Apartment or Suite Data Is Not Saved

Symptom: street, city, and ZIP code are filled, but the apartment number, suite, or building section is missing. This is not always an error. Google Places may not know internal location details. Keep Address Line 2 visible, give it a clear label, and make sure it is not hidden by CSS or form settings.

The Key Is Visible in Page Source

Symptom: an administrator sees the Google API key in HTML or network requests and assumes it has leaked. For Maps JavaScript API, the key is normally used in the browser, so visibility is expected. The fix is not to hide the key at any cost, but to restrict it correctly by domain and API inside Google Cloud Console.

When Gravity Forms Address Autocomplete Is the Right Choice

Gravity Forms Address Autocomplete is worth using when the address is an important part of the submission and the site already relies on Gravity Forms. The plugin solves a specific problem: speed up address entry, reduce manual errors, save coordinates, and optionally show a map. Its strength is that it does not disrupt the familiar Gravity Forms structure. It adds a suggestion and geodata layer to the standard Address field.

Before launch, verify the Google key, domain restrictions, required APIs, enablement on the correct field, map behavior, and coordinate storage. Then test the form in the real environment: with the theme, cache, popup, or page builder if those are part of the setup. If everything works on a test page but breaks on the live one, look for a rendering conflict rather than rebuilding the form from scratch.

If the product fits your workflow after testing, you can download the Gravity Forms Address Autocomplete archive and move on to a careful test on a copy of the form. The best outcome here is not just a working suggestion list, but a form where the user selects the right address quickly, the manager receives clean data, and the site stores coordinates for downstream use.