Tyson

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 }  

Blesta is trying to send an email but fails to do so because some tag in the email template is not being used correctly.
Double-check your "Service Creation" email template and how you are using the tags. If email is sent successfully for other services, then the problematic tag is probably in the package's Welcome Email section instead (which is imported into the "Service Creation" email template as the tag "{package.email_html}"/"{package.email_text}"), so edit that service's package and take a look at the Welcome Email template for both text and HTML.
Some tags cannot be displayed as written because they are not strings, and instead need to be iterated over. You should take a look at the package module's documentation for what tags are available and how to use them. For example, when using the cPanel module, there is a tag "{module.name_servers}". That tag cannot be displayed as a string since its data is an array of multiple nameservers. If you attempt to display it as written, you will receive the error that you encountered. In this example, you would use a "for" statement in the email template to loop over the nameservers as mentioned in the cPanel documentation:
{% for name_server in module.name_servers %} Name server: {name_server}{% endfor %}  

It would have to expand to the next digit.

Does the currency appear twice on the Order form, or everywhere else in the system too?
It looks to me like you are using the currency code as the suffix for the currency as defined in Blesta. You can double check under Settings > Currencies > Active Currencies > Edit (USD and CAD currencies). Do you have "USD" and "CAD" set as the "Suffix" value? Both of those currencies shouldn't have a suffix set, so leave them blank. You would just keep the setting "Show Currency Code" under Settings > Currencies > Currency Setup checked.

Linking to a product as described in the documention is what adds a product to the cart. Blesta's services have more options than I think WooCommerce products allow for, so there is additional configuration typically necessary for products, (e.g. config options, module options, addons, etc.) and what appears and where also depends on the order form used, but you can preselect most of those options and have them set in the cart per a link to the product, then the customer can fill out anything else and proceed with checkout.

You don't have to modify URLs. You will need to reissue your license though. See the documentation.

So you do not charge tax for any customers that are outside of India? You should be able to handle that by configuring your tax rules to only apply to India rather than "-- All --" in the system settings. Any orders placed by customers with addresses outside of India would then not be charged the tax.

Blesta comes with an .htaccess file in the root web directory and you should use that one. There is already a rule in it to force HTTPS and all you need to do is uncomment it to make it active.

Take a look at using the Order plugin's Embed Code field to add HTML to the footer. You can specify your JS there (i.e. Packages > Order Forms > Settings tab) and add a conditional to display content only when on the checkout/complete page. There are fields for order number and total price that you can use too, but there is no coupon code field. You could try to parse the coupon code field from the {{invoice.line_items}} if you really needed it, via other custom JS.
e.g.
{% if order_page == 'checkout/complete' %} <p>Total: {{order.total}}</p> <p>Order #: {{order.order_number}}</p> <p>Currency: {{order.currency}}</p> {% endif %}  

You may want to re-upload all files for Blesta and/or check your web server configuration. I notice that the CSRF token changes on every page load, which indicates the server is recreating a session each time. It's possible your web server does not have permission to write session data.

Take a look at using the Order plugin's Embed Code field to add HTML to the footer. You can specify your JS there (i.e. Packages > Order Forms > Settings tab) and add a conditional to display content only when on the checkout/complete page. There are fields for order number and total price that you can use too, but there is no coupon code field. You could try to parse the coupon code field from the {{invoice.line_items}} if you really needed it, via other custom JS.
e.g.
{% if order_page == 'checkout/complete' %} <p>Total: {{order.total}}</p> <p>Order #: {{order.order_number}}</p> <p>Currency: {{order.currency}}</p> {% endif %}  

Blesta follows the ISO 3166-2 standard for provinces/states for ISO-3166-1 countries, and the ISO lists the states' codes numerically where Johor is "01". If there is a better 2 or 3-character standard abbreviation, you can update the states in your system to reflect your needs better by using the States & Countries plugin.
Note that third-party APIs may operate on the use of the ISO 3166-2 standard, such as when Blesta makes payments to a payment gateway and includes the customers address with that ISO-3166-2 state code. It's possible that such APIs may encounter errors if the state is invalid.

Sure, upgrade to Blesta v4.7.0+ and ensure the Order plugin is using v2.20.0+. The domain module should then make the service's domain field available via ::getServiceName or the configuration value service.name_key.

Sure, upgrade to Blesta v4.7.0+ and ensure the Order plugin is using v2.20.0+. The domain module should then make the service's domain field available via ::getServiceName or the configuration value service.name_key.

Sure, upgrade to Blesta v4.7.0+ and ensure the Order plugin is using v2.20.0+. The domain module should then make the service's domain field available via ::getServiceName or the configuration value service.name_key.

I think the best question is, what are you intending to use the transactions for? You don't have to use a status like "Returned" if you don't want to or your payment processor does not support a similar status.
Different payment gateways provide different transaction statuses, and the statuses Blesta supports covers pretty much all of them in a generic way.
Typically:
Approved - payment received Declined - payment declined/refused Voided - payment voided/invalid Error - payment error occurred Pending - payment may be received but awaiting confirmation; on it's way; authorized but not yet captured Refunded - payment was probably Approved in the past, but has now been refunded back to the client Returned - payment was probably not Approved in the past, but any money received was returned back to the client Use, or don't use, those statuses to your liking, but "Approved" should be your successful payment received status and all of the others are not.

Declined, generally means no money in account.
Error, network issue etc
They are completely different.

You shouldn't have any problem removing mcrypt and still have your data encrypted/decrypted the same as before so long as your Blesta system key remains the same.

This is fixed in v4.7.0.

You shouldn't have any problem removing mcrypt and still have your data encrypted/decrypted the same as before so long as your Blesta system key remains the same.

The mcrypt extension is a recommended requirement, but it is optional. You can run without it.

Moving between modules would require some manual updates. I'm not aware of a utility to map from cPanel or DA or vice-versa.
You will need to make 2 primary changes:
Update the service fields (`service_fields` table in the database) saved for the cPanel services to map them to DirectAdmin in Blesta. Alternatively, you can do step #2 first and then manage each service in the admin UI to add the appropriate fields for the service. cPanel fields include: cpanel_domain cpanel_username cpanel_password cpanel_confirm_password DirectAdmin fields include: direct_admin_domain direct_admin_username direct_admin_password direct_admin_email direct_admin_ip Based on that information, you will need to map the fields by renaming the `service_fields`.`key` of affected services to their DirectAdmin equivalent: cpanel_domain => direct_admin_domain cpanel_username => direct_admin_username cpanel_password => direct_admin_password cpanel_confirm_password can be deleted direct_admin_email should be added direct_admin_ip should be added Update any of those values as necessary (e.g. if the cPanel username is different now that it is on DirectAdmin, update the value for it). The password fields are encrypted, so you can update those through Blesta by managing the service in the admin UI if necessary. Update the module row for each affected service from the cPanel module to the DirectAdmin module Making this change will only affect Blesta. You will still need to move the service yourself from your cPanel account to your DirectAdmin account Assuming you are doing a one-to-one mapping (i.e. you have 1 cPanel module row and 1 DirectAdmin module row), you can update all module rows for all services in a query: UPDATE `services` SET `module_row_id` = DIRECT-ADMIN-MODULE-ROW-ID WHERE `module_row_id` = CPANEL-MODULE-ROW-ID; Replace those IDs with the appropriate module row IDs for those modules

OpenSSL is the alternative and has been for some time, which is already a minimum requirement of Blesta.

The mcrypt extension is a recommended requirement, but it is optional. You can run without it.