Formidable Forms Geolocation - WordPress Plugin

Guide to Setting Up and Using Formidable Forms Geolocation

Formidable Forms Geolocation is best viewed not as a standalone map for visual flair, but as a precision layer for WordPress forms: a visitor enters an address, picks a suggestion from Google Places, optionally allows the browser to detect their current location, and the site owner receives an entry with the address, coordinates, and a map. This guide covers more than just installation and the first settings. It also shows how to connect geolocation to a real business task, whether that is a field service request, a property directory, a delivery form, an appointment booking form, or an internal location database.

This article is intended for users who already have, or plan to use, Formidable Forms Premium with access to the required add-ons. We will go from preparing a Google Maps API Key to checking the saved entry in the admin panel, displaying data through Views, setting safe key restrictions, and troubleshooting issues such as the message This page can not load Google Maps correctly. It also explains where this product does more than a standard address field and where a different tool may be the better choice.

This article does not include instructions for purchasing, entering license details, or bypassing access limits. The focus is strictly on using a product you already have access to: which elements to enable, which fields to add, what to verify after saving, how to avoid exposing your Google key to unnecessary traffic, and how to confirm that the map, autocomplete, and coordinates are actually tied to the submitted form.

What Geolocation Solves in WordPress Forms

A standard address field accepts text. A user may enter a street without a city, mistype the ZIP code, leave an abbreviation, use another language, or make an error in the street number. That may be acceptable for a simple message, but for delivery, on-site service, property maps, or region-based reporting, those mistakes quickly turn into manual work. A geolocation layer matters when an address needs to become structured and verifiable, with a city, state or region, country, latitude, longitude, and a clear point on the map.

Formidable Forms Geolocation adds several practical capabilities to a form. The first is address autocomplete: the user starts typing, sees Google Places suggestions, and picks the right one. The second is a map directly inside the form when it helps to show or confirm a location. The third is using the current location when the visitor agrees to share their coordinates through the browser. The fourth is saving geographic data in the entry, so the administrator can see the city, region, country, coordinates, and map on the individual submission page.

The plugin is especially useful in projects where the form is more than just a contact block and serves as the entry point into a workflow. For example, a service company takes repair requests with the customer's exact address. An event organizer collects venue locations and displays them on a map. A real estate agency accepts properties through a form and then publishes them as a directory. A small store uses a request or delivery estimate form and wants to reduce the number of incorrect addresses. In every case, geolocation saves time not on typing itself, but on the follow-up validation, sorting, and use of the data.

Where the Product Delivers the Most Value

The main strength of Formidable Forms Geolocation is that it works inside the Formidable Forms ecosystem. If the site already uses forms, entries, notifications, conditional logic, and Views, geographic data can be folded into the existing data model without switching to a separate directory system or a separate mapping plugin. That is useful for a site owner who wants to collect submissions and also build something visible from them: a branch list, a request map, a property directory, a pickup-point collection, or an internal address database.

The clearest use case is an address field in a form. The user picks an address from the suggestions, the plugin saves the value and coordinates, and the administrator opens the entry and sees a geographic block. A more advanced use case is pairing it with Visual Views: form entries become the data source for a Map View, and a map with markers appears on the site. In that case, not only the form matters, but also the setup order: first configure Geolocation on the field, then create entries with autocomplete enabled, and only after that build the map from those records.

Where Geolocation Does Not Replace a Dedicated System

The plugin should not be treated as a universal platform for logistics, routing, or a full directory with radius search unless that functionality is built through additional Formidable Forms features or third-party tools. It helps you capture and display address data in forms, but it does not by itself promise a sophisticated nearest-location finder, a courier platform, or a navigation app. If your goal is full geotagging for all records, advanced distance search, faceted filters, route pricing, or large-scale location management, check in advance whether Views, shortcodes, and the available add-ons are enough.

Main takeaway: Formidable Forms Geolocation works best when the address is part of a form and part of what happens next with the entry. If the map needs to exist separately from forms and power a complex location database, compare this product against directory systems and specialized mapping plugins.

Who This Plugin Is For and When It May Be Overkill

Before installing it, answer one question honestly: what exactly do you want to do with the address after the form is submitted? If the address is only needed for reading inside an email, a simple field may be enough. If it needs to become a map point, a basis for sorting, filtering, regional handling, or publishing in Views, geolocation starts to add clear value. That distinction matters because Formidable Forms Geolocation requires more than just enabling an add-on. You also need to prepare a Google API key, security restrictions, browser permission checks, and a test submission.

The product is a good fit for WordPress site owners who already build workflows around Formidable Forms: request forms, questionnaires, directories, tables, private dashboards, or pages with submitted data. It is also useful for webmasters and agencies that need to build a client form with an address field and an easy-to-verify outcome. Developers can benefit from the documented hooks that let them change the default map point, initial zoom level, and autocomplete suggestion types without editing plugin files.

For marketers, the product can be useful when submission geography affects what happens next: regional email campaigns, routing leads to branches, city-level analysis, or choosing the nearest office. But those use cases need to be designed carefully. Simply saving the city and coordinates does not mean all business rules will appear automatically. In many cases, you will still need to configure separate notifications, conditional logic, exports, tables, or a View.

Strong Use Cases for Adoption

• Field service request. The customer's address is selected from autocomplete suggestions, the map helps visually confirm the location, and the administrator can see the coordinates in the entry.
• Property or branch directory. The user submits a location address through a form, and the site owner displays the entries through a Map View.
• Delivery or pickup form. Autocomplete reduces the chance of incomplete addresses and makes manual order or request review easier.
• Local community. A signup form can collect the city and country, while the map helps show member geography if that makes sense and aligns with your privacy policy.
• Internal address database. A team collects submissions in WordPress and uses the coordinates later for review, export, or publication.

When a Different Approach Makes More Sense

If all you want is to place an office map on a contact page, a dedicated geolocation add-on for Formidable Forms may be excessive. For a single static map, a map block, iframe, or specialized mapping plugin is often enough. If you need visitor geolocation without a form, such as IP-based content personalization, you should also look at a different class of product. If you need a large directory with nearest-location search, distance filters, location categories, and separate location pages, Formidable Forms Geolocation may be part of the solution, but not always the only component.

There is also a technical limitation: the official documentation states that Geolocation is not compatible with repeating sections. So you should not build a form where a user adds multiple addresses inside a repeatable block and expect each address to be handled correctly by geolocation. For multiple locations, it is better to design separate entries, separate forms, or a different storage model from the start.

What to Check Before Installation

Preparation matters because geolocation depends on three different layers at once: WordPress, Formidable Forms, and Google Maps Platform. If you miss one of them, the form may still display, but suggestions may not appear, the map may stay gray, the browser may never ask for location permission, or the entry may be saved without coordinates. That is why it helps to go through a short but concrete checklist before installation.

Basic WordPress-Side Requirements

The plugin is meant for a WordPress site running Formidable Forms Premium. In the official Geolocation documentation, access to this add-on requires the Business plan or higher. The core Formidable Forms plugin is also available in the WordPress.org repository, but the geolocation layer itself is part of the premium feature set. It is important not to mix these tiers up: the free Formidable Forms core helps you build forms, but the specific autocomplete and map features in Formidable Forms Geolocation require the appropriate add-on access.

Make sure the site loads over HTTPS. Formidable's documentation specifically notes that Google Places requires secure site loading and enabled billing in Google Cloud. This is not a marketing formality. It is a real dependency: browser APIs and maps are sensitive to the domain, source origin, and security settings. On a staging copy that loads through a local address or a temporary domain, behavior may differ from the live site.

What to Prepare in Google Cloud

You will need the required Google Maps Platform APIs enabled. Formidable's documentation lists three services: Geocoding API, Maps JavaScript API, and Places API. In Google Cloud Console, create or select a project, enable those APIs, create a key, and set restrictions. In its own recommendations, Google specifically emphasizes restricting keys by application and by API, because the project owner is responsible for unwanted key usage.

If the site already uses Google Maps through a theme, another plugin, or custom code, do not rush to paste the same key everywhere. It is more practical to have a separate key for Formidable Forms Geolocation, or at least understand which services each component uses. That makes troubleshooting easier: when the map breaks only inside the form, you check the form key; when the entire site fails, you look for a broader conflict in how the Maps JavaScript API is loaded.

Permissions and Data Policy

Geolocation can involve personal data. Addresses, coordinates, and visitor location details should only be collected when they are genuinely needed to process the submission. If the form includes Use visitor location, the user will see a browser prompt asking for location access. It is best to explain on the form page why that is needed, for example, to speed up entering a service address or to find the nearest service point. Do not enable current-location collection "just in case."

Before publishing, decide who in the admin panel has access to entries, whether geo data will appear in emails, exports, or a public View. If a request map includes private customer addresses, that View should not be published openly. For public pages, use only the data the user knowingly submits for publication, such as the address of a branch, a directory listing, or an event venue.

Installing the Add-On and Doing the First Admin Check

Installation starts with the usual WordPress plugin flow, but Formidable has one important difference: premium add-ons are enabled from inside the Formidable Forms interface itself. After installing and activating Formidable Forms Premium, open the WordPress admin panel and go to Formidable -> Add-Ons. In the add-on list, find Geolocation and enable it with the toggle or install button if the add-on is not installed yet.

Do not jump straight into building a complex form. First, make sure a path for global geolocation settings appears in the Formidable menu: Formidable -> Global Settings -> Geolocation. That screen should include a field for the Google Maps API Key. If the tab does not appear, check whether Formidable Forms Premium is activated, whether the add-on is available under your plan, and whether WordPress is showing a plugin update error.

Safe First-Time Setup Order

1. Enable the add-on. Do this on a staging copy or during a low-traffic period if the form is already in use on the live site.
2. Paste the API key into the global settings. After pasting it, click Update and do not leave the key in notes, public tasks, or code comments.
3. Create a separate test form. Add one address field and one field for a name or object title so the test entry is easy to identify.
4. Enable autocomplete on the field. In the field settings, check Add address autocomplete.
5. Test the public page. Open the form not only in the builder preview, but on a regular site page where theme scripts, cache, and other plugins are also loading.

This setup order helps you quickly separate installation issues from workflow issues. If the test form works but the older complex form does not, the cause is likely a specific field, conditional logic, a script conflict, or the way the form is embedded. If even the test form does not work, start by checking the Google key, APIs, domain restrictions, and HTTPS.

Quick Check After Enabling

On the page with the test form, start typing a real address. The expected outcome is that suggestions appear and can be selected. If the map is enabled, it should appear below the field and update after the address is selected. If current location is enabled, the browser may ask for permission. After submitting the form, open the entry in Formidable -> Entries and check whether geographic data and a map appear in the entry details.

Required step: test not only address entry, but the saved entry as well. A visible suggestion inside the form does not yet prove that the coordinates are available for Views, emails, or later processing.

Configuring the Google Maps API Key Without Unnecessary Risk

The most common cause of map issues is not the form field, but the Google Maps Platform key. In Formidable Forms Geolocation, the key is entered in the global settings, but its lifecycle starts in Google Cloud Console. There, you need to enable the required APIs, create a key, and restrict it by domain and allowed services. If you leave the key unrestricted, the form may start working faster, but that is poor practice: the key is used on a public page, and it should not be treated as a secret in the same way as a server password.

Which APIs to Enable

Formidable's official instructions list three APIs: Geocoding API, Maps JavaScript API, and Places API. Places API is needed for address suggestions, Maps JavaScript API is used to display the interactive map in the browser, and Geocoding API is involved in translating addresses and coordinates. If you enable only one of them, the form may work only partially: the field exists but no suggestions appear; suggestions appear but the map does not load; the map opens but coordinates are not saved as expected.

After enabling the APIs, create a key under APIs & Services -> Credentials. If a key already exists, do not change its restrictions on a live site without testing. Google recommends reviewing the key's actual usage before changing restrictions. This matters even more if the same key is already used by a theme, a contact map, a store, or another plugin.

Domain and API Restrictions

For a WordPress site, the usual approach is to restrict by HTTP referrers, meaning the site addresses from which requests are allowed. In Google Cloud, specify the site domain and, if needed, subdomains. Formidable's documentation gives an example pattern such as yoursite.com/* for a single domain and *.yoursite.com/* for subdomains. Google's documentation also recommends specifying the full origin with protocol where required by the interface and current referrer policy. In practice, the important part is not to copy an example mechanically, but to verify the format in Google Cloud Console and test it against your actual domain.

API restrictions should allow only the services the form needs. To do that, choose Restrict key and add Geocoding API, Maps JavaScript API, and Places API. If another map on the same key requires more services, the list may be broader, but troubleshooting becomes harder. The strongest practical setup for a new deployment is a separate key for Formidable Forms Geolocation, separate restrictions, and separate validation inside the form.

How to Tell Whether the Key Is Configured Correctly

First, confirm that address suggestions appear on the public site. Then select an address and check whether the map updates. After submitting the form, open the entry and make sure it contains not only the address text, but coordinates as well. If the map shows an error, open the browser console and compare the error code against the Google Maps JavaScript API documentation. Those messages usually point to a bad key, disabled billing, an unauthorized referrer, an inactive API, or exceeded limits.

Do not leave the key temporarily open after testing. If you had to remove restrictions to find the cause, restore them immediately after troubleshooting. If the map works without restrictions and breaks after they are enabled, the problem is almost always the domain format or a missing API in the allowed-services list.

Address Fields, Autocomplete, and the Map Inside the Form

Once the global key is in place, the most practical part begins: choosing the field and configuring how it behaves in the form. Formidable Forms Geolocation supports two main approaches to addresses in a form: a single-line text field and the Address field. A single-line field is convenient when you want quick full-address entry in one line. The Address field is a better fit when the data needs to be stored in separate parts: street, city, state or region, ZIP code, and country. The choice affects not only appearance, but also how you can later display the data in emails, Views, and templates.

Single-Line Field or Address Field

A single-line field works well for short requests: "enter the property address," "where should the technician go," or "where is the event located." It takes up less space and feels lighter on mobile. But if you need to use the city, state, ZIP code, or country separately later, the Address field is usually the better choice. In Formidable's documentation, the Address field includes Address Type options: international, U.S., and without country. That helps you avoid overloading the form with unnecessary fields when your audience is local.

For an international site, keep the country visible so suggestions and saved data do not get confused between similarly named cities. For a local form limited to one country, you can choose a narrower address type if that matches the interface and visitor expectations. The key is not to remove address parts just for compactness if you need them for delivery, tax handling, regional processing, or accurate map placement.

Address Autocomplete

In the selected field settings, enable Add address autocomplete. After that, the user should choose an address from the suggestions rather than just typing arbitrary text. This reduces errors, but it does not remove the need for manual review in critical workflows. In some cases, the user may not find the needed address, especially if the location is new, inside a restricted area, listed in another language, or missing from Google's database. For forms like that, it is helpful to keep an extra field such as "Address notes" or "Landmark."

If you need to narrow the suggestion type, Formidable's developer documentation describes the frm_geo_autocomplete_options filter. It lets you switch autocomplete to types such as geocodes, establishments, or exact addresses. Not every site needs that. For a field service request form, addresses are usually the right fit. For a form where the user selects a known place or landmark, establishment suggestions may make more sense. Only apply that kind of adjustment after testing it on a copy of the site.

Map and Current Location

The Show map option displays an interactive map below the field. It is useful when the visitor needs to visually confirm the point. But a map increases the number of external requests, adds scripts, and takes up space. For a short form in a sidebar or on a narrow landing page, you may want to disable the map and keep only autocomplete. For a field service request, a real estate listing, or an event location, the map is often worth it.

The Use visitor location option controls whether the browser is asked to detect the current location. According to Formidable's documentation, it is enabled by default; turning it off removes the permission prompt. Enable it only when the workflow truly benefits from the visitor's current location. If the form is simply asking for a delivery address, an unexpected browser prompt may feel annoying. If the form helps the user find the nearest service point or quickly enter the service location, the prompt makes more sense.

How to Keep the Form User-Friendly

Geolocation should shorten the user's path, not make the form heavier. Do not place a map in every address block if suggestions are enough. Do not require precise current location if the user still needs to type the address manually. Do not hide required fields so deeply that the visitor cannot understand why the form will not submit. For mobile users in particular, large fields, clear labels, and the absence of unnecessary steps matter.

After configuring the form, open it on a phone and on a desktop. Check whether suggestions fit properly, whether the map covers the submit button, and whether the field style conflicts with the theme. If the form is embedded inside a page builder, test it on the published page, because the builder preview and the live front end may load different script sets.

How an Address Becomes Coordinates, a Map, and a Saved Entry

To troubleshoot errors correctly, it helps to understand the product's flow. The visitor enters an address or allows the browser to determine the current location. The browser layer uses Google Places and the Maps JavaScript API to show suggestions and the map. After the address is selected, Formidable Forms Geolocation links the visible field value to geographic data. When the form is submitted, the entry is saved in WordPress, and the city, region, country, latitude, longitude, and map become available in the entry details.

Input, Processing, and the Visible Outcome

At the input stage, the product sees one of three events: a user picks an address suggestion, the map receives the current point with browser permission, or the administrator tests the form with a known address. The controlling layer is the field settings, the global API key, and the connected Google services. The state change happens when the address is selected or detected: the field receives a normalized value, the map moves to the point, and the hidden data layer prepares the coordinates for saving.

You need to check the visible outcome in two places. On the public site, you should see the suggestions and the map. In the admin panel, you should see the geo data on the entry page. If the first layer works but the second does not, the form may have displayed the suggestion but failed to save the geographic data behind it. If the second layer works but the public View map does not show markers, the cause may be the View configuration, the selected field, older entries, or visibility permissions.

Why Older Entries May Not Show Up on the Map

When creating a Map View, Formidable's documentation warns that the geolocation add-on must be enabled on the address field before you create the entries you want to show on the map. That is logical: if older entries were submitted as plain text without geo data, the View may have no coordinates to use for a marker. In those cases, you may need to collect the addresses again, review old entries manually, or use another data-enrichment process. Do not promise automatic coordinate recovery for an old database unless that has been confirmed in the specific installation.

Result check: create a new test entry after enabling autocomplete, then use that entry to validate the Map View. This rules out the case where the map looks empty simply because older entries have no coordinates.

Displaying Individual Address Parts and the Map

Formidable lets you display field data through shortcodes. For geolocation, the documentation includes ways to output the full value, the state abbreviation, latitude, longitude, and the map. For example, for a field with ID 123, you can output the coordinates like this:

[123 show="lat"]
[123 show="long"]

For the map inside a View, the format is:

[123 show="map" keepjs=1]

The documentation also notes that this map output is available in Views and not available in email. That is an important limitation. In an email to the administrator, it is better to show the address, city, region, and coordinates, and keep the interactive map in the entry or the View. If you place the map shortcode inside an email and expect a full map, you will get an incorrect result or an empty block.

Displaying Requests and Listings on a Map with Visual Views

The form itself handles data entry. But many users install Formidable Forms Geolocation for the next step: showing submitted entries on a public map. That is where Visual Views comes in, with its Map view type. Together, this setup turns forms into a small application: the user submits a listing, the address is saved, the View pulls entries from the form, and those entries appear as map markers.

This use case requires a careful sequence. First, configure the address field with autocomplete and create new entries. Then open Formidable -> Views, click Add New, choose Map as the View type, and select the source form. When creating the Map View, choose the address field that should be used on the map. If you select a field where geolocation was not enabled before entries were submitted, the map may appear empty or incomplete.

How to Build a Map View Without Extra Code

1. Open the form and check the address field. Make sure Add address autocomplete is enabled before your test submissions.
2. Create several entries. Use real but test addresses so you can see distinct points.
3. Go to the Views tab. Create a new View and choose the Map type.
4. Select the data source. Choose the form that should provide the entries.
5. Select the address field for the map. That field must contain geo data, not just arbitrary text.
6. Configure the marker content. On the Listing Page, you can add the object title, a link to the detail page, or other fields.
7. Publish the View on a page. Use the standard method for inserting the View and test the page as a regular visitor.

What to Show in the Marker and on the Detail Page

A map becomes useful when the marker answers the visitor's question: what is this point, and why should I click it? For a property or location directory, the marker only needs the title, area, and a short link to details. For branches, you can add a phone number or business hours if those values exist in the form and are safe to publish. For customer requests, private addresses are best kept off the public site. In that case, the Map View should remain private or use only anonymized data.

On the View detail page, you can output individual parts of the address field and, if this is a View, the map using show="map". The main thing is not to overload the marker with the entire entry. The map should help people orient themselves, while the details belong on a separate page. If the View includes sensitive data, verify the visibility settings. Visual Views documentation explains that a published View may be accessible to anyone who can open the page, so privacy should be planned before publication.

Checking the Public Map

After publishing the View, check three things. First, do all the test markers appear? Second, does the marker content open when clicked? Third, does cache or JavaScript optimization break the map behavior? If the map loads only for an administrator but not for a regular visitor, check access permissions, page caching, deferred script loading, and the View's privacy settings. If the map is visible but some markers are missing, compare the entries: most often, the missing points were created before geolocation was enabled or contain an address without coordinates.

Practical Use Case: A Field Service Request Form with a Verifiable Address

Let us walk through a concrete example that can be adapted for repair work, cleaning, equipment installation, medical visits, sample pickup, or on-site consulting. The goal is to build a form where the customer can quickly enter an address, use the map to confirm the location, submit the request, and let the administrator open the entry and immediately understand where to go and whether the contact details are complete.

Goal and Preparation

We need a "Request a Technician" form with name, phone or email, service type, property address, and comments. Formidable Forms Premium and Geolocation are already active, the Google Maps API Key is saved, and address suggestions work in the test form. If you plan to send a notification to the administrator, verify basic Formidable Forms email delivery in advance and, if needed, confirm your SMTP plugin setup. Geolocation does not fix email delivery, so it is better not to mix those two checks.

Form Setup Steps

1. Create a new form. In Formidable -> Forms, click Add New and choose a blank form or a suitable template.
2. Add contact fields. The minimum set is name, phone or email, service type, and comments.
3. Add an Address field. For a local service, you can choose an address type without an extra country field if that matches the field settings and your audience.
4. Enable Add address autocomplete. Ask the user to select the address from the suggestions instead of entering it as free text.
5. Enable Show map. The map gives the visitor visual confirmation that the correct address was selected.
6. Make a decision about Use visitor location. If the service is often requested for the user's current location, leave it enabled. If the request is usually for a property that is different from the visitor's current location, it is better to disable the prompt so it does not create confusion.
7. Add a field for "Landmark or address notes." This helps when Google Places does not know the apartment building entrance, unit, checkpoint, or local name of the location.
8. Configure the notification. In Settings -> Actions & Notifications, send the administrator the address, coordinates, and comments. Do not treat the map in email as a required element, because interactive map output is intended for Views.
9. Publish the form. Insert it with a block or the shortcode [formidable id=x], replacing x with the form ID or key.

Expected Outcome

On the public page, the user enters part of the address, sees suggestions, picks one, the map shifts to the selected point, and then submits the form. In the admin panel, the entry should show the address data and coordinates. In the notification, the administrator gets enough information to contact the customer quickly and verify the service area. If the company has multiple branches, you can add notification routing logic by district or city, but only if those values are saved consistently in the fields and the team understands how to maintain those rules.

A Commonly Missed Detail

Do not make the user wrestle with the map. For most requests, the map should confirm the address, not require separate work. If the visitor cannot find the address in the suggestions, the form should still provide a clear path forward: an additional comment, manual entry, or an explanation that the manager will confirm the exact address later. If you make suggestion selection too strict, some legitimate requests may fail because of new buildings, private areas, or nonstandard addressing.

Quick takeaway from this use case: a good field service form does not collect the maximum possible amount of geo data. It collects exactly the data needed to process the request without having to ask for the address again.

Best Post-Install Settings for Different Form Types

There is no single set of "best settings" in Formidable Forms Geolocation for every site. The right configuration depends on who is entering the address, why the map is needed, and how the entry will be used afterward. A common beginner mistake is to enable every available option and assume the form has been improved. In practice, an unnecessary location prompt, a large map, and a strict suggestion requirement can reduce conversions if they do not support the user's task.

Request or Contact Form

For a service request, an Address field with autocomplete and an additional comment field is usually enough. A map is useful if the address is critical for dispatching or distance estimation. Enable current location cautiously: it makes sense for an urgent callout or mobile-driven use case, but it feels odd in a standard contact form. In the administrator notification, output the address and coordinates on separate lines so they are easy to copy.

Form for Adding a Listing to a Directory

For a directory, each entry needs a stable point. Use the Address field, enable autocomplete, create several test entries, and only then configure the Map View. In the form itself, you can add a field for the listing title, a category, and a description. In the map marker, show the title and a link to details, not the entire address block. If the listing is private, decide in advance which part of the address may be published.

Delivery or Logistics Request Form

For delivery, accuracy and completeness matter. The Address field is preferable to a single-line field because individual address parts may be needed during processing. Autocomplete helps, but you still need an address notes field: apartment entry codes, floor numbers, warehouse entrances, and other details usually do not come from Google Places. Do not rely on the map alone if you have internal delivery rules or zone restrictions. Formidable Forms Geolocation helps collect the address, but the delivery business rules need to be designed separately.

Participant or Event Registration Form

For an event, city and country may be enough, and a participant's exact address may be unnecessary. If you are building a public map of community members, collect only the data the user agrees to show. For a venue form, by contrast, the exact address and map are useful. Keep those use cases separate: a person's location and an event's location are different kinds of data with different sensitivity levels.

How to Choose Geolocation Options by Form Type

Use case	Field	Map in form	Current location	What to verify
Field service request	Address field	Often useful	Only if the request is usually submitted from the service location	Address, coordinates, administrator notification
Location directory	Address field or text field with autocomplete	Useful for confirming the point	Usually not needed	The new entry appears in the Map View
Short contact form	Single-line field	Often unnecessary	Usually not needed	Suggestions do not get in the way of submission
Delivery or pickup	Address field	As needed	Depends on the workflow	Address completeness and notes field

After choosing the configuration, save the form and submit a test entry as a regular visitor. If the site uses caching, minification, or deferred JavaScript loading, be sure to test the form after clearing the cache and in a private browsing window. That will show you how the form behaves without administrator privileges.

How to Design the Form So Address Data Is Actually Usable

Geolocation will not fix a poorly designed form. It helps the user select an address and gives the site coordinates, but the quality of the entry still depends on which fields you added, what instructions you gave, and how the administrator will handle the submission. So before publishing, it helps to look at the form not as a set of fields, but as the future working record inside Entries.

Imagine the request has already arrived. Can the manager understand what needs to be done without opening an email thread or calling the customer back just to clarify the address? If yes, the form is designed well. If the entry includes a clean address but no apartment entrance, contact phone, service type, time window, or publication consent, geolocation is solving only part of the problem.

Separate the Precise Address from Location Notes

The autocomplete field should store an address that can be recognized and placed on the map. The address notes field should store the human details: rear entrance, gate number, access restrictions, landmark, apartment entrance, floor, building name, or suite. Do not try to force everything into a single autocomplete field. If the user adds free-form notes directly inside the address line, Google's suggestion may become less precise and the coordinates may be unexpected.

For a field service form, a good set looks like this: an Address field with autocomplete, an "Apartment, office, or unit" field, a "Landmark" field, and a "Notes for the technician" field. For a listing directory, the set is different: Address field, listing title, category, public description, and separate consent to publish the address. For an event, you need the venue address, event name, and date inside your business workflow, but the date should not be part of the geolocation layer.

When to Require Selecting from Suggestions

Requiring the user to pick an address from suggestions is helpful when the map or coordinates are critical: a listing directory, a field service request, delivery, or a branch map. But it can backfire if users often enter new buildings, restricted areas, rural addresses, or internal location names. In that case, it is better not to block submission completely, but to add a warning and a fallback field for clarification.

A practical pattern is to place a short instruction next to the address field: "Start typing the address and select an option from the suggestions." If the user cannot find the address, they fill out the notes field. The administrator then sees that the address requires manual review. That is more honest than silently saving incomplete data or forcing the visitor to keep trying different wording indefinitely.

Do Not Collect Coordinates Without a Clear Purpose

Coordinates are not always necessary. If the form is used only for contact requests, storing latitude and longitude may be unnecessary. If the entry will become a map marker, coordinates are needed. If a manager will copy the address into navigation software, coordinates may speed up verification, but they still do not replace the text address. If the data will be exported into another system, decide in advance which fields are exported and how the columns are named.

A strong setup starts with one question: "What is the next step a person or system takes after submission?" If the next step is calling the customer, you need a phone number and a clear address. If the next step is showing the listing on the site, you need a map and publication consent. If the next step is routing the request to a branch, you need a stable city, district, or manually selected zone value. Google does not have to provide all of those values. Sometimes it is more reliable to add a separate branch or service-area field.

Design the Public View Separately from the Internal Entry

The internal entry can contain more data than the public map. That is normal. In Entries, the administrator sees the full address, coordinates, notes, and contact details. In the Map View, the visitor sees only the listing title, area, and a link to the detail page. That separation is especially important for request forms, where geography is needed by the team but should not reveal private addresses.

If you are building a directory of user-submitted listings, add a separate field such as "Show exact address publicly?" or define publication rules in advance. Do not rely on the editor remembering each time which data may be displayed. It is better to have a field structure that separates public and internal data from the outset.

Practical check: open a test entry and read it as a manager. Then open the public View as a visitor. If both sides see exactly the data they need, the form is designed correctly.

Compatibility with the Theme, Cache, Email, and Anti-Spam

The geolocation field sits at the intersection of the user interface, external scripts, and entry storage. That means issues are not always inside the add-on itself. The theme may alter field styles, cache may delay or combine JavaScript, anti-spam may block submissions, and email delivery may create the false impression that the form is broken even though the entry was saved. It is important to test the full path without mixing up the causes.

Theme and Page Builders

If the form is embedded in a page through a block, shortcode, or builder widget, check whether the container is clipping the Google Places dropdown suggestions. Sometimes the parent block has a height limit or hides overflow. The symptom is simple: the field is active, but the suggestions are only partially visible or hidden beneath the next section. The fix depends on the theme, but first test the form on a normal page with a basic template. If everything works there, the problem is not the Google key, but the page layout.

Cache and JavaScript Optimization

Maps and autocomplete depend on JavaScript. If the site uses script optimization, bundling, delayed loading, or exclusions, add the form page to your verification checklist after every change. Do not begin by permanently disabling all optimizers. First, temporarily disable bundling or delay for the form page, check the outcome, then restore settings partially and isolate the specific rule that breaks the map.

For forms with a map, it is usually safer not to defer critical Google Maps and Formidable scripts until first interaction if deferred loading causes the map to render empty. If the optimizer supports exclusions by URL or script name, use that option narrowly. After making the change, clear the cache, open the page in a private window, and repeat the full test: address suggestion, map, submission, entry, View.

Email, Notifications, and Submission Storage

If no email arrives after submission, first open Formidable -> Entries. If the entry exists and geo data is saved, the problem is in notifications or mail delivery, not geolocation. Formidable's email notification documentation recommends testing notifications after setup and handling common delivery problems separately. On production sites, an SMTP plugin is often useful, but that belongs to the mail infrastructure, not to the map itself.

Anti-Spam and Location Permission

Anti-spam matters because address forms can attract automated submissions just like regular contact forms. Formidable supports multiple protection methods, including Akismet, reCAPTCHA, hCaptcha, and Cloudflare Turnstile. But do not overload the form with several barriers at once. For a short request form, one well-configured protection method is usually better than a combination that breaks submissions for real visitors.

The browser location prompt is not an anti-spam measure and does not confirm the user's identity. It is only a way to get the current location if the visitor agrees. If the user denies access, the form should still work with manual address entry if your workflow allows it. Do not turn a geolocation refusal into a form error unless it is truly necessary.

How to Work with the Entry Map After Launch

Once the form is live, the work is not over. In the first days, it is important to watch which addresses users actually submit, how often they choose suggestions, whether entries appear without coordinates, and whether the public map makes the page heavy. This step is often skipped because the form already looks finished. But it is only after the first real submissions that you see how well the settings fit the audience.

For Formidable Forms Geolocation, it helps to define a simple handling routine. A new entry is first checked in Entries: does it include the address, coordinates, and contact details? If the entry is meant to appear on a public map, the editor checks whether the address can be published and whether the description is complete enough. If the map is used as a directory, the entry should have a clear title, a category, and a detail page. If this is an internal request, a public View may not be needed at all.

Editorial Review of Addresses

Autocomplete reduces errors, but it does not make the data flawless. A user may choose the neighboring building, enter an office complex instead of the exact entrance, submit a relative's address, or add a note that changes the meaning of the request. For that reason, important workflows still require an address review before action: open the map in the entry, compare the note, and contact the customer if needed.

If you see recurring issues, do not just fix each entry manually. Improve the form itself. For example, if users often omit the building section, add a separate field. If they enter a neighborhood instead of an address, change the field label. If the map takes too much space and people submit the form before selecting a suggestion, make the instruction next to the field more prominent or temporarily remove the map from the form while keeping autocomplete.

The Public Map as Part of the User Journey

The Map View should answer a concrete visitor question: where are the listings, which one is closer, and what can I open for more details? If the map simply shows many markers without titles or context, it may look impressive but offer little help. It is better for the marker to show a short title and one useful line. Details, images, contact information, and a long description are better displayed on the View detail page.

Check the map at different zoom levels. If many markers are in one city, the user should understand where to click. If listings are spread across the country, the initial zoom should not open too tightly on a single point. To change the initial zoom, you can use the documented frm_geo_map_zoom filter, but first make sure the default behavior is truly getting in the way.

What to Do with Incorrect or Incomplete Entries

Do not delete an entry immediately if it has no coordinates. First determine why that happened: old data, manual input, an API failure, a script conflict, the user declining current location, or the wrong field being used in the View. For a directory, you can temporarily leave such an entry unpublished. For a request, you can handle it manually while also improving the form.

It is helpful to agree on simple internal status labels inside the team: "ready to publish," "verify address," "do not publish exact point," or "call needed." That can be implemented with standard Formidable fields or as part of the team's internal workflow. The key is not to confuse automatic geolocation with the editorial decision. The plugin helps collect the data, but responsibility for publication and handling still belongs to the site owner.

SEO, Local Search, and User Trust

Formidable Forms Geolocation is not an SEO plugin and should not be described as a tool that guarantees ranking growth. Its impact is indirect: it helps collect accurate address data, display a location map, improve form usability, and reduce mistakes in submissions. For a local business, that can support page quality, but only if the data is published correctly, useful to visitors, and respectful of privacy.

If you publish a map of branches, listings, events, or service points, give each entry a clear title, a short description, and a link to details. A map without text context is harder for both search engines and people to understand. A visitor needs more than a marker. They need to know what is at that address, why the location matters, when it is available, and what to do next.

How to Avoid Turning the Map into a Weak Page

A weak map page contains only the map and a few random markers. A strong page explains what the map shows, how to choose a listing, which data is updated through forms, and how to contact the owner. If users add entries themselves, state that the data is moderated only if that is actually true. If there is no moderation, do not promise it.

For a listing directory, it is useful to combine the Map View with a text list or detail pages. The map helps people orient themselves quickly, while text gives search engines and users real content. Formidable Views can display form data in multiple ways, so the map does not have to be the only presentation mode. Sometimes the strongest setup is a combination: map at the top, a filterable list below, and a detail page for each entry.

Microcopy Next to the Address Field

A short phrase often makes the form more usable. Instead of the generic "Address," write: "Start typing the address and select an option from the suggestions." If current location is enabled, add a brief explanation: "Permission is only used to quickly detect the service address." If the address will be published, say so before submission. That kind of microcopy is not a legal document, but it reduces confusion and increases trust.

Do not overload field labels with legal wording if you already have a privacy policy nearby. The field should support action. Detailed data-handling rules are better placed in separate text, while the form itself should keep a clear explanation of why the address is being requested right now.

Safe Enhancements for Developers and Webmasters

Formidable Forms Geolocation includes documented extension points. Use them carefully: only on a copy of the site, and through a child theme, WPCode, Code Snippets, or another safe mechanism that can be disabled quickly. Do not edit WordPress core files, Formidable Forms files, theme files, or add-on files. If the site handles customer requests, test each snippet on a form dedicated to testing first.

Below are a few small improvements based on official Formidable materials: changing the initial map zoom, narrowing autocomplete suggestion types, and adjusting map height with custom CSS. They are not required for a standard setup, but they help tailor the form to a specific use case.

Change the Initial Map Zoom

If the map opens too far out or too close in, use the frm_geo_map_zoom filter. Formidable's documentation describes this filter for setting the initial zoom level. The example below applies a closer zoom. Pick the value on a test form: for a city, a medium zoom is often enough; for a precise address, you can zoom in further.

add_filter( 'frm_geo_map_zoom', 'my_formidable_geo_zoom' );

function my_formidable_geo_zoom( $zoom ) {
    return 15;
}

After adding the snippet, open the public form, select an address, and check the map's initial position. If the map becomes less usable, disable the snippet or restore the previous value. Do not use an excessively tight zoom for forms where the address may be approximate, because the user will end up seeing too small an area.

Narrow the Autocomplete Suggestions

The frm_geo_autocomplete_options filter is useful when Google Places suggestions are too broad for the form. For example, a field service request form usually expects an exact address, not the name of a business or landmark. Formidable's official documentation includes ready-made controller methods that switch the suggestion type. For an address-based form, you can use the address autocomplete option:

add_filter(
    'frm_geo_autocomplete_options',
    'FrmGeoAppController::use_address_autocomplete_type'
);

Before rolling this out, test several real addresses from your service area. If users often enter shopping centers, clinics, or office complexes by name, an overly strict suggestion type may make the experience worse. In that case, it is better to keep the default behavior or choose another type that better matches the form data.

Adjust the Map Height in the Form

Formidable's documentation notes that custom CSS can be added under Formidable -> Global Settings -> Custom CSS. If the map takes up too much space or feels too short, you can set a cleaner height for the map container. The exact class depends on your current form markup, so inspect the element in the browser first. The example below assumes the map is inside a container with the class frm-geolocation-map; before applying it, replace the selector if your form uses a different one.

.frm-geolocation-map {
    min-height: 320px;
    border-radius: 8px;
    overflow: hidden;
}

The check is simple: open the form on desktop and phone, select an address, and confirm that the map is fully visible, does not cover the submit button, and does not break nearby fields. The rollback is equally simple: remove the CSS from the global settings or disable the snippet in your snippets manager. If the selector is not confirmed in your current markup version, do not paste it in blindly.

How to Verify the Setup

Verification should cover the entire chain, not stop when the map simply appears on the screen. That is especially important with Formidable Forms Geolocation, because the product is involved in address entry, external service loading, form submission, entry storage, and possible data display through a View. An error at any stage may look similar to the user, but the fix is different.

Admin Verification Path

1. Open the published form page. Do not limit testing to the builder preview.
2. Start typing an address. Check whether Google Places suggestions appear.
3. Select a suggestion. Make sure the map, if enabled, moves to the selected point.
4. Submit the form. Use test contact data that will be easy to identify in the entries.
5. Open the entry in the admin panel. Check the address, city, region, country, latitude, and longitude if those values are available for the chosen field.
6. Check the notification. If the email does not arrive, first confirm that the entry was created, and only then troubleshoot mail delivery.
7. Check the View. If you are displaying an entry map, make sure the new test entry appears as a marker.

What Counts as a Successful Setup

Success is not just a nice-looking map on the page. A successful setup means the visitor can complete the form without unnecessary confusion, the address is saved in the entry, the geo data is available to the administrator, and the public output shows only the information that is allowed to be shown. If the Map View is used for a directory, a successful outcome also includes correct markers, clear popups, and no sensitive data exposed publicly.

Check the failure paths too. What happens if the user denies current-location access? What if they type the address manually and do not choose a suggestion? What if the map does not load because of a blocker or poor connection? A good form should explain what to do next, or at least avoid losing the submission if manual entry is allowed. For critical address-based forms, you can add nearby text such as: "Start typing the address and select an option from the suggestions."

Quick Audit Before Publication

Before opening the form to visitors, submit at least several test entries using different addresses: a nearby address, a distant address, an address with a building section or unit, and an address outside the main country if international entry is allowed. Then delete or clearly mark the test entries so they do not appear in the live View. Make sure the Google API Key is restricted to the domain and that public Views do not expose private addresses. This takes less time than cleaning up submissions manually later.

Troubleshooting Common Problems

Geolocation issues often look similar: no suggestions, an empty map, an entry without coordinates, or a public View with no markers. But the causes are different. Below is a practical troubleshooting guide based on symptoms that are specific to forms using Google Maps and Formidable Forms Geolocation.

The map shows the message This page can not load Google Maps correctly

Symptom: instead of a normal map, you see a dimmed or error-state Google Maps block. Address suggestions may not work at all or may work only partially. Likely cause: billing is disabled in Google Cloud, one of the required APIs is not enabled, the site restriction is wrong, or the key does not match the domain.

What to check: open Google Cloud Console and confirm that Geocoding API, Maps JavaScript API, and Places API are enabled, and that billing is active. Check the HTTP referrers: the domain must match the real address of the page where the form appears. If the site works both with www and without www, include both versions if they are actually in use.

How to fix it: correct the key restrictions, save the settings, clear the site and browser cache, and then repeat the test on the published page. If the map only starts working after disabling restrictions, do not leave the key open. Instead, refine the allowed domain format and the API list.

Address Suggestions Do Not Appear

Symptom: the address field is there, but no dropdown suggestions appear when typing a street. Possible causes: Places API is not enabled, the key is not saved in Global Settings, the field does not have Add address autocomplete enabled, JavaScript failed to load because of an optimizer, or the suggestions are covered by theme styles.

What to check: create a simple test form with one address field. If suggestions appear there, return to the original form and check the field settings, conditional logic, and page layout. If suggestions do not appear anywhere, check the key and APIs. If suggestions do appear but are visually cut off, the issue is in the container CSS or the page builder layout.

Coordinates Are Not Saved in the Entry

Symptom: the user selected an address, but the entry does not contain latitude and longitude, or the map in the entry details does not show the point. Possible causes: the address was entered manually without selecting a suggestion, the field is configured as plain text without geolocation, the entry was created before the add-on was enabled, or a nonstandard form validation rule fired.

How to fix it: enable autocomplete on the correct field, create a new test entry, and review it separately from old data. If the form truly requires an address from suggestions, add a clear instruction next to the field or use safe validation based on documented Formidable hooks, but do not block users without a thoughtful fallback path.

The Map View Is Empty or Missing Some Markers

Symptom: the View map is published, but there are no points on it or some entries are missing. Possible causes: the wrong data source was selected, the wrong address field was selected, older entries do not contain coordinates, the View is published with visibility restrictions, or there is a JavaScript conflict on the page.

What to check: open the View settings and confirm that the type is Map, the source form is correct, and the address field is the right one. Create a new entry after enabling Geolocation and see whether that specific entry appears. If the new entry appears but older ones do not, the problem is in the old data, not in the View.

The Browser Does Not Detect the Current Location

Symptom: the current-location feature does not work, or the user sees a denial state. Possible causes: the site is not running over HTTPS, the visitor denied access, the browser is blocking the request, the device is not providing accurate geolocation, or the feature is disabled in the field settings.

How to fix it: verify HTTPS, repeat the test in another browser, clear the site's geolocation permission, and try again. If the workflow does not depend on it, keep manual address entry as a normal path. If current location is required, explain to the user why access is needed and provide an alternative way to contact you.

The Form Submits, but the Email Does Not Arrive

Symptom: the user sees a confirmation, the entry is created, but the administrator email never arrives. The cause is usually not Geolocation. Check the notification actions under Settings -> Actions & Notifications, the recipient address, sender address, spam folder, and WordPress mail delivery. If the entry exists, the geolocation layer has already done its part.

When It Makes Sense to Roll Back a Setting

Roll back the specific change, not the entire plugin. If the form became too heavy after enabling the map, disable Show map and keep autocomplete. If users complain about the location prompt, disable Use visitor location. If a custom snippet made suggestions too strict, disable it and return to the default behavior. Completely disabling the add-on only makes sense when address data is no longer needed or the conflict cannot be resolved without risking the forms already in use.

Limitations, Privacy, and Careful Publication of Geo Data

Geolocation has boundaries that are best made clear before launch. The first limitation is official documentation: Geolocation is not compatible with repeaters. If your form is built around repeatable rows where the user adds multiple addresses, do not assume geolocation will handle them as reliably as a standalone field. Design the data differently: one entry per address, multiple separate forms, child entries, or a specialized solution.

The second limitation is tied to accuracy and data source. Google Places helps the user choose an existing address, but it does not guarantee the person is actually there. Browser geolocation depends on permission, device, network, and user settings. IP-based location can be approximate. That is why field service and delivery forms should always keep an address notes field and administrator review if an address error costs time or money.

The third limitation is the visibility of Views. If you output entries on a map, you are effectively publishing part of the form data. That is fine for restaurant directories, stores, events, or public listings. It is not fine for customer requests, home addresses, medical inquiries, or internal submissions. Configure View visibility carefully, do not output private fields, and test the page as a regular visitor.

How to Reduce the Risk of Collecting Excess Data

• Collect the exact address only when the workflow requires it. For regional statistics, city or country may be enough.
• Explain the current-location request. A short note next to the field reduces distrust and helps the user understand why the permission matters.
• Do not display coordinates publicly without a reason. For a map visitor, a marker or general area is often enough if the exact point should remain private.
• Review access to Entries. Not every WordPress role should be able to see requests with private addresses.
• Do not send unnecessary data in emails. If the email goes to multiple employees, think about who truly needs the coordinates.

Privacy is not a ban on geolocation. It is careful data separation: what the user needs in the form, what the administrator needs in the entry, what can be shown publicly, and what should remain inside a private workflow.

Practical Pairings with Other Formidable Forms Features

Formidable Forms Geolocation becomes much more useful when geo data does not sit in isolation. Inside Formidable Forms, you have forms, entries, notifications, conditional rules, Views, shortcodes, import, and export. Not every pairing is a standalone official Geolocation integration, but many real workflows are built on Formidable's documented platform features. The important thing is to distinguish honestly between what the documentation explicitly supports and what is a safe custom setup built on standard functionality.

Geolocation + Visual Views for a Location Directory

This is the clearest pairing because the Views documentation directly describes Map View for entries with geolocation. The role of Geolocation is to collect the address and coordinates. The role of Visual Views is to take form entries and show them on a page. The setup order is: enable Geolocation, create the address field, submit test entries, create a Map View, choose the data source and address field, and then publish the View.

Potential friction points: old entries without coordinates, View visibility, map caching, and markers that reveal too much detail. Validation: a new test entry should appear on the map, and clicking the marker should show only the fields you intend to publish. Rollback: unpublish the View or temporarily restrict its visibility without deleting the form or the entries.

Geolocation + Notifications for Routing Requests

Formidable Forms can send email notifications and supports conditional logic in actions. Based on the city, region, or a selected field, you can send different notifications to different recipients. That does not mean Geolocation automatically routes requests to branches on its own. It provides address data, while notification rules still need to be configured separately.

The workflow is straightforward: make sure the needed city or region values are saved consistently in the entry, create separate email actions, add the conditions, and submit test requests for different addresses. The main friction point is inconsistent region values across countries or address formats. Validation: the message should go to the correct recipient, while the entry remains available in Entries. Rollback: disable the conditional logic or return to one general notification.

Geolocation + Form Publishing via Block or Shortcode

The form can be published through the standard block or the shortcode [formidable id=x]. On pages that include a map, the insertion method matters less than the surrounding environment: theme, container, cache, and access settings. If the form does not work inside a complex builder page, place it on a temporary basic page and compare the behavior. That makes it easier to tell whether the issue is in the form itself or in the page layout.

The safe order is to get it working on a simple page first, then move it into the final layout. If suggestions become clipped or the map is no longer visible after the move, check the container CSS, suggestion z-index, deferred script loading, and optimizer settings. Do not change Geolocation code to solve a problem that actually belongs to the page layout.

When Formidable Forms Geolocation Is the Right Choice

Formidable Forms Geolocation is worth using when the address is part of the form and part of the follow-up entry handling. The product fits well into projects that already run Formidable Forms Premium, where faster address entry matters, where coordinates need to be saved, where a map should appear in the entry, or where an entry map needs to be built through Visual Views. It is especially useful for field services, listing directories, delivery forms, event requests, and internal location databases.

Before launch, verify three things: do you have access to the required add-on, is the Google Maps API Key properly restricted, and is it clear where geo data will be stored and displayed? After that, you can download the installation package, install it on a staging copy of the site, configure one form, and walk through the full validation flow from address suggestion to saved entry and map.

If all you need is a static office map, this product may be excessive. If you need a large geolocation platform with radius search and complex location types, compare it with specialized directory solutions. But if your workflow starts with a WordPress form and the address needs to become an accurate, verifiable, and useful part of the entry, Geolocation handles that part more clearly than a collection of manual fields.

Questions Worth Answering Before Launch

Can I use Formidable Forms Geolocation without a Google Maps API Key?

According to the documentation, Google Places features, address autocomplete, and maps require a Google Maps API Key with the necessary services enabled. Without a configured key, the form may still work as a normal form, but the geolocation features will not perform their core role.

Why might Google suggestions in a Russian-language form look different from what I expect?

Suggestions depend on Google Places, the browser language, request settings, and the selected autocomplete type. If you need more narrowly targeted results, a developer can use the documented frm_geo_autocomplete_options filter, but it should be tested against real addresses used by your audience.

Can I display the geolocation map in an email?

The interactive map shortcode with show="map" is documented for Views and is not available in email. In notifications, it is better to send the text address and coordinates, and view the map inside the entry or on the View page.

What should I do with old entries created before autocomplete was enabled?

Start by checking a new test entry. If that one appears on the map and the older ones do not, the older entries most likely do not contain the necessary geo data. Do not promise automatic recovery: an older database may require manual review, collecting the data again, or a separate address-enrichment process.

Is the plugin compatible with repeating sections?

Formidable's official documentation lists a limitation: Geolocation is currently not compatible with repeaters. If you need a form with multiple addresses inside repeatable rows, design the data differently and do not treat that use case as guaranteed support.

Does the map affect page speed?

The map and autocomplete load external Google scripts, so they can affect the page more than a standard text field. For short forms, enable the map only where it genuinely helps the user. After publishing, test the page with caching, JavaScript optimization, and a real mobile connection.

Do I need to enable current location for every form?

No. Use visitor location is useful when the form genuinely works with the user's current location. For a property address, delivery to another address, or a standard contact form, a geolocation prompt may be unnecessary. In those cases, keep autocomplete and manual entry.

Can I use this product for a full "near me" directory?

Formidable Forms Geolocation helps collect addresses and, together with Visual Views, display entries on a map. For advanced distance search, categories, geotags across multiple post types, and a large-scale directory, you may need additional architecture or a specialized plugin. The right choice depends on the specific use case, the data volume, and the search requirements.