Kashir2000

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.

2 hours ago, Bill Dalton said: "What really struck me was the amount of inconsistencies I found: coding style, duplicate subsystems, prices being calculated with tax then re-calculated to remove tax, character set conversions that no one was able to explain—even legacy controllers, which look like they were designed to execute a single action, had been subverted into incongruence in order to handle multiple actions. It really looked its age: layer over layer of changes made by a thousand hands shuffling things around over the course of a decade, without really understanding why things worked that way nor what the original intent was. Some subsystems had even been replaced by new ones without anyone being able to explain why or how they were supposed to work. Madness!" He is talking about PS 1.6x - the code TB is based on. I assume that now, TB is very different from that description. To be perfectly clear. Both thirtybees and PS 1.7 ARE based on PS 1.6. PS 1.7 PS 1.7 is theoretical try to straighten things up. At the moment it's few more times inconsistent than 1.6. 1.7 is partially custom framework based and partially Symfony based. So you can only imagine what mess it is. That's why it literally has thousands of bugs... Half of 1.7 is powered by old system, and other half by Symfony, which still uses legacy code and hacks... and will use hacks if they want to have it backward compatible (good example can be found in src/Adapter/LegacyHookSubscriber.php - also first commend in code sums whole controller pretty much: //Hack SF2 cache clear : if context not mounted, bypass legacy call) So its new system, that maybe one day will be "consistent" (and complex like Magento - meaning lower count of specialists and more people who do things not understanding why) - but its nowhere near that term, and i belive it will take around 4-6 years (or more) to achieve this state. All PS 1.7 users are live test subjects and guinea pigs. thirtybees I see it as approach to stabilize 1.6 (ie. fix inconsistencies and bugs, but without bloody revolution) and add many missing features that 1.6 lacks - and 1.7 lacks even more. I know few people who migrated from 1.6, to 1.7 and then, after testing thirtybees they were like "Really? A good working Prestashop finally! It does not crash where 1.6 crashed while 1.7 crashes even more than 1.6". I think that's how you can conclude those two projects 🙂

Don't get me wrong. But come on... comparing thirtybees current state to 1.6.1.11 is insult... It's like saying: Your tb may not exist, if it didn't I would be on 1.6.1.11 and it would be exactly same. It's like saying: You copied Prestashop and did nothing - I know you most probably didn't mean it. What has been done in thirtybees deserves not only support but also great acknowlegement for lots of great work. I, personally, hate where PS 1.7 is going, for standards these days it has literally nothing. Great learning curve for development, lots of not needed files, complexity and code overhead.

Looking at code, it may happen in few cases: OrderInvoice is not assigned properly to ID order (or rather order is not properly assigned to orderInvocie in database). Can be caused by a module or core itself Order does not exist anymore - quite common if you use any kind of removeOrder module In both cases, this OrderInvoice does not have properly assigned Order ID (Missing or wrong) which should not happen.

C'mon... blog module, webp to start with and many more... progresive images etc. Is it nothing? It's so much and bug fixes as addition!

I did not claim anything. Firstly I wrote what people are afraid of. Secondly I wrote they may not, not will not work (tho, I agree some might not know difference). What I have a chance to test was working fine.