Paul

What version of Blesta are you running? Did you import from another system, or migrate TLDs from the old method into the domain manager or is this a fresh setup? Any errors written to ../logs_blesta/ when attempting to change the registrar for .com to Enom? Regarding #2, the error means that the feature is not supported by the module - not necessarily that it is not supported by the registrar. It's possible this has yet to be added to the Enom module.

You can view the source of the login page and copy the form fields and post URL. However, you will need to disable CSRF checks for the login page. Per https://docs.blesta.com/display/user/Configuration+Files you would update your /config/blesta.php to set the following for Blesta.csrf_bypass for the client area login URL. Configure::set("Blesta.csrf_bypass", ['client_login::index']);

What version of Blesta is this? Have you made any modifications or are you using any third party extensions? What browser are you using? Do you have a lot of configurable options? Did you make any changes to the order or client bootstrap templates or CSS? A full screenshot might provide more answers.

I have created this task and our developers will take a closer look very soon. https://dev.blesta.com/browse/CORE-4622 What registrar are you using? Though I was able to reproduce it with our Generic Domains module, I had to manually add one of the TLDs to it. It seems you are using a custom module, so it is possible that it is module related. I could not reproduce it when using .co and .uk.co, though each were configured to use a different registrar.

What version of Blesta are you running? What version of PHP? Which logs are you checking? The file logs, at ../logs_blesta/ (Full path defined under Settings > System > General) may have more information. Only logs written in the files containing the word "cron" are relevant, from the time of the delivery attempt. You can do a couple tests: Edit an invoice, make sure "Email" is checked. If it is checked, delivery should be attempted at next cron run. Wait for the cron to run, edit the invoice again and see if it is no longer checked. Is it checked? Was the email sent? Does anything appear in the Email log under Tools > Logs: Email? Is anything written to the ../logs_blesta/ file logs? To see if the problem is related to your CLI PHP, try the following: Disable your cron job on your server. Edit an invoice, make sure "Email" is checked. Wait 5 minutes from the time you disabled your cron job. Go to Settings > System > Automation, and click the button to manually run the cron job. Was the email sent? Is "Email" unchecked for the invoice? Re-enable your cron job. If it sends when running the cron manually in the interface, then your CLI version of PHP may be missing dependencies.

You can use "Restricted" packages to give special pricing to customers. Copy an existing package and adjust the price, and set it to "restricted". Under the client's profile page Actions > Set Packages, grant them access to the package. Make sure the package is assigned to an order form. Only clients that are logged in and have access via Set Packages will see the package and be able to order it. There is nothing automatic about this due to quantity, etc. If you want to make a feature request and can provide details, feel free to submit at https://requests.blesta.com

Blesta can currently import pricing into TLDs, but the TLDs must be created first. In version 5.5 we plan to have an option to also import the TLDs themselves as well.

I've created this task https://dev.blesta.com/browse/CORE-4596 to add a redirect option. To do it now, you'd need to write some PHP code that would accept the affiliate code and write the necessary cookie, then do the redirect on its own. It's not complicated but requires some PHP knowledge.

I created this task so we can update PHPIDS for PHP 8 https://dev.blesta.com/browse/CORE-4588 however, a deprecation warning should not cause any actual problems, unless you have errorReporting or debugging enabled in /config/blesta.php errorReporting should be set to "0", debugging, false. If you are seeing this in the logs, but everything is working fine, then there's nothing to worry about.

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