Paul

The Enom module does not yet support DNS Management, Email Forwarding, or ID Protection yet. This is a new feature, which has yet to be updated for all registrar modules who's APIs support the actions. See https://docs.blesta.com/display/user/Enom

5.4.1 is the latest. It's possible that 5.0.2 does not have full compatibility with PHP 7.4, but I'm doubtful that is the issue here. If you can get SSH access and run that command via SSH it will tell us quite a bit.

Based on this information, you should use: /usr/local/php74/bin/php /home/username/domains/domain.com/public_html/subdomain/index.php cron > /dev/null 2>&1 If this doesn't work and you have SSH access you should try running it manually like this and see if it works: /usr/local/php74/bin/php /home/username/domains/domain.com/public_html/subdomain/index.php cron This last command should output to your shell any output from the cron. Take note of what is output. If it works, run the following command to check what your cron job actually is: crontab -l

That is unusual. I was able to reproduce this and have created the following task: https://dev.blesta.com/browse/CORE-4667

I'm not familiar with DA's 2FA and nobody else has mentioned it, but if you are forcing 2FA then that may be the problem. I would suggest temporarily disabling it to check if it works. Edit: Obviously if API commands require 2FA they ill never be able to be automated.

Thanks, I knew I had to have missed 1 or 2 when I updated a bunch of servers this week. FIxed.

Often times companies hire a dev firm to build the integration for them. They might have someone like that maintaining that integration from 10 years ago. You can use the universal module and manually activate anything that you sell. See https://docs.blesta.com/display/user/Universal+Module#UniversalModule-ServiceOptions I linked directly to the service options section, because that and notifications is going to be the most important part of creating a Universal Module product. Any fields you want to request from the customer can be added here as service fields if they do not add to the cost. Any fields that would add to the package cost can be added as configurable options under Packages > Configurable Options, and assigned to an option group, that is then assigned to your package.

When Blesta is not the authority on the password requirement, we go with the strictest possible requirement defined by the control panel. If the panel has a setting to force passwords of 12 characters, upper-case, lower-case, and a special character, then we require that so that there is not a failure to deploy a new account or update a password within the panel. We are actually against such requirements that make it difficult for the user to remember the password while making it easy for a computer to guess. This sums up our thoughts on passwords: https://xkcd.com/936/ Regarding the issue, are you certain that you have modified the correct file? You don't have another copy of Blesta in another directory? You are using the DirectAdmin module and not another? The password you provided meets the password requirements for your DA server? The text of the error message will not change based on you changing the requirements, so if the password doesn't meet the requirements you set, you'll get the same error unless you modify that in: /components/modules/direct_admin/language/en_us/direct_admin.php:$lang['DirectAdmin.!error.direct_admin_password.format']

If the plugin was already installed then its name and description, including what is shown under Settings > Company > Automation will use the language at the time it was installed. You could uninstall and re-install the plugin, or more preferably (To not lose data by uninstalling the plugin), update the language in the cron_tasks table and plugins table cron_tasks.name, cron_tasks.description plugins.name These are one of the few remaining things that do not pull the language dynamically.

Ok, this is unusual because an IP restriction on the API would normally mean that the API would restrict the IP for the source of the request. If you can specify any IP and it uses that, it could be spoofed to bypass the check. It doesn't make sense. I think the 1st comment in that documentation you linked sums it up well: It seems to me that this is something Namecheap should fix. Adding a field to specify the IP is a pretty hacky-fix. The example in this thread of using an IP address of 127.0.0.1 for ClientIP, does this work universally? If so, the simpler solution may be to just specify 127.0.0.1 for ClientIP in all requests like the example code, rather than requesting it. OR, if the IP address = IPv6, then instead of using that address, send 127.0.0.1. Thoughts?

If you are loading Blesta through your browser using the hostname "localhost", then it won't work due to abuse. Use a different hostname, even if its one you make up and add to your hosts file. Also make sure your docker container's IP doesn't change or the license will stop working.

What is the purpose of the ClientIP? Is this the IP address that API calls should originate from , or is it simply passed as a parameter in the API call? I have not looked into this myself. If $_SERVER['REMOTE_ADDR'] is returning an IPv6 address for your server, I can understand the fix posted above to force another IP. However, what are the implications if you enter an invalid IPv4 address, or one that does not resolve to this server? If the IP is just passed along to the API as a parameter, then I suppose it wouldn't cause any communication issues if the IP that made the request were different.

The example Blesta shows under Settings > System > Automation is usually correct. Sometimes your path to PHP will be different, but it usually does a good job of detecting it. If you deleted your cron job and don't remember what command you were using, probably you were calling a different version of PHP and that version met the system requirements while the new version does not.

The Namesilo module does support DNS management, email forwarding, and ID protection. Are you running the latest version of Blesta? You must set pricing for these options, if they are enabled under Packages > Domains. Packages > Domains > Configuration: Configurable Options tab, click edit next to each option. Set pricing for each term/currency you offer.

A client can click Manage next to their service in the client area, and there will be a cancel option.. assuming that you have enabled their ability to cancel under Settings > Company > Billing/Payment, by checking the option "Allow Clients to Cancel Services". If your client group settings are defined for the client, you may need to enabled it within their client group also, as these override the default company settings.

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.