Jump to content


Level 2 Member
  • Content count

  • Joined

  • Last visited

  • Days Won


mustardman last won the day on October 20

mustardman had the most liked content!

Community Reputation

12 Good

About mustardman

  • Rank
    Level 2 Member
  1. Works reliably for me. When you first set it up you usually have to visit the following link and enable less secure apps. https://www.google.com/settings/security/lesssecureapps You also sometimes needed to disable captcha during the first login attempt although not sure if it's still the case. https://accounts.google.com/displayunlockcaptcha Also, it appears that google is now more aggressive in blocking new sign in attempts from addresses it does not recognize. So if you log in to the google account after you try connect from WHMCS you may see a security warning asking you to verify and accept the unknown login attempt.
  2. To eliminate templates as a possible cause, try to do it by accessing a standard template directly. So add the following to the end of your URL &systpl=standard_cart Also, WHMCS built in Stripe module has a problem imo. I consider it a bug but they apparently do not. If the default payment method is set to PayPal (I am assuming the same applies to any alternate payment method), then WHMCS tries to save credit card numbers locally instead of on Stripe. I believe it can also generate errors like what you are seeing because the last 4 digits of the Stripe stored number are saved locally and show up in that change credit card view, however, I do not think it tries to update the remote information when the default payment method is set to something else and then you get that error. That is not how it worked with the 3rd party ServerPing Stripe module which never had this problem. This seems to be a PCI compliance issue but WHMCS doesn't seem to think so. Probably not related to your problem if you have default payment method for the customer set to Stripe.
  3. Emails from @outlook.com email addresses appear to work ok as well. Only Hotmail seems to have this problem. I have tried from more than one Hotmail email address.
  4. I use POP3 importing from Goggle apps/Gmail. It has always worked perfectly including importing Hotmail emails. Now it detects the Hotmail email message body as an attachment. I am pretty sure this started happening after I upgraded to v7.3.0. Nothing else has changed with my POP3 import settings or my Gmail. The email is received by Gmail normally. So it is definitely the POP3 import step that is detecting it incorrectly. Looking in Utilities > Logs > Ticket Mail Import Log the email message is as follows: To: [email protected] From: SomeCustomer . «[email protected]» Subject: test Status: Ticket Imported Successfully No message found. Attachment [email protected] blocked - file type not allowed. If I allow .plain email attachments in Setup > General Settings > Support > Allowed File Attachment Types, I receive the above email with message body "no message" with the message body contained in an attachment in the ticket which I can then open and read. So the POP3 Mail importer is incorrectly detecting the Hotmail message body as an attachment. This only appears to happen with Hotmail. I have tried sending messages from Gmail and from other mail systems that are not Gmail or Hotmail and they all seem to work.
  5. I finally got to the bottom of this. My environment uses different php.ini files depending on whether php is run from Apache or from CLI. WHMCS uses the php.ini file used by Apache. However, phpmailer (included with WHMCS) apparently uses the php.ini file used when php is run from CLI. When I change the max memory in the php.ini file that the CLI environment uses then phpmailer uses that memory limit. You can check the php.ini file used by CLI by running the following command php --ini
  6. For anyone else having this problem. It appears to be related to /vendor/phpmailer/phpmailer/class.smtp.php. It appears to be ignoring php.ini `memory_limit=256M` and using the PHP default of 128M even though WHMCS and phpinfo(); show that php is max memory is set to 256M and there is still plenty of spare physical memory. I figured it out by running the cron without the -q or the >/dev/null 2>&1 which then caused cron to send the out of memory error message to root. The error occurs on line 655 $lines = explode("\n", str_replace(array("\r\n", "\r"), "\n", $msg_data)); The workaround is to add the following line just before line 655 ini_set('memory_limit','256M'); That will get overwritten every time WHMCS updates that file so it's just a workaround.
  7. Are you using a custom template? Have you tried with a standard template to see if the problem is still there? You can direct link to templates with URL for testing So try as follows https://yoururl/yoursuburl/supporttickets.php?systpl=six
  8. Is this the troubleshooting guide you used? Did you check your email piping cron as per that guide? https://docs.whmcs.com/Email_Piping
  9. I spend far too much time on upgrading WHMCS. Mostly because of custom templates. On one hand, it's nice to see constant improvements. On the other, it's a PiTA when customized templates that have to be constantly re-customized. The changes from v6 to v7 were particularly painful. All the templates I used to use were discontinued.
  10. I think I had a similar problem awhile back and WHMCS told me to delete that upgrade7.x*.sql file which solved the problem for me. In that case it was because it was trying to update a version that never existed in the wild or was removed afterwards. It may not be the same problem. It was awhile ago in v7.1.x times and I many not be recalling the details correctly. I accept no responsibility for what may happen.
  11. ticket notifications

    Do you have the separate cron job running? https://docs.whmcs.com/Email_Piping
  12. Down for Maintenance (Err 3)

    I second this. It's big and scary looking in v7. At least change the font size back to what it was in v6.
  13. Stripe module problems v7.3.0

    I think there is another problem that results from the first explained above. Now that the full CC number is stored locally, if you switch the client payment method back from PayPal to Stripe and run a transaction, it then saves the Stripe token locally and remotely on Stripe. However, the full CC number is still stored locally. Now if you switch back to PayPal and delete the credit card locally, the token is still stored locally and remotely on Stripe. Now switch back to Stripe and I believe you can still run a transaction using the card which is still stored on Stripe. Probably an unlikely scenario but I don't think this should be possible in the first place.
  14. Stripe module problems v7.3.0

    Thanks for the reply. I do see card type in admin and client area when the client payment method is set to PayPal. It goes away when client payment method is switched to Stripe or default (Stripe). Would this be considered a bug? To reproduce on v7.3.0. Set up Stripe and PayPal payment gateways with Stripe as default (at the top). Setup a test client with no credit card saved and go to Profile > Payment Method and set it to PayPal. Now if you try save a credit card to that client in admin or client area it will have "Card Type" option. In admin area it fails and Gateway Transaction Log has stripe gateway data "No Stripe Details Found for Update". If you try do the same thing in client area it successfully saves the credit card locally. No gateway transaction log. Now view it in admin area and you see the option to enter CC Hash to view entire card number. I tested the same thing on a v6.3.2 system that uses the serverping stripe module and it works the way I would expect it to work. It always saves credit card info to Stripe even if I set client profile default payment method to Paypal. I updated that database to WHMCS v7.3.0 on a different server. So the settings are all the same. The only changed are the WHMCS version and switching from 3rd party to internal Stripe module. This is definitely not a template issue because it happens in admin area and there are no custom templates being used there. The requirement to not "Disable Credit Card Storage" was adding to the confusion. It is not explained anywhere in the documentation that I could find and if you google around you will find discussions/solutions involving checking that feature, including in this forum. I think if you specify that it must NOT be checked that may help others.
  15. I just updated from v6 and from serverping 3rd party Stripe module. I made sure that all the 3rd party stripe files were deleted including the custom template files and replaced by six and standard_cart template files. So far existing customers do not appear to be affected. This is only for new customers and credit card changes since the update. First problem is that credit cards are stored locally. I read in the stripe documentation that cards are stored locally until after a purchase is made. After that it creates the customer and token on Stripe and saves that token info locally. That works as expected. However, it is also supposed to delete the full credit card number stored locally but it does not appear to do that. I know because in admin area "Credit Card Information" it has an additional field for entering the CC hash. If I enter the CC Hash number I get the full credit card number. Second problem probably related to first. If I check "Disable Credit Card Storage" in admin area then nothing credit card related works in admin or client area. I cannot add/change/delete cards from admin area. The "Manage Credit Card" link in the client area disappears. I cannot browse to it even if I use the direct link "/clientarea.php?event=creditcard" I found this troubleshooting guide (about 3/4 of the way down) by searching for another error I had only in admin area ("No Stripe Details Found for Update") and went through all those things. https://docs.whmcs.com/Stripe There are definitely no remaining 3rd party stripe files, templates or changes anywhere. I can get around that error by enter credit card in client area so that error only happens in admin area and no I do not have any admin area customizations.

Important Information

By using this site, you agree to our Terms of Use & Guidelines