lesley

The rule should be added when you get to the checkout page. But I think the first way is the correct way to do it, that is what I have always done.

@Raymond I totally understand what you mean. One aspect you might take into account with all of this, is if you use a major processor like stripe, auth.net, any paypal products, they will all close your account over this. So it is something to be aware of and it is a key reason why it never made it into PrestaShop before thirty bees was forked from PrestaShop.

@Raymond There is no good option for what you want to be honest, in any e-commerce package. What you are going to end up introducing is more ways to break the checkout imo. When you are able to set payment methods on a per product basis this is what will happen. Someone will order a product that has payment restrictions, they will order another product that has no restrictions. What happens in that case is the same thing that happens with carrier restrictions, you get a message that the order cannot continue and the customer cannot pay or complete the order. Multi-carriers per order is not something that is supported, so I doubt that multi-payments per order would be supported either. Then again, I am no longer with the project so I do not have any say over this.

@Raymond You can set the discount to be applied based on the carrier as well. That should solve your issue.

It already supports this in a way. Create another set of carriers that work with only one payment method. Like your computer example, create a carrier that only works with bank transfer, then select that as the only carrier that will deliver the computer. You have effectively forced the customer to use the bank transfer to buy that product. That way in my opinion will be the best. Because it does not add another area for an order to not be able to be completed.

Most Prestashop 1.6 themes are compatible with thirty bees, yes.

I think you are missing something, viewing the source of your site I can still see its in the head going to bootstrapcdn

@datakick font awesome is not hosted by google usually, its hosted by either cloudflare, stackpath, or cdnjs, which if they were blocked would be a huge problem because a lot of shims and other js files are hosted there. @veganline have you considered using the google font loader? That can get around some speed test issues.

Why? Are you trying to make a online speed test happy?

Have you looked into sendy.co that is what I use and what thirty bees uses.

I assume its because both of you are in the UK and the UK and EU do not have any countries with required states (except italy). I am not a fan of the big address format either to be honest, but paypal kind of ties your hands. For the autofills those are great, but generally not free. Algolia used to offer a free one, but they have twilighted it. And I know a lot of people in the EU would be upset if the google one was offered as a standard component, they do not like sharing their information with google and clicking no in the gdpr box would break the checkout since they would not allow google to look up the address.

@AndyC Not all processors require a state to be passed. With paypal, that is honestly the main reason that PrestaShop and ergo thirty bees ever included states. If you look at the list of the countries with states that comes with the default installation, those are the countries that paypal requires states from. This is the current list of countries that require a state to be passed, and the state / province code that they need. https://developer.paypal.com/docs/api/reference/state-codes/

You can't do that, that would really defeat the purpose of the software.

@AndyC The reason that was never done and isn't done in any third party modules is because the data needs to be sanitized. Take paypal for instance, if you pass a payment with a state name, the payment will fail and the user will get an error. It has to be passed with an iso code of the state. That is how most gateways are. So having a typed state really does not work.

@Rhapsody The main reason I am suggesting adding more tables is because the data is not going to be accessed internally. In wordpress you have their plugins grabbing the data and sorting through the json looking for what they need. What I am suggesting is for to make it all accessible through an updated web service. That way people do not have to run a theme at all, it can be a completely separate application accessing the data in the shop. This would standardize things.

I want to throw my 2 cents in the ring on this. What I would like to see as a new feature is likely something most merchants would not care about, but I think it would be instrumental in pushing thirty bees forward in the future and expanding the base with more developers and larger tier users. 1. Push a change to how modules store data. I think this will get a lot of push back, but I think its needed for the end result. I think modules need to start adding columns to the default tables, with maybe more default tables needing the be added. Say you have a module that displays a custom section of text that is editable on a per product level. Like a module that hooks under the productextraleft that says "Free Shipping" on the front. I think that module needs to quit relying on its own table and store in the tb_product_languages table by adding a column. I think every possible module needs to start extending the default tables and storing data there when ever possible, 2. I think the current webservice needs to be left as is, completely compatible with prestashop, but a new version 2 needs to be built out with a different end point. But instead of building it like the limited webservice that prestashop has, build a really extensible, resilient api. There are a ton of limitations with the current webservice, its only good for getting (some) data and storing data. What I am talking about is bringing everything online with the api. It needs the ability to build carts, query the api for shipping prices on those carts, get payment gateways, pass payments (which I do understand the modules have to be written to support this). Where the adding columns comes in, is in the resiliency of api. Where someone working with the api can just get product id -> language - > moduletext. The idea is when a module is added since its adding a column to the table, that new column becomes available in the api. Bringing an api like this online and making 100% of the core available through the api will expand the thirty bees universe more than anything. Look at PrestaShop, they are working towards a better more modern smarty integration, taking logic from their templates, ect. But in the end they are ending up with the same thing, just organized differently. Bringing the whole api online will make it possible for thirty bees to be headless, which will open doors of new technologies as the come out. Want to run a node front end? Sure, you can. Or React? Ok. Static html? Yeah, that would actually be possible. That (those) are the features I think need to be added.

It means you need to create a carrier for each shipper.

No, you have to manually change it.

Yes, it matters. Try with a new order from scratch. thirty bees saves carrier information in a way that does not break orders using a carrier of a previous save.

I am all for consumer protections, but it gets to a point where it becomes a bad thing and this is one of them.

It looks like mysql is not running on the server or you did not create the database.

My two cents on this. Keep the core updater working with 5.6 for a couple of years. That way people can still upgrade. But add php version detection into the core updater to alert people of php version issues. IE `Upgrading will require you to change your php version` with a link to the docs on how to change it on common systems like plesk, cpanel. Then also adding a post flight page after an upgrade. That checks for the php version before the system is ran, if its not a supported version give them a clean page notice, with another link to the docs about how to upgrade their php version. Nothing is more frustrating than upgrading and coming up against a 500 error. Especially one that could be easily caught and a pretty page / message displayed.

No, the mail alerts module is for sending emails to the shop owner really.

Sales tax is not stored on a column level in the database. What is stored is the pretax price and the post tax price. So you need to calculate those two columns to arrive at the sales tax for the order.

If you are using paypal pro they will ban you. You have a couple options, one would be to move the server behind cloudflare and then enable the under attack. Another would be to add a brute force protection to your payment module. We have done this before where we log all of the ips for failed transactions, then after the 3rd one ban it from the site. Sometimes this works, other times they just rotate ips out. Another solution might be to rename a couple form elements in the checkout or the payment module, that will usually break their script for a point. They could fix it, or they might decide to move to a different site. I would use cloudflare with one of those other suggestions though.