Since its initial stable release in December 2013, the Joomla Framework has steadily grown to better suit the needs of the Joomla ecosystem, providing the backbone of Joomla installations worldwide. The work that has been done on this small portion of the Joomla codebase has been extraordinary and lays the framework for an even more powerful Joomla 4.0 release. Today we would like to share an update on the state of the Joomla Framework and our intentions for it moving forward.

Background

It wouldn’t be appropriate discussing the future without first understanding its past and what has brought it to the state it is in today. The Framework evolved as a “soft fork” of the previous Joomla Platform, the set of core libraries which have been powering Joomla itself since 2005. Though this was seen as a controversial move at the time, over the years this has proven to be a valuable move for the codebase as it has enabled developers to pay off much of the technical debt that had accumulated in the core libraries without being disruptive to the primary CMS distribution, as well as enabling new features to be developed and tested in real life applications before being introduced into the CMS. The downside of this separation has been that much of the Framework code has now been duplicated and maintained separately, resulting in bug fixes and improvements only being made in one source. Thanks to this separation, community members have been able to introduce several major architectural improvements into the core APIs, changes which are being added to the Joomla 4.0 release.

In 2016, the Database package was updated to provide full support for each supported database driver’s prepared statements integration, a major security enhancement over the existing API and a standard feature in any database abstraction layer in the PHP ecosystem. This effort hadn’t been attempted previously for the full package due to the API’s support of the now deprecated mysql PHP extension, but the support was designed into the API when PDO based drivers were added to the Platform and Framework. However, the initial release of this full implementation had several oversights that weren’t accounted for which have called for additional architectural changes and improvements in the database API to address issues with each driver’s underlying implementation and to provide a consistent API, work which will enable Joomla 4.0 to fully support and use prepared statements in its database queries.

Since work first began in 2015 on the Framework 2.0 packages, a lot of effort has gone into improving the Framework’s code and offerings (both as a standalone set of packages and as an API which would be the foundation of Joomla 4.0). In addition to the database API work, we have introduced a new Console package leveraging Symfony’s Console component which allows Joomla developers to build well integrated command line utilities into their extensions and applications. Additionally, the Framework offers a Dependency Injection Container allowing for application dependencies to be centrally managed and is now being used to reduce the hard coupling between various elements of the Joomla API, allowing advanced integrations where core components can be replaced with a custom implementation. Our Session package was overhauled to address several architectural concerns in the class designs resulting in an API which can be fully tested.

Current State

During March 2018, the 45 individual Framework packages reached a milestone of having a cumulative one million downloads. Several of these packages have been well received, accounting for over 90,000 downloads each, while other packages not being as popular and have less than 2,500 downloads. This indicates there are some things we have done well while there are other things which may have been well intended but didn’t work out, and we aren’t afraid to admit that not every idea works and some will ultimately fail. Likewise, some of our packages have been well maintained (in some cases owing in part to their use within the CMS), and other packages have received little-to-no attention, and this can be used as an indicator of our resources being spread too thin or a lack of interest in those offerings.

Much of the development focus has been on the 2.0 branches of our packages, taking the opportunity to optimize our code for our PHP 7 minimum requirements or to experiment with (and implement) architectural changes improving the usefulness of our packages. As pointed out earlier, this has resulted in several much needed improvements which will benefit the Joomla community over the years to come, and we are proud of our efforts to continually grow and improve. However, we have also grown enough to see that the Framework has lost some focus and that there is a need to re-analyze our current and future efforts.

Moving Forward

After analyzing the current state of the Framework, what it is we are offering, the resources available in the PHP ecosystem, and the resources available within the Joomla community to maintain the Framework, we have made a decision to deprecate several packages (in addition to the existing deprecations of the Compat, Form, and Log packages).

• All API connector libraries except the GitHub connector - These libraries have essentially been abandonware since the Framework’s initial stable release, receiving few downloads over the years or minimal maintenance focus; the GitHub connector is excluded because we are actively maintaining this package and use it quite consistently in our tooling across the project
• The DateTime package - Much of this package’s functionality is now encompassed in the Carbon library
• The Date package - This subclass of PHP’s DateTime is quite useful in the CMS environment where date/time strings are commonly localised and translated, or for quickly converting a DateTime object to a SQL formatted string, however these capabilities were removed from the Framework package and again the Carbon library has become a viable replacement
• The Cache package - Even though this has been an actively maintained package supporting both PSR-6 and PSR-16, we have found that it is not within reason to be able to integrate a PSR compatible cache package within the CMS because it relies on functionality that is not supported by either PSR and in essence requires that we maintain two caching APIs; we would rather focus on supporting one and therefore the CMS implementation will be that package, especially given the number of well supported packages in the PHP ecosystem
• The LDAP package - This has been a package where support and maintenance have been minimal and its internal API design is reminiscent of the PHP 4 times it was written during, we recommend Symfony’s LDAP component as a replacement

Another point of focus that we have been working to improve upon is the documentation of the Framework packages and having resources to help users get started building applications upon the Framework. We have established a standardised documentation structure for each Framework package which sets the minimum structure for what requires documentation (thus far this primarily focuses on the 2.0 upgrade documentation and package overviews, though some packages also have feature guides or example guides on using various classes), and as the Framework 2.0 release draws closer this work will be integrated into the Joomla Framework website.

We are firmly committed to creating a strong foundation for the future of Joomla development and feel these efforts will best help us utilise our existing resources and bring in new contributors more easily than before.