Tyson

I think we'll just need to keep an eye on this one for now. From my testing, the license validates successfully and updates the license data as expected, so there are no required license validations when logging in for me. There could be another use case that triggers it though.

Are you using the SDK from the API documentation? It will do this for you, but @activa is correct that you should pass your data through http_build_query() if you do it yourself.

No, not for proprietary software. We have a number of extensions available on github already that are licensed under MIT that can be contributed to.

I've created CORE-3182 for this addition, but it wouldn't be in v4.6. We'll need to consider how best to add that information for addon services and then it can be scheduled for a future release.

We have a task to add a hostname field, CORE-2287, but it will not likely make it into v4.6.

CORE-3181

The license check occurs automatically apart of cron without setup on your part. So long as you have the cron job setup to run all tasks (i.e. the command "/path/to/blesta/index.php cron"), the license check will run too. If you encounter a license check on log in, it's because the license data in your system is old. I'm not aware of an issue with this behavior, but I can take a look to see if the license check can fail to run automatically which may account for why it does it on log in for you.

There are some tutorials online that illustrate how to setup a cron in cPanel, like here.

Multicraft should have updated the IP address to coincide with the appropriate daemon and returned it in the last step. Should the port not be "25803" and IP "88.198.15.249" in your example? Your logs look accurate to what I would expect.

Do you have a cron job setup to run all tasks automatically? The system will attempt to revalidate the license by cron, but if it hasn't done so in a while it will also do it when you log in. It also checks other license information like companies and whether the license has changed, which needs to occur periodically regardless of license type.

The Cron Command is an example command derived from what Blesta knows about the system it is installed on. It is not a setting that controls the cron or relates in any way to an actual cron job. A cron job would need to be setup on the server separately (e.g. through cPanel). The Cron Key is a unique key you can use to run the cron manually in Blesta. It should be kept secret so that others cannot run the cron. It is not required when a cron job runs via CLI mode, but it is when you click the "Run Cron Manually" button as shown in your screenshot. I would recommend you do the following: Click "Generate Code" to create a new cron key. Click "Update Cron Key" to save that change. Create a cron job on your server. This is done outside of Blesta, typically through a control panel (e.g. cPanel) or via command line. This is where you would set the frequency to 15 minutes, and you can use the example "Cron Command" as a reference to what to set for the cron job. The "Cron Command" field in Blesta will still show 5 minutes (i.e. "* /5 * * * *") because it is only an example. Verify the cron has been running successfully by checking the last run time for automation tasks under Settings > Company > Automation.

That's a very general question, but everything comes down to the specifics. You will need to have a module in Blesta that can interface with the API in that control panel to manage those domains, then you need to create package(s) in Blesta that use that module and create services from those packages, for each client, to set information about their domain so that the module can interface with it automatically. You haven't identified the control panel you are using to manage your registered domains, so I'm not sure if there is a suitable module in Blesta for you to use already, or if you will need to create one.

Do these Chinese translations differ from what's on translate.blesta.com?

Extending the container has been available since v4.0. We just happen to use it for v4.6. I suspect you can extend the container from wherever you'd like (although I have not tested that), but it is better to extend it as early as possible in execution or it may be possible for some places to have already used the value before you override it.

The language for those definitions are under /languages/en_us/navigation.php (Navigation.getprimarypublic.nav_dashboard) and /languages/en_us/app_controller.php (AppController.client_structure.text_login)

Interesting. You can extend it by calling the container's ::extend method, e.g.: $this->container->extend( 'minphp.constants', function ($instance, $c) { return array_merge($instance, ['WEBDIR' => $instance['WEBDIR'] . 'fr/']); } ); There is an example in Blesta v4.6 that does this to override a few of the services for the application.

We haven't yet added a blacklist feature to do that. You would have to update Blesta source code to add that behavior yourself. At minimum, update the Contacts model to add an input validation rule against the email address that checks whether it matches certain domains you want to block. Then no user matching that domain could sign up successfully.

I'm curious to know what the reason is behind overriding WEBDIR? Adding a new constant for your case would not suffice? Also, you can override WEBDIR by extending the container.

You can update the package's Welcome Email to include that information. In case you need to see what data is available as tags, you can include {% debug %} in the email template and send yourself the email. It will list all the data available as tags. However, that should be used exclusively for testing only since tags can include information you do not want anyone else to see, like values for company settings.

Do you have a link to their API documentation? If their system will observe that 'virtualserver_autostart' option and not let the user start a suspended server, then we can update the module to add service suspensions/unsuspensions as you have.

That's strange. I don't encounter that issue when a space exists before null. Must be something with the context. I'm glad you were able to figure it out though.

Glad to hear it. What error do you receive? null is a valid argument to Date::__construct: public function __construct(array $formats = null, $timezone_from = null, $timezone_to = null)

I recommend you don't override containers, but extend them instead.

Do you have COREDIR defined in /core/ServiceProviders/MinphpBridge.php? It sounds like it's missing.

Cancellations typically remove the account from the service, so it would make sense for the canceled service to delete the server on Teamspeak. It doesn't look like the Teamspeak API supports any type of service suspension, so the module doesn't support suspensions in Blesta. What is the behavior you are expecting?