Tyson

The license is unable to validate because you changed its location. You should login to your Blesta account with us to reissue your license, or contact the reseller you bought the license from to ask them to reissue the license for you.

Take a look at this thread. It may just affect the sandbox API.

FYI, docs on the cPanel welcome email tags can be found in the documentation.

A task has already been created to support this behavior, but it has not yet been completed. See CORE-1269.

Correct. The only place you could define icons in the interface is via the Portal, because you can set your own HTML there to define them yourself.

Icons shown in navigation links in the client interface are defined in /app/models/navigation.php. In the admin interface, they are set in the associated template where it is displayed.

What is shown under [Tools] -> [Logs] when you click on the table row related to the service being provisioned with GoGetSSL?

The Tax ID is not required. And as mentioned, can be removed using a setting available in v3.4.0.

The way orders 'In Review' are handled was updated in v3.3.0. You may want to upgrade Blesta to ensure the behavior you're experiencing hasn't already been resolved as apart of CORE-1370 in v3.3.0.

It's possible, but it's not natively supported. It would require you to make core changes, which will be overridden during upgrades. You would need to maintain the changes in your installation. Amounts are displayed in several places across the admin/client interfaces, but for brevity I'll give an example of one place on the Wizard order form. The other order forms (i.e. Standard/AJAX) would need to be updated similarly. This example will change the price display on the Wizard order form's drop-down menu for Term and Price. This will show prices using the per-month price rather than the price for all months combined. Open /plugins/order/views/templates/wizard/config.pdt Find (line 37): $prices[$price->id] = $this->_("Config.index.package_price", true, $period, $this->CurrencyFormat->format($price->price, $price->currency)); Replace with: $amount = $price->price; if ($price->period == "month" && $price->term > 0) $amount = ($price->price/$price->term); $prices[$price->id] = $this->_("Config.index.package_price", true, $period, $this->CurrencyFormat->format($amount, $price->currency));

The system settings nav was updated in 3.4.0-b2 to use the marketplace URL from the config file, however, the value in the config file is not set until v3.4.0. The message you received should have been a PHP warning--not an error--so you may not have been able to view the links because of your error reporting level.

Ensure your Root Web Directory setting ("/var/www/domain.com/billing/") is indeed the full path to Blesta.

The {client_url} reflects the location of the Blesta client area. Since you setup an alternative subdomain that redirects to that location anyway, you could either leave the email templates alone, or manually update them to your subdomain.

The first way is the correct format: {service.options.options1}

What do you mean the footer doesn't stay at the very bottom of the page? If the page height is short, the footer will begin where the content above it ends, whether that's in the middle of your browser window or not.

Here's a breakdown of the flow for manual service approval: Under [Packages] -> [Order Forms], every order form should have the option checked for "Require Manual Review and Approval of All Orders". When a user places an order, whether they pay for the service or not, the order is "In Review", and no action is taken to provision the services ordered. To manually approve an order, you mark it as "Accepted" in the Order widget under [billing] -> [Overview]. The status then changes from "In Review" to "Pending". When the invoice for the order has been paid, if not already, it will be activated. The status will then change from "Pending" to "Active". It's important to note the subtle difference between "Pending" and "In Review" statuses. A pending service can be activated automatically once paid while one in review cannot. If this is not how orders are working for you, then there is something amiss, and we'd need to know more about your settings, and version of Blesta, to help diagnose the issue.

Typically, a cron task that has been executing for over 60 minutes has actually stalled. This may be because an error occurred when attempting to process the task. As Licensecart mentioned in his link, a button will appear after some time that will allow you to reset the task. Otherwise, the task will be attempted again 6 hours later, automatically. I would recommend updating your config setting to enable error reporting by updating /config/blesta.php and changing error reporting at the top of the page to: Configure::errorReporting(-1); Then clear the cronk task when the button appears next to it. Immediately afterward, run the cron manually from [settings] -> [system] -> [Automation]. The output of the cron should be displayed, along with any errors that may be encountered.

If the service renew date (as shown on the invoice) doesn't change, what exactly is being billed for? Are you asking for a way to generate an invoice for a service before an invoice is automatically scheduled to be created for it?

The data sent for each action don't need to, and often can't be identical. It's not data inconsistency because it follows functional logic in that each action itsef returns the same output for the same input. But as you mentioned, there may be some fields (e.g. service_id) that may be available for use throughout each action. That's something we'll need to look into and will consider it from your feature request. In the meantime, I'll close this thread as not a bug.

Can you add any more information for this report? Have you experienced the issue again, or determined the cause? Can you provide steps to duplicate it?

I'm aware of this design limitation for plugins. It's something we'll need to discuss internally. In the meantime, I'm going to move this to the Feature Requests forum.

Unless you can confirm that the email address belongs to a valid domain when you encountered that error, I would chalk this one up to normal behavior. As Paul already mentioned, an email address must both be in a valid format, and pass a DNS lookup.

Thanks for all the info. The issue will be fixed in v3.4.0 (CORE-1528).

Thanks. This has been fixed for v3.4.0 in CORE-1528.

If PayPal supports additional currencies beyond that which the gateway currently claims to support, please open a feature request and include a source reference to the most up-to-date list of currencies.