Kashir2000

If you're at fixing stuff, then one thing. Just one small thing I can't watch at... or 2 rather... Pretty please... it hurts me 😞

Can't quite agree here (maybe a personal matter). I think it's a company that should post such messages. Not its members. Not every member should be allowed to post official statements, so only selected ones should have access to this account. Still, this account privileges should be elevated to @Messenger Bee a minimum of credibility.

There are mainly personal accounts here. So basically this account was created to post "Official" statements. Quite logical I would say (Unless there is other official account) Still, anyone could've created "Member" account. @Messenger Bee Maybe upgrade this account to Moderator/Admin etc? As long as it's a "Member" It's safe to assume it may be a troll account! On the other hand. It's interesting who wants to take this project over 🙂 @datakick already stated that he does not want. @Traumflug hmm... interesting 🙂 Praying for well being of a project 🙂

@Traumflug There is also another thing. There are not many people wanting for TB to rise for one simple reason: Having to maintain compatibility for 2 shops. A lot of devs dream of 1.6 being put to rest (yes, they also hate Prestashop 1.6), as 1.7 takes over. Maintaining backward compatibility with 1.6 (and/or TB) is additional work. So basically it's not personally aimed at TB or you guys, it's aimed at lowering costs and maximizing income. Because of state of 1.7 I'm seriously thinking about changing my business model. I don't want to be held responsible by my clients for bugs in 1.7. Still, my clients I migrated to TB expect FROM ME modules for prestashop to work or fix them. Their mentality is like: "If I had Prestashop, it would surely work". So either I go on war with them or comply with their insane requests. It's a shame, but this brings a lot of regret to devs like you and me. PS: Also, when I recommend thirtybees and explain all differences, I'm being held responsible for recommending it to clients. Some people are insane, and blaming their decisions on others. And saying "Prestashop would be better". That's where "brand" part comes in.

And for them you probably won't buy a anything for it ;(

Actually "PAID" I think it would be hard for him to be paid. Not sure how are the sales, but income from donations seems quite tiny. Maybe "marketplace" does better job. That said, alot of people here using TB, but not many of thems seems to support it in any way. So this project will have it hard to stay alive. I once created free open source project used by few thousands shops. It was only for donation if someone wanted. For 4 years of development, I had only one donation. Switched to freemium mode so I could carry on with module. Donation oriented projects depend on community, and from my experience, it's sometimes hard to even maintain server, not saying team of devs who also eat, drink and want to buy a car or something. You can't live only from satisfaction of creating something. Everyone is expecting super open source product and not many wants to pay for it. The first comparision that comes to my mind are torrents. There are seeders and leechers. Leechers kill torrents and seeders keep it alive. It's exactly same here. Seeders who support growth and leechers who only take from project. (I do not write it to offend anyone, as maybe not everyone can afford those 5$/month - but that's the truth that will most probably put that well dry... )

https://github.com/seigieu/watermark/tree/thirtybees Here is version of PS 1.6 watermark module that also generates webp images. Also, thank @Smile for this 🙂

I think it would be better to post this bug here: https://github.com/thirtybees/thirtybees/issues That way it can be labelled and taken with appropriate urgency.

Have you checked what AJAX request is returning?

@justinrosander Depends how much you pay for hosting and what limit reall is. If its 50 and you pay like 10Eur/year then this is not service for your shop.

Just checked ISO 639-2 table. Which should be compatible with ISO field in thirtybees, but it does not seem to have a code for Vlaams language.

By me it's a design flaw, a World-Wide design flaw. Why? Cause ISO 3166-1 (used here) is not a language code. It is a Country code. However, it's a common misusage. Many systems around world use Country code as Language code not taking consideration there are multiple languages in each country. Almost all external systems will expect you to provide Country ISO code as language code. It cannot be fixed... not quickly and without problems Why in current system we cannot have 2 identical values in ISO: Unique urls: http://example.com/{iso_lang}/ Having 2 identical languages could call for trobule. Result: Could return a random or only one translation, as 2 translations have same ISO All people around globe are used to use 2 digit code and it's easier to use 2 digit code in url. getting language id by iso "Language::getIdByIso('nl')" Could also result in random or only one language ID returned These are only 2 reasons i quickly came up with. Fixing it and forcing to use proper code could be quite troublesome. As many external systems assume that ISO code returned is an ISO alfa-2 code. Changing/fixing it would trigger following consequences: Having to change all language urls (to properly match lang="" definition) Requiring all developers to adapt change to their modules. and all external systems There is also possibility for "mixed" implementation, but that could also be troublesome. Could elaborate about this problems for quite longer... Dirty hack to achieve what you want There is one thing I see in code.. iso languages can be 2 to 3 letter codes. You can try, to set ISO to: nl with nl-nl nlb with nl-be (ofcourse nlb it's not an official ISO code and SHOULD be only used internally as a hack - dont expect external modules to recognize it) It's a hacky way, but should work. Also, don't expect any module developer would change anything to support it.

I'm against on the other side. It's a great feature. It does not shine without heavy traffic. But all modules that add this option mainly break shops. So it's good its implemented as core feature. Such complicated things should not be done via modules. Or core should be designed with that type of module in mind.

https://github.com/thirtybees/docs/blob/aa392b1107b8ad4487d73215a9d085006bb85cbc/_includes/api/1.0/custompayments-content.md You mean this guide?

@M4ketech Product A - non cloth - Delivery limited only to 15€ shipping. (restricted to 1 delivery option only) Product B - cloth - available delivery options: 5€ and 15€. (not restricted to delivery) Then it would be Product A - 15€ only Product B - 5€ and 15€ Product A+B 15€ only. That's how it goes.

I'm sorry... I saw topic in "recent" posts. Did not check first post date and it was active!

@zen He means, that some of his code (from express cache) was integrated into core of thirtybees. Meaning, it will not cause conflicts - i think. Anyway, @haylau You do not need this module with thirtybees. It does exactly same thing as OnePage Cache system implemented into thirtybees (regardless if copied or not). You just don't need this module for TB. Prestashop does not have this functionality so it needs a module.

I would make FAQ and link on product page, pointing to FAQ. Copying same text over many products could weaken your keyword SEO.

Can't agree. http://www.dotsamazing.com/en/labs/phpmemorylimit 8000x8000 would require 334MB. So lots more than Default 256MB on most hostings. Some still use 128MB. Software cannot simply overcome this. Prestashop would fall here too.

@musicmaster You even have progress bar, that shows you how many were regenerated. Did you look into admin panel? @Havouza How does it look for you? It's just a hunch, but I had simmiliar problem on my server.... acually CPU usage shot from 4% to 160% in usage summary, cause one image could not regenerate. If i recall properly, the problem is that there was not enough time on server, it was able to regenerate 710 images... 711 was so big, that it couldn't generate miniatures from it and script was hammering server for same image whole day. No idea if I got throttled or something. @Traumflug Images are regenerated in batch of 1 product, right? So if i have like 100 thumbs it has to do 100 in one run, right?

@musicmaster Acually TB is more sophisticated in this term. Image regeneration in TB is indexed 🙂 So TB does not need to have it. After product images are reset, then product is marked as "1" in database. And next "not regenerated" product is processed. Prestashop has to check all images with file exists each time "Do not delete images" is used. Thirtybees does not need that and can resume where it left in an instant! Also, you can track how many images are regenerated already 🙂

Hard to say... you need to debug to solve this I think. For that I would need to have issue reproduced on local test. Check if next image is not too big. Maybe its like 12k x 12k px and it stops on it.

Are you sure your hosting provider does not block you from increasing php script timeout?

If anyone is interested in which file exactly to look for its [https://github.com/sebastianbergmann/phpunit/blob/master/src/Util/PHP/eval-stdin.php](https://github.com/sebastianbergmann/phpunit/blob/master/src/Util/PHP/eval-stdin.php) Which mostly translates to: phpunit/phpunit/src/Util/PHP/eval-stdin.php. So this file is exact source of evil 🙂 It may be included in 3rd party modules.