GeoIP city definition and geo-dependency on sites

This article was translated automatically. We are working over improving the translation.

Please send your questions about the article to info@intervolga.ru

Why do you need GeoIP

Your task is to show different phones / prices / availability of goods depending on the user's city? Or maybe you want to simplify the user ordering? - These tasks rest on the automatic determination of the country / city by IP-address.

Is it difficult to locate a user by IP address? Probably not difficult. But to do it qualitatively - the task is not for the faint of heart. There are several reasons for this:

1. Accuracy is extremely low and varies depending on the base of IP-addresses.

2. IP addresses are constantly changing their location, and site owners forget to update their databases.

3. Developers have a temptation to go along the curve track and start accessing online services.

4. Developers too lazy to do caching

5. The name of the city, which returns the geo-base, it is difficult to associate with the site location and business logic.

6. In Bitrix there is no ready-made component to display / change the city

The difference in labor intensity between “and so come down” and “reliable solution” is 20-40 man-hours. We stuffed cones for a long time, and when we’re tired of it, we put together all our developments in one cool module for Bitrix.

Under the hood of the geo-module

Several GEO IP databases to choose from

There are a total of 4.22 billion IPv4 addresses. They are divided between countries. Within countries between Internet operators. The latter, in turn, distribute them between the cities of presence. And then redistributed by necessity.

There are special registries where this distribution is fixed. In this article, we will call them GeoIP databases. They differ in the frequency of updates, accuracy and volume of additional data (city names in several languages, postal codes, names of Internet operators).

In the module we support 3 ordinary geo-bases:

• MaxMind,

• IpGeoBase ,

• Sypex Geo

and one “meta base”: MaxMind + IpGeoBase.

MaxMind is located down to cities around the world. But rarely updated (free version once a month). On the other hand, IpGeoBase works well only in the Russian Federation and Ukraine, but it is updated every day.

“Meta-base” determines the location first by IpGeoBase. If the country is defined as Russia or Ukraine, the data are considered the most accurate. If the country is different - turn to MaxMind.

Coding independence

Different databases are stored in different encodings (CP1251, UTF-8). And sites can be in different encodings. It was not easy, but we implemented the correct operation of all geo-bases for sites in both codings.

High speed

Almost all geo-databases can be accessed both through web services and locally (after downloading).

Novice developers often choose the first option. It is understandable, it is simpler and you do not need to worry about updating the databases. But there are 2 fly in the ointment:

• The web service will hang - the site will hang. The web service is “dead” - the site does not open at all.

• Accessing web services is a network request. And this, in turn, is the “longest” operation in programming (10-100% of the time it takes to form an entire page).

INTERVOLGARU has seen many examples when developers went this way and got a lot of problems with the speed of the site.

Our module works exclusively with local geo-bases. In addition, we implemented caching of requests to these databases. As a result, determining the location by IP practically does not affect the speed of the site.

Automatic geo-base update

Local geo-bases are reliable. But they need to be updated. And no one remembers that.

Especially for this case, we implemented an automatic update of these very databases: only those that are necessary, only if they have changed, with the frequency necessary for a particular database, and then reset the geo-requests cache.

There are several ways to choose: on agents (by default), on hits and on CRON.

 Linking to Bitrix locations

Geobases return the textual name of the country and city. But without reference to the logic of the site, the sense of this is zero.

Let's take a closer look at why you need to determine the position of the user:

1. Show the availability and / or cost of delivery in a particular city in the item card.

2. Select the default city in the order form.

3. Show different phone numbers in the header for Moscow, St. Petersburg, City X and the default phone number for everyone else.

nfortunately, in the program code you will learn only the name of the city of your visitor. For example, “Volgograd”. For one of the three tasks this is enough.

For the other two tasks, you will need to compare the textual name of the city from the geo-base with Bitrix locations. And they are tree-like, and the names of cities with geo-bases do not coincide (“Volgograd” vs “Volgograd Citi”) ...

We implemented such a comparison by a tricky algorithm and consider the resulting result to be of sufficient quality.

Integration with new Bitrix API for geolocation

Since version 17.0.9 of the main module, geolocation services have been added to the BEADS, and we have implemented the integration of our module with this new API.

Widgets and components

The module has 2 components:

• User location

The widget shows the current city of the visitor with the ability to change.

• Autolocation.

When you click on the button, the location is determined and the page is reloaded. Additionally, this component implements the definition of a city based on Yandex.Map (more precisely, but only works in the browser - not on the server).

More information about their use - below.

More information about the browser

In addition to defining GEO IP, we have embedded in our module definition of information about the visitor's browser (operating system, mobility, language, etc.) based on the browser parameter “User Agent”.

This information is rarely needed, but it was useful to us in a couple of projects.

Check interface

In the module settings section, we implemented a separate tab to test its capabilities.

It allows you to quickly test all available geo-bases on different IP addresses.

Restrictions

• Version Bitrix> = 16.0

• PHP version> = 5.5.

Installation, configuration, use

Consider how to install, configure and start using the module on the example of a typical online store Bitrix.

Install and configure the module

After installing the module, it is necessary in the settings (Settings> Product settings> Module settings> ”GEOIP and advanced visitor information”) to select the most suitable GeoIP base. The remaining settings do not touch unnecessarily.

Save the settings and go to the “Check” tab. We check your IP address.

Is the location defined right? - Well.

Not right? - Try a different geo-base on the “Basic” tab.

For Bitrix 17+

Go to the geolocation settings Bitrix: Settings> Product Settings> Geolocation. In the list of available providers, open “INTERVOLGA: GeoIP and advanced visitor details”.

Activate. Field “Sort” set the highest priority among other providers. We save.

API usage

Let's make sure that the module works and figure out how to use it at the API level.

In admin. panels on the PHP Console page execute the code

use Bitrix\Main\Loader;

if (Loader::includeModule('intervolga.enrich')) {

    $result = \Intervolga\Enrich\ProviderProxy::getIpInfo('88.87.88.238');

    var_dump($result);

}

The result should be something like this.

Select a city in the header of the site

The component is called intervolga: enrich.user.location. Here is the result of his work.

Autodetection of the city in the design of the order

The enrich.autolocation component is a button that is embedded in the old ordering component template (Bitrix version 16.0.11). By clicking on this button, the user’s location is automatically replaced in the location input field without reloading the page.

If you use a newer version of Bitrix (17.0. +), The component is not needed and the location will be determined automatically by the geolocation service for auto-locating.

Conclusion

Модуль intervolga.enrich was assembled on the basis of our best practices. This is a universal reliable solution without any dependencies.

It closes most of the geo-tasks encountered in the development of complex online stores:

• city ​​selection in the header of the site,

• city ​​selection in user profile,

• city ​​selection in ordering,

• output specific content depending on the city.

The module has public methods for obtaining information about the user, which can be used to extend the functionality of its solutions.

This article was translated automatically. We are working over improving the translation.

Please send your questions about the article to info@intervolga.ru