By Private Profile c2e15406 on 2015-09-02 00:00 in Joomla X Architecture

Odense (DK), fri 2015-07-10 - 2015-07-12



name   status
andrew eddie   virtual-parttime
chris davenport   attending
george wilson   attending
herman peeren   attending
marco dings   attending
michael babker   virtual
nicholas dionysopoulos   attending
niels braczek   attending
robert deutz   not


As we are divide up in the most unfortunate way in terms of time zones, we will have toendure some repeating/ summarising and furthering of discussion.
We shall try to fit andrews into slots as early as possible in the morning. Michael will chime in during the day and hopefully we can have some overlap with the both of them.

We are all strong and passionate individuals we can discuss in the same way. However respect one another and realise that this sprint is not about winning a personal victory its a bout a victory for the group, with the potential unfortunate consequences for some of your own points of view

These minutes are tailored to tthe working group which is why they are at a highly technical level. Should you whish clarification contact me ( marco dings ) on glip


Leave after 3 days with a tangible plan of attack in the form of a decission register and basic plan.




Morning 8:30 - 12:30


  • Inidividual presentation of thoughts for architecture, unbiased timeslots fro everybody to present and talk

    • andrew eddie
    • marco dings 
    • chris davenport
    • george wilson 
    • herman peeren
    • nicholas dionysopoulos
    • niels braczek
    • michael babker



  • Discovery of topics to cover
  1. target audience
  2. supported features
  3. implementation
  4. timeline
  5. architecture academic
  6. architecture practical
  7. min php version
  8. Namespacing
  9. Mvc architecture
  10. not touching on interface
  11. ucm, refactor remove/refactor/keep
  12. multilingual remove/refactor/keep
  13. custom fields

Early Evening

  • Prioritisation and planning of topics for the sprint






Wrap up discussion.

  • write up / finalise up plan and actions
  • revisit timeline decision


  • wrap up

  • Decision register

  • Design for change

    Decisions and goals are to be considered tentative. They were made with the knowledge of the day and may be subject to change with progressing insights.

Who do we serve stakeholders and users.


Focus on User roles

i. User roles

        1. Site builder / Integrator

        2. Extension developer

        3. Backend user (administrator / manager)

        4. Site owner (decision maker)

      1. Contributor

      2. Site visitor

      3. Hoster


We focus on user roles, the other stakeholders need to be informed but are outside of our scope. Contributors also typically have a secondary user role.

How do we represent our target audience to make valuable decisions?


Personas will be created for each class of stakeholder. They should also cover the combined “Site owner / Site builder / Backend user” sufficiently. The personas are published to the community to use them as “User Patterns”, similar to “Design Patterns” in software development.


Personas help to focus on the needs of our users and other stakeholders.


See for more detailled information.

What is the Joomla! 4 timeline


Release at JAB 2016


We need to timebox based on a end-date

Orthogonal Component Structure




An orthogonal system is introduced, where two different kinds of components are distinguished:

  • Vertical: Weblinks, Contacts, Users, Content, …

  • Horizontal: Versioning, translating, tagging, commenting, ...

Any horizontal component works with any vertical component *out of the box* being themselves agnostic about other components. This way, com_contact, com_weblinks, even com_users would automatically have ‘inherited’ tagging and versioning in 3.2 / 3.3 without the need to change a single bit of code in these components.


This approach allows any component to take advantage of new capabilities that are designed to be used across extensions. The orthogonal structure is a design supporting change.

CQRS (Command Query Responsibility Segregation)


The separation of read and write models will be implemented


CQRS allows for scaling, by supplying multiple slave databases for read access and thus increase performance on large sites.


Event Sourcing


Event Sourcing was deemed of interest to the attendees. The library “broadway” was proposed as a potential solution although it would need a good amount of integration with the CMS/Framework (the eventdispatcher, use of DBAL etc.).
We need performance tests on this.

Complexity for extension developers must be taken into account

Performance Testing Information

There were also potential performance issues raised. A complete cycle for storing an article using Event Sourcing shall not take more than 150% of the time than it does using the current JModelLegacy in traditional 3.x


Using events instead of states for internal communication allows other parts of the software to react on these events in an adequate way. Storing is lossless.The impact of replaying the events on the last snapshot should not have much impact (will get tested first), but give a native versioning instead. Event sourcing is a design supporting change.


Minimum Joomla! 4.0 PHP Version


Working minimal version PHP 5.5.9

Ultimate minimal PHP version will be defined at the moment of Joomla release. It cannot be changed within the major release after 4.0.0.


End of support

    1. PHP 5.4 14 Sep 2015

    2. PHP 5.5 10 Jul 2016

    3. PHP 5.6 28 Aug 2017

Want to use native password hashing, instead of libraries, and misc language features

Use of namespacing


We will use namespacing with the following convention:

    1. Core Components

        • Joomla\Component\Content\Site

        • Joomla\Component\Content\Admin

    2. 3rd party Component

        • Akeeba\Backup\Site

        • Akeeba\Backup\Admin

    3. Other extensions (modules, plugins)

      • Module

        • Akeeba\Module\Site\SubscriptionStatus

        • Akeeba\Module\Admin\LastBackupStatus

      • Plugin

        • Akeeba\Plugin\System\BackupOnDemand

The vendor part of Joomla core extensions is ‘Joomla’.

    1. Framework Library:

      • Joomla\Image

      • Joomla\Controller

    2. CMS Library:

      • Joomla\Cms\Mail

It is recommended that the JED marks extensions not adhering to this scheme.


This scheme covers the need of the Joomla project(s). 3rd party developers use their own vendor namespace, so collisions are effectively avoided.


Use of database abstraction layer


Our intention is to use a DBAL. We will investigate using Doctrine 2’s database abstraction layer. We are not going to put an abstraction layer in front of the DBAL.


The DBAL allows us to target all of its supported database types without having to write queries specifically for the database type. It supports testing by making database mocking easy to accomplish.


Its performance is near to what we can do by manually optimising queries and generally better than our under-optimised queries, something we have in common occurrence in Joomla!. In case a developer needs to use native queries, for example to get the best out of performance optimisation, the DBAL does allow them to do that and even lets them know the database type to target it with the correct query format.


Finally, the DBAL has data importers and exporters that work which can create and update both the schema and the data of the database.


We are not going to put an abstraction in front of the DBAL because of performance reasons and because it has no added value.


Doctrine 2 DBAL


Using composer for 3rd party extensions


Composer isn’t usable in mass distributed Joomla because of issues with the time it takes to update dependencies and the inability of users to debug failed dependency resolutions. Most users also do not have SSH abilities on Shared Hosting and requiring users to build their sites on a local machine is not feasible.

Nevertheless, a composer-like dependency management is wanted for Joomla’s installer. Dependencies, which cannot be resolved automatically, are represented to the user (admin) as a choice of possible resolutions.


The design for change encourages components to only provide their core functionality and pull in other features as needed from other components. As an example, a forum component provides the thread management and pulls in any commenting component to manage follow-ups. It is up to the site builder to decide which commenting system to use.


White paper by Nic about improving the Joomla Installer system:

Drupal is dealing with composer for D8 between core and third party and how it all affects distro, site management, etc. has some useful resources.

Filesystem abstraction


We will use flysystem as our filesystem abstraction layer.


Framework already has planned to create a wrapper for the version 2 Flysystem package.  It has existing adapters for FTP, SFTP and Local wrappers. The AWS adapter might prove to be useful when rebuilding the media manager.



Universal Content Model


Content uses the Composite Pattern. There is no difference (internally) between categories and content items. *Any* component producing output implements the same Content Interface. Output is created using channel specific Renderers.

According to Herman, PHPCR implements that concept already.

Performance of pagination, edit, delete with PHPCR has to compared the same with current Joomla 3.x.


Content should be handled as content, not just articles. In reality, content is made up as a non-cyclic graph: paragraphs, images, or other content types can have multiple parents, so content gets re-usable. For each node, the site owner can choose to render its children as a list (like categories do now), or to compose a page from the children.

Performance: Pagination, edit, delete, are hurting performance-wise in J3 currently. If PHPCR does not worsen things, it is the way to go.


Content structure:

PoC for Renderer:




The attendees prefer to stay with GPL v2 or later, i.e., not to change the license. However it is needed to consult with lawyers.


Majority of intended functionalities (doctrine2 DBAL, flysystem etc.) use the MIT license (X.11).  We need to check with the Legal Team regarding distribution of MIT-licensed code with GPL2. Otherwise we will need to upgrade the CMS license to GPL3.


Contributors that have had a “significant contribution” ( ? > 100 lines) to the code that have not signed JCA need to be consulted.

Extensions should be a limited problem as the usually have been licensed as GPL2 or later.

Backwards compatibility management with 3rd party code


No action required. Some effort will be made to allow J3 extensions to work with J4.


Decision can’t be made in advance. Ultimately we could bump to next major version to cater for bc break caused.

Multilingual support


Multilingual support is provided. With the implementation of the J3 solution, a compound id (id+langcode) has to be used.


The orthogonal structure allows to implement different solutions - e.g., one working like JoomFish/Falang, another like it is done in J3.

If the results from the PHPCR performance test are satisfying, translated items could be just nodes in the graph, selected by the ACL, language setting etc.

The compound id allows us to keep the id-number for different languages. Thus we get rid of complicated associations, and additionally get a fallback mechanism.



The routers along the lines suggested by Niels and Hannes (with possible additions from the Framework’s router) are used as a base. The menu system is used to generate custom route patterns for specific sites. The route must still run through JComponentHelper.  For REST we can support “best practice” URLs using the same router.


The approach provides ability for auto-generating route patterns, but allow for customization. Best practice RESTful URLs come out of the box. A router.php will no longer be needed in components.


As there are going to be multiple MVC systems used within 3rd party components the routing must be independent of the MVC layer. JComponentHelper is therefore used to “dispatch” components in the CMS and therefore all routing should call the component helper.


MVC Implementation


The proposed command structure will be implemented.  (see references; naming according to GOF Design Patterns)

A command decides which model(s) to use. It is responsible for making input available to the model and to add the output to the visitable output object graph. Thus, the model can be literally any object with public members - in theory even a J1.5 MVC triad or a non-Joomla solution.

The output graph is transformed into a streamable format (according to content negotiation), and - if appropriate - wrapped into a PSR-7 response object.


The command/controller approach gives most possible flexibility for the implementation of models, so it is possible to integrate existing software. it allows to do proper CQRS, if wanted, by letting read (‘Query’) and write (‘Command’) commands use their own model.

The renderer approach allows to serve any output channel (JSON, XML, HTML, PDF, ePub, …) without the model or controller even knowing about that.


Command structure

Content negotiation


Adding a custom renderer


Examples will be drawn up for

  1. CLI

  2. HTML

  3. Download

  4. JSON-LD (i.e. something that isn’t included in core by default)



Custom fields


Custom fields will get implemented as a horizontal component.


As a horizontal component, custom fields are provided for any existing and future vertical component.

Data Context Interaction


Interesting, but needs more  exploration and concrete examples. Also: what are specific use-cases in the CMS.


It is also an orthogonal division of responsibilities: adding behaviour (roles) to objects only within the context of use-cases.



Composition vs Extension


We prefer composition over inheritance. When tempted to use traits, consider composition.


Loose coupling increases maintainability and supports change.


Dependency Management


Use Dependency Injection (Containers) wherever possible. Avoid Service Locators, if possible.

Global services are requested by raising an event (e.g., ‘requestLogger’), which returns a logger.


With Dependency Injection, the provided services and objects are controlled by the calling instance. Dependency Injection Containers may help to keep the signature of constructor short, if several dependencies are required.

Service Locators are appealing on first sight, but tend to turn into an anti-pattern, as they provide global references and cannot easily be tailored for special use cases (HMVC, for example, may need different services for subsequent requests).

Requesting services using events decreases coupling. The event dispatcher is responsible for caching the result of those events, so there is no performance impact.

FIG Standards


We’ll follow PSR-3, PSR-4, and PSR-7. PSR-1 has to be reviewed; if feasible, we’ll follow it, too.

We don’t adopt PSR-2.  We will keep an eye on PSR-6 (Caching) and will adopt it if it is agreed before we reach beta 1.


As a voting member of the PHP-FIG we want to live up to our responsibility.

PSR-2 is not an option for Joomla, because its own code style (which actually is older than PSR-2) is widely adopted in the community.





Although testing is strictly not within the scope of architecture, we want to encourage test-first development. Leading by example we will write Behat behavioral tests, integration tests and unit tests for the structures we propose.


Red-Green-Refactor will yield better and less buggy code. Good tests will give developer documentation, too.



Supporting migration shall be an integral part of every deliverable in the context of Joomla! architecture, implementation and new features.


We want to deliver a non frustrating migration experience: migration without frustration.

Inform and educate 3rd party developers


Provide documentation and guidance for 3rd party developers to migrate their extensions. This is both a marketing and technical challenge.


We want to deliver a non frustrating migration experience



Using DDD is at the discretion of the implementers. Working group is to be informed upfront to discuss. Core components should be refactored to follow DDD with minimum impact on the outside view.


Affects the components (model) and not so much the system as a whole.

It should be possible to use the same user interface as in J3 (the paradigm change under the hood), so current users do not get distracted.

BC Policy


No change required.
In development care has to be taken, defaulting to private, public and using protected only if needed.

Also see next section (APIs).

Where API’s are going to be replaced in future Joomla versions, we should ensure that the classes and methods are marked as deprecated.


Existing BC definition should be ok




Postpone the decision until the formalisation of PSR5 and discussion on acceptance

If PSR-5 is finished and accepted by Joomla, API relevant members (properties and methods) are annotated with ‘@api’. Public members, which are not part of the API, should be annotated as ‘@internal’. Changing members not marked ‘@api’ are subject to change without notice, not causing a BC.


PSR-5 defines an ‘@api’ and an ‘@internal’ tag for this purpose. Using these tags makes clear, which elements are covered by the BC promise.




JForm will be refactored to support not only form generation, but also list and detail views. The input is provided by a form definition class, which is populated through an XML file, or - if feasible - through JSON or Yaml files (optionally).


JForm provides a template independent gateway to data structures. Supporting list and detail views in addition to the forms will reveal the real power of the concept. Allowing other file formats for the definition input will enhance flexibility.

Define custom URLs using alias field


It is intended to extend the use of the alias field. If an alias starts with a ‘/’, its URL is at root level.

Example: /my-article becomes

If the alias does not start with ‘/’, it gets prepended with its category. This is continued, until a leading slash is found or root is reached.

There has to be a way to suppress the id in the URL.

The current behavior has to be retained, however, as the default behavior.

A final decision is taken after an elaborated proposal is provided and reviewed.


Joomla users complain about not being able to define SEF URLs for articles. This approach provides an intuitive way to provide that feature without breaking current behavior.

Framework Reconciliation


Stuff gets merged both ways. CMS changes seep up into the framework

profiler, session and language.


It makes sense to keep  CMS and Framework as close to each other as possible.




#Sprints (2wk)                                                                                                              
BC Management
Composition over inheritence
FIG Standards
Licence GPL3
BC Policy
Min. PHP Version
Framework sync
        all       marco       all       marco, robert       marco       marco       Herman (behat)       marco       all       all       george, niels
Orthogonal system
Database support DBAL
Refactor core extensions
Dependency mgt (containers)
Code Police
        3       3       1       2       3       3                       4       3        
        hannes?, herman, niels       niels, nic, robert,
      herman, chris       george, herman       Niels, chris       niels, chris       all       george, nic, robert       nic, robert       nic, george, robert       michael
custom fields
Composer like dep. mgr.
refactor multi-lingual support
alias => urls
        2                       1                                                                      
        niels       nic, robert       chris       niels                                                                      
event sourcing
        herman, robert       herman, robert                                                                                          
Renderer examples
Inform & educate 3rd party
Target audience
        1       1       99               99                                                            
        niels       niels,
      George, nic,
marco (marketing)
      marco(marketing)       marco