Jump to content
thirty bees forum

Kashir2000

Members
  • Posts

    76
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by Kashir2000

  1. @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.
  2. 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.
  3. 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.
  4. 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.
  5. https://github.com/thirtybees/docs/blob/aa392b1107b8ad4487d73215a9d085006bb85cbc/_includes/api/1.0/custompayments-content.md You mean this guide?
  6. @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.
  7. I'm sorry... I saw topic in "recent" posts. Did not check first post date and it was active!
  8. @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.
  9. I would make FAQ and link on product page, pointing to FAQ. Copying same text over many products could weaken your keyword SEO.
  10. 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.
  11. @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?
  12. @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 🙂
  13. 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.
  14. Are you sure your hosting provider does not block you from increasing php script timeout?
  15. 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.
  16. 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 🙂
  17. 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.
  18. 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.
  19. 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!
  20. 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.
  21. It's due to 2 reasons. One is time, other one is that these modules (I'm talking about) are not mine and don't have licenses for them. All my modules are tested against thirtybees and work without problems 🙂 So I did test - but only ones I created 🙂 Still. They get there and ask question none answers... can't it be disabled?
  22. @lesley That is what we wanted and didn't want to hear at same time :(. I'm somehow happy knowing what is happening but utterly sad about your health state. Wish you all best!
  23. 4 hours ago, Traumflug said: So far my impression of this discussion is that some people are more into leeching free software rather than running and growing their own business. Not a single post along the lines of "I'd like to do this or that, but I can't, because thirty bees doesn't cut it". It's only natural. Wherever there is open source project there will be leechers and supporters. But everyone is worries if it will survive... There are some supporters, there was roadmap which disappeared from site. It's natural everyone is worried... and there are a lot of people who fear thirtybees and spread word that it's dead project... why? I will answer in next section... 4 hours ago, musicmaster said: What I consider much more important is getting Prestashop users to switch over. I don't think the lack of features is stopping them What fears people most of thirtybees? There are some people thinking of thirtybees, but few wrote via main contact from... no answer... I also did write a message once via page contact form and had no answer... first thing comes in mind that there is no answer? No one maintains it... On that, people who are afraid of thirtybees are basing their claims it's going to be dead (or is dead already). Every non answered question rises doubts... those "doubts" are used by enemies to prove that tb is dead... Basically, all claims "thirtybees is dead" can be easily backed up by inactivity and no clear goal... no progress. And what, from my experience is frightening most people? devs - a lot of developers are not building modules properly and rely on database queries instead of API - they will not advertise tb because it will mean more problems for them modules - as above, lots of modules will not work with tb due to database changes (actually... are there any changes in db structure? compared to 1.6? ) inactivity - No one answers contact forms... better remove contact form, email adress and tell people to ask in forum than leave it not answered no clear goal - there was a roadmap... i really loved it. If people don't know whats planned, then they don't know if anything is happening. So... all those people ask themselves one question: Will it survive? Will there be updates in 1, 2 or 3 years? First thing people are taught by Prestashop: 1.6 is EOL, and that 1.6 is not secure anymore as it does not receive updates. And people actually believe that there will magically appear security issues out of nowhere because its labeled EOL (non programmers don't know how software is made and believe this propaganda). Going this way they come to conclusion: if project dies, then there will be no updates, which will result in insecure shop... better go with 1.7. Many core modules needed in my country may not work with tb due to database changes (not tested). And those modules are must have... there will be no PS migration to TB if they're not sure devs support thirtybees... and that's concern i hear the most, even more than EOL complains. If any of you have employee... and he is drunkard... you never know if he will be in work next day... then you don't want to employ such person... even if he does best work, none will keep them as he is not reliable. Even tho thirtybees is far more stable in terms of software, there is clear concern about stability of staff/crew/creators. And many matters you do not attend to create such illusion you're not there. As Brijlander linked us vision of 1.7.... even if it's partially bullshit, people who don't understand it rise in trust to Prestashop... I won't lie... I'm also one of those people who are afraid about future of thirtybees. You're fighting against Goliath here... against trust to Prestashop brand... and you don't try to build this trurst...
  24. Will take lots of time to stabilize it. 1.7 is complete failure for almost 3 years. It's slugishly slow because of overhead symphony adds. The only thing you don't notice it is because servers evolved, SSD and NvME etc. Yesterday I copied shop from one of my clients, and it was 1.6.0.11... almost don't remember it was so fast... backoffice generation (board) takes 200ms. Front page pages generate in less than 350ms with cache enabled and less than 2500ms with caches disabled (index.php only times). ON same server, newest 1.7 takes 3-4 times more... 1.7 is broken by Symfony implementation
  25. Also Interested! Any roadmap, plans?
×
×
  • Create New...