-
Posts
79 -
Joined
-
Last visited
-
Days Won
5
Content Type
Profiles
Forums
Gallery
Downloads
Articles
Store
Blogs
Everything posted by Kashir2000
-
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?
-
@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!
-
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...
-
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
-
Also Interested! Any roadmap, plans?
-
Acually... i think it may be related to this function... /** * Find an existing variant of a specific image type. * * @param string $name * * @return string * * @throws PrestaShopDatabaseException * @throws PrestaShopException * @version 1.0.0 Initial version */ public static function getFormatedName($name) { $themeName = Context::getContext()->shop->theme_name; $nameWithoutTheme = str_replace( ['_'.$themeName, $themeName.'_'], '', $name ); if (static::typeAlreadyExists($themeName.'_'.$nameWithoutTheme)) { return $themeName.'_'.$nameWithoutTheme; } elseif ($themeName && strpos($name, $themeName) !== false && static::typeAlreadyExists($name)) { return $name; // These last two are for retrocompatibility. } elseif (static::typeAlreadyExists($nameWithoutTheme.'_'.$themeName)) { return $nameWithoutTheme.'_'.$themeName; } elseif (static::typeAlreadyExists($nameWithoutTheme.'_default')) { return $nameWithoutTheme.'_default'; } // if $name contains _default suffix, ie. home_default then try to resolve the name without this suffix $pos = strpos($name, '_default'); if ($pos === strlen($name) - 8) { return static::getFormatedName(substr($name, 0, $pos)); } // Give up searching. return $name; } No theme name normalization. @Traumflug @datakick is it safe to allow name?
-
@pmfjoe Screen from Images section? Where thumbnail names are? Also 13-PMF eTicket Store Theme_home_smallest in names still exist... so why is some kind of other theme names in your image names? Seems installation of this theme made some permanent changes to your shop.
-
@pmfjoe Your link looks like https://www.firefightersfair.net/13-PMF eTicket Store Theme_home_smallest/power-pass-eticket2x.jpg which is bad. But now we know what happend and what went wrong 🙂 That's why I asked for page. I may be wrong, but your "template" made some error with thumbnail name generation. Maybe template creator used theme name to prefix theme images. And they contain not proper characters. Basically you have to fix your template. But that's just a guess. You would have to: - Fix thumbnail names to only contain a-z0-9_ characters. - Fix template (in .tpl files), to use new thumbnail names. PS: Link do not contain directory path. This adress is dynamically translated by htaccess
-
Not sure how to help you without any link. It might be that thumbnails are not generated and/or htaccess problems. Need more info 🙂
-
Queue sending order emails to speed order confirmation?
Kashir2000 replied to Chandra's topic in English
@datakick Acually I think ther could be a Hook actionSendMail which could be able to "break" mail sending and do its own magic. That way TB could implement mail sending in many ways. One could use PHPList integration, other one mailchimp or any kind of other service. And those who want could stay as it is by default! -
Queue sending order emails to speed order confirmation?
Kashir2000 replied to Chandra's topic in English
Just to note, with good mail servers/services mail send takes few miliseconds. But implementing it has another tricky part would be requiring of cron or services as @datakick said. Which would increase requirements of knowledge from one setting up a shop - some don't even know what CRON is and setup their own shops. Do you really want to increase complexity of TB setup? So definitely that would have to be an option I think. -
Error 500: both front end and back end
Kashir2000 replied to movieseals's question in Technical help
@movieseals In admin panel, under settings there is "Logs" tab. You can uplad this file there, decode error and post error here. Only then we can tell/help you more. Or you may find out what's wrong yourself 🙂 -
This can happen only in Russia. I like the part that they own the code, cause he wrote it in his free time, while he was working... It's carazy 🙂 Rumbler must've paid lots of money to someone 🙂
-
Created issue and pull request for this. Fix is here: https://github.com/thirtybees/thirtybees/pull/1125 Hope I did it good 🙂 Haven't made a pull request yet ^^
-
@Briljander In that case you would need module to do so. Without it it's gonna be hard. But, on the other hand, maybe check, how your competition work with this problem?
-
How many products you've in your shop? Is it mass offer or individual? I would try to use weight ranges if possible. I understand your problem, but don't know ready to deploy solution for it.
-
@Briljander I'm sorry, but I don't know such module. Working with prestashop since 2011 and I don't recall anyone asking for such module ever. Most of companies do not care about that and put additional shipping costs into margin of products.
-
TL;DR The rule here is different. It does not check how many would fit into a package, but if carrier can take that package. If you have Carrier A and it's max dimmensions are 30cm x 30cm x 30cm then this carrier would not take product that is 40cm x 30cm x 30cm But, same carrier can take 3 30cm x 30cm x 30cm packages It only checks if all could be taken by carrier, not if all will fit for one package. Many times i put one order and recieved 2-3 boxes with shipping number xxxx/1/3, xxxx/2/3 and xxxx/3/3. So it's rather common used solution. Longer version The thing you mean is "Box Selection Algorithm". TB (nor PS) does not support this. Many people solve this using weight system as "volume system". You could calculate weight for those. But it will not work in 100% cases. Still if your package is 30x30x30 (Volume 27000) then it would fit 2x 15x30x30 (2x 13500 = 27000 = it fits!) boxes. But if you had at last one 5x30x40 product, it would volume to 6000. So theoretically, you could use 30x30x30 box... but would it fit? For this case you would need 20x30x40 packaging box. So unless all your products come in exactly samame dimmensions its pointless.
-
If it's not easy to fetch by join, you can use callback parameter and fill field value by it.
-
Not sure if TB supports "ID" to "NOID" redirect for products. Would need to dig into code and/or maybe someone who knows more may answer that. But I'm not writing here for your problem, but more as a warning: Read above and then decide if you really want to disable URLs 🙂
-
-
Basically structure of Prestashop is as follows: Category id 1 is root category. This category should (or even must) exist. All other categories must have parent > 0\. So for standard Prestashop its 1 (Root) with parent 0; 2 (Home) with parent 1; (this - meaning value of 2 - should be set in your store as HOME category in settings for your shop) Things complicate if you have multistore and want a different category tree. Let's assume you want Category 123 to be home category of your second shop, then: 123 (Home of 2nd shop) should have Parent 1* and in Configuration of 2nd store HOME category should be set to 123. Note: * - It does not need to be 1... it may be 2 for example - but only if you want to - for example - setup second shop and use one of your existing categories and products in 2nd shop. For example, you may sell bikes and parts.... and you have Category tree like: 1 - ROOT (parent=0) 2 HOME (parent=1) 3 Bikes (parent=2) 4 Bike Parts (parent=2) 5 Bike Cloths (parent=2) 6 HOME2 (parent=1) 7 Laptops (parent=6) For SHOPID = 1 you may want to have 2 as HOME_CATEGORY - it will sell all products For SHOPID = 2 you may want to have 4 as HOME_CATEGORY - meaning it will only sell bike parts For SHOPID = 3 you may want to have 6 as HOME_CATEGORY - meaning it will use different tree Also note, that modyfing anything in category 4 will have effect in Shops 1 and 2 but not 3.
-
Wanted to quickly ask, if someoneknows if there has been anyc hanges to Advanced Stock management in TB comparing to PS? I have problem where sometimes in one of my client shops stock of a product jumps to millions... wonder if there was such bug fixed and/or got fixed in TB?
-
Smaty cache takes too much SSD space for some modules
Kashir2000 replied to vsn's question in Technical help
If you really want to disable caching, then one would replace return $this->display(__FILE__, 'productscategory.tpl', $this->getCacheId($cache_id)); with return $this->display(__FILE__, 'productscategory.tpl'); Trick is to remove cache_id from display and it will not write caches. Do it in all places where you want to disable caches. After doing so check if shop did not slow down. -
@Traumflug Huge posting because I think Prestashop is one of the best eCommerce platforms out there, and 1.7 is a "Fall of Prestashop" 🙂 TB is my light in a tunnel 🙂 Sorry, for making ruckus, as I wrote in my second post, i had no idea it was backward compatible with {id} and that {id} had priority 🙂 - which is super fine 🙂