Paul

Did you get the version from the Github link? What version of Blesta are you running? Did you upload it to /components/gateways/nonmerchant/ ? The directory must be unpacked to that location.

Which captcha type are you using? What are the steps to reproduce? For anyone stumbling on this, here's how you can manually disable captcha's in the database, from https://docs.blesta.com/pages/viewpage.action?pageId=10551368#Debugging/Tools-DisableHumanVerification(CAPTCHA) UPDATE `company_settings` SET `value` = 'a:0:{}' WHERE `company_settings`.`key` = 'captcha_enabled_forms' AND `company_settings`.`company_id` = 1;

We can tag them and see if they reply. @Blesta Addons are you all still around? Some have been concerned.

Did you look at this one also? https://modulesfactory.co/

What version of Blesta is this? What version of PHP? Do you have the Messenger system enabled? Settings > Company > Messengers, and Messenger Configuration. Also check all support staff under Support > Staff: Edit. Do any staff have any boxes checked under "Receive Ticket Messenger Notifications"? If the Messenger system is not in use, no staff should have any of these options enabled.

You don't have more than 1 uploads directory do you? Check that the path is correct as defined under Settings > System > General. This should not occur unless the old geoip database file is present.

Ah, very good! Yes, errorReporting and debugging in /config/blesta.php should never be left on, only enabled temporarily to diagnose an issue. Good catch!

There is an issue with the Stripe API library in PHP 7.4 for Blesta versions < 5.3.0. I would recommend rolling back your PHP version to 7.3 and see if the issue persists. After the final release of Blesta 5.3, you can switch PHP back to 7.4.

Are you using Stripe or Stripe Payments and did you switch/migrate from Stripe to Stripe Payments? What version of Blesta did you upgrade from? Are the errors occurring with only new or only existing payment accounts, or both? What version of PHP are you running and did you change it, or change anything else on the server recently?

This function geoip_open() is no longer used, it shouldn't be called. What could cause it to be called is if you have a copy of the OLD maxmind GeoIP file. What files do you have in your ~/uploads/system/ directory? If there is an old version of the GeoIP data (Not the one ending in .mmdb but one ending in .dat, it will try to call this function. The file should be removed.

Thanks, we have a task here https://dev.blesta.com/browse/CORE-4574

Interesting. I'm not able to reproduce this. So you have the .mmdb file in the right location, and the database shows that geoip_enabled is true and the settings page for GeoIP at ~/admin/settings/system/general/geoip/ still throws an error? Check if GeoIP is actually working. Go to a client's profile page, hover over their IP address on the left next to "Last seen". Does it show their location in the a tooltip? Are there any other errors written to the log file ../logs_blesta/ (full path defined under Settings > System > General) when you reload the GeoIP settings page?

So far I've not been able to reproduce this on Blesta 5.3.0-b1. I am able to change the renew date even if there is a partial payment on it. Are you sure only the due date is being modified? Can you provide the full line item description and price of each line item? Maybe we can reproduce using the same data.

The amount in the "Amount to Pay" box cannot exceed the "Payment Amount". If the payment is 5 million, you cannot apply 10 million to the invoice. Change the Amount to Pay to be equal to the Payment Amount and it should work. This is not a bug.

It would be located at ~/uploads/system/GeoLite2-City.mmdb whatever the path to your uploads directory is. If you have access to the database, you can also check to make sure it's not enabled. Here's the query to run to check: SELECT * FROM `settings` WHERE `key`="geoip_enabled"; settings.value would be false for disabled, and true for enabled. If it is true, change it to false to disable it

If that doesn't work, you might try enabling GeoIP and see if that gets rid of the error. To do that you'd need a free MaxMind account to download the data file though.

What happens when errorReporting is 0 and debugging is false in /config/blesta.php? Does it still produce a 500 error? There is a possibility that some files may be missing. Sometimes they get skipped when uploading, I would try re-uploading the files from zip, overwriting the existing just to be sure everything is there. If your FTP program lists all the files, make there were no errors uploading.

Do you have errorReporting or debugging enabled in your /config/blesta.php config file? What version of PHP are you running? Is this a fresh 5.2.2 install or did you upgrade from an earlier version? If you upgraded, what version did you first install?

Do you have GeoIP enabled under Settings > System > General > GeoIP Settings? If you upgraded from an earlier version that had the legacy version of MaxMind GeoIP, you must DELETE the original GeoIP data file and upload a new one.

It sounds like there's a problem with that plugin. You can try this.. in MySQL, change the plugin in the plugins table from enabled=1 to enabled=0, then see if the page loads. If it doesn't, you will need to delete the record from the plugins table for the plugin and delete the plugin files. Backup everything first, database + files. To do a thorough job of removing it, any/all tables the plugin may have created should be deleted manually as well. Because it's a 3rd party plugin, I have no idea what those are though. But, this shouldn't be necessary if you are not going to try re-installing it later.

The API response is logged to the module log under Tools > Logs > Module tab. Click the row for the API call to expand it and see the raw input/output from the API call. Usually the output will provide more information. If there is some kind of PHP error, it would be logged to the file logs under ../logs_blesta (Path defined under Settings > System > General) so you may want to check this also. Only errors written during the registration attempt would be relevant.

If it marks it as read but doesn't import it, it is probably failing. Try disabling your cron job, and running it manually under Settings > System > Automation by clicking the button, after a 5-min wait with an email ready to be imported. At the same time, tail your logs via SSH. tail -f /path/to/logs_blesta/*.log Note any output and whether the email is imported when running the cron manually that way.

What version of Blesta are you running? Namesilo requires that you have a payment ID and a verified payment method to register/renew/transfer domains over the API. That is the most common reason it does not work as expected. It is possible to manually renew/transfer/register domains with Namesilo through their interface without a verified payment ID, but not over their API.

How are you importing tickets, using POP, IMAP, or piping? Are you saying that a new email to the department opens a ticket, but replying to the email sent to the client from a staff reply does not get imported? It's unusual that an email would be imported for a new ticket but not for a reply unless the reply is missing the required information in the subject line. I would check that mailparse and php-imap are installed. When changing PHP versions, this is most commonly overlooked. The errors you've included do not appear to be related.

It's a good idea for sure, but as you've noted it hasn't had that much support thus far. As a result, it isn't a very high priority, but definitely something we'd like to add support for.