Paul

Are you running the official support manager plugin that we ship with Blesta, or the modified version? Have you changed anything, like the date/time format in the settings, or upgraded/downgraded anything on the server?

Most people are running older versions of the Ioncube loaders, and PHP 5.5 supported builds of Blesta are not backwards compatible with these legacy loaders. Additionally, Blesta must be encoded for PHP 5.3 or 5.4 support in order to work with PHP 5.5, per this thread on Ioncube's forums, quoted below -- But, the minimum requirement for Blesta is PHP 5.1.3, so we have been releasing builds that are compatible for the majority (PHP 5.1.3 through 5.4.x), but not compatible with PHP 5.5. Adoption rates for PHP 5.5 are increasing, and we recognize the need to support it. At this time, due to Ioncube's limitations, we would be required to have 2 separate builds in order to support PHP 5.1.3-5.4.x and PHP 5.5. We are releasing this hotfix to allow PHP 5.5 support for Blesta 3.1.2. The zip contains only the 3 files we encode, to protect licensing. If you are not running Blesta 3.1.2 DO NOT apply the hotfix. blesta-3.1.2-php5.5-hotfix.zip If you are doing a fresh install, first download blesta-3.1.2.zip and overwrite the files in 3.1.2 from the hotfix above before attempting the installation. If you are planning to upgrade your existing server to PHP 5.5 and have Blesta 3.1.2 installed, overwrite the files in the hotfix above after you upgrade your PHP.

I've created a task for it, CORE-1091 and it can be tracked there. It is tentatively assigned to v3.3, but it's not guaranteed to be in that release.

Added as CORE-1090

We have had a similar experience. We operated as a sole proprietorship for years before incorporating and it was never an issue, customers never brought it up except to ask for W-9's and issue 1099's. Running a sole-prop in CA can be the absolute best option for a small business. We're incorporated in California and have to pay $800/yr, every year to the state, not counting taxes on profit. That's the cost of admittance, and many small businesses can't afford it. There are lots of reasons why a business may want to be a sole-prop, LLC, S-Corp, or C-Corp. My suggestion is that anyone starting a new business should do some research, understand the different legal entities and make a decision that is in their best interest. What is best for one person isn't necessarily best for another, but if you understand your options you can make a better decision.

There will always be bad players, whether malicious or negligent. Unfortunately, it will result in calls for government regulation. Rather, I suggest people do their research on exchanges before doing business with them, and diversify. Never put all your coins in the same place. Don't leave large deposits in exchanges, transfer them out into wallets you control. Never use a hosted wallet.

My recommendation is to start local. Friends, family, local businesses. Treat them well and they will tell other people. Do not underestimate word of mouth. You won't see results overnight, but you're building a lasting business, right? People like to do business with those they feel like they can trust, and people trust their friends advice far more than a Google ad (Don't advertise on Google).

We are aiming for a beta in a matter of weeks.

Mike, did you change your invoice draft format? DRAFT-{num} is the default. I'm still not able to duplicate this in my environment, can anyone else confirm?

It's unresolved, but it's currently a blocker for 3.2. I discussed this one with Cody last week, and he seemed confident that it wouldn't take much time to implement and that it is likely to be included in 3.2. This is assigned to CORE-852 and can be tracked there.

Interesting idea. I think this would work better if services were displayed on their own page though. In the future, I'd like the client area to be more customizable, staff can determine which widgets should be displayed as well as which pages. Then, the services widget could be disabled, and a services page could be enabled that categorizes them by group and has more advanced filtering options.

If it needs to appear on all invoices, you might consider putting it in the Terms section. Settings > Billing/Payment > Invoice Customization.

Is that the only error? Normally this error will occur because of a previous error being output to the browser first.

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.