It’s officially been 7 months since our last blog about FreePBX 15 titled FreePBX 15 Alpha Now Available for Testing. Less than a week later Sangoma and Digium merged. What a journey it has been since then. Our humble team expanded two fold and progress has been happening at lightning speed. Thanks to the merger I now have an office in sunny San Diego, California!
FreePBX 15
When we started the development of FreePBX 15 around September 2017 we had high hopes for a release within six months. We announced that this release would include a redesigned backup module that would no longer require FreePBX restores to be from the same version you are restoring to (meaning in the past you could only restore 13 into 13, or 14 onto 14). However, software development never goes the way one plans for it to go.
There’s been a lot of work going on behind the scenes in getting FreePBX 15 to a stabilized release that we will explain below. If you haven’t seen our most recent blog be sure to check out: Performance Improvements in FreePBX. Additionally, during this time we were also able to release our highly anticipated Zulu 3.0 redesign and Queue Wallboard commercial modules.
Backup & Restore
Since backup’s inception on Nov 7, 2005 the main purpose of the module was to be able to backup FreePBX and restore it either on the same system or a brand new system. The way this was achieved for the past 14 years was to do a complete database dump of the FreePBX system and store that in a compressed backup file.
While doing a database dump is by far the easiest way to be able to backup a system, in the case of FreePBX it because increasingly more difficult to support restores from older FreePBX versions and sometimes even restores from the same FreePBX version. The reason being that FreePBX is a modular system and modules are constantly changing database table structures. If you load the database structure for a module from version 12 onto a module in version 15 the module won’t know what to do or how to migrate and you’ll be faced with errors that sometimes you can’t correct.
What FreePBX needed was the ability to utilize the modular system already provided to it and give the power of backing up and restoring to each module. In this model an individual module would assume responsibility for backing up and restoring all of its own data. FreePBX would no longer make global assumptions about modules.
There is one drawback to this idea. Namely that there are over 128 modules in FreePBX that need to be individually updated to support the new functionality the backup and restore module provided. Early on a decision was made that there would be no default fallback for unsupported modules because doing so would land you in the same boat as before the redesigned backup and restore.(Speaking of which, if you are a developer, supporting Backup and Restore is an easy process! Checkout the developer documentation for implementing Backup & Restore in your own modules)
Additionally, it was requested that each module should also be able to deal with restoring from legacy versions of FreePBX. This creates other technical issues in that we never wanted to load the FreePBX database dump back into our database because it would blow everything away. Our team came up with a unique solution to load the FreePBX MySQL database dump back into an in-memory SQLite database to use temporarily. Each individual module is then provided a handler to talk to the in memory database to query against it and then add the data it needs to the permanent database.
After many months of work and refinement our development team successfully updated 95% of the 128 modules and we are excited to be able to release the new Backup & Restore module for FreePBX 15 to the general public. We’ve also tested a few restores from FreePBX 14, 13 and yes, even 12 backup files and they all worked, however we know that not every FreePBX system is alike so we encourage you to run restores from older versions of FreePBX and report them to our bug tracker at http://issues.freepbx.org.
Additionally, because most of the data stored from each module are text strings, backup file sizes have been reduced significantly. The files can be so small that technically you could have FreePBX email you your nightly backup. (And we provide you with that ability in Filestore)
Learn more about the new Backup and Restore in FreePBX 15 on our wiki: Backup and Restore FreePBX 15+
Filestore
Backup & Restore has always had support for Local and FTP file storage locations. About four years ago a community member submitted an Amazon S3 patch and our own Bryan Walters committed that patch to Backup & Restore. The patch allowed users to store backup packages on Amazon S3. While this worked well for a while, the original code the patch was based on unfortunately hasn’t seen very many updates and thus was hard for the FreePBX development team to maintain.
When we started the planning for FreePBX 15 we wanted to make sure that the new backup module would be able to officially support Amazon S3 through a regularly maintained library. Then we found Flysystem (Spelled correctly!).
Flysystem is a filesystem abstraction library for PHP. By providing a unified interface for many different filesystems you’re able to swap out filesystems without application wide rewrites. Using Flysystem can eliminate vendor-lock in, reduce technical debt, and improve the testability of your code.
Enter the Filestore module. A centralized place in FreePBX to manage remote or local file storage locations. Right out of the gate FreePBX File Store supports Dropbox and Amazon S3 and with demand from the community we could potentially support any other service that is a supported adaptor from Flysystem.
The best part about Flysystem is that it gives FreePBX the flexibility in the future to be able to store items like recordings, faxes and much more away from your system and into the cloud.
API
Somewhere along the road of FreePBX 15 we also decided to be ambitious in adding an official API based on GraphQL with the ability to use a normal RESTFul API as well. In doing so we added the ability for FreePBX to become an OAUTH 2.0 server for API authentication.
Adding GraphQL or RESTFul API calls to 128 modules is not an easy task. At this moment we have about 10 modules completed. Since the FreePBX API is mainly a developer resource we decided over time that we would add features and functionality as developers contribute or request them.
Learn more about the FreePBX API on our wiki: Sangoma Documentation. If you are a developer you can also learn how to allow your module to hook into API here: Sangoma Documentation
Upgrading
If you’d like to upgrade your 14 system to BETA 15, simply go to Module Administration and check online for PBX Upgrader.
If you are the type of person that enjoys using Ansible then you’ll love that we added the ability to perform upgrades using PBX Upgrader without having to go to the GUI at all.
What’s Next?
PHP 7
With the release of the Sangoma 7 Distro almost 3 years ago we are finally able to provide a modern PHP version. When we started the process of bringing FreePBX to a modern supported version of PHP we had to first go to the last release of the PHP 5.x series. Both FreePBX 14 and 15 only support PHP 5.6.x. However with the release of “FreePBX 16”, FreePBX will finally have a minimum supported PHP version of 7.3. Commercial modules will also work with FreePBX 16 without the need or use of Zend. Our team is starting on this work immediately and we hope to have something to show you in the next six months.
FreePBX 13 Support
Once we have our releases of High Availability for FreePBX 14 & 15 into stable we will be sunsetting our support for FreePBX 13, so if you haven’t already start making plans to upgrade to 14 or make a backup from your 13 system and restore that onto a new 15 installation.
Parting Words
In the next few months you’ll be hearing from me again as we release High Availability 14 and announce our stable release of FreePBX 15.
Andrew Nagy, On behalf of the FreePBX Team