lesley

I don't think it will be integrated into the core. We need to keep it modular for the time being. The reason is if the regulations change, it will be easier and quicker for shop owners to update a module then to have to update their whole shops.

@Traumflug That is where all of the overwhelming logic comes in. I think using hidden products it will create a spiderweb of queries that are going to be hard to untangle. One thing that we will need is the option to exclude products. No one wants the dog bowl autoshipped I will imagine. I like to follow Amazon's lead on things, I like the way their system works in the frontend I think to pull reliable stats and not to overwhelm the database we need to do it off of the products themselves, not the orders as a whole. Let each autoship order have its own entry, one product per entry, then build from there.

If that is all you are needing, the cart can handle that without a plugin. You can set the carriers up manually in the system, for flat rate you just limit the weight and box sizes in the carrier. Then name it something like USPS flate rate as a name, add a USPS icon to the carrier, and add the tracking link stub in. Then it will act like USPS flat rate. The only times the live api carriers are any use is for packages that are shipped depending on weight and dimensions.

Hey, we have yet to fork over all of the US carrier modules from PrestaShop currently. There are a few that are paid that work well though, The paid ones I would recommend are at Presto-Changeo, you can view their shipping modules here, http://www.presto-changeo.com/en/10-prestashop-shipping-modules They should all work with thirty bees and they will support them for thirty bees. The reason we have not forked over the carrier modules yet is because they are extremely limited and need a ton of work to get them working correctly. They also can slow your to a crawl, because they constantly query the rate servers in a bad manner. We just haven't gotten them refactored yet.

@DavidP and @dynambee I could not agree more. That is exactly how you make a better system. We might even go so far as to find a couple users and ask them what could be done to make it better and add those features in.

Some people will, some people wont. We need to have both built in.

Correct. We want to make this in such a way that as more gateways start supporting tokenized charges that more modules can be made. But at the same time, I know there are going to be companies that use this system for other uses that won't need actual payment, they will need to generate invoices only. That is why we need to have it where it has hooks to interface with modules. So the payment modules have flexibility on what to do.

@Havouza What I see is having the recurring system have hooks that are called. That way we can only worry about a couple of payment gateways internally like auth.net, stripe, and maybe a couple of others. But by having hooks other developers that develop payment gateways can develop their gateways to hook to that hook. When that hook is ran it will do the charge.

@Traumflug and @Havouza The main reason a lot of the payment processors do have api's that allow for recurring billing, but I think using just them is a bad idea. If you do that you run into issues of having orders created and paid for that could have products that are no longer available. Having the logic in the shops gives us the chance to have contingencies in place where the order can be delayed, or cancelled altogether. Also having a "hidden" product is not a perfect idea either. Say I have a shop that sells dog products and I have a subscribe and save option like Amazon has. I need to be able to pull a monthly stock status and see how many bags of xxx food are going to be autoshipped. Things like that will be very useful to merchants, especially the ones that sell physical goods. @dynambee I agree with everything you said, we need to make this system robust to be able to handle all of those situations because they are real life use cases, I subscribe to several box sites and I have seen some of those cases before.

We are starting to discus the recurring payment system that we will implement in future versions of thirty bees, as merchants we would love to know what your suggestions are. We have a blog post detailing some of the thoughts so far here, https://thirtybees.com/blog/recurring-payments-in-thirty-bees/

It might just be a bug in the interface, but most everything from the module is actually loaded from the Piwik instance, so if there was a security issue it would be with Piwik, I am thinking it is some kind of redirection bug however.

I am not following what the issue is either.

Can you send me access to your shop to [email protected] I can look into it now.

No problem.

Yes, that module can handle it. It will not work by category though, you will have to assign it for individual products.

At this point you will have to manually redirect the urls if you use the new system. We tried to put automatic redirects in place, but it was really buggy and problematic.

I saw your post previously and thought it was solved. Sorry about that. Tomorrow when I am in the office I am going to try a migration using XAMPP, 1.6.1.11 to thirty bees and see if I encounter any issues. If so I push some changes to the repo to fix them. Its really disheartening to hear some I know is a developer having these issues and at the same time not able to debug them. That is what open source is about, helping the community as a whole with bug fixes and making stable software. We are a small team that is trying to bring a software to a stable version. Not a multi-million dollar company that is ignoring your wishes. We want this to be stable. We have a lot of sweat, blood, tears, and our own money invested in it. We will get your migration working, I am going to look into it personally and make sure it works. But please, don't group us with other software companies that do not have the merchant's best interest at heart. I think that is unfair and I am sure you do as well.

Yes, when we release it, it will be a free module.

Hey, what version of PrestaShop were you on? Do you know if you had any overrides or custom code hard coded in your shop?

Because it is not finished yet.

It should be. Check back over the next day or two and see if they are updated or changed.

From what I understand it will not work and a special version is going to have to be made. The issue is because of the friendly urls the module uses is pretty much the same that thirty bees uses, so they clash since they are not needed in the module. I sent the thread over to @Nemo to explain more.

Can you look at the error logs on the server and see what the error is too.

It should be back up now, apparently they had a glitch with our open source account.

Yeah, likely it will be soon. I think it might be one the next major modules we release. It likely will not be compatible with all themes at this point, but should be a good base. In the future we have talked about having a deeper Algolia integration as well, it just makes sense for large shops.