Paul

In case anyone else experiences this issue, this case was due to /config/blesta.php missing pagination settings. This could happen if the config file is not writable during upgrade.

If you moved Blesta, make sure that you moved it correctly including copying ALL files + database. Review the big red note in our moving Blesta guide here https://docs.blesta.com/display/user/Moving+Blesta If you moved Blesta correctly, then it's likely your new server doesn't meet the system requirements. See the requirements here https://docs.blesta.com/display/user/Requirements You can temporarily enable errorReporting in /config/blesta.php by changing it's value from 0 to -1 and any errors may be output to your browser, but be sure to switch it back to 0 when done.

In the Edit Signature, HTML tab you can use the "Insert HTML" option to paste in raw HTML. Ckeditor removed the "Source" option, then later they added it back. We have a task to update Ckeditor again to re-gain this option per https://dev.blesta.com/browse/CORE-4597 Using Insert HTML, you should be able to accomplish what you want, it just isn't as convenient.

Confirmed, thanks for the report. https://dev.blesta.com/browse/CORE-4704

How are you searching the domain? What registrar module are you using? What version of Blesta? What version of PHP?

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?