eddieajau/composer_for_Joomla_4.md Secret

## composer_for_Joomla_4.md

      
    Raw
  

              composer_for_Joomla_4.md
            
          
    RFC ??? - Composer driven distributions for the Joomla CMS

Executive summary

This paper proposes that Composer can be used as the basis for re-engineering the Joomla CMS into discrete packages that can be assembled in various combinations to form a "distribution" of the Joomla CMS.
Preamble

Composer is a robust and reasonably well established method for distributing libraries or "packages" within PHP community on a per-project basis (as opposed to PEAR which distributes libraries on a per-server basis).
The Joomla CMS can be thought of as just a collection of discrete "packages". Currently those individual packages, which would include groups of related extensions, consists as a single, monolithic and exclusive offering to the Joomla community. However, it is impossible to suggest that a one-size-fits-all approach works for all users within the CMS community, whether completely new to using a CMS or a veteran.
The question of "what extensions are best for X?" is also commonly posed. To help answer that question, the author proposes that the Joomla CMS be broken up into discrete packages of functionality, and then reassembled in different combinations to be known as "distributions".
A distribution is simply a recipe for the extensions, or packages of extensions that are to be included within the initial installation of the Joomla CMS. One could draw the analogy that extensions could represent "songs" in the music industry, packages represent "albums" and a distrubution representation a custom "playlist" that someone has compliled for a particular purpose. In a similar fashion, a manifest of extensions and packages could be created that has an affinity for a particular type of web site (a blog, a small business site, an e-commerce site, a church or other social organisation, and so on). Anyone should be able to devise a distribution, although the Joomla project will undoubtedly prepare a few official suggestions, and obviously maintain some of the most critical elements that would represent the DNA building blocks of a Joomla CMS website.
To that end, Composer could be used as the vehicle for installing the packages that would form a distribution manifest. Packagist.org could host the directory of the individual packages that can be brought together to form a distribution of the Joomla CMS - at least those that are already hosted on public source repositories. Additional thought needs to be given to how commerical packages could be included within distributions but that is beyond the scope of this paper at this time.
Composer "projects" could be the vehicle for defining the distribution manifest and possibly be hosted on Packagist directly.
Composer itself would be included in a core set of tools that would run parallel to, and eventually replace, the existing extension installation system in the Joomla CMS (providing the eventual problem of file-based installation is solved).
Advantages:

Composer is the main installation engine which cuts down on com_installer code, at least for pulling and pushing files around. Composer could be extended to install from file as the Joomla CMS currently handles them.
Extensions can draw on any dependency available to Composer.
Source git repos can be downloaded.
Developers can easily create distributions off any repository, even forks of the official ones.
Code like DI from the Joomla Framework can just be included via the Framework's distribution channels. No need to add it to the equivalent of /libraries/.
It is much easier to source additional third-party dependencies (for example, Monolog).
It is much easier to blend older style Joomla code with newer PHP libraries (for example, the DI can be sourced directly from Composer rather than including it manually in the monolithic source tree).
It makes it very easy for testers to build a distribution themselves.
It could standardise how extensions are managed across the community.
A new major version (Joomla CMS 4) is a good time change the way things are done.

Disadvantages:

It's going to be different from how Joomla is normally done.
Extension developers may push back at having to build a different type of package for Joomla 4 (but this can be automated).
It disadvantages developers that would not want to use Github for source control.
It favours free and public extensions. Additional work, and possibly investment, is required to support commerical extensions.

Distributions as Composer projects

A typical distribution, modelled as a Composer project, could look like the following:
project
|- administrator
|  |- index.php
|- bin
|  \- jools.php
|- installation
|  |- index.php
|- media (etc)
|- src (custom PHP)
|- scripts
|- vendor
|- index.php
`- composer.json

Almost all of the PHP code would end up living under /vendor/ (created by Composer and not part of the distribution itself). Custom PHP code that was specific to the individual distribution would live under /src/.
In this example, /bin/jools.php is the command line administration tool for the Joomla CMS.
A composer.json file for a distribution could look like:
{
  "name": "joomla-cms/cms-distro-alpha",
  "type": "project",
  "description": "The most basic distributions of the Joomla CMS used to custom build itself.",
  "keywords": ["joomla", "cms", "content management"],
  "homepage": "https://github.com/joomla-cms/cms-distro-alpha",
  "license": "GPL-2+",
  "minimum-stability" : "beta",
  "support" : {
    "issues" : "https://issues.joomla.org",
    "wiki" : "http://docs.joomla.org/Distributions:Alpha"
  },
  "require" : {
    "php": ">=5.3.10",
    "joomla-cms/cms-site-application" : "dev-master",
    "joomla-cms/cms-platform" : "dev-master",
    "joomla-cms/cms-cli" : "dev-master",
    "joomla-cms/cms-admin-application" : "dev-master",
    "joomla-cms/cms-installer" : "dev-master",
    "joomla/di" : "1.0-beta2",
    "monolog/monolog" : "1.6.*"
  },
  "autoload" : {
    "psr-0" : {
      "CMS\\" : "src"
    }
  }
}
Possible "editor's pick" distributions

cms-distro-core      - The basic project from which all other distributions would be derived.
                       Basically a self-installer.
cms-distro-classic   - All the features of 3.5
cms-distro-lite      - A <em>WordPress</em> like distribution, stripped down specifically for blogging.
cms-distro-developer - A distro tailored for developers developing J4+ extensions
cms-distro-rest      - A RESTful version of the CMS

There is nothing stopping a distribution from including un-official packages that do not live in the /joomls-cms/ organisation. For example, Akeeba could refactor Akeeba Backup the Composer Way and a distribution could automatically include it.
There is nothing stopping anyone form producing un-official distributions.
Any other code that is available via Composer is immediately available to the distribution builder. A good example would be for a distribution to add logging support with "Monolog" (for code elements that support PSR-3). Joomla 4 could even replace more atomic packages like cache with the counterpart in the Joomla Framework.
It's likely that the JED (with a question mark above what to do with templates - are they not extensions?) could form the basis of user-generated, and even official distribution manifests.
Extension Packages (Composer Libraries)

Extensions get installed in /vendor/ and they would use Composer scripts to do anything special (a standard set of them will probably be developed).
A typical extension package could look like:
package
|- src
   |- com_foo
   |- com_foo_admin (?)
   |- mod_foo
   |- plg_system_foo
   |- languages
   |  |- en-GB
   |- media
|- scripts
\- composer.json

Here, extensions are flattened because the distrinction between front-end and back-end should be made at the application level, not the extension level (it should not care what type of application is using it). Where possible, just one type of extensions would be encouraged but we'd have to support a type of back-end version so that developers could literally just copy folders around to make the new packages.
Possible packages

/cms-site-application    - The front-end application
/cms-admin-application   - The back-end application
/cms-install-application - The CMS installation application.
/cms-cli                 - command line tools
/cms-platform            - /libraries (Joomla code, 3rd party use Composer normally)
/cms-installer           - the main build to help the CMS "build thyself"
/cms-extension-manager   - the rest of com_installer
/cms-templates           - template manager
/cms-modules             - module manager
/cms-plugins             - plugin manager
/cms-languages           - language manager and all multi-language extensions/cms-cpanel
/cms-fof
/cms-categories
/cms-tags
/cms-configuration
/cms-users
/cms-articles
/cms-cache
/cms-help
/cms-weblinks
/cms-banners
/cms-search
/cms-smart-search
/cms-tinymce
/cms-media-manager
/cms-menus
/cms-two-factory-auth
...
/cms-isis-template
/cms-protostar-template
/cms-beez-template
/cms-jquery (?)
/cms-twitter-bootstrap2 (?)
/cms-twitter-bootstrap3 (?)
...
(near or distant future)
/cms-discussions
/cms-ucm
/cms-jed-checker
/cms-developer-tools
/cms-social-tools
/cms-ckeditor

Intelligent succession management

Packages can be used to provide an intelligent approach to succession management for extensions. Or, to put it another way, how to gracefully retire packages and extensions designed on older architecture. For example, an "Articles" package could be built using the existing com_content components and the associated modules and plugins. A "UCM" package could be build, based on the new Joomla Framework, as the ultimate replacement for the "Articles" packages. Distributions could include one or the other or both depending on what a user wanted.
Versioning

All packages would follow their own versioning scheme based on semantic versioning. Any special versioning rules (such as how to define Long Term Support or LTS, or how to deal with an increment in the major version number) is beyond the scope of this paper. However, as an example, it should be possible to create a distribution with fixed versions of packages with the full degree of flexibility that Composer allows (see version constraints).
Updating distributions

Distributions themselves would not be updated. The packages and extensions that were installed in the intial distribution would update in a similar fashion as extensions would be updated today, just as would be the case for any new packages or extensions added to the distribution after the initial installation.
Future considerations

The scope of this paper is simply to establish that Composer is a viable tools for creating customised distributions of the Joomla CMS. This is but one part of many that needs to be solved and further discussion is required on the following topics:

How to handle the installation of media in the correct place under the web roots.
How to optionally install PHP libraries off the web root.
How to build a distribution without an administrator extension.
How to gracefully resolve dependency conflicts.
How to cater for commercial packages within a distribution.
How the community would actually be able to specify distributions either via a joomla.org UI or, for example, a special extension within the Joomla CMS that allows you to "save this site" as a distribution (an ideal candidate for a developer distribution of the CMS).
How to handle end-of-life for packages.
How to "approve" new packages that can be maintained under https://github.com/joomla-cms.
How to deal with distrubtion "profiles", that is, the starting data and configuration that is also required for a distribution to be truly useful (and taking that thought further, it could also be possible that single distributions could have multiple installation profiles, much like we have a selection of "sample" data to install with the Joomla CMS today).