Blesta 3.0: Client Groups (video)

I’ve got another video for you this week. I’ve been meaning to get something out every week, but it’s been tough. Time flies, we all get drawn into the excitement of v3 development, and I let things slide a little bit. I’m trying to reel things back in and be more regular in my posts. Let’s see how it goes.

This week I decided to make a video on Client Groups. It’s not what I was planning to do, and at first glance it seems kind of boring, but it’s not and I’ll tell you why.

Client Groups have settings, and here are a few things you’ll be able to do.

1. Invoice different groups at different times. Bill some 10 days in advance, others 5, for example.
2. Charge different groups at different times. Charge some on the day their invoice is due, charge others earlier.
3. Send payment reminders and late notices at different times for different groups.

But the really powerful thing about these settings is that they are inherited from a higher level, if they aren’t specified. By default, new groups will inherit these settings and can be specified if they should be different. Since a vast pool of options exist at a higher level, they can eventually be specified at the group level. We have only specified 3 relevant groups of settings because we believe in simplicity… but it’s only the tip of the iceberg in terms of what is possible.

I’ve said enough! Video below, there’s sound and you can make the video go full screen if you want. There might be a bit of echo in the audio, my apologies. It’s because I recorded it from my home office last night rather than at work. Not sure I’ll do that again, hardwood floors don’t exactly create the best acoustics.

---

Blesta 3.0: System Requirements

I was working on a couple ideas for a new video this week. One involved touching on a feature that we’ve previously touched on, that would show off some more advanced functionality. The other is a new feature that we haven’t shown yet, but we’re working on making a couple changes to the way it looks so I thought it better to wait.

Then, of course there is a huge new feature that I’m anxious to share.. but I can’t, just yet. Actually there are several, but one really big one that’s sure to cause some stir. Some good stir.. and it’s been in the works for a really long time.

Still, I wanted to post something.. so here are the system requirements for v3, and a question for you.

Minimum Requirements

1. PHP version 5.1.3
2. PDO, pdo_mysql, curl (version 7.10.5), and openssl (version 0.9.6) PHP extensions
3. MySQL version 4.1
4. Apache, IIS, or LiteSpeed Web Server
5. ionCube PHP loader

Recommended Requirements

1. PHP version 5.2 or later
2. PDO, pdo_mysql, curl (version 7.10.5 or later), openssl (version 0.9.6 or later), ldap, mcrypt, gmp, json, imap, libxml, and simplexml PHP extensions
3. MySQL version 5.0 or later
4. Apache, IIS, or LiteSpeed Web Server
5. ionCube PHP loader
6. memory_limit set to 32 MB or greater

You’ll notice the only loader listed is ionCube, and that brings me to the question. Do you have need for a Source Guardian version? Do you prefer it over ionCube?

The vast majority of installations are using ionCube, and most servers that would have Source Guardian have ionCube too. If there are those that really need a Source Guardian encoded version, we could continue to make those builds, but prefer to drop it in favor of streamlining our build process and simplifying downloads. A common question we get is, “Which version do I need?”. Since I don’t need to use my toes to count the number of files we’ll actually be encoding for v3, our build process should be much simpler.. even better if we can just stick to ionCube.

If you have an opinion, please email me, paul [at] blesta. com

The goal is for another video next week and I’m trying to convince Cody to do more developer commentary. Maybe he can touch on the Plugin system, it’s incredible.

Ok, back to work. Thanks for being awesome.

---

Blesta 3.0: Payments (video)

Last week I posted about Payment Accounts in version 3. This week I wanted to show you how those work when the rubber meets the road in the Staff interface. Perhaps the best new feature for Payments in version 3 is the ability to void and refund transactions in real-time when supported by the gateway.

This video focuses on..

1. Make Payment (Processing and voiding or refunding a credit card or ACH transaction)
2. Record Payment (Processing and voiding a manual payment, such as a check payment)

Payments in this version are more robust than previous versions. There’s a lot more you can do without leaving the screen, yet it’s remarkably simple and straight forward. I recommend taking the video full-screen, and be sure to turn your sound on.

---

Blesta 3.0: Payment Accounts (video)

Payment Accounts are brand new way to manage payment details in Blesta v3. In previous versions you had to create a contact for each and every credit card you added to the client. All of that has been done away with. Payment Accounts are independent from contacts and you can have as many as you want. In addition, Payment Accounts introduce 2 big new features in this version.

1. ACH Transactions
2. Offsite ACH & Credit Card Transactions

In this video, I’ll give you a preview of Payment Accounts and show you how they work. I recommend taking the video full-screen, and be sure to turn your sound on.

---

Blesta 3.0: Designing A Modular System

There are two prevailing factors that determine how well a software product can adapt, improve, and be extended without imploding in on itself. They are:

1. Coupling, and
2. Cohesion

Coupling represents how dependent a given module is on other modules within the system (I use the term “module” in this article in an abstract sense to describe an object or set of objects that are designed to accomplish some task). A loosely coupled module doesn’t rely or expose much of its inner workings to other modules. Conversely, a tightly coupled module relies heavily on other modules and may expose portions of its inner workings so that other modules may interact with it.

Version 3 of Blesta is built on top of an MVC (Model-View-Controller) framework, which, as the name suggests, separates control into three distinct areas. Building off of an MVC framework (in our case, minPHP) gives us the discipline needed to maintain a loosely coupled system. But it’s not without its challenges. For example, as I’ve mentioned in a previous article explaining data validation, error handling can be handled in a number of ways, but the best way is this through message passing. This allows the errors of a model to be accessed and interpreted without the controller having any direct knowledge of the model or how it works, and vice versa, thus maintaining a loosely coupled relationship.

Cohesion relates to how well the various functional elements of a module are related. High cohesion requires that the module be, in a sense, single-minded. In other words, a class may have high cohesion if all of its methods are closely related. Low cohesion means that a module attempts to accomplish too many tasks, or relates to multiple distinct sets of data.

When designing a modular system, we strive for high cohesion because it improves readability and comprehension of a particular module. If a module attempts too much it becomes bloated, disorganized, and difficult to maintain.

This works hand in hand with coupling. As each module becomes more refined it generally becomes more independent, or loosely coupled. A perfect example of this is the payment gateway system in version 3, which consists of four merchant gateway interfaces (Credit Card, ACH, off-site Credit Card, and off-site ACH). Each interface is designed to accomplish a distinct set of actions (high cohesion), and each payment gateway is thereby only associated with the rest of the system through the implemented interfaces (low coupling). This allows us to create a wide variety of payment gateways that can process credit cards only, or ACH payments only, or any other combination of interfaces without requiring any changes to any other parts of the system.

---