garyhoffmann

I figured out what was going on. The store admin had a mixed case address for the email to portion of the EmailAlerts. Once I put this in as all lowercase, it worked as expected. However, that got me to thinking - people can obviously enter a mixed case email address. Therefore, I continued searching now that I knew what the problem might be. Inside of classes/Mail.php, it had the following code: /* Construct multiple recipients list if needed */ $message = \Swift_Message::newInstance(); if (is_array($to) && isset($to)) { foreach ($to as $key => $addr) { $addr = trim($addr); if (!Validate::isEmail($addr)) { self::dieOrLog($die, 'Error: invalid e-mail address'); return false; } if (is_array($toName) && isset($toName[$key])) { $addrName = $toName[$key]; } else { $addrName = $toName; } $addrName = ($addrName == null || $addrName == $addr || !Validate::isGenericName($addrName)) ? '' : self::mimeEncode($addrName); $message->addTo(self::toPunycode($addr), $addrName); } $toPlugin = $to[0]; } else { /* Simple recipient, one address */ $toPlugin = $to; $toName = (($toName == null || $toName == $to) ? '' : self::mimeEncode($toName)); $message->addTo(self::toPunycode($to), $toName); } I needed to change the $toPlugin to use the toPunyCode equivalent. So, I now have: /* Construct multiple recipients list if needed */ $message = \Swift_Message::newInstance(); if (is_array($to) && isset($to)) { foreach ($to as $key => $addr) { $addr = trim($addr); if (!Validate::isEmail($addr)) { self::dieOrLog($die, 'Error: invalid e-mail address'); return false; } if (is_array($toName) && isset($toName[$key])) { $addrName = $toName[$key]; } else { $addrName = $toName; } $addrName = ($addrName == null || $addrName == $addr || !Validate::isGenericName($addrName)) ? '' : self::mimeEncode($addrName); $message->addTo(self::toPunycode($addr), $addrName); } $toPlugin = self::toPunycode($to[0]); //TA Added was $to[0]; } else { /* Simple recipient, one address */ $toPlugin = self::toPunycode($to); // TA Added was $to; $toName = (($toName == null || $toName == $to) ? '' : self::mimeEncode($toName)); $message->addTo(self::toPunycode($to), $toName); } That seems to fix it. The problem is that the plugin was receiving the address with mixed case, but the to address had been converted to all lowercase by the toPunycode call in the $message->addTo call, so the DecoratorPlugin was never finding the correct replacements. Since people can enter a mixed case address, I figured this was the only safe way of handling it across the board. I tested by resetting the admin email to mixed case, plus I entered a mixed case address as the customer. Both received the correctly formatted emails, so I believe we can put this one to rest. If anyone from Prestashop looks at these messages, PLEASE make sure that Mail.php is setup correctly for the future versions. Thanks.

This has been an issue from the start, but we have not had a ton of sales. However, sales are picking up and now we want to address it. We are using PS 1.7.5.1. We have the Mail Alerts downloaded. We have Version 2.2.1 which seems like it is the latest as it does not show up on our updates tab. When the email comes to us, it has all of the template tags in it still. For example, it says "A new order was placed on {shop_name} by the following customer: {firstname} {lastname} ({email})" rather than the replacements for those variables. This is true for the entire template. The module has the code to fill all of those template variables in ps_emailalerts.php in the function hookActionValidateOrder. What do you suppose might be causing this to not work correctly? We'd love to get the emails working as expected, but don't know where to start troubleshooting this. We have looked at the vendor/swiftmailer/swiftmailer/lib/classes/Swift/Plubins folder and the DecoratorPlugin.php seems to be OK (but I have not studied it completely). We have looked at the Mail class (MailCore) and it seems OK. I'm just looking for a pointer in the right direction to see if I can figure out what might be going on. Thanks in advance, Gary.

It seemed to work fine after clearing cookies and cached data. Thank you for checking this...it led me to the correct answer, at least.

Hmmm...I wonder what it could be. I purposely tried the incognito windows to try to avoid anything like bad cookies and/or cache. I think I'll try to clear cookies and cache and try again.

I'm having problems logging into the add-on store this morning (5:00 AM CDT) Wednesday 13-May-2020. I keep getting 404 errors. Is anyone else experiencing this? I have tried through two different browsers and with "private" or "incognito" windows as well. One time, but requesting a password reset, I was able to login, but I could not download anything (kept getting 404 errors). Any thoughts?

I'm on 1.7.5.1 and I have the ability to set those up by product, so I apologize for misleading. Also, 1.7.5.1 seems to have a priority rule setting by item on specific prices. I'm not sure which version you are using, but it may be worth looking at 1.7.5.1 to see if it solves your needs. I'm new enough to PrestaShop and am having some troubles with specific prices also, so I may be completely off base...

That's the tool I use - I love it - been using it for probably 15-20 years. Plus, ScooterSoftware is from Wisconsin, which is where I am at.

That would have been great - I found that simply replacing the files actually worked, though. I'm trying to do a comparison of the files I downloaded when I saved off the original files to what I re-uploaded. There are a lot of differences, so I'm not sure what to make of that. Nothing like a hack situation, just additional config files, cache files obviously, etc. I think something got corrupted but I'm not sure what it was. When I tried to go into Performance before doing this, it would eventually timeout and go back to the homepage of the website (after about 300 seconds). The last thing that did paint took 243 seconds to come up. That's when I decided to give replacing the files. There was really nothing else to try because the site was completely unusable. Thank you for your pointers.

Would this be better served with a discount rather than a specific price? I'm not sure, just putting it out there. There is priority on the discounts, just not on specific prices.

I have an item that is on sale. It's normal price is $35.27. I want to give it a specific price discount of $14.00. I would expect, because my customer group says to display without taxes, that I would see regular price of $35.27 and the price of $21.27 with a discount of $14.00. Instead, i am seeing a regular price of $36.86 (price + tax) and a discounted price of $23.54. So, when someone sees this, the first thing they will think is that the discount isn't really $14.00. What setting do I need to change to make sure that items with specific prices show without taxes? Thanks in advance. Gary.

I have not been able to figure out what caused it, but I made a backup of the site, re uploaded all the files (which I saved on my computer), re-copied the img folder and everything is better now. Something must have gotten out of whack, but I have no idea what it was.

I spoke too soon - it's still really really slow. Now I'm trying to get into products and it's taking forever and a day - I guess it's time to turn back on dev mode and profiling to see if I can understand what's going on now.

The short answer to this - don't use the translation engine - I had one translation in the software and it read the database 356 times to paint one page. I removed the one row from that table and now pages paint normally again. Lesson learned - change the tpl files rather than using the translation engine - if anyone from PS actually reads these forums, please take a look at this. Gary.

Interesting - I turned on the profiler - to load one page (the stats page in the BO, it read the translation table 356 times. That's a problem in and of itself. There's no reason for it to constantly reload the translations table. Does anyone have any idea of what's causing this? Thanks, Gary.

I was using PHP-FPM, but have turned that off, I restarted the MySQL service. I have not tried to restart Apache after changing this - maybe I will try that. My servers are constantly under attack, but I have quite a few safe guards in place to try to alleviate some of that. Thanks for the pointers. I continue to look for additional ideas in the meantime. I will write back if restarting Apache solves the problem. Gary.