Paul

I've created this task https://dev.blesta.com/browse/CORE-4586

Good to hear!

What version of PHP are you running? Looks like this is removed in PHP 8, so the plugin will not be compatible with PHP 8 unless we update it.

Is your web server doing any caching/proxying? If the page is cached, then CSRF and captcha's will not work correctly.

If I understand, you want to create different Domain Package Groups for different order forms? So that you can offer certain TLDs on an order form, and others on a different order form? Or have different pricing for TLDs on different order forms? This is not currently supported, but might be something we want to look at. I can see this being useful, but in order for this to work there would need to be a way to "switch" between different domain package groups under TLD Pricing, so that when you edit TLDs it's for a specific group. Right now, only the 1 group is supported. Am I on the right track? What's your use case for having multiple domain groups?

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.