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.

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.

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.

i18n, or internationalization, is the process of adapting software to be deployed around the world. Since version 1.0 we’ve dedicated a large portion of our time to making Blesta an international product. And in version 3 we’ve gone even further by enhancing our multi-language support.

To start, you’ll notice language definitions are now diffused across multiple files. This serves two purposes. First, it promotes congruency between objects and their associated language (each Controller and Model has its own language file). Secondly, it allows us to load only content that is relative to the resource being requested. This saves memory, speeds up load times, and makes development much easier.

Syntax support has also been greatly improved. Previous versions supported tag replacement, but many phrases and sentences were graphed or concatenated together. This meant that some translations were left with incorrect syntax or awkward phrasing. We were able to do away with that thanks to minPHP‘s Language support.

Here’s an example, flashing a success message after having saved a staff group:

<?php
// Success
$this->flashMessage("message", Language::_("AdminSystemStaff.!success.group_updated", true, $this->post['name']));
$this->redirect($this->base_uri . "settings/system/staff/groups/");
?>

Here’s the related language definition:

$lang['AdminSystemStaff.!success.group_updated'] = "The staff group, %1$s, has been successfully updated!";

And the visual result:

In addition, version 3 offers automatic fall-back language support in the case of missing definitions.

And finally, we’re introducing translation support for modules, gateways, plugins, and widgets. Everything is translatable. Let’s see how long it takes the competition to catch on.

In this developer commentary, I give an in depth look at how AJAX events are handled in version 3 and how you can include them in your own widgets or plugins.

The technology employed here allows us to seamlessly update the state of the browser when performing AJAX requests. This permits the user to navigate using the browser’s back and forward buttons while at the same time offering backward compatibility with normal requests for the same resource.

The context of this video is technical in nature and best suited for viewers with a strong understanding of PHP, minPHP, javascript, and jQuery.

Click the icon in the bottom right of the video player to go full screen.