Jump to content

WHMCS Lawrence

WHMCS Technical Analyst II
  • Content Count

    114
  • Joined

  • Last visited

  • Days Won

    3

WHMCS Lawrence last won the day on July 19 2019

WHMCS Lawrence had the most liked content!

Community Reputation

4 Neutral

1 Follower

About WHMCS Lawrence

  • Rank
    WHMCS Technical Analyst II

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Please ensure that you are using the "Resend Verification Email" option shown on the Client Summary page itself. If the merge field isn't being replaced with the unique, this usually suggests that the e-mail is being sent manually using the unrelated "Send Email" option and won't work as expected.
  2. Hello, Looking over your ticket, I can see that we requested additional details to perform further investigation. Please follow up with them so we can do so. We've attempted to reproduce this locally, but cannot at this time. This would normally suggest that the underlying cause is a cron-related issue (for example: the crons folder wasn't updated during the update, an unexpected issue with cron on the server itself, etc) that is either causing the cron job to fail to complete or preventing the credit card task itself from completing. The first thing to do would be to debug the cron using our instructions at https://help.whmcs.com/m/automation/l/683269-advanced-cron-troubleshooting At the very least, that should reveal any errors that are occurring and those can be investigated further. I'd recommend opening a ticket with the findings from the above and we can assist further.
  3. Hey everyone, If anyone is still experiencing this issue and hasn't opened a ticket, could you please do so and provide temporary login details so we can investigate this further. Thanks!
  4. Hey everyone, Digging into this further, the overage billing you've noticed isn't occurring specifically due to this change from case CORE-13060. The instances I've seen of this have been due to an unexpected value of "0" in the overagesenabled field in the tblproducts database table - we expect it to be empty when the Overages Enabled setting is disabled on a product. Myself and my colleague are investigating how this happens. In the meantime, the result is that unexpected value appears to be causing the product to get included in the overage billing process. I've tested locally and editing and re-saving products without making any changes corrects the value in the database as needed to prevent this from occurring going forward. If you wish to update all products at once, the following SQL query should do the job: UPDATE tblproducts SET overagesenabled = '' WHERE overagesenabled = '0';
  5. Hello, Most likely the data in your database tables is in latin1 (which is/was the MySQL default for some time), which (simply put) isn't compatible with utf-8 and will need a manual conversion to fix this. In my experience, the instructions at https://docs.moodle.org/31/en/Converting_your_MySQL_database_to_UTF8#Linux_.26_Mac are a good starting point. I would recommend searching and replacing any references to "utf8mb4" with "utf8" to help ensure that the end result is compatible with WHMCS. As you will be modifying the database directly, I'd strongly recommend making a backup of it before proceeding and contacting your system administrator if you are unsure of how to do the above.
  6. A 404 error on saving in the admin area is generally going to be caused by a malfunctioning mod_security rule on the server and would need to be investigated and corrected (or disabled) by your system administrator to resolve it.
  7. Most likely it was probably set a long time ago and only noticed now. As for the line in the configuration.php file, I'd strongly recommend adding it - otherwise it can lead to other unexpected issues with saving data.
  8. Hello, Please make sure the System Charset under Setup > General Settings > Localisation tab is set to utf-8 and the configuration.php file has this line: $mysql_charset = 'utf8'; Without those, you may see some weird issues with saving data due to how MySQL works by default with latin1 instead of utf-8.
  9. Those are configuration files for PHP - not MySQL. Generally the MySQL configuration can only be modified by the root user on the server and resides in the /etc/my.cnf file.
  10. It would depend on the type of module. Generally for an addon, it will create any needed database tables during activation and remove them during deactivation. However this is up to the author to implement. Once the addon is deactivated under Setup > Addon Modules, deleting the files under the /modules/addons folder and then checking to ensure it removed any database tables it created is usually the best option. For other module types (server, domain, etc), you would first need to edit the applicable items using them and then delete their files and manually remove any database tables that they created.
  11. Hi everyone, as mentioned by John in that feature request, we expect 7.8 to reach beta status later this month, so the general release of 7.8 should be available in advance of the deadline. Rest assured that we are aware of the impact of this change and are working to get it taken care of.
  12. If deleting currencies helped, this is likely a MySQL issue as doing so would reduce the number of queries needed to display the pricing and process the request. The likely next step would be a general tuneup of MySQL on your server. As a starting point, you may want to set max_connections to a low value like 50 and increase based on your available RAM. Other important setting are wait_timeout (at least 600, so MySQL doesn't drop connections too soon), table_definition_cache (at least 5000), sort_buffer (2-4M seems to be good), read_buffer (2-4M seems to be good) and max_allowed_packet (16M is usually fine). Note: in MySQL, "M" means megabytes. Once this has been done, restart MySQL and let it run for at least 48 hours. Then you can look into something like MySQLTuner to do an automatic check and see if it makes any suggestions on improvements: http://mysqltuner.com/ As always with MySQL, the above are just general starting guidelines. Ultimately, the best possible performance will require a thorough review and optimization by a qualified database administrator, but this should at least be a good start.
  13. If your hosting provider has ruled out a DNS resolution issue on the server (as the error messages suggest there is), please feel free to open a ticket with our support team so this can be investigated further.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use & Guidelines and understand your posts will initially be pre-moderated