lesley

We could create the other repo and then add the modules to it for people that do not use github. I just want there to be a difference in the modules that are officially supported and the ones that are community supported.

We aren't going to do a free module forum for downloads, its just not the direction we are going to go. We are actually talking about it right now, because its a good point you brought up. I suggested having a repo like thirty bees community, in there storing things like that. For the free module forum, we are just going to put free modules in our shop. We are actually hoping to launch the iteration with our free modules this week maybe. The main thing about having modules for download in the forum is they get lost, not updated, and no one can contribute. This is what we are trying to change. It expands the reach of the software so much.

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.