Paul

Blesta Addons has been a bit non-responsive, we're not sure what happened to him.

We have a task to more fully automate this and someone will be looking at it soon. It will require an update to Blesta, so it would be part of a future release. In the meantime, if you know your license key you can reach out directly and request that any hostnames be added or removed from the license.

Interesting, I'll mention this. I think the IP address is required as part of the API call. Perhaps the IP should be defined on the server/module row rather than the Package, in which case it would use the IP as defined there. Is there ever a need to select a different IP for the same server between Packages? That would be the concern there. The alternative at the moment, would be to select a server instead of a group for the Package, but obviously this would have to be updated more frequently.

We have a task CORE-3942 to allow a single login to access multiple accounts. This has not been in high demand, and the inability of a client to use the same username for multiple companies is not a bug. We'll take another look, it would be a nice to have feature. Would you be interested in sponsoring it?

We've created a task for this, see https://dev.blesta.com/browse/CORE-4756

Hi Barry, when emails are generated are they queued for delivery? If you edit the invoice, is the Email box checked? If you aren't able to check quickly after they are created, you can create a manual invoice. Do the invoice emails appear in the mail log under Tools > Logs > Email? Are you using Sendmail or SMTP for outgoing email? Settings > Emails > Setup If an invoice is queued for delivery, then marked as sent, then most likely an attempt to send it was made and did not return an error. If you are using as SMTP server and the messages are being filtered out or rejected on that side quietly, then that could explain it.

ini_set is called throughout Blesta and in vendor code for legitimate reasons. In your case, /vendors/minphp/session/src/Session.php ini_set is used to set session variables. As far as I know, this has not changed recently, so it may be that a change to PHP 8 is responsible. We would probably recommend not disabling ini_set, but @Jono may be able to take a look when he has some time.

Yes, they would be able to request a payout when their balance meets your minimum requirement for a payout for matured funds. This is pretty common to have them make the request. In the future we may tie in an outbound payment option(s), after which automatic payouts might be a good feature.

When affiliates reach the minimum payout amount you set, they can request a payout. The payout request would be available under Clients > Affiliates > Payouts. Not currently, but the current version of the affiliate system is the initial release for the most part and we are open to adding additional features and improvements. You can make a request at https://requests.blesta.com for a specific feature You can create whatever payout methods you want, so yes, Venmo would be an option. Payouts are made manually after you receive a payout request. To add payout methods, go to Clients > Affiliates > Payment Methods and add 1 or more options.

Do you mean each TLD? TLD pricing is set individually per TLD under Packages > Domain Options > TLD Pricing. Just click Edit next to the TLD. If you mean giving 1 customer a different price than the TLD, you can set a price override for them.

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?