smarterweb

so for now the question is: how can we get the pw in emails back when converting a guest account to a real one (guesttocustomer.html email template)? right now they get an email with the pw showing as "*****" and they obviously can't log in, so it's pretty useless. what's the official statement here and is there a solution/commit for this on git? (couldn't find anything)

yes, for me this fixes the problem with wrong sub totals in cart and also when you delete the customized product from the cart, it removes the product completely (as intended I guess...)

the problem only happens when you have combinations. can you please test again with a product that has combinations?

haha, hence I post here - just a user too trying to contribute

that bug has been reported in sept last year, so I assumed TB would have seen it too. will post it on git

well I don't quite why there's a forum for bugs and github. so where do I best report bugs? why have 2 places?

reported PS bug here: http://forge.prestashop.com/browse/PSCSX-9383 and the fix here: https://github.com/PrestaShop/PrestaShop/pull/8538 can this be added to 1.0.4 please?

in TB 1.0.3: when you add say 3 text fields for customization in BO product and you add to cart, the sub-total line in cart shows the wrong price. however the total shows the correct amount:

I had another bought Recaptcha module and that was working just fine with the same keys on this domain. However the TB module throws an error: Uncaught Error: Missing required parameters: sitekey But the keys are 100% correct, I triple checked and when I reinstall the other recaptcha module, all works well. The site runs in a subfolder and on https - maybe that causes some issues. UPDATE: the problem is in fact caused by another module (Form Builder) that also uses the recaptcha library, when I switch it off the TB recaptcha module works as expected. Now I am wondering if it is possible to use both modules....

@mdekker ok, I see, well there's your good reason. keep up the good work!

not sure why you want to use umask. Why not just set the permissions with chmod to 0755? From the php manual comments: Whenever reasonable, default to shut and open as needed instead of default to open and shut as needed. The above still has a race condition, but the race condition will deny appropriate access instead of granting inappropriate access. Nut you might have good reasons, not sure...

In my opinion it's considered an unsafe practice to have the default permissions of folders set to 0777 upon install of new modules. I can see in file controllers\admin\AdminModulesController.php line 1222, 1225, 1252 and 1255 that the default chmod is set to 0777. Shouldn't this rather default to 0755?

When you set Preferences -> Customers to "Re-display cart at login" then add a product to an existing order through admin, PS creates a new cart for this product. Then when customer logs in to frontend, they can see that product sitting in their cart, even though it has already been added to their order through admin. I would consider this either a bug or a confusing functionality that needs addressing. How to reproduce? 1- Add a new product to an existing order from admin (BO). 2- Sign in in the FO and open cart 3- The added product appears in your cart as a new order which makes confusion to the customer. original forge: http://forge.prestashop.com/browse/PSCSX-8554 solution: https://github.com/PrestaShop/PrestaShop/pull/8315

How to test? create an order with two products, one of them with custom fields (MUST be the first product in the order). Then, try to change the price of customized product from BO, and click update. Original Forge: http://forge.prestashop.com/browse/PSCSX-8688 Solution here: https://github.com/PrestaShop/PrestaShop/pull/8250

Hi, I have reported a few bugs in PS forge and some never got any attention (I guess that's one reason I ended up here). So I wonder if I should re-post these bugs here, or if TB is looking at unresolved bugs in the PS forge and will fix them eventually?