Paul

Your order form should use the "General" order form type instead of "Domains and Other". Modules determine what fields are required from the customer, so if you are selling shared hosting through a module like cPanel, Plesk, Directadmin, etc then the module will request a domain from the customer during checkout.

The cron should only run every 5 minutes, if it runs every minute it will be ignored. I realize you were probably just testing to see if it was working. Blesta does a generally pretty good idea of determining the command which you can see under Settings > System > Automation. Sometimes the path to PHP is wrong. If your path to PHP is right, as well as the path to your cron, then your CLI PHP may be missing system requirements. You can check your logs under ../logs_blesta/ for any errors (Path defined under Settings > System > General) and you can, if you have SSH access, try running the cron command manually without sending the output to dev null. To run it via SSH, the command would look something like this based on what you provided: /usr/local/php74/bin/php /home/username/domains/my_domain/public_html/subdomain/index.php The most common problem is that the CLI version is missing ioncube or some other dependency.

Have you configured a payment gateway with a currency, and enabled both the currency and the gateway on the order form? Packages > Order Forms: Edit

As of Blesta 5.4, PHP 8 is supported through the hotfix-php8 SourceGuardian patch included in the release. As of now, ionCube has yet to release support for PHP 8, so we have implemented this alternative.

Thanks for the update. Tagging @Jono so he can take a look. If you are willing to provide basic steps on how to create a billable item to generate multiple invoices in WHMCS as you indicated, we can try to reproduce for a test import.

You can assign multiple addon package groups to a package group, in which case the client will be able to select 1 addon from each group.

Ok, very good, glad that worked!

There are no hidden packages under Packages when you filter using "Show hidden Packages"? All domain TLDs should have a hidden package.

Thanks, we added a help box just below the table that lists the fields with this information. Much appreciated!

Ok, that sounds like it's trying to use the "None" module, which is not a registrar module. Try this.. under Packages, click the Filter icon and check the box "Show Hidden Packages" to filter by hidden packages, which are domain packages. Note the "Module" listed for all, in each status "Active", and sometimes "Inactive" will have some. Are any using "None" for the module? If so, backup your database as a precaution, and then try to delete the hidden domain package using "None" for the module.

It sounds like there might be an invoice with duplicate number or ID. Since it probably failed at that point, it would be useful to take a look in the invoices table to see what the most recent invoice imported was. Then compare to WHMCS and see which invoice is next. That one is likely the culprit.

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?