Tyson

Not that I know of. I think someone was working on this before, but I don't know if anything came of it:

If AUD is available for Square checkout, you can update the currency list in the gateway file under /components/gateways/nonmerchant/square/square.php to add AUD similar to the others.

You can create a plugin that registers actions which will appear in the navigation as described in the documentation.

The response you received indicates the resource at that API URL was moved. You may want to take a look at updating the module's configured Hostname and Port as I suspect that one, or both, of those fields no longer comprises the correct socket to the API end-point. Typically, the API URL is something like "https://domain.com:8083/api/" where "domain.com" is the hostname and "8083" is the port.

It sounds like the problem is that the email they receive is an HTML version, and the password contains a special HTML character, "<", which begins an HTML tag. The HTML renderer takes "<" and everything after until a closing ">" character to represent an HTML tag, and that is not shown as text to the user. If the user views the Text version of the email, however, they should see the password correctly. If you want to resolve the password truncation issue in the HTML version of the email, the password itself should be escaped for HTML. To do so, you will have to update your email template. There is a tag in the email template that represents the password, like "{password}". Change that tag to "{password | escape}". Then, those special characters, like "<", will be displayed correctly and the entire password will be visible. Just set that for the HTML version of the email, not the text version.

I'm not sure about that particular issue, but the system tries to maintain data integrity by forbidding deletion of certain records, like packages, when services exist that reference them. We plan to update this to allow a soft package deletion when services still exist, canceled or otherwise.

Sounds like a DNS issue then since it's working with IP instead of hostname?

When you setup a package for the module, and you see no templates loaded from VirtualMin, you should take a look at the module logs. There may be an error with the API request described there which could point you toward the issue. Since you moved to a new server and changed the VirtualMin module settings, it's possible the module connection details are no longer valid, or that the new server cannot connect to the VirtualMin server due to a configuration issue such as a missing permission, non-white-listed IP, lack of support for TLS 1.2, etc.

Yes, that is possible. You will need to add this logic into a plugin that creates a daily cron task. When that daily cron task executes, you can check for services whose renew date is the same as its cancelation date minus 1 or 3 days. Then you can send an email about it, presuming you have created the email template to send as you described in your other post.

You can send email in multiple ways through a plugin, such as via a cron task or view a controller action in the UI. If you want your plugin to create email templates, you need to create an email group and an email template for that group during your plugin's Install and/or Upgrade methods. Be sure you also remove those email templates/groups on uninstall. It's the plugin's responsibility to manage its own data. I recommend you take a look at an existing plugin's source code to see what a working implementation looks like, such as the Support Manager plugin.

For any module, it is expected you have an account with that third-party service. In this case, you need to have a VirtualMin account to resell from. You enter your VirtualMin credentials to that account in Blesta and then you can create packages that clients can order.

To add to what Jono said, the permission system is generalized to entire resources (e.g. /clients/). If you give staff access to clients, they can see all clients. There is currently no mechanism to limit staff to access only certain clients based on some criteria. However, if you create a plugin, you can setup plugin events that listen for an event like the AppController.preAction event that is called when someone views a page, and your plugin can perform logic to determine whether this is a staff user and whether they are viewing an appropriate client they have access to or not, and redirect them elsewhere if necessary.

If you run the cron manually with error reporting enabled, do you receive a stack trace too? If so, that would be useful to see as well.

That's a bit of a strange one since the line referenced is 0. My guess is that you may have a cron task running via CLI that tries to read from the Session without initializing the Session first (i.e. assuming it is already loaded). Do you have any custom cron tasks in your system? Perhaps some created by plugins/modules? One of those may be the cause.

Did you update your mail settings in Blesta to connect using the details for the new host? Same with the cron job on the web server?

Enable error reporting in Blesta and then try to duplicate the white page. That page should show the errors that are occurring. Be sure to disable error reporting after you are done testing. Since you moved hosts, the new host probably does not meet the minimum requirements to run Blesta. You will need to have your host install whatever extensions are missing once you determine what those are.

It looks like the API for your module is not responding appropriately. First, it's returning HTML, and second, it's sharing an error and stacktrace because something is wrong with the CWP server. This issue isn't caused by Blesta, but by the server it's attempting to connect to. You should look into that CWP server and resolve the error that's mentioned because it's not running correctly. Type: ErrorException Code: 8 Message: Trying to get property of non-object File: /usr/local/cwpsrv/var/services/api/v1/index.php Trace #0 /usr/local/cwpsrv/var/services/api/v1/index.php(0): Slim\Slim::handleErrors(8, 'Trying to get p...', '/usr/local/cwps...', 0, Array) ...

You should keep the currency's precision to whatever precision (i.e. digits after the decimal) the currency operates under. Like USD, AUD has a two-digit precision and should be left at 2. There will be cosmetic rounding errors since rounding has to occur for each item when displayed, however, the total should be accurate as it sums up the total amounts before rounding. Blesta doesn't currently support "inclusive" prices, if that is what you expect (i.e. that tax is derived from the total price you enter). Instead, tax is added to the price provided. So, a 10% tax of 9.05 is 0.905 (which rounds to 0.91) would give the total 9.05 + 0.905 = 9.955 (rounded to 9.96).

I don't recommend testing on a live environment. An additional company in Blesta wouldn't suffice for this purpose. If you have an owned license with us, open a ticket from your account and request a development license. You can use a development license elsewhere for testing purposes on a non-production server.

The error indicates it is missing the port field on the module row object. This port field should be set on the module row when you save it. From your screenshot, that is the "API Port" field. However, you get an error about the connection failing to be established. Can you check your module logs to see if there is an entry that begins with "<yourdomain>|validate_connection/packages_get"? That log should contain some information on the API request that failed to validate the connection. This is the reason for the port error as well. The port is not being set on the module row because you cannot successfully save the updated module row information. Once the connection issue is resolved the port error will go away.

It looks like it's available here, and the changelog says it is compatible with php 7.3. I can't comment on php 7.4 as it was released not very long ago and we haven't yet checked compatibility with Blesta.

You'll need to utilize the help of a web developer to integrate it into your Wordpress site in whatever fashion you intend to use it in.

You should enable debugging in Blesta and repeat the steps you performed to generate that error again. It would be useful to know what file/line number that error occurred on to help identify the issue. Make sure you've uploaded all the files for the CentOS web panel module, and that you've upgraded it in Blesta (also that you've upgraded Blesta by running /admin/upgrade/ in your browser if you haven't already). The module should be version 2.1.0. By default, the login port would be 2031 and the API port would be 2034. Yours are different, so you may want to double-check that yours are correct. FYI, the CentOS Web Panel module was updated to use their new API in v4.8.0.

Blesta doesn't currently have a generic domain availability checker for you to integrate with in other systems. Currently, domain lookups are done using a specific module in Blesta (e.g. Enom). What you can do is use the Blesta API SDK to call ModuleManager::moduleRpc to check a domain's availability, e.g.: // Load the API SDK require_once "blesta_api.php"; $user = "username"; $key = "key"; $url = "https://yourdomain.com/installpath/api/"; $api = new BlestaApi($url, $user, $key); // Choose one of the domain registrar modules from Blesta to use to lookup domain availability $module_id = 1; // set to the module ID of the domain module you want to use, like Enom $module_row_id = 1; // set the specific module row ID from the module that you want to use $domain = "google.com"; // the domain to check for availability $response = $api->get( "ModuleManager", "moduleRpc", ['module_id' => $module_id, 'method' => 'checkAvailability', 'params' => [$domain], 'module_row_id' => $module_row_id] ); // View the response from the check if ($response->response() === true) { // The domain is available } else { // The domain is not available }

The user packages are accessed via CMD_API_PACKAGES_USER. Do you get a response in your browser with that command? If not, then there are no user packages in DA or there is some configuration/permission issue in DA for that command.