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.