oliver

I fixed it. The install function needs to look like this, to circumvent the problem: public function install() { parent::updateTranslationsAfterInstall(false); return parent::install(); } Also submitted an issue on github: https://github.com/thirtybees/thirtybees/issues/1220

Hi! I just created my first module for TB, pretty much using a template from an existing module. There's nothing in it so far other than a front controller. I get the following exception on installation: My module's install function literally looks like this: public function install() { return parent::install(); } Any ideas what I'm missing? Tho, TBH it looks like there is a bug with the code that's supposed to handle the error. Why is getRequest undefined?

Okay this is interesting... I just switched to TB last week. Hoping the new owners will learn from the mistakes that happened when PS changed leadership for like 2 years, published a completely overhauled, but unfinished version, and then left lol Please don't break the entire architecture like they did!

Ooof, okay I fixed this... The main problem boiled down to the old DB having the field for passwords limited to 32 characters, but the new db has it set to 60 characters. Further, TB uses a better encryption method, compared to the old PS. Any customers that are trying to log in, it will check if they still used to old encryption method. If yes, it will update their password with the new encryption method. But, once again, the new encryption method requires 60 characters in the database, so the fields needs to be updated. ✌

Soo, did you ever get this to work? I'm needing to do the same thing right now, except that my old site is still running PS 1.6 I've succeeded up until the point that I can't log in with my existing customers, and - oddly - I can't even create new customers and log in with those O_o Super weird, and I'm seeing it might have to do with the _COOKIE_KEY_ Does anybody have any advice or experience with this? What difference is there in the way passwords are encrypted and stored in TB compared to PS? And why would I no longer be able to log in with newly created customers after migrating my old DB over? O_o

Hmm, interesting, for me transparent and non-square images work! I've used transparent category images for several years now on PS, and my product pictures have alwasy been 16:9 (but not transparent) I've just tested it, and I've used a transparent product image, and it shows up transparent on the product page, as expected. Check in the Back office, under Preferences -> Images. There's a setting to "always use PNG" and there's also various setting to change the size and ratio of your images. Of course, it may depend on your theme, I don't think my theme uses the standard image carousel, but instead I have slippry.js

I am absolutely not clear on what the "best" or "correct" way is for me to add JS files to my modules. I suppose this problem can be categorized as Asset Management. There are several variables: Sometimes JS should be included in the header, sometimes before the body tag closes. Sometimes my JS has a dependency, which needs to be loaded BEFORE my JS file (e.g. jQuery) Sometimes my module has a controller from which it can load JS, sometimes it's only a hook. Sometimes I need JS on the front office (customer area) sometimes in the back office (admin area) Personally I think jQuery should be included by default, but I understand the reasons why it might not be. Over the years, I've quite a few methods of how to get things to work: public function hookDisplayBackOfficeHeader($params){ $this->context->controller->addJquery(); $this->context->controller->addJS($url); } protected function addBackOfficeMedia(){ } public function setMedia(){ } And probably a couple of other ways, including to just slap it into the tpl file... I've been really confused on this for a long time! PrestaShop 1.7 actually introduced something super useful: public function hookActionFrontControllerSetMedia(){ $this->context->controller->registerJavascript( 'title-of-script-or-lib', $path, [ 'position' => 'head|bottom', //SO USEFUL!! 'priority' => 50, //SO USEFUL!! 'inline' => false, 'server' => 'remote', 'attributes' => 'async', ] ); } Source: https://devdocs.prestashop.com/1.7/themes/getting-started/asset-management/ I thought this was a really nice, clean, long needed solution for this problem. Literally, this was probably the only good thing about PS 1.7 hahah What's the status quo about that on Thirtybees? Is there any conclusive documentation available about this?

Woohoo! This worked, thank you! 🙂 I'm gonna have to do some research on how to get TB 1.1.x Bleeding edge ... Do you pull that directly from the repo?

How peculiar... what currency have you tested it with?

Well, what you describe is not what I personally expect, lol Unless the behavior has changed since you wrote this. I'm using TB 1.1.0

Hmm, I'm actually a bit confused on this... I'm just now switching over from PrestaShop. In my old shop, I've gone to Preferences -> Number of decimals and set it to 0, which made it so that $123 was shown, rather than $123.00 With Thirtybees, it does however show as $123.00 (which I don't like) I see my template uses {convertPrice price=$productPrice|intval} which is the same that the default TB template uses. Now sure, I could use smarty and do my own rounding and removing of decimals... But $productPrice doesn't contain the currency symbol! I see there's some improvements are in the works: https://github.com/thirtybees/thirtybees/issues/865 But in the meantime, I'm left unsure on what to do... How can I get rid of the decimals, if not by going to Preferences -> Number of decimals and setting it to 0 ? Hardcoding this into my template seems like a bad solution. What exactly is this setting supposed to do anyways?