The World’s Most Advanced And Scalable WordPress Directory Plugin
GeoDirectory is an enterprise-grade WordPress plugin for building scalable business directories, city guides, real estate listings, job boards, event sites, classifieds, and local discovery platforms. Unlike generic listing plugins, it uses custom database tables, not WordPress post meta, so sites perform well from small local portals to directories with hundreds of thousands or millions of listings. Core features include optimized search, maps, reviews, frontend submission, and an extensive add-on ecosystem for customization. Rated 4.8/5 across 700+ reviews on WordPress.org and Capterra.
Get GeoDirectoryWhat can i do with GeoDirectory?
WordPress localization features allows you to make plugins and themes easily translatable through WordPress Language files (po/mo files).
This is true especially since WordPress 3.7 and it got a whole lot easier since WordPress 4.6.
A lot of improvement has been made to the whole translation system for WordPress, I felt it really needs a refreshed post.
WordPress language files – The confusion ( Developer edition )
For developers, it comes down to how to let WordPress know you have translation files the proper way.
As developers we were told to use “load_plugin_textdomain()” and point this to our language file in our plugin folder.
However in the past this would be the only place WordPress would look and if a customer added their own language file there, on the next update it would be gone!
There was an article on the web a while back promoting using a second call this time using the function “load_textdomain()” to point to a file in the WP language folder and that is what a lot of people did (including us).
This meant that users could place their language files in a predetermined place in the WP language folder and the translation would not be lost on the plugin update.
WordPress language files – The confusion ( User edition )
Users need to know where to put a custom translation for a plugin/theme, the problem is that in the past this could have been in several places.
The WP documentation tells developer to link to a folder inside their plugin folder called “languages” but the developer might use the folder “lang” and even then this will be lost when the plugin/theme is updated.
Some developers would add a second check again in a place of the developers choosing, but often in a custom named folder in the WP languages folder.
This meant there was no consistent way for a user to know where to place their custom translation files safely.
Loading language files the correct way (2017)
Since WP 4.6 this got a whole lot easier for both users and developers!
As a developer you now just have to make sure you are loading your language files correctly, following the WP documentation as below:
<br />
// for plugins<br />
add_action( 'init', 'myplugin_load_textdomain' );<br />
function myplugin_load_textdomain() {<br />
load_plugin_textdomain( 'my-plugin', false, basename( dirname( __FILE__ ) ) . '/languages' );<br />
}<br />
<br />
// for themes<br />
add_action( 'after_setup_theme', 'my_theme_setup' );<br />
function my_theme_setup(){<br />
load_theme_textdomain( 'my-theme', get_template_directory() . '/languages' );<br />
}<br />
Notice we fire these on the ‘init’ and ‘after_setup_theme’ hooks, this should mean everything will load nicely.
If you fire it directly or before their respective hooks you can have problems with some strings not translating and plugins to manipulate translations or to create multi lingual websites such as WPML, might not work at all.
As users we now have a convenient and consistently named place we can place our language files.
- For plugins: /wp-content/languages/plugins/my-plugin-en_US.mo
- For themes: /wp-content/languages/themes/my-theme-en_US.mo
The ‘my-plugin’ and ‘my-theme’ being the textdomain of the plugin/theme (usually found in the plugin readme.txt or the theme style.css at the top).
This is a great improvement over the old way and will prevent losing translation on updates in most cases.
In some cases the plugin/theme might already have a new translation in your languages stored on wp.org, if this is the case then it might overwrite your .mo file but in most cases this will be desired.
You can contribute to translations on wp.org if the plugin is hosted there, if it is a premium plugin there there is little chance it will be overwritten.
Bonus information
WordPress will try to find your WordPress language files in several places,for a plugin with a textdomain ‘my-plugin’ it would first look here:
/wp-content/languages/plugins/my-plugin-en_US.mo
If it does not find a translation there and the plugin specifies where to find one locally, it will look there:
/wp-content/plugins/my-plugin/languages/my-plugin-en_US.mo
If the plugin does no specify a path then WordPress will look here instead:
/wp-content/languages/my-plugin-en_US.mo
The WordPress documentation should be followed but in reality from WP 4.6 you don’t even have to specify a local file if you are not including any (if they are stored on the wp.org repo), so you could just add this:
<br />
// for plugins<br />
add_action( 'init', 'myplugin_load_textdomain' );<br />
function myplugin_load_textdomain() {<br />
load_plugin_textdomain( 'my-plugin');<br />
}<br />
<br />
// for themes<br />
add_action( 'after_setup_theme', 'my_theme_setup' );<br />
function my_theme_setup(){<br />
load_theme_textdomain( 'my-theme');<br />
}<br />
I hope this clears translations up a bit and if you have any questions or have anything to add please leave a comment below.
Update Sept 2019
This has been added as a predefined custom field in V 2.0.0.67. The snippet below will only work if using GeoDirectory V1.
The Problem
Today a member had a bit of an unusual request, they are using GeoDirectory to run a local festival and they are listing things like accommodation for it. The request was to show the distance in each listing to the main event so users have a clear understanding of how far it will be to the event from each listing. I do something very similar on one of my own sites that is for one location, i list the distance to the airport and the distance to the main town, i have until now just had users enter this distance manually, this is often wrong and i have to correct it.
The Solution
This seemed like the perfect time to create a new custom field, lets call it “Distance to”. The code is below but there are two ways to use this field:
#1 We could just add the field and let the user enter GPS coordinates, it might be for example a “closest airport” field, the user could then enter the GPS info for the closest airport to them.
#2 In this users case he just needs to show the distance to one place and without the user really needing to even know about the field, so when he is adding the custom field he would set the field as a “admin only” field so it is not shown to the user on the frontend and they can’t change it, and then set the “default value” to the GPS coordinates needed and all listings will then show the info needed.
The Code
This post will tell you how to fix the “This page didn’t load Google Maps correctly. See the JavaScript console for technical details.” problem with Google Maps.
If you are using GeoDirectory please see our documentation here.
If you want to read about the problem see our blog post here: https://wpgeodirectory.com/google-maps-api-key-and-new-limits/
If you have seen the message “This page didn’t load Google Maps correctly. See the JavaScript console for technical details.” or any of the following messages:
“Esta página no ha cargado Google Maps correctamente.”
“Google Maps ne s’est pas chargé correctement sur cette page.”
“Google Maps non è stata caricata correttamente.”
“Google Maps wurde auf dieser Seite nicht richtig geladen.”
“При загрузке Google Карт на этой странице возникла проблема.”
The chances are you need this fix, if you are using WordPress then we have created a plugin that should fix this for most users who’s plugin or theme is causing this, you can find it here: GOOGLE MAPS API KEY FIX
If you are not using WordPress you will need to find your call to google maps in your source code and add the api key, you can find instruction on creating an API Key here. Once you have your API key you add it to your call to the Google maps file maps.google.com/maps/api/js?key=YOUR-API-KEY-HERE
I hope you found this useful, feedback is always welcome.
The GeoDirectory Team.
We are delighted to announce support for Snazzy Maps in our Custom Google Maps addon (1.0.5).
What is Snazzy Maps?
Snazzy Maps is an online resource that enables users to customize the colors, saturation, and other styling options of their Google Maps.
The customization options are provided in the form of different map styles designed by various authors across the web.
In addition to editing maps with Snazzy Maps, users can create their Snazzy Map styles for use within their websites or apps.
All customized maps also offer high-resolution satellite imagery and vector support for both web and mobile devices.
With these features, businesses and developers alike can create visually appealing maps for their projects without relying on coding skills.
Why did we add support for Snazzy Maps on GeoDirectory?
Just over a week ago, one of our Members `Pieter Ravelli` brought the website to our attention, and it struck a chord with the team here, so it was pushed to the top of our development tasks.
This defines our ethos here at GeoDirectory. If a member can suggest something that will benefit all members, we will happily add it.
Importing Snazzy Maps Styles into GeoDirectory
Adding snazzy maps to the Geodirectory Custom Maps add-on is relatively simple.
- First, go to snazzymaps.com and find or create a style you like.
- Once you are on the page you like, you will see a copy button. Click that.
- Next, go to your GeoDirectory settings and go to GD>Custom Google Maps>Manage Styles and click to edit the map you want to change.
- On the edit map styles screen, click the “import styles” button, paste your styles code from Snazzy Maps, and click the “Import & Save Styles” button.
- Now your new map styles will be used on your site.
Are you using Snazzy Maps with GeoDirectory? If yes, which style are you using? Let us know in the comments down below.



