Tyson

In that case, your module should set Input errors because it cannot provision the service remotely at that time. When your module's addService or editService is called, but you cannot add or edit the service, set errors and return: $this->Input->setErrors(['error' => 'Enter your error description here']); return;

I don't think the payment processors are the problem here. The error you mentioned is caused by fraud detection. You should double-check your anti-fraud configuration under Packages > Order Forms > Settings (tab). Your order rejection score due to fraud may be too low, which is denying the user from completing the order. That may be the problem. Fake email addresses tend to increase the fraud score.

There are a couple ways to include additional information in that section: Update the custom module you're using to accept that field. This is usually done if the module itself uses the value of that field for some purpose Create a configurable option under Packages > Configurable Options. Then, assign it to a Configurable Option Group and assign that group to the package. If the configurable option term/period/currency matches what's available on the package, that configurable option will be displayed on the order form.

Keeping the suspension reason saved after a service changes status was intentional if necessary for reviewing the past. It will be changed if the service is suspended again. If you're evaluating whether to show a suspension reason you should ensure that the service is currently suspended.

Thanks, I created CORE-2980 to look into this issue

You mentioned in a ticket with us that you were able to resolve this issue by deleting extraneous ACL permissions set from the stats plugin by @Blesta Addons, so I'm just posting that here in case anyone else has a similar issue.

I think you're referring to the fields required by the module, which are defined in the module's source code you're using found under /components/modules/MODULENAME/MODULENAME.php.

What are you trying to do exactly? If you're creating a new template set, you probably want to write your own JavaScript to use in the client UI. You could strip out the Bootstrap JavaScript from app.min.js. I believe everything defined before "function(t){t.fn.extend({blestaRequest:function" is related to Bootstrap.

The client-side JavaScript file was renamed from "blesta-VERSION.min.js" to "app.min.js". They're the same thing.

You may want to take a look at the tags described in the documentation for that email template. The email template can be sent with multiple invoices, so you will need to iterate over each one and can display the invoice total, e.g.: {% for invoice in invoices %} Invoice ID: {invoice.id_code} Amount Due: {invoice.due} Invoice Total: {invoice.total} Pay now at https://{invoice.payment_url}. {% endfor %}

This would best be done with configurable options in Blesta that the CentovaCast module supports for allowing listeners/disk storage to be changed. I'm not sure what the CentovaCast API supports in regards to this, but I know the CentovaCast module in Blesta does not currently support the use of any config options. If their API allows for it, the module could be updated to allow the listeners/disk storage to be updated, then you could simply allow clients to change their config options on a service in order to perform the upgrade. And if you have Queued Service Changes enabled in Blesta, those service changes can be automatically applied after payment.

I don't believe that the CKEditor, which is the WYSIWYG you added the HTML to supports iframe. It is itself an iframe and probably conflicts with iframes you add to it, and doesn't have a way of allowing you to preview it either. I noticed that there is a CKEditor add-on that supports iframes though, as described here. We can look into integrating support for that, then you can use the YouTube embed code to set an iframe using that new iframe dialog.

Make sure the directories under Settings > System > General > Basic Setup in Blesta are correct and writable. If you're not on at least Blesta v4.4.0, you should be since that tempnam notice was updated in that version per CORE-2818 for php 7.2. The H2o library will now specifically write to the system temp directory on its own. The email probably did not send because the H2o library could not save that cache file to the system temp directory and use it to perform the email tag replacement.

We have not released a build of Blesta with the new ioncube loaders yet, so Blesta currently wouldn't work on php 7.3. It usually takes a little while for everyone to catch up when there's a new software release with php. I appreciate the guide on installing mcrypt for php 7.3 though.

All text is stored in language files and can be changed there. However, links created by plugins are stored in the database, which you can update in the `plugin_actions` table. In a future update, the plugin links will be pulled from the language files.

We're going to look into it and see what has changed. It's possible there may need to be an update to the gateway in Blesta.

Blesta would log the 2Checkout IPN if it received one, but it sounds like it didn't receive one, or they didn't send one. I just tried to test this myself and I got a bizarre error page after submitting payment on 2Checkout's website. After submitting a payment, I'm redirected to an error page at 2checkout.com/checkout/purchase that shows the BoxBilling logo and displays an SQL error, SQLSTATE[HY000][2003] Can't connect to MySQL server on '...mysql.domain.com...' (111 "Connection Refused") that references our server's domain name for some reason. Do you receive an error when attempting to make a payment as well, or does it go through successfully? After payment, are you redirected back to Blesta?

Hi @rebus9, Blesta does not perform cross-domain AJAX requests without specifying the dataType option, so I don't see how the vulnerability mentioned (i.e. https://snyk.io/vuln/npm:jquery:20150627) could be exploited as it is described. Blesta, actually, does not perform any cross-domain AJAX requests at all except for one in the admin interface in order to load the "Follow @blesta" button in the Feed Reader plugin. Unless you have installed some other third-party extensions with Blesta that do perform cross-domain AJAX requests, I don't think you have anything to worry about regarding that jQuery XSS vulnerability.

Yes, there is a 30-day free trial. You can download and install the software and be generated a trial key valid for that time period. See here (scroll down a little bit). What you've described is a bit different than how Blesta operates. Blesta uses "companies" to allow for multiple brands within the software, each equipped with their own company names, logos, invoice templates, clients, etc. In your case, it sounds like you use a single client across multiple brands, while Blesta has only unique clients, even across companies. Invoices don't currently support attachments, so you would need a plugin to integrate that and its related functionality (e.g. downloading the attachments). Typically, plugins are what you want when you are integrating functionality and event-driven actions within Blesta. Modules are specific integrations with third-party services (e.g. cPanel), and gateways are specific integrations with third-party payment processors (e.g. PayPal). We generally refer to plugins, modules, and gateways altogether as "extensions", but other customizations can fall into that category as well. For domains, the integration depends on the module you're working with and what it supports. We're planning better domain support in general for Blesta in the future. I haven't heard of NAB Transact, but if it accepts payments via POSTed credit cards it can be integrated as a merchant gateway in Blesta, or if it takes the client off-site to make a payment it can be integrated as a non-merchant gateway in Blesta. Each license can only be used once in a single location. However, we will grant a development license to owned license holders, and others upon request, for the purpose of making and testing your changes in a test environment. Regarding testing invoices without emailing them, I would recommend simply not using real/live email addresses, and possibly disabling the cron from attempting to send emails automatically. I would go a step further and only use fake/test data in the test environment.

What you've described with the blank "Supported TCAdmin Servers" is typical if the credentials set on the module are incorrect. You may want to double-check the information you have set on the module and try again.

The "OrderPlugin.client.name" definition is used in a couple locations: In the client navigation When listing available order forms on the /order/forms/ URI For #2, the language is loaded from the language file, so it will appear as whatever definition you have set. For #1, the language is translated to the default language and saved in the database under the `plugins_actions` table. This navigation language does not change, or reload, unless the Order plugin is installed/upgraded, and remains static from there on. We intend to update plugins to support multi-language definitions that are pulled from the plugin's language file instead of the database, but this is not currently integrated into Blesta.

The editor is loading properly, yes. The order form's description only supports Markdown, not direct HTML, so a WYSIWYG is not usable for that field.

The issue with service options not allowing you to add an option for the Universal Module was an issue resolved in v4.4.1. You should upgrade to that version of Blesta and try again.

There are two editors available: a WYSIWYG and a Markdown editor. How the field is used in Blesta determines which editor the field supports. You can take a look at the Markdown cheatsheet to get familiar with the syntax.

You should take a look at the email template documentation for reference with what email tags are available to each template. You may also want to look at the "Additional Tags" section of the templates since the tags listed in Blesta are a subset of those that may be available to the email depending on data available when it is sent. Some email templates, like the "Invoice Delivery (Unpaid)" and "Invoice Delivery (Paid)" templates, are sent for potentially multiple invoices. Since the payment_url tag only applies to one specific invoice, the payment_url tag is attached to each invoice individually, i.e., the tag is {invoice.payment_url} when you iterate over the invoices, e.g.: If there is an {invoices} tag available, then you may have a payment_url value available: {% for invoice in invoices %} Invoice ID: {invoice.id_code} Amount Due: {invoice.due} Pay now at https://{invoice.payment_url}. {% endfor %} The "Payment Declined (Credit Card)" email template doesn't have an {invoices} tag available to it, possibly because the invoices aren't available at the point the email is sent. However, that is something we can look into adding. I'd be curious to know if others would find it useful as well.