Geolocation

[fuji3776]

I want to use the geolocation but since TB is a fork of Prestashop I'm worried about the function. As far as I know, the native geolocation of Presta is automagically refusing visitors if the IP address does not resolve. Does TB handle non resolved IP's in the same way and if so, how can it be changed so that non resolved IP's have full access to the site?

[colorful-ant]

Sorry, I probably do not understand your request.

I think this topic / question is now obsolete for sellers. Block any potential customers? Anonymous visitors, guest orders, customers who try to hide their IP's. There are other ways to prevent spam etc. I personally do not want to block any customers because of their IP address. Registration with payment ok, then the goods will be shipped. For me, the IP address is absolutely unimportant, name, address and payment must fit. For me as a seller within the EU, privacy is important.

[fuji3776]

My intention is not to block anyone or to prevent spam or other things but since I sell worldwide I have customers with different currencies. Thus I want to use geolocation so that a customer from the US sees USD, someone from Europe sees EUR and the guy from down under gets AUD. This does work fine with the geolocation (I've already tested id). Unfortunately it might happen that a visitor has an IP that is not in the database of geolocation. In that case he should get the shop's default currency, but as I have read on the Prestashop forum it seams that such IP's get automatically blocked by the geolocation what is absolutely not what i want to happen. So I'm wondering if the TB geolocation works in the same way as the Prestashop as TB is a fork of it.

[colorful-ant]

thanks - now i understood it better

[dosbiner]

@fuji3776 there are some modules to achieve this https://addons.prestashop.com/en/436-international-localization

[lesley]

There are a few compatible geo-location modules here as well, https://www.prestaheroes.com/en-us/modules/thirty-bees

[fuji3776]

I've already taken a look at these modules from what I think that the geo-targeting pro looks the best, however, since there is a function for geo-location already in the core I would prefer to use core function without any additional module.

@lesley Am I right that the TB geo-location works in the same way as the one of prestashop and blocks non known IPs by default?

[Traumflug]

Yes, that's still pretty much PS code.

[lesley]

It does, but you have to realize that the library that it uses for ip addresses is no longer maintained.

[fuji3776]

For my needs the localisation does not have to be accurate, but just an estimate so that a customer from the US gets USD and someone from EU gets EUR and not KRW (South Korean Won) as that is my default currency and might cause some confusion. If some who's IP does not resolve or is incorrect due to an old database and therefore gets KRW displayed or another currency it is not a big problem and I can live with that. I might think different in the future and then be able to spend money for a accurate module but as for now, I don't. So I try to change the basic code and hope it works.

For everybody who wants to use the core function and hopefully avoid blocking non resolving IPs, here are my changes of /classes/controller/FrontController.php

Around line 1607 get rid of /* Delete product of cart, if user can't make an order from his country */ elseif (intval(Configuration::get('PS_GEOLOCATION_ENABLED')) && !in_array(strtoupper($this->context->cookie->iso_code_country), explode(';', Configuration::get('PS_ALLOWED_COUNTRIES'))) && $cart->nbProducts() && intval(Configuration::get('PS_GEOLOCATION_NA_BEHAVIOR')) != -1 && !FrontController::isInWhitelistForGeolocation() && !in_array($_SERVER['SERVER_NAME'], ['localhost', '127.0.0.1']) ) { Logger::addLog('Frontcontroller::init - GEOLOCATION is deleting a cart', 1, null, 'Cart', (int) $this->context->cookie->id_cart, true); unset($this->context->cookie->id_cart, $cart); }

Around line 1974 } elseif (Configuration::get('PSGEOLOCATIONNABEHAVIOR') == _PSGEOLOCATIONNOCATALOG_ && !FrontController::isInWhitelistForGeolocation()) { $this->restrictedCountry = true; } elseif (Configuration::get('PSGEOLOCATIONNABEHAVIOR') == _PSGEOLOCATIONNOORDER_ && !FrontController::isInWhitelistForGeolocation()) { $this->context->smarty->assign( [ 'restrictedcountrymode' => true, 'geolocationcountry' => isset($record) && isset($record->countryname) && $record->countryname ? $record->countryname : 'Undefined', ] ); }

Change to } elseif (Configuration::get('PSGEOLOCATIONNABEHAVIOR') == _PSGEOLOCATIONNOCATALOG_ && !FrontController::isInWhitelistForGeolocation()) { $this->restrictedCountry = false; } elseif (Configuration::get('PSGEOLOCATIONNABEHAVIOR') == _PSGEOLOCATIONNOORDER_ && !FrontController::isInWhitelistForGeolocation()) { $this->context->smarty->assign( [ 'restrictedcountrymode' => false, 'geolocationcountry' => isset($record) && isset($record->countryname) && $record->countryname ? $record->countryname : 'Undefined', ] ); }

[toplakd]

Since the GeoLite Legacy is discontinued, are there any plans for using GeoLite2 with thirty bees?

As it seems, the prestaheroes is stil using Legacy as base.

Edited January 26, 2019 by toplakd

[toplakd]

Have now bought one on ps market one that adds support for new free GeoLite2 Free Databases.

Support for MaxMind GeoLite2 Databases (MMDB) Module

 

[fuji3776]

Thanks for the hint. I took a look at the module to an diced to buy it.
Not only that it updates the the geolocation to the new database it also solves the problem of blocking non resolved IPs so that my mentioned modifications are not needed which means no worries when updating the shop.

[toplakd]

Just found this:
https://github.com/sherpya/geolite2legacy

[toplakd]

Have just converted the free GeoLite2 City Database to GeoLiteCity.dat and uploaded into live store and it works.

Have tested the site on dotcom-tools to see if prices are shown with tax included or tax excluded based on country location, as for EU I display prices with tax, and for other countries without tax.

Edited January 29, 2019 by toplakd

[datakick]

6 minutes ago, toplakd said:

Have just converted the free GeoLite2 City Database to GeoLiteCity.dat and uploaded into live store and it works.

Have tested the site on dotcom-tools to see if prices are shown with tax included or tax excluded based on country location, as for EU I display prices with tax, and for other countries without tax.

Thanks for confirmation. This is a good workaround until this is fixed properly in core

[toplakd]

Yeah, geolocation is good and needed if you sell across the globe and you are registered to VAT.

As in EU prices for the customers have to be shown with tax included, but tax is not charged in case of shipping outside European Union.

So displaying tax included prices for outside visitors is not good, as they would see higher price if not logged and many of them would not even register to see that actual price for them is lover for the % of your countries tax.

So in my case we have 22% VAT and EU customer sees 122 EUR (tax incl.) price, but for customer outside EU the 100 EUR price is shown (tax excl.)

But If you are not registered to VAT than you don't need geolocation for normal shop operation.

Edited January 29, 2019 by toplakd

[toplakd]

Have uploaded it for test if one could not do the conversion by him self.
It's convertet from current GeoLite2 City, dated 2019-01-22.

GeoLiteCity.dat

Just upload it into /tools/geoip folder, enable geolocation from the backoffice and you are ready to go.

Edited January 29, 2019 by toplakd

[fuji3776]

Geolocation is not only valuable for VAT reasons, but also for setting the currency. If you sell worldwide you might present your prices in the customers local currency.

I haven't tried your mentioned workaround because I bought the module you mentioned some posts before, but can you tell me how it works? Do you have to download the database and convert it every time by manually or can it be done automatically.

I never updated the database in the past as the old legacy was not updated since last year, but the module for the new MMDB support comes with a useful cron job and I think that and the fact that the module handles non resolved IPs makes the module worth to buy.

[toplakd]

If you bought that module, than it's described in the module configuration page.

I sell and display prices only in my currency, as paypal has different exchange rates that the currency-exchange pages.

And than you get to the point where customer is upset, as your page showed 100$ total, but once on paypal checkut he was billed little more due to different exchange rate for USD to my EUR.

[toplakd]

That module from PSBlog "Module Support for MaxMind GeoLite2 Databases (MMDB)" does not state that it handles non resolved IP's. At least I found no info about that, neither online neither with manual that came with module when I bought it.

From my understanding it just reads the database in new format and it passes it to the TB/PS software in known language.
 

[fuji3776]

How to make the cron job for the module, I know (Thanks again for the hint about that module).
I was just wondering if with the workaround you found on github it can be also automatically done or just manually.

I know what you mean with the exchange rates of PayPal. They can be really bad.
Since I manage the exchange rates manually I include that in my rates.

[fuji3776]

1 minute ago, toplakd said:

That module from PSBlog "Module Support for MaxMind GeoLite2 Databases (MMDB)" does not state that it handles non resolved IP's. At least I found no info about that, neither online neither with manual that came with module when I bought it.

From my understanding it just reads the database in new format and it passes it to the TB/PS software in known language.
 

I asked the developer what files his module changes or overrides because I have made some modifications to handle the non resolved IPs and the answered me that he was aware of that problem from the core when he wrote the module and wrote the module with the function to handle non resolved IPs.
He even showed me the code lines for the non resolved IPs before I bought the module, so really thumbs for the developer.

I told him that he should state the fact of handling non resolved IPs on the module page as the feature might be interesting for some people.

[toplakd]

With workarround legacy base you have to do it manualy as before.

Have now found section in module and i think this is for the non resolved ip's

Quote

        if ($ip === null) {
            $ip = Tools::getRemoteAddr();

 

Edited January 29, 2019 by toplakd

[fuji3776]

                    if (is_array($record)) {
                        // Special IP (not geolocable)
                        if (!array_key_exists('country', $record)) {
                            return false;
                        }