Paul

We aren't going to convert file based templates to database based templates.

If you modify a file in Blesta, then upgrade Blesta by uploading the files over your existing install, then yes, it would be overwritten. This is why I suggest creating a NEW CSS overrides file. This way, all you have to do is add back your include in structure.pdt which would take all of 1 minute.

So an option when editing an Addon Package Group, to only allow it to be added to an existing service? Meaning, you could not buy it during order form checkout, but only after the parent service has been provisioned?

It's likely there will be an option to add custom CSS or JS via the UI, near "Settings > Company > Look and Feel" in the future, but it's not a high priority right now.

In an ideal world, it would be great if everything was open and audited with our seal of approval. Because Blesta is extensible, 3rd-party developers can create their own extensions. Those extensions are therefor their own intellectual property. So, they can choose to license it how they wish, encode it or not, have it audited or not, etc etc. If we were to put strict rules on 3rd-party extensions, it would result in fewer such extensions being available and still be no guarantee that the ones available, and audited, with our seal of approval could never be exploited. There is some risk with any software, so it's up to people to assess that risk and make decisions on what to use. I like the idea of an optional, paid "Certified by Blesta" process for extensions, because it's voluntary and ensures people that the code was reviewed by Blesta developers and meets our standards for security or code styling. This can add value to 3rd-party extensions by creating a level of trust with users, but there would be a cost associated and it wouldn't make sense for obscure or open source extensions. "Certified by Blesta" is not something we would require though, because it would have a negative impact on the availability of extensions. We want to make it as easy as possible for 3rd parties to create more extensions, not less.

"Deliver Invoices" and "Create Invoices" are different. The Create Invoices task actually generates the invoice, via recurring services or recurring invoices. Deliver Invoices actually sends it, as is the one that runs every 5 minutes. Create Invoices runs once per day. I hope that makes sense and glad that it seems to be working for you now!

Merchant payment gateways do not show the name. For example, the customer will never see "Authorize.net", but rather "Credit Card". So, I see this exclusively for non-merchant gateways, and the example of showing simply "PayPal" instead of "PayPal Payments Standard" and "Bitcoin" instead of "Bitpay" are excellent examples. If we have to localize the names of gateways, then that sort of pushes us toward language files. I'm not convinced that gateway names like "PayPal" or "2Checkout" translate well into other languages. Are they not known by their names in other languages? The simplest solution is to be able to set a single name to "override" the build in gateway name. So, for non-merchant gateways, we could potentially add a new field when managing the gateway called something like "Display Name", which would default to the gateway name. For PayPal, this might say "PayPal Payments Standard", but could be modified to say anything you want. Thoughts on this kind of implementation?

It doesn't matter if it's in public_html, because the subdomain will have its own docroot. I suspect the redirect is happening outside of Blesta.

Do you think the name the customer sees should be part of the language file, included with the gateway? Or should you be able to specify the name manually when configuring the gateway? I'm not sure most gateways would need to be translated. Authorize.net, PayPal, these names are universal are they not?

Make sure the paths are correct under Settings > System > General. Make sure there are no other .htaccess files that may be creating a loop scenario.

Nice work, looks really clean!

See CORE-2295 and let us know if you have any suggestions on how we can improve the task.

I like it, congrats on the new display name! Blesta Addons

Yes sir it should! Please feel free to test it out on the v4 beta if you have the time to do so.

So, Proforma invoices should not be calculated in the outstanding balance, the same as planned for "Pending" invoices, aka invoices with future bill dates? Please confirm, and I'll modify the task, assuming this is a standard requirement. It seems to make sense, since it's not forcibly due.

I would enable error reporting in /config/blesta.php (change error reporting from "0" to "-1" value). Then, disable the cron temporarily, and run it manually when the next backup should be processed. Settings > System > Automation. It may output more errors. If the issue is only when your CLI/cron environment runs it, and not via Web, then you can execute the same cron command via SSH/CLI instead.

The License Manager for licensing your own software is a paid addon ($100 one-time), which you can add to your owned license by clicking Manage next to your license in the client area, then Addons on the left, then select it from the drop down. Once purchased, you'll have access to it within the Downloads section where you can grab it and install. The mass mailer plugin is included in 4.0, and is part of the current 4.0.0-b3 beta release. It will not work on 3.6, but you can try it out on the beta.

See CORE-1805. As of 3.6.0-b1, scheduling cancellation for a parent service, should automatically set the same cancellation date for addons.

Looking at the gateway logs, was the first attempt the successful one for the full amount? After that, the gateway would normally (for authnet anyway) return a duplicate transaction error. Your logs would be most helpful in determining what may have happened here.

Yes, they would necessarily have to be able to see a history of all their orders. Do you think this is best as a new widget on the client dashboard, or better as a new page? Could be a dropdown option under the new "Order" nav link in the client area, that shows "Order History" or something. They could view all orders, and cancel only incomplete orders. Thoughts?

Thanks Mike, I'll just add, re #2. We can audit the code for a module or plugin for a fee, and label it as "Certified by Blesta". We haven't done this yet for any 3rd party extensions, but we're open to the idea. Re #6. Maybe. This would be on a case-by case basis. But, in large, our recommendation is that the developer release the extension as FOSS on Github.

Please post beta bugs in the beta bug forum - https://www.blesta.com/forums/index.php?/forum/37-bugs/

I highly recommend running Blesta separately from Wordpress, on it's own VPS at a subdomain if possible. The security issues prevalent with Wordpress make your customer data in Blesta less secure when under the same account.

CORE-2230 has nothing to do with invoices generated by the order system. It has to do with pending invoices. When someone places an order, an invoice is created, not a pending invoice.

Did this resolve it? A seg fault is unusual for such an issue (assuming google was rejecting the logins). If it continues to happen, I would suggest disabling the cron temporarily and running it manually after enabling error reporting. You might get more information about the error, though no guarantees with seg faults.