lesley

Soon it might be even less... I am just talking with @mdekker about my organizational dysfunctions about how I like things organized and clean.

I think what is going to be the smoothest is to have people keep the modules in their own github repo and do everything from there.

I think it has to be pointed out as a community dies, the toxic complainers are left sometimes to feed on other toxic complainers. My first exposure to @eleazar in the thirty bees community was of him trying to remove open source translations from the German version of thirty bees because he did not want to be associated with the project. My second exposure was of him bashing thirty bees on a thread in another forum. Then he came over for awhile, participated, and then took his ball and went home again when things did not go the way he wanted. We honestly don't have the time for that. I want everyone to be happy, but I don't want to bring toxic community members over, they drain the life force of a project.

I think this is going to be addressed in 1.0.5, we are going to add a round of non breaking features to it. This is going to be one of them from our talk last week on EU issues.

It can be done, yes, but you give up a lot. We are planning on redoing the front end next year so it will be more stable and offer the best possible performance and ease of editing for users. Its not a small task. Shimming everything so front end modules would still work would pretty much negate any front end performance we added in. This would be a totally separate version of thirty bees, 2.0.0

Ahh I get it. Ideally we would break everything all at once on the front end. By that time we should have a large enough eco system that developers would just make the required changes.

@wakabayashi I don't understand what you mean, can you rephrase it.

I would not worry about larger packages like store manager, its something we ensure there is going to be support with. Some of the smaller module makers might not support us in the future because a lot are leaving the ecosphere of making modules currently. We cannot prevent that though. If there are companies that you rely on, list them, I will reach out to them to see if they can join our compatibility program.

Are you using an adblocker?

Do they work with friendly urls turned off?

It should be fine, I can for it over to our repo soon and go through it.

@Briljander Have you tested them? We have very high compatibility with most modules. I do know that store manager works and warehouse with the prestahome blog.

About the images, to be honest we need them lots of places. We need a good docker image, we need a bitnami image, we need an AMI image in their library. Kubernates would also be an interesting one to get into as well. They just take time and people that know how to package them.

Yeah, I just don't know how many users will know how to use docker.

I did not know bitrix was Russian. They do have an interesting software. Honestly, the best course of action is to try to get us listed in bitnami. I know they do things by a voting process, let me see if I can get us registered.

I mean in your stripe account, does it look like the card was passed and declined in the account.

Awesome, that one has caused me so many problems over the years.

If you are using fcgi, ask your host if they can increase the max timeout in fcgi. I think the key is the maxwaittimeout

Ahh, ok. I see what you mean. Still, we need to invest in what will bring us the most gain. We have always try to shoot for thirty bees place in the market to be the mid to high level shops, if we want those shops, we need to key to features that they want.

@wakabayashi Because there exists the option 3 modules which are compatible, the built in search extenders like Presto-Changeo and Presta-Module make. Having an Algolia module would give us coverage to all search bases.

The plan for next year, is early in the year to set a feature set and framework for 2.0.0. You @wakabayashi actually helped influence it. I have talked to a lot of people over the last few weeks and it seems like merchants would like a new front office as opposed to a reworking of the back office. So we are planning on breaking compatibility on the front office and with some modules to redesign the front office. A total redesign, not a new theme, but a redesign of the theme and the under laying architecture of the front end. It needs to be modernized and have a lot of stability changes put in. I am sure more merchants will use it over time, it does appeal to developers more, I do have to admit that. That is why I always leaned towards another module. We are trying to work out a deal with Algolia now, for users that cannot set up their own Elastic instance to be able to have another search module choice.

Can you look at your server logs and see what is throwing the 500 error.

Are there any errors on the failed transactions in your stripe panel? Like anything that might be giving a clue what is happening.

It could be something with the stripe api, that would explain why it worked the second time. Like a downout or an error on stripes end.

@DavidP I guess I am in a position to address some of your concerns. There is a business plan behind thirty bees, we are working to live off an affiliate channel and the revenues our store generates once it is up and running. Both are pretty straightforward and easy to accomplish, we just need more users to accomplish them and make them viable. We also plan to make free modules for service providers, we have a couple on the burner right now actually. We have also been entertaining investments as well to help jump start use starting a 2.0.0 version with new and different features that we cannot make compatible in the 1.0.x branch. So we do have a plan, its just not moving at breakneck speed, which is just as frustrating for us as it is for you I can imagine. I am sorry that you feel your contribution to the elasticsearch was a waste. The module was a bit more complicated than we anticipated, we were not able to build off of existing code because of the quality of the code. thirty bees is never going to be a paid service, it will always be free and open source. As for @mdekker leaving, I wouldn't consider that. This is a startup company, he has sunk a ton of his own time and money into this company, I don't think there is the option to give up and take a loss on everything. This one is likely to go against the grain with some people, but this is how I feel. I have always tried to handle my business in a manner that was honest and transparent. The developer of Transformer has two products in his shop and requires a ton of content pages. thirty bees, prestashop, magento, open cart, ect are just not the best platform for him. I don't think thirty bees is the best platform for 2 products that require nothing more than uploading zip files. There are better solutions. That is not to say it cannot do it, it just offers too many features that would not be needed. That is why there is choice in the marketplace.