Tyson

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 direct_admin_ip field is expected to be set to what is stored in DirectAdmin. To update those in bulk, you would need to write a script to query Blesta for all DirectAdmin services, get their usernames from the service meta data, then fetch them from the DirectAdmin API using the CMD_API_SHOW_USER_CONFIG command by their username to retrieve information about the user, including the IP address. Then the script can update the service meta data in Blesta with an IP address for each user.

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.

It sounds like you may not have installed his "CmsPages" plugin. He linked to it above in one of the posts.

One case may be that you were trying to apply 120000 even though only 119999.78 was available to apply from the transaction, so you received the error about trying to apply more than was available.

The video shows some odd behavior. Is this online for me to test out an order? I would recommend trying it in a different browser, one you are not logged in as an admin with, and to ensure your browser session is clear before starting the order process.

That's interesting, a transaction for 120000 won't apply to a total of 120000.. something I'll need to test myself.

Blesta always needs to check you have a valid license. If you decide to sell it to someone else later, why should your copy of it continue working? I don't play the lottery, but if I did, it wouldn't change anything. There may be more money to spend making it better though.

I would need to know how you have the order form configured to be more specific, but it looks like you are using an order form that always has one of the products selected, so one will always be displayed in the cart (the one with the green "Selected" button at the top of your screenshot). You can change the order form type to try alternative order forms.

In order for a gateway to appear on an order form, you need to do the following: Ensure the gateway is configured to accept the currency you're using on the package (i.e. NAD) Edit the order form (Packages -> Order Forms), and at the bottom, make sure that the gateway you want to use is selected Note: Payflow Pro doesn't support the NAD currency, so that is probably the reason it does not appear on the order form for you.

What is the precise invoice total? It says 120,000, but it sounds like there may be a non-zero decimal value added to it, e.g. 120000.0001. If the invoice was partially paid from a separate transaction then that could contribute to a total value that contains a non-zero decimal value that accounts for that discrepancy. In Blesta v4.7.0, we've updated amount rounding to use the currency's defined precision so issues like that shouldn't arise again.

Is there an open invoice for the service? Services are provisioned automatically if the associated invoice is paid, or if there is no open invoice associated with it.

You'll need to escape characters for JSON when entering them manually. In your example, the backslashes should be escaped: /((?=.*\\d)(?=.*[a-z])(?=.*[A-Z])(?=.*[\\W_]).{6,18})/i

In the Universal Module, you can define service options, which are fields that customers can enter when they order a service. You mentioned using regular expressions to validate the input, which you can do by defining them in the "Input Rules" section for each of your fields as described in the Universal Module documentation. e.g. { "hostname":{ "valid":{ "rule":["matches", "/^[a-z0-9]{1,24}$/i"], "message":"Please enter an alphanumeric hostname between 1 and 24 characters in length." } }, "password":{ "valid":{ "rule":["matches", "/^[a-z0-9\\!\\@\\#\\$\\%\\^\\&\\*\\(\\)\\+\\_\\-\\=]{10,24}$/i"], "message":"Please enter an alphanumeric password between 10 and 24 characters in length. You may also include any of the following characters: !@#$%^&*()+_-=" } } } My example does not enforce a minimum 1 lower case character, 1 upper case character, or 1 digit, but you can update the regular expression to whatever you need.

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

Custom formats can require custom logic to format them correctly in the system. We would prefer to have a known list of formats. It looks like there aren't that many formats, so we can add any others like "####,##". It does look like the formatted currencies displayed in HTML should be set to LTR whether the document is RTL or not. I think that would be a nice addition since HTML documents cannot determine whether it should do it or not if the currency format has a space in it like "# ###,##".

You use "####,##" but your accountant doesn't accept it because it really should be "# ###,##"? The only currency formats I'm aware of are listed here, which Blesta supports. If the problem is the display in RTL HTML documents, what if we treat just the currency format as LTR? So instead of seeing "586,12$ 1" you will see it as "1 586,12$" even when the rest of the document is RTL. Would that work?

The issue is a bug with TCPDF. See here. They have not yet included a fix in TCPDF. You could fix this in your installation by updating /vendors/tecnickcom/tcpdf/tcpdf.php:6849 by commenting out the "return false": if (!@TCPDF_STATIC::file_exists($file)) { return false; } to if (!@TCPDF_STATIC::file_exists($file)) { //return false; } Note: I did not investigate what, if any, issues may arise because of this work-around. I would consider updating Blesta to include a downgraded version (v6.2.19) of TCPDF for the last known working copy except that a security vulnerability was fixed in the same patch release as this issue.

It sounds as though a payment is being attempted without using an off-site payment account. I just took a look at that third-party gateway and their github, and it appears to support off-site CC and ACH payments only. If you're encountering this problem, make sure: you are using the latest version of their gateway that the payment account in Blesta for that client is actually stored off-site Blesta makes this determination by saving a `gateway_id` value on the payment account stored in the database (e.g. `accounts_cc` table) If clients had created a payment account in the system prior to you switching to the Stripe (plus) gateway, then that is probably the cause of the issue--i.e. the payment account was originally for a different merchant gateway, not Stripe (plus). Their payment account should be updated, or a new one added to replace the existing payment account that is not currently being stored off-site with Stripe.

I just tried testing that myself by sending 2 invoices from a client profile in the admin UI. Both invoices in the invoices.pdf file display my logo and background. What settings do you have set? I tested with these settings: Logo: JPG Background: JPG Paper size: Letter Invoice Template: Default Font family: dejavusanscondensed Terms: (none) Display on invoice: all checkboxes checked Have you tried using a different logo image? If so, does the logo appear then?

Does the logo appear on all pages if you "View" the invoice (i.e. download it)? Viewing the invoice produces the same PDF as is sent by email. I tested this myself a minute ago and it is working correctly for me.

The module really should make several attempts at generating a username if one is already taken before it fails in Blesta. I've created CORE-3225 to look into adding that behavior.

Blesta doesn't come with a ClientData plugin, which explains why it was not in your new installation of Blesta. It looks like your ClientData plugin is a third-party plugin from @Blesta Addons. You should contact him if there are any compatibility issues.

The admin route you have set conflicts with other routes in the system, which is why you encounter that behavior. We may be able to resolve that issue though, which we will look into shortly. Thanks!