Metadata

Goal

So you turned geofilters on, and now something’s off — the app opens to the wrong starting location, the listings come back empty or way too short, or a city sits in the wrong spot on the map. This article walks through the most common causes, in the order they’re worth checking, so you can get the location picker back to showing the right content.

Here’s what’s happening under the hood: geofilters send the chosen city’s latitude/longitude plus a search radius on every content request. Almost every “wrong location” or “no listings” problem traces back to one of those two inputs being off, or a city getting filtered out before it ever reaches the app. We’ll check both.

Prerequisites

• Geofilters already enabled for the role you’re testing — see Recipe: Enable geofilters. If the picker doesn’t show up at all, that’s an on/off problem rather than a results problem — start there instead.
• WordPress admin access to Mobile App Manager.
• A device or simulator signed in as a user in the affected role.
• For the code-level checks at the end: access to the site’s PHP (a snippet plugin or theme functions.php).

Steps

Work through these in order — the first three catch the large majority of cases.

1. Confirm the radius isn’t too small

The single most common cause of “no listings” is a radius smaller than the distance between your content and the selected city. Set a regional app to a 25-mile radius, say, when your nearest listing sits 60 miles out — the app is doing exactly what it’s told when it comes back empty.

• Go to Mobile App Manager → App Settings and open the affected role.

• Find GeoFilter Radius (Miles) (tsl-setting-geofilter_radius) on the GeoFilters settings tab.

• If it’s empty, the plugin uses a default of 25 miles. For a statewide app that’s almost always too tight.

• Bump it to something appropriate for your content density:
  Tight regional app: 25–50

• Statewide app: 100–250

• National app: 500+

• Save and re-test.

There’s a hard cap of 3000 miles, built into the plugin’s own radius callback — anything you enter above that has no further effect on the default path.

Watch for a per-request override, too. The mobile app can send its own explicit radius query parameter, and that short-circuits the per-role setting. So if one user is getting a different radius than the role configures, check whether the client is sending its own radius. (See Hook: mam_geofilter_radius for the full precedence chain: $_REQUEST['radius'] → per-role setting → 25 → capped at 3000.)

2. Check the selected city’s coordinates

“Wrong location” — the map or the results centered on the wrong spot — almost always comes down to bad coordinates on a city row. There’s also a hard rule that quietly removes broken rows before you ever see them:

A city whose latitude or longitude is 0 is dropped from the mobile payload without any error. If you added a city and it never appears in the picker, this is the first thing to check.

• Go to Mobile App Manager → Manage Cities.
• Find the city in the editable table (columns: Name, Latitude, Longitude, Active?).
• Confirm Latitude and Longitude are both non-zero and actually point at the place you mean. A common mistake is a swapped or missing sign — US longitudes are negative (e.g., New York is roughly 40.71, -74.01). Drop that minus sign and the city lands on the other side of the planet, so nothing in your content ever falls inside its radius.
• Fix the values and Save Changes.

The Manage Cities page writes to the WordPress option tsl_gd_map_manager_cities, storing each entry’s name, lat, lon, and active flag. Worth knowing: a standalone geofilters install actually serves the picker from a built-in default city list (in geofilters-cities-list.php). The Manage Cities coordinates take over once mam-geodirectory is driving your location list (the common pairing) — that’s when they become what the app matches your selected city against.

3. Make sure the city isn’t hidden or inactive

For a city to show up, it needs to be both active and not hidden — two separate switches on two separate screens, which makes it easy to flip one and forget the other.

• Manage Cities page — confirm the Active? column is on for the city. This flag is stored on the tsl_gd_map_manager_cities row; leave it on for cities you want available in a mam-geodirectory-backed app.
• Geofilters tab (Mobile App Manager → Geofilters) — confirm the Show checkbox next to the city is checked. Unchecking it adds the city to the WordPress option mam_geofilters_hidden, which drops it from the built-in default list.

If a city you’re expecting is missing from the picker entirely, rather than just returning no listings, it’s almost always one of these two — or the zero-coordinate drop from Step 2.

4. Understand the “Current Location” / GPS path

If the app opens on the device’s actual location when you weren’t expecting that — or stays put when you were expecting it — you’re looking at the GPS path.

• When the device shares GPS coordinates, the app sends actual_lat and actual_lon, and the picker is prepended with a “Current Location” entry at those coordinates. This is on by default.
• This prepend is suppressed when the option gd-show-current-location-on-app is set to 'no', or when the request signals no GPS (no_gps=yes).
• If users report the app “starts in the wrong city,” they may simply be seeing Current Location selected first — showing content near them rather than near your default city. That’s expected behavior, not a bug. Just confirm with the user whether they granted location permission.

Most of the time, there’s nothing here that needs fixing. If you do want to suppress the Current Location entry, set gd-show-current-location-on-app to 'no'.

5. Understand the IP fallback (GPS denied)

When the user denies or has no GPS (no_gps=yes) and the GeoIP Detection plugin is installed, the plugin works out a city from the request’s IP address and prepends that to the picker, setting location_name along the way.

This one path explains two symptoms that tend to confuse people:

• “It picked a city near my data center / VPN, not me.” IP geolocation resolves to the network’s location, and for a VPN, corporate proxy, or certain carriers that can be a long way from the actual user. That’s just how IP-based location works, not a misconfiguration.
• “It used to fall back to a city and now it doesn’t.” The fallback only runs when the GeoIP Detection plugin is active and its lookup function is available. Deactivate that plugin, or lose its database, and the request just falls through with no prepended city. Re-check that GeoIP Detection is installed and active under Plugins.

If you’d rather not have IP-based fallback at all, just leave GeoIP Detection uninstalled — the plugin simply skips that branch.

6. Code-level overrides (developers)

If the admin settings all check out but the behavior still doesn’t match, a filter may be overriding the resolved values behind the scenes. Check for subscribers to:

• mam_force_geofilters — last-word override on whether the picker is on at all. Despite the name, returning false here disables geofilters even when the role setting is yes. A stray kill-switch callback can make the whole feature look broken.
• mam_geofilter_radius — overrides the resolved radius. A callback running at a later priority can return any value, including one that ignores the 3000-mile cap or a too-small clamp. Grep your snippets for this filter if the radius doesn’t match the role setting.
• mam_geofilter_list — fully replaces the city list (this is how mam-geodirectory takes over). If this filter has any subscriber, the built-in city list and the Manage Cities / Geofilters admin screens no longer drive what the app sees. Verify whether something is hooking it before you spend time editing cities that aren’t being used.

See the dedicated hook articles for signatures and examples.

Quick checklist

Verification

After making a change, confirm the fix end to end:

• Open the mobile app for a user in the affected role and open the location picker.
• Confirm the expected cities are present (none unexpectedly hidden or dropped).
• Select the city in question — the app should refresh the home view and show content near it.
• Confirm the listing count looks right for the radius you set.

This article was last verified against:

• Plugin: mam-geofilters v2.1.1
• Source: mam-geofilters/includes/phone-manager.php (Current Location prepend, IP fallback, gd-show-current-location-on-app, no_gps)
• Source: mam-geofilters/includes/geofilters-cities-list.php (mam_geofilters_hidden, zero-coordinate drop)
• Source: mam-geofilters/includes/admin-settings.php (Manage Cities, tsl_gd_map_manager_cities)
• WP options: tsl_gd_map_manager_cities, mam_geofilters_hidden, gd-show-current-location-on-app

Re-verify whenever the radius precedence chain, the default/cap radius values, the zero-coordinate drop, or the GPS/IP fallback logic changes.

Related articles

• Recipe: Enable geofilters — if the picker doesn’t appear at all
• Recipe: Manage the city list — hide, edit, or add cities
• Hook: mam_geofilter_radius — override the resolved radius in code
• Hook: mam_force_geofilters — override the on/off decision in code
• Hook: mam_geofilter_list — replace the city list entirely
• Plugin overview: mam-geofilters