Tyson

When does the empty error box appear? After what action is performed? Modules often display errors received from the module API, so it could be that the error returned by the API is blank. In this case, you might want to check the module logs after you receive the error to see if there is any raw error log data.

The OP's issue ended up being caused by normal markdown behavior in the creation of a header (<h2>) tag. The header font was larger and appeared bold. e.g. He had a sentence on one line immeditaelly followed by a line of hyphens: This sentence was translated to a header <h2> in markdown. ---------------------------- when the desired behavior was a paragraph followed by a horizontal rule, which requires a blank new line in between, e.g. This sentence becomes its own paragraph <p> when it is followed by a blank new line. ----------------------------

I haven't looked at the code. What does commenting out the return line intend to solve?

See the discussions here and here.

Curious, what purpose would it fulfill to have it as an option?

How are you cloning/duplicating packages/options now?

TCPDF is not a model, which is why you receive an error. It is vendor code, so you would need to load it directly. include_once VENDORDIR . "tcpdf" . DS . "tcpdf.php"; There is a TCPDF wrapper class for the invoice templates component which may or may not be useful for what you're doing.

The [billing] -> [Overview] page shows a "Billing at a Glance" widget that lists current revenues. Any type of revenue forecasting wouldn't come until after CORE-1479 as mentioned above. If you have specific expectations of what you'd like to see regarding future revenue, like the OP, that would be good to know.

I wouldn't say it'd be in the next release. An addition to the success page has not been a consideration for us yet as we have more pressing additions to get through to get to version 4.

What do you consider to be 'full support'? Stripe, like many other gateways, supports taking payment in different ways. Typical behavior is to either allow a customer to pay from your website using their API, or to pay from the gateway's website. We categorize these behaviors into Merchant and Non-merchant gateways, respectively. Blesta implements the Merchant behavior of Stripe, that is, to allow payment to be taken from within Blesta without redirecting the client to pay off-site. When a customer makes a payment, their card data comes to your server before it is sent along to Stripe. You can choose to either store the credit card information in Blesta via a Payment Account, or to store it remotely with Stripe and use a token to process payments with it in the future. In either case, your server sees the credit card number at some point. This requires you to be PCI-compliant. Blesta also stores the last four digits of it as well as the expiration date for internal use, such as to send email reminders when the card is about to expire. The person that wrote the comment you quoted appears to consider "full support" to be a scenario where card data never touches your server (i.e. PCI avoidance). This can be accomplished using Stripe.js whereby credit card data is submitted directly from the customer's web browser directly to Stripe, skipping your server altogether. Blesta does not currently integrate with Stripe.js. I have no ETA on when that may be available, but it is on our radar and you would want to follow this task for updates.

I'm not aware of any issues with Plesk 12 and the Plesk module with Blesta. Plesk maintains backward compatibility with its older versions, so even though the Plesk module in Blesta only currently allows you to select a version up to 11.5, this will work for any newer version of Plesk (e.g. 12) as well. If you are looking for the module to support features added in Plesk 12, then these are not available through the module in Blesta. Some people have experienced issues with configuring Blesta/Plesk to work correctly, however, which may be what you were referring to regarding other forum posts. You should make sure Blesta is installed on a server with libxml enabled in php and that your Plesk credentials are set appropriately in Blesta to ensure the API is working correctly. It is also recommended to have Plesk and Blesta on separate servers. If you have them on the same server, you can experience an issue where Plesk will restart itself before it is able to notify Blesta that an account was created. This will result in the account being added in Plesk, but not being synced up with the service in Blesta. See this thread.

Here are events you can tie into. Plugins can't tie into another plugin's action, but since you are looking for where another plugin sends email, you can try the Emails.send event. However, it may not contain the data you're looking for.

Can you provide an example of content you've added that resulted in bold text? You could have added two underscores to make it bold, or an email client can do so as well.

Something like that could be shown to the client on the success page. I believe the data is available to the success page template, so it could be included.

There are always bugs somewhere, but none that I'm aware of that are caused by something in v3.5.2. Here's a list of recent bugs.

Invoices can't simply disappear. They may have changed statuses, like being marked closed when they are paid. It would be useful to know what happened to the first invoice, and what date the second invoice was created, and whether it is for a service or a recurring invoice so we can determine why it was created.

If you use the Portal plugin (installed by default), an "Order" link will appear on the index page that you have Blesta installed under. You can set that link up to default to the client registration form by setting it as the default order form under [Packages] -> [Order Forms] -> (Settings tab). If you want the client login page itself to have a link to register, then this would require you to update that template file. You can find it in /app/views/client/bootstrap/client_login.pdt. You can then add HTML to set a link to the client registration order form. Note that you have to maintain this core file change after each upgrade of Blesta, or it may be overwritten.

What version of Blesta and the SolusVM module are you using? In v3.5.1 of Blesta, a bug was fixed that addressed an issue with service upgrades not processing because a setting was not being observed. If this bug is what you're experiencing, you can either enable the company setting "Queue Service Changes Until Paid" under [settings] -> [billing/Payment] -> [invoice and Charge Options], or you can upgrade to v3.5.1+. Afterward, the pending service changes should be performed via cron. If that doesn't solve it, there is something else going on, such as an error being encountered when Blesta tries to provision the service changes.

Make sure Zlib is enabled in php. That blank page is likely due to an error. You can enable error reporting to see it. In /config/blesta.php, change the line: Configure::errorReporting(0); to Configure::errorReporting(-1); The error would help diagnose what's really going on.

One of these reasons caused the redirect: The ticket is assigned to a client. -- The client must be logged in to reply. The ticket's support department only allows clients to reply. The SID was not given or is invalid.

You can link to a specific product, but there is no URL that would auto-select configurable options apart of that specific product. That may be a good feature request, though. I like the idea of linking directly to a product with each option selected.

Can you elaborate on the exact issue? Can you give an example? Invoices are generally sent a number of days before a service renews. This may be what you are experiencing, which is normal behavior based on your Invoice and Charge Settings under [settings] -> [billing/Payment]. Note that those settings can be overridden by client groups under [settings] -> [Client Groups] -> (Edit).

The error "Register is in an invalid format" is not a message that Blesta displays AFAIK. Is that the exact error? I see you are using custom client fields. You have one disabled. That might be the issue.

This is what you should do.

A credit is the sum of all unapplied transaction amounts on the account. If you want to remove a credit, I would suggest voiding/refunding the transaction(s) from whence it came. No need to create an invoice to apply the credit to, as that may indicate revenue received for tax purposes, which may not be the case.