Tyson

As @activa mentioned, you update the language files in the Order and Support Manager plugins under /plugins/ on your file system. You can also translate them from https://translate.blesta.com, or download your language from there, and modify the files to include your definitions in those plugin directories.

It sounds like Blesta sent the proper information to cPanel, but did not get a response, and has been waiting for one. It's possible there was a response, but there was an error encountered before the response could be logged and the service activated successfully in Blesta, so you may want to check your logs for any errors around the time that Blesta sent that request.

I think with whatever system you go with you are going to run into this problem. Migrating between billing systems is usually supported, but migrating data from a module, like Plesk, into a billing system is usually not supported. A script could certainly be written to perform this migration, but Blesta does not currently have an automated way of creating Blesta clients and services from Plesk data. We don't recommend having Plesk and Blesta on the same server for the same reason that Plesk will restart before notifying Blesta that it provisioned a service, and so Blesta will never know about it. With the graceful restart function enabled, I haven't encountered any problems, but if you search the forums you may find some that have issues and others that don't. I'm not sure I fully understand the issue with creating users, but that may be a limitation of WHMCS. Blesta usernames and Plesk usernames are typically different. If you intend to use the Plesk account's username as the Blesta client's username, that is certainly possible assuming there are no other users in Blesta with the same username. As mentioned above, I am not aware of any third-party Plesk importer, and Blesta does not provide one. The current Stripe payment gateway does not use tokens. This is largely not a problem, but apparently there is a setting in your Stripe account that needs to be checked in order to accept payments in this way. Blesta does not include an OpenSRS module, but there is a third-party integration of it. I have not used it. Yes. A service can be prorated on order (e.g. to the first of the month) as defined on the package template. Services are also prorated when you upgrade/downgrade to another term or package. This depends on what you mean by "immediately". Blesta does not install a daemon on the server, so it does not spin off separate processes to run immediately. Instead, services are provisioned by cron, which you setup on your server to run every 5 minutes. Therefore, a service can be provisioned automatically within 5 minutes. You can have orders wait for manual review if you would like, but that is configurable. I hope that helps.

The Cron Command field shown in Blesta is a generic command based on the server's operating system that you can copy and use to define the cron job. The actual command that will work on your system may vary depending upon your server environment, and where you define the cron job depends on your environment as well. For example, if you have cPanel installed, you can create cron jobs easily through their interface. See the documentation.

Since the voided invoice is an unpaid invoice, it sends that email template. You can update the email template if you'd like to be more specific. For example, since that email template accepts multiple invoices, you might check that the status of the first invoice and set the subject conditionally: {% if invoices[0].status == "void" %}Invoice Voided{% else %}Invoice Due{% endif %} I did not test this, so you should before using it.

Thanks, I think that would be a useful addition. We'll look into it for CORE-3066.

The module allows you to specify a port, but only a single port, not a port range. You can still set multiple ports on a single IP to use as multiple dedicated IPs though.

If you're trying to use the API to fetch a non-merchant gateway's payment HTML, see Payments::getBuildProcess as @coreyman mentioned above. The arguments required are the method's parameters. If you are making a merchant CC payment, look at the other end-points available on the same page.

Output is the information received from the gateway. In your example, 2checkout sent information that appears to be for a refund, not a payment. Was that refund issued from within Blesta? Do you have any error logs that were for a failed payment transaction?

The problem is that you are trying to access the /cart/ URI on an AJAX order form template. The AJAX order form templates don't have a cart template because the AJAX template represents a single page that makes AJAX requests for most of the checkout process (including the cart), so there is no cart page. I'm curious how you got to that page, though, are you linking directly to it? If so, take a look at how to link directly to a product. If you want that link to work, you can update your order form to use one of the Wizard templates instead.

Have you tried to enable error reporting in the blesta configuration file (i.e. set Configure::errorReporting(-1); and Configure::set('System.debug', true); in /config/blesta.php)? Afterward, you should see an error on the blank white page.

Can you click on the table row representing the gateway log? There should be more data about that transaction that may tell us why it was an error.

I left a detailed response to exactly this question yesterday

I think what you're referring to with regards to the "select" module group is apart of an issue we resolved in CORE-2244 and CORE-2292. There shouldn't be an issue with modules because of it, but you're welcome to create a bug thread if there is something amiss that we should look into.

It sounds like you want to POST each form to a separate location. <?php // POST to the valid method $this->Form->create('/validate/valid/', [...]); ... $this->Form->end(); // POST to the index method $this->Form->create(null, [...]); ... $this->Form->end(); Your Validate::valid() method really shouldn't require an argument if you want to POST to it

Your example mixes procedural and class syntax, so I'm not sure if you're running individual functions or if those are methods in a class. If you are writing procedural functions, simply: return success(); otherwise for one class method to call another non-statically: return $this->success();

Depending on the configuration, you will likely need to reissue your Blesta license to the new domain/location. If the credentials are all the same. There is a README file included with Blesta that describes how to upgrade. The upgrade documentation is also useful. Here's what I would recommend in your case: BACKUP YOUR BLESTA INSTALLATION AND DATABASE (especially /config/blesta.php) Put Blesta in maintenance mode Disable your Blesta cron job Download and upgrade to v4.0.0 as an intermediate step. This is mainly due to there being a lot of changes between v3.6.2 and v4.4.2 to make in one big leap. I would recommend upgrading via CLI mode (instead of /admin/upgrade in your browser) so that the upgrade process cannot time out in the web browser. Upload the contents of the "blesta" directory The upgrade documentation will be helpful to review. There are files you should delete as well, mentioned in the note at the top of that page. Some people have problems if those files remain after upgrade while most others do not. Run the upgrade script (via CLI is preferred) Check your Blesta installation to make sure it is working normally on v4.0.0 Backup your Blesta installation and database again, now for v4.0.0 (You can perform the server/cPanel migration here, or later at step #12-13) Upgrade your server to use php 7.2 (php 7.2+ is only supported on v4.4.0+ of Blesta) Ensure php 7.2 is installed for both CLI and web Download and upgrade to the latest version (currently v4.4.2) - via CLI mode is recommended over /admin/upgrade in your browser Since you are on php 7.2, you will need to overwrite a few files from the "blesta" directory with all the files in the "hotfix-php71" directory. You will receive ionCube errors if you do not do this Upload the contents of the "blesta" directory, which now contains the overwritten files from the "hotfix-php71" directory Run the upgrade script (via CLI is preferred) Check your Blesta installation to make sure it is working normally on v4.4.2+ Update configuration settings, like cron jobs and email templates, if necessary, since many changes were made since v3.6.2 Backup your Blesta installation and database again, now, v4.4.2+ Perform your server/cPanel migration as necessary Be aware that changes to your Blesta location (e.g. by domain or subdomain) may necessitate that you update any third-party configuration to point to the new location. e.g. PayPal IPN URL Log in to your account with us, or your reseller, and reissue the license Click to "Manage" the service representing your Blesta license, check the "Reissue License" checkbox, and submit Visit your Blesta installation at your domain and log in. This will complete the license reissue at your new domain Re-enable the Blesta cron job and observe that it runs tasks as shown on the Settings > Automation page You may need to reconfigure the cron job to run at the new location if it has changed Disable maintenance mode

cPanel (and essentially all other systems) will not send notifications to services (like Blesta) regarding a password update made through their system. If the cPanel password needs to be changed, then the user should: Change it from within Blesta, or Update it in Blesta after having changed it in cPanel

There are two separate calls you need to make: Create a ticket (as @Jono mentioned above) Create a reply for the ticket (as you did in your OP). FYI the first question from a customer that opens the ticket represents the first reply

You mentioned a potential bug. I'd be curious to know what the issue is so we could resolve it if necessary. I suppose it must be

Using config options will probably be more difficult since it uses pricing and needs to be set based on the service's term/period. There is a lot more complexity in config options compared with universal module product service fields. The universal module looks for fields in a meta array. It does not use configoptions, since those represent different data entirely. For example, if you are creating a universal module product, under the "Service Options" section you can set fields. I could set a "Hostname" Label with a "hostname" Name of the "Text" Type. The Name field represents the key for that option, and the value entered by the customer is that key's value (e.g. 'hostname' => 'mydomain.com'). When you add this through a call to Services::add() in $vars, it would look similar to: $vars = [ 'client_id' => 1, ... 'meta' => [ 'hostname' => 'mydomain.com' ] ]; $services = ...; // set to an instance of the Services end-point $services->add($vars);

Yes, you can disable it similar to what is shown above in the configuration file using the plugin controller and method. But since it's in your plugin, you can always disable it from the source by calling Form::setCsrfOptions prior to Form::create, e.g.: $this->Form->setCsrfOptions(['set_on_create' => false]); $this->Form->create();

You should contact that module's developer for help since we have no Namesilo module.

The UTC timezone offset shown in Blesta comes from php's timezone database. You may need to update php to use the latest timezone database if Casablanca is no longer accurate because of a change in policy regarding the timezone.

Are you referring to the plugin's cron tasks being active, or the plugin's cron task being run? Blesta doesn't run plugin cron tasks if the plugin is disabled. I think this has been the case since at least v4.3.