In the previous two installments of this series we discussed the target audience for Joomla! 4 and beyond and the vision for the end user. In this third installment we’ll see things from the developers’ perspective, defining a vision for the PHP code’s architecture and design goals.
I’m told that Joomla! needs accessibility improvements. This is apparently required for using Joomla! in the public sector in many countries. This is not my area so I guess this requires input from accessibility experts.
A modern CSS framework
Joomla! 3 is stuck with Bootstrap 2 for ages. Even worse, it’s not even Bootstrap 2, it’s out own botched down version of it. Maybe that made sense in 2011, but in 2015 it’s like trying to use smoke signals when everyone else is texting. We need a modern, up to date CSS framework.
There are two school of though on this. One school of thought says that we should develop our own CSS framework abstraction or even our own CSS framework, period. I disagree with this approach because it requires rare talent we barely have and it’s not guaranteed that we will continue to have in the future. In simple words, it’s no longer a great idea if you can’t guarantee the longevity of such a project.
The other school of thought is effectively Joomla! growing a pair. Bootstrap is a great framework and we should stick to it. As in: pledge to always use the latest version of it, at most 6 months after its release to cater for Joomla!’s development cycle. We should NOT be afraid to break b/c with regards to updating to the latest version of Bootstrap. I know I was against this four years ago, but I’ve seen where staying rooted in an obsolete CSS framework got us.
JLayout for the win
Supercharge view templates
One of the innovations of Joomla! 1.5, back in ’06, was the introduction of view templates which separated the code which does stuff from the code which renders stuff. That was great… nine years ago. Have you taken a look at our view templates? There’s an awful lot of PHP code in there. Front-end developer need to have much more than a superficial understanding of PHP to style things.
Meanwhile in the PHP world Laravel happened. And it has these stupidly simple to understand Blade templates. Oh my, he nailed it! It’s powerful as heck and easy for front-end developer to understand and customise without going into PHP specifics. And yes, it can be ported to Joomla!, I have already done that.
The Blade syntax allows us to simplify the lives of developers even more by adding support for constructs like @jlayout(‘com_example.foo.bar’, $this->items, $somethingElse) Compare this to the typical JLayout invocation in core code and you see where this is going. In the words of Darth Sidius: POWER! UNLIMITED POWER!
PHP 5.4 and later
PHP 5.3 is dead since August 2014. PHP 5.4 will be dead in August 2015 but at least we know that all shared hosts support it – except those which shouldn’t be allowed to be connected to the Internet! – at least as an option.
PHP 5.4 allows us to write leaner code with less duplication using Traits. This is the practical reason behind this suggestion. We could easily shave off 15% of our core components’ code and reduce the amounts of bugs we’re dealing with. Double win.
MySQL (and compatible variants) only
I know that this will upset the 10 people who are using Joomla! with Microsoft SQL Server and PostgreSQL. There are several practical reasons for doing this, though:
- Query optimization. Our queries are suboptimal and lead to bad performance, especially on larger sites. If we know that the core is only supposed to work with MySQL we can use the expertise of MySQL DBAs in the Joomla! community with a long standing offer to help to make Joomla! fast. That’s one hell of enterprise feature and major marketing point.
- Reduce the barrier to entry and errors in deployment. If someone delivers a new feature with schema changes they’re supposed to deliver these changes in MySQL, PostgreSQL and MS SQL Server format. In two different locations each. This puts off developers who are very experienced with PHP and MySQL but can’t afford to learn and test against PostgreSQL and MS SQL Server. Even worse, the PostgreSQL and MS SQL Server schema changes usually get merged untested and errors are only discovered long after the release.
- We don’t have the people to support 3+ database server technologies. Proof of that is that the PostgreSQL integration was broken for the longest time (at least 1 year) and nobody noticed. Even when we noticed, it took several months to get it fixed. I still have no idea if the MS SQL Server driver really works.
So let’s just drop support for additional database types. We can leave the drivers for them in the core (Joomla! Framework?) for 3PDs and enterprise users to use them. The core will only support running on MySQL.
As for MySQL itself, since we can’t raise the minimum requirement to MySQL 5.6 yet we’ll have to put up with core tables in need of full text search support to stick to MyISAM (and chop the head off any moron who suggests converting them to InnoDB).
Get rid of UCM
UCM was half baked, is half baked and will forever remain half baked, so let’s just pull it out. It is NOT required for Tags and Content Versioning. We just need tags assignment and content assignment tables with one extra field denoting the content type. Then we can use something like Laravel’s “morphable” relations to make them work. If you read Laravel’s documentation you’ll see that this is the use case for morphable relations, after all.
Bonus points: this greatly reduces the content duplication and clutter of core tables, simplifies queries and speeds things up.
Remove a lot of core extensions
Per the existing plan. One thing we currently suck at is advertising to our users the core supported extensions. I think that the Install from Web landing page should have two areas: core supported extensions and a curated list of commonly sought after JED categories. This allows us to tell users to go there to quickly add the features they don’t find in the core. This approach works perfectly for WordPress: the landing page of the Add Plugin page is essentially a list of Automattic owned or sponsored plugins.
Since this is a major version I believe we can finally break b/c and provide fully namespaced code. This will also reduce our code since it will be finally possible to extend a front-end MVC class from a back-end MVC class. Previously that was just not possible because they both had the same name.
Moreover we can completely do away with JLoader. Instead, use Composer’s PSR-4 autoloader which is already shipped with Joomla!. This will do away with bugs in 3PD code caused by core classes moving from libraries/joomla to libraries/cms, or classes which do not follow the current autoloader’s scheme.
Backwards compatibility layer, at least for 4.x
A new version of the CMS is useless without 3PD extensions. It’s our job as developers to ease the transition of code written for Joomla! 3 to Joomla! 3. This can be done by providing a compatibility layer which adds class aliases and backports of obsolete code for the most commonly used core APIs. This will allow developers to work their way towards Joomla! 4 compatibility without feeling they have to start from scratch.
It would pay great dividends if we also document the conversion process for existing code. If anyone reading this complains about the feasibility of such a plan I have the page which proves that I put my documentation where my mouth is.
Better Composer integration
Move composer.json and composer.lock into the libraries folder, not libraries/vendor. This allows adding requirements without essentially hacking core.
Allow 3PDs to add requirements to Joomla!’s Composer installation during the extension installation / update. We need to see if this is possible on shared hosts without CLI access – for context see this Drupal 8 discussion. This needs to be tied to an overall com_installer refactoring. The feasibility study should concentrate on whether it’s possible to make the dependency discovery and individual dependency download and installation separate steps which can each complete inside a single page load.
Finally, drop all “invented here” core libraries in favour of Composer dependencies (especially things like JImage, JGithub etc).
Ah, my favorite pet peeve. Right now we have this magic global black box called JFactory. Get rid of JFactory, replace it with a DI container (something like Pimple?) which is then fed to the application object. Anything you want can be fetched in a manner similar to Joomla\Application::getInstance()->getContainer()->user.
I also suggest taking it a step further. Each extension type gets its own container type which gives access to the main DI container and local dependencies that make sense for the specific component type. You should be able to spawn the Container of an extension from anywhere, e.g. Joomla\Container\Component::getInstance(‘com_something’). This allows for painless HMVC. Been there, done that – in FOF 3.
I know that the Joomla! Framework has a “new MVC” which I call “no MVC” because this is what it feels like. I disagree with its approach for mass distributed software like Joomla! and its extensions. I do understand why you may need this for decentralized applications. I suggest keeping it in the core for these use cases but not using it as the default development paradigm for Joomla!. Remember what our target audience is? Exactly.
Instead, I propose following Laravel’s lead, without the façades – a major reason why some serious PHP developers hate Laravel. Let’s do away with the Model vs Table separation. Create a Model for non-data-aware stuff and a DataModel for data-aware stuff. using a vocabulary and feature set similar to Laravel’s Model + Eloquent is a good idea. I’ve already done the work in FOF 3 and made my development a breeze. Less code, faster execution, less and easier to fix bugs are the immediate benefits.
Also, as I said above, add Blade template language support to our Views. I am half tempted to propose allowing views to be defined with XML forms –which lends itself to RAD features such as scaffolding– but unless you’re willing to essentially make a RAD framework the core default it’s unadvisable.
Well, OK, what the hell. Let’s just put FOF 3 into the core. I already know that the biggest drawback will be for me. It will however benefit everyone else by having a RAD framework in the core. Right now we bleed developers to Laravel, ZF etc because it’s easier to develop there, even though you have to do everything from scratch. If we remove that “coding for Joomla! sucks” feeling we can regain a lot of that audience. That audience does indirectly or directly drive the choice of a platform for big business’ new sites so there’s a plan to increase our market share.
JSON API with virtually no code
If we could allow access to the CMS data (and data management) though a JSON API we would let advanced uses of the CMS. For example using Angular.js to render pages, remotely managing the content, systems interconnection, easy mobile application development etc.
The groundwork for easy JSON views with HAL support is already done in FOF. No matter if it becomes part of the core or not the HAL support is something we have to put in. I know we already have com_ajax but it’s only useful to do AJAX like it’s 2008 all over again. HAL allows API consumers to discover content more easily, without having to know the exact inner workings of the server.
Improve the schema installation and updates
At this point each core database change requires editing two files, one for updates in the com_admin component and one for installation in the installation application. This is error prone. This is a problem already solved with FOF’s FOF30\Database\Installer using XML files which allow the installer code to create and/or update the schema automatically. It would also simplify the Fix Database feature: you can use the same code as the schema installer/updater.
Since this was already discussed for inclusion in Joomla! 3 I think it’s a given?
Improve the extensions installer
Last year I’ve written a whitepaper on it. We can and should add support for package signing as well. Some specifications work is already done by David Jardin. I’m sure there’s a revised version somewhere butI can’t find it.
I know, you think I’m done with this big subject in 30 words. Well, the two documents are about twice as big as this entire blog post 🙂
Decouple menus and routing
The current menu system defining routing leads to duplicated content and some impossible to solve problems. If a leaf node (e.g. article) can be routed through two or more menus there’s no way to know for sure which URL you should follow unless you also know which Itemid you should use too. If no Itemid is provided chances are the “wrong” one will be picked, leading to the “wrong” modules being loaded.
Fixing that MAY cause some problems with our module system. If every leaf node article has a canonical URL you might end up again with the “wrong” modules being displayed in some situations. For example if I have a menu item for an entire category and another menu item for one of its articles (with different module assignment) then clicking on that odd article will yield an entirely different page layout than the other articles of the category. This is not necessarily bad, but it does change user expectations compared to Joomla! 3 and earlier.
Finally, com_redirect actually becomes important since it’ll be the easiest way to add custom URLs. In Joomla! 3 and earlier the typical method was creating items in hidden (no module for them published) menus instead.
I do need feedback from people who have a better grasp on routing.
Testing and QA
Upgrade PHPCS rules to PHPCS 2 format. This allows contributors to auto-fix their code style (the bane of our existence for large contributions).
Unit and functional tests should be written for our common use cases first. The short term goal is not 80+% test coverage, it’s making sure that regressions don’t happen.
I think that we can now all admit that trying to create a generic PHP framework to compete with the likes of Symfony, Zend Framework etc was a waste of valuable resources. So what we should do with Joomla! Framework?
One idea is to completely fold it back to the CMS core, much like Joomla! Platform was before we called it Joomla! Platform. I think that’s the wrong approach because it ties CMS development with framework development. This is not always a good idea. The framework is basically an R&D lab. You just don’t put R&D under production.
A better way to approach this is as a semi-detached project. The goal of JF is to provide a stable platform for Joomla! (the CMS) to be built on. This requires a major shift in JF’s development since it has to keep in mind and cater for the complexities of mass distributed code. For example, the Uri package just can’t ignore the need for a forced $live_site instead of consulting the $_SERVER superglobal. But having it separate from the CMS allows it to both do R&D at its own pace without affecting CMS development and lets anyone interested use it outside the CMS.
As for Joomla!, it can pull in JF packages through Composer. This should be the one and only way to do it, not the current situation of having a human copy .php files from a gazillion Git repositories into the libraries/joomla folder.
I’d like to discuss these ideas further with Andrew and Michael. Perhaps we could do a joint post on the future of the Framework. I think that if we frame the framework right (pun intended) it can be a successful child project of the Joomla! organisation. Basically, we need to (re)define its target audience and discuss how it can finally move forward.