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.

---

Blesta 3.0: Full Featured ACL (video)

ACLs (Access Control Lists) allow refined control over resources in Blesta v3. There are a few notable differences in the way ACLs are implemented in Blesta vs other applications.

1. Plugins can easily register resources into the permission system to be controlled within the Staff Groups settings page for seamless integration.
2. The permission system automatically ties into the primary and secondary navigation elements, so even custom controllers can take advantage of the ACL.
3. The ACL library can be invoked directly for even more refined control. You can design your own hierarchy of permissions and explicitly deny or allow any resource.

In this video, I touch on some of the basics. The ACL currently has 87 resources, but we’ll likely have over 100 in the initial release for the core. The Order and Support plugins will add to that.

---