Paul

Turn on error reporting and see if an error is output To enable error reporting, edit /config/blesta.php and change Configure::errorReporting(0); to Configure::errorReporting(-1);

Maybe you need to put the full path to your php in there? ie /usr/bin/php or /usr/local/php?

MariaDB definitely looks promising, time will tell how close they stay with MySQL compatibility-wise. But, if anyone finds an issue with it we'll do our best to correct it.

As we continue to grow, there will be more trolls, it's how they operate.

Email sales and we can issue you a new trial key. Actually, I'll PM one to you.. one moment.

It can happen, and probably will, but it's not as likely as the other guys due to our code base and build process.

Anyone else find this to be a useful addition? Personally, I like the idea of custom client fields being available to invoices. I can see many cases where these might need to be displayed on an invoice. I'm just not sure the Terms section is the best/only place for them. The alternative would be a much more complex system, whereby invoices can be customized by drag-n-drop of elements, allowing custom client fields, and default fields to be placed visually. This scenario is much more involved, and less likely to happen soon, but it's certainly a possibility.

There's something in the works via a third party that would effectively add this, among other things, but this could be a good standalone option as well. Do you want this to appear in the client area, related to a specific service? ie, a dedicated server? If you can provide more context, it may help moving things forward.

What about the "Billing at a Glance" widget under Billing > Overview. We could detect if the PayPal gateway is installed, and add an option in here to display the balance. *Potentially EDIT: Or, a new PayPal plugin that registers a widget for display on the billing overview, or dashboard.

Maybe you can clarify PCI levels. I understand PCI Level 1, 2, 3, 4 to be largely based on transaction volume. See http://usa.visa.com/merchants/protect-your-business/cisp/merchant-pci-dss-compliance.jsp. Levels 2-4 require the annual SAQ and quarterly network scan. Is this what you mean? If you are a Level 4 merchant, based on your transaction volume, you still have to fill out the SAQ, and get a quarterly network scan. I think the question is, what exactly is the difference in terms of what you have to do by using stripe.js versus passing the data through without storage. If all merchants must fill out the SAQ, and get a quarterly network scan for PCI compliance, and using stripe.js does not exempt you from these requirements, what is the difference?

I predict that in the future, stripe.js and other javascript implementations will no longer be exempt from PCI. While the card details technically don't touch the server, the server is responsible for serving the markup. An attacker with access to the server could modify the javascript in order to intercept those details.

You make good points.

I think what he's saying is that most of the PCI requirements are related to infrastructure. We're not saying that you're off the hook from such requirements, you're certainly not if the card data touches the system in any way.

I don't believe so no, you might start a new feature request thread. Rather than HTML, we would be more likely to accept markdown syntax... that is, if it's feasible. Because our invoices are not generated from HTML, it would probably be some subset of markdown.

Patches are cumulative, you can install the 3.1.2 patch on 3.1.0 or 3.1.1. The patch includes 3.1.1 in it.

@iamp, fair enough

It requires PCI compliance, sure. I agree that pass-through maintains that requirement and I understand and acknowledge the benefit and need for the stripe.js implementation.

There probably should be something in the documentation to indicate which API it implements. I don't understand what you mean by "isn't fully tokenized" though. Blesta does not at any point store sensitive card details for Stripe, just the token. (Unless configured to do so instead of tokens). The contention is the pass-through of card details. It's still tokenized, it just isn't using stripe.js to keep your server from seeing those details when the payment account is initially created. The result is that Stripe works a lot like Authorize'net's CIM method. As far as I know, there is no stripe.js equivalent to Authorize.net CIM. There's less risk than storing card details, but some risk because of pass-through, and a requirement for PCI. Cody will have to comment on the design aspect of a javascript implementation.

Stripe is a merchant gateway and does not work like PayPal at all, so it's not possible. A payment account exists in Blesta, and Blesta makes the necessary API calls to Stripe when it wants to charge a card (and passes the token). Allowing Stripe to inject javascript code in the process means that a feature is necessary by which all merchant gateways could do the same.

The Lounge is the best place for this.

Yes, please start a new thread in the feature requests forum.

Check out /components/invoice_templates/default_invoice/default_invoice_pdf.php, lines 15-30. I wonder if we should allow the font size to be set in invoice customization.

There is a known issue where going to /admin/upgrade can cause an error and prevent you from running the upgrader. It has to do with maintenance mode being enabled. You may run the following via a shell to upgrade with maintenance mode on.. php ./index.php admin/upgrade Or, disable maintenance mode and try again via /admin/upgrade in your browser. See CORE-1081 for details on this bug. It is resolved and will be in the next release.

I thought we were keeping the thread fresh. Come to think of it, this is in the wrong forum. </closed>

There are others successfully running Blesta on Windows, and we're committed to fix any issues that arise on that OS. Still, we recommend Linux over Windows.