fuji3776

When I used that module, or lets say when I evaluated whether gift cards are an option for me or not I used PrestaShop and faced a big problem that is that gift cards could not be used to settle shipping cost as they are only discount vouchers and not a real payment. So if someone had a gift card for 30 Dollar he could use that for all products but had to pay the shipping cost separately. The only way I found to solve that problem was either to offer free shipping when using gift cards or to buy a module that make it possible to use gift cards as real payment. As the first option meant a loss on my side for every order where a gift card was used and the cost of the module for the second option was 99 Euro I decided that both options were not worth offering gift cards. I have never tried it again with TB but I guess there might be the same problem.

Did you mean this: https://www.prestashop.com/forums/topic/355886-giftcard-3/

Take a look at A2 I'm there since more than three years and besides the trouble they had in March in their Amsterdam data centre when the main power supply or something (forgot the exact reason) broke down an the server was not accessible for several hours, I have never experienced any problems and the speed is more than enough even on shared.

@haylau I know that OPC from knowband, but when you go with the standard things you will face less troubles than when using third party modules, esp. third party checkouts. Another point is that these checkouts usually have a quite different style than the rest of the shop which, for me, often looks strange and therefore also need a lot of time to arrange. Up to now, the only third party OPC I was interested in and thought buying was the very simple one from prestasite.ru (now presta.site), but when I came to the point to give it a chance the module was removed from their site. So I decided to arrange the original OPC to the point I'm more or less satisfied with and able to do (I'm not a programmer)

@lesley Don't get me wrong. I don't want to persuade TB to include such a function as I even don't know myself how useful it si, but if the work of changing the code to include a feature of showing available payment methods in advance would not be that much, I think some merchants would appreciate such a feature. (I can change some small things in the code if I use try and error system, but have not really any clue of programming so I cannot even estimate how much work it is) If you use a 5 step checkout there is no benefit or need for showing the payment methods before. If you work with the OPC it might be different. As said before, I even don't know myself if it is worth thinking about and investing time into this feature, but I know from several years as merchant that some people enter their address but don't finish the order. Sure, their are many reason why the don't finish, including failures of payment gateways, reconsidering, etc.,, but I got also some mails in the past where customers asked if the cannot pay by using "whatever". It was often the case when I started the shop because I could only offer PayPal at that time. Since I also offer credit card payments the situation has changed for me., so I don't invest lots of time thinking about that feature, but still occasionally think about it. Other merchants might be more interested as randomly someone comes up with this question. An other reason for showing the payments before might be also the design of OPC. There is now "Step 3 Payment" and a red notice that you need to sign in first. It would just look nice if the payments are shown grey instead of the message. @toplakd Thanks for the advise. I use that module already and it is a good feature so that customers are informed. For me, I don't need the feature of showing the payment methods in advance urgently because I show payment methods with your mentioned module on the site and also offer most used payments such as credit card and paypal, but I still occasionally think about it because of "personal" design reasons. (I'm sometimes very pernickety)

This is an old discussion, can't count the threads in the PS forum, and usually both sides or all variations have their pros and cons. Of course lots of merchants ship to different countries and offer various payments, but also lots of merchants do not. They have only one or two payments systems and offer them for every country, deliver just to one country, etc. I think it would be great if the merchant can choose whether he wants to display the payments or not. Would make everybody happy. What I try to achieve, but unfortunately haven't reached yet, is to show the payment methods in an inactive state with a grey design so that they can see the methods before entering an address. Not everyone reads the payment or FAQ site and might afterwards find out the the shop does not offer the way they want or can pay.

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

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.

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.

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.

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.

Hi tommat, I just replaced the file and not it works. Thank you very much for contributing such a nice theme.

After installing the theme on a clean TB 1.0.8 it shows following error on the front end

@wakabayashi said in GitUpdater preview: @nickon said in GitUpdater preview: This is a feature I always whished for. Especially the downgrade part. I would like a checkbox so I would be able to uncheck a specific file I don't want to update. (all files checked by default) I don't know how database changes are handled though. This is something I always wanted for tb. To be stable and add features missing in 1.6 Keep up the great work. This is an intersting idea. But I guess, it can also make troubles. Imagine a new function is added to a file, which you don't update. Once this new function is called, your shop will throw an error. But of course I see your point. Especially for theme files, it could be helpful. When I read nickon's suggestion I thought "great" but than I got wakabayashi's point of causing eventually some troubles, but maybe there could be a function included that the manually changes files are kept with a prefix, e.g. M, into the same folder. So one can easily check single files if the work or what exactly is different and include the same changes again if needed. (Not everybody keeps a good record of changes done)

As long as there is no solution for TB you can try to fix it with a "dirty" solution. (Just my thoughts. Haven*t tried it yet) If you do not offer free shipping you could create a carrier that is only connected to visitors and set it on free shipping. Than you have to change the translation "free shipping" to the text you want to have displayed. So it should display the text in the cart until the address is entered, either for guest or customer and shows than the real carrier with the real cost.

@drmasterchief said in Off Topic - New German Packaging Laws: However, if this manufacturer has its headquarters abroad, then the domestic importer can also be considered as the first-time distributor in Germany and thus as the manufacturer. That is exact the situation I was talking about. The domestic importer is the one who imports the product into Germany. If you are based in the US and sell over your own website and have no representative in Germany you are not the importer but the one who buys the goods is. That can either be a company or a private person. In case you sell on the German Amazon marketplace and use FBA it might be a different issue as you are sending goods to Germany in bulk and then from there to the end user. @mockob said in Off Topic - New German Packaging Laws: I don’t get it. If I’m selling to German market from other eu country, who is responsible for the tax and who should comply with the law? Is it the shipping company or me as importer (manufacturer)? When selling from an EU country to another EU country, things might be different as the EU has specific rules how to deal with domestic laws of their member countries. Especially the taxing is something I would advice you to consult your local chamber of commerce or a lawyer.

@drmasterchief said in Off Topic - New German Packaging Laws: .....Importer is also an online shop based abroad, if the goods are delivered directly to private consumers in Germany. This applies both to the shipping packaging including filling material and to the packaging of the products themselves, insofar as these are typically incurred by the private end user as waste..... Was that also written on the website? Regarding my knowledge of import/export, the importer is the one who brings an item into the country. So if you are a US based shop that sells directly over your its website and a German guy orders something, the importer is the German guy who has ordered it and not the seller.

As far as I understand the following part from the German website QUOTE START: Wer ist verpflichtet? Was ist ein Hersteller? Das Verpackungsgesetz (VerpackG) nutzt den vieldeutigen Begriff „Hersteller“. Tatsächlich gemeint ist jedoch derjenige, der eine Verpackung erstmalig mit Ware befüllt oder erstmalig befüllt in Deutschland in Verkehr bringt (Importeur) und diese Verpackung typischerweise beim privaten Endverbraucher als Abfall anfällt. ... QUOTE END It says IMPORTEUR so that means to me that the person or company that imports the product into Germany. If you are not based in Germany and you sell over your own website you are not the importer but the customer is. I would also take the same if you sell through ebay.com or amazon.com, but it might be a different issue when you sell via ebay.de and amazon.de and here especially when selling with FBA on amazon.de

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', ] ); }

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?

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.

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?