Composer Based Install and Dependency Management

[nibra]

Using Composer, we'll

• get easy installation (of predefined packages)
• enable extensions to require external libraries

[nibra]

Associated Pull Request: https://github.com/joomla-x/joomla-standards/pull/8

[laoneo]

Then we need https://medium.com/@yanick.witschi/composer-cloud-resolver-e64254f5728e

[nibra]

Thank you for the link, @laoneo!

[anibalsanchez]

If Joomla is going to be a Composer Project, it must use the standard tools that Composer offers.

Statamic is a good example of how to build a CMS around Composer: https://statamic.dev/quick-start

composer create-project --prefer-dist statamic/statamic cyberspace-place

Contao's Cloud Resolver is a good experimental service, but it is not a reliable service. Check these comments: https://github.com/contao/contao-manager/issues/552

[brianteeman]

Which is why its never going to be an option for a shared hosting cms

[anibalsanchez]

So, from the business point of view, the question is if it's better to support Joomla as a Composer Project or continue to support only the shared hosting CMS space and leave the space to Statamic, Craft, October, etc.

In my view, a Composer-enabled Joomla would be a killer in the CMS area.

[Llewellynvdm]

I agree we should find away for both options to co-exist.

[brianteeman]

Here is a hammer you can use - it will help you get the final nail in the coffin

[anibalsanchez]

Talking about hammers, nails, and coffins is not a valid argument.

I guess you don't like the idea of a composer-enabled Joomla competing with others CMS that are born in that market.

[Llewellynvdm]

Here is a hammer you can use - it will help you get the final nail in the coffin

No this is not true, since I know you have many times made your agenda very clear, you are not interested in making Joomla more attractive to the corporate market and you are doing everything to discourage it, including changes that will work in that direction.

Having a CMS that can run as always on a shared hosting environment, as well as be able to be extended with composer by the end user is a step forward.

Really, @brianteeman to keep Joomla somehow simple for the less technical world of website developers who have low budgets is not working.... I am living and working in Africa where I have done much work with many low budget projects, and most of them always ask why Joomla is so limited, and outdated with regards to these kinds of basic needs of composer libraries integration options. Which isolate Joomla from the rest of the PHP world for the end-user.

When I speak at universities and colleges these are always the reasons given to why they are not interested in Joomla. Hey even during my own studies I keep running into the isolation of Joomla from the rest of the PHP worlds direction of collaboration.

Honestly often times was it not that I insisted that we use Joomla, these low budget shared hosting websites would have moved to a more integrated PHP solution with simple sFTP as the workaround.

Understanding computer science must always mean that we improve our processes to be more harmonious with the rest of the industry. Keeping Joomla away from the ability to be extended for example with composer by the end user is counter productive and that is just the simple truth. I mean why do you thing the Joomla Framework was made, it was the first step in the right direction of PHP architecture.

So just shouting its ...final nail in the coffin is simply propaganda to serve your personal agenda, or at-least that is how it looks to me. Since I have never seen any small project who want to use simple and/or outdated tools to realize their huge dreams. They want the best tools and most advanced tools, they want to use the same tools that the corporate world is using. Believe me, I have sat in many many meetings, and if I am not able to prove that Joomla can hold its ground as a PHP project with tools like October CMS, or Drupal.... then they are simple not interested.

Go look at the Joomla JUG groups map.... tell me why are there so few African teams? because Joomla is not advance enough to impress the upcoming generation of developers in Africa. This I know first hand...

We must wake-up, the real "..nail in the coffin" are those who are holding Joomla back...

[brianteeman]

IF both composer and regular can work then fine - waste your time developing it. IF you say only composer then no - absolutely not

Understanding computer science must always mean that we improve our processes to be more harmonious with the rest of the industry. Keeping Joomla away from the ability to be extended for example with composer by the end user is counter productive and that is just the simple truth. I mean why do you thing the Joomla Framework was made, it was the first step in the right direction of PHP architecture.

Oh of course I forgot what a success the framework has been - forgive me for not noticing the handful of people using it and the even smaller number of people contributing development.

Lets stick to measurable facts and not personal attacks. The vast majority of joomla sites are hosted on shared hosting which will not provide the ability to use a command line composer. Joomla is designed as a monolith and using composer makes little sense for that and as for extensions no developer is going to maintain the two separate versions that would be required.

Composer is great for the job it does and I use it everyday for that job. Installing and maintaining a mass market cms is not that job. If I really wanted to build a site using composer then I wouldn't look beyond real frameworks such as symfony and laravel.

Joomla 4 took so long because two years were wasted working on pythagoras and other crazy schemes that are not suitable for our userbase. If people really did want that then it wouldnt have been abandoned. The reality is that no matter how much a few people tried to force that approach there were no real developers interested in working on it.

Finally I make no apology at all for putting our userbase first. Maybe its because I've been around in the project for a long time but every few years I see the same arguments about "we must move to the corporate world" and make changes that will abandon all the existing users. Those arguments have never been led by anyone who has any real connection to the joomla marketplace and always die when they realise that no one else is interested in doing the work for them.

[Llewellynvdm]

This reply is not fair and mostly not true either... I have been using Joomla since 2008, and the only reason this always dies is because there is a push-back from people like you, and that is not a personal attack just an obvious observation. All my comments about your negative dealings with any corporate market share can only be seen as an attack if it is not true, in which case I make apologies...

You say no... and yet this is not your call. We all have a say in the matter.

You talk about our userbase... but its like you are completely ignoring the reality that the majority already left. The only reason the framework is struggling to gain traction is simple the same reason as this conversation. The advance developers who would make it work, leaves... or just never come closer when they read threads like these, only a handful stayed around, and they are overloaded.

Most developers who would like to see this happen are not the kind that will waist time building something that does not get adopted into Joomla. They are specialist in their field and do not have time for debates about what is obviously right, they just walk away...

How much I would like to get out of this tug-of-war and see freedom return to Joomla. Why can't we dream, why can't we innovate.

The answer to this problem of both a composer and easy deployment approach is not even what the last few comments are about. No it is a debate about whether the option should even be investigated and documented in a RFC.

What is really very discouraging to me is the obvious negative statements from you:

Which is why its never going to be an option for a shared hosting cms

Here is a hammer you can use - it will help you get the final nail in the coffin

...can work then fine - waste your time developing it.

To make it sound like your the one who is looking out for the userbase, is counter productive, and is kind of an accusation as if others don't. Sure some may not... but most volunteers in Joomla are sincere and do care. When they ask for change you or I don't like, that does not by default make them selfish, and wrong. That is why I call that kind of talk propaganda, as it is not true, and serious stereotyping. Which again is not helpful to the project or its userbase.

The link shared above:

Then we need https://medium.com/@yanick.witschi/composer-cloud-resolver-e64254f5728e

Was very informative and serious innovative solution the the very same issue we have. They realized the need, and build a GUI solution for their CMS.

I really think we can do the same... in fact I can already see a SAAS solution.

[brianteeman]

You get no where with personal attacks

[Llewellynvdm]

Neither do you...

[nikosdion]

I think that there is a lot of work and animosity being expended on the how, instead of the why and the whether.

Joomla is currently lagging behind other PHP CMS because it cannot be installed unattended, using CLI tools. This means that deploying a Joomla site by something like Ansible is a fool's errand unless one uses custom or third party tools — I am making such a tool for unattended installations, I am not just saying that out of left field.

Joomla 4 has a primitive CLI which tries to ape WP-CLI and Drush but fails in two very major counts:

• It is not standalone; you need to install Joomla before you use it.
• There are very few commands and even these do not produce machine readable output.

I had to write my own commands to automate updating my business site and I am still working on it. This experience comes into stark contrast to what I can do with WordPress and WP-CLI without writing any code.

Using Composer to install the CMS is a backwards solution to solving this problem.

It is also doomed because you will have to consider the typical problem with Composer dependencies when applied to a CMS. You are trying to de facto deploy an application where each part was developed by a different developer, on a different release strategy, with different goals regarding platform, PHP etc compatibility and cross–operability. When you try to unify all this under a single Composer dependency tree you are in a world of hurt.

Not to mention that trying to support BOTH Composer AND the web GUI for installing and updating Joomla and third party extensions is a surefire way to create confusion if not utter havoc. If you try to disable or, worse, remove parts of the web interface in the Composer–based installation you are essentially talking about a different CMS, with different design goals and a different code structure. This will cause immense breakage with third party (and, I'm afraid, also core) code. You will essentially be asking developers to support two radically different environments, maddeningly sharing the same branding and versioning. The natural consequence of that is that 3PDs will only support the web GUI which is popular, causing the Composer-based CMS to atrophy. Worse than that, the fact that a Composer–based CMS exists even in a vegetative stage will act as an excuse to never improve the CLI tools. The end result is that maintenance automation with core tools is impossible.

These are not even new findings. We had that discussion in Athens back in 2015. When we did the SWOT analysis we concluded that a CMS like that would be antithetical to the needs of the people using Joomla, i.e. its de facto target audience. Not that I expect anyone to remember any of that; there seems to be a selective amnesia virus doing the rounds among the Joomla leadership these past 16 years.

At this point I suggest taking a break of how to implement solution X and spend a lot more time thinking WHY we need it in the first place.

It comes back to what I said. WordPress has wp-cli. Drupal has Drush. Power users uses these tools alongside automation software such as Ansible, Puppet, Chef and so on to automate the deployment and maintenance of these CMS. If you talk to them you will see that Composer is of no importance. They write custom plugins (WP) and modules (D) with their own Composer dependencies to get stuff done. Joomla offers an even more appropriate extension type, libraries, which can serve as a container for a custom project's dependencies without requiring each smaller custom extension to provide its own dependencies and potentially lead to dependency Hell.

Therefore what would provide value to the power user, the big agencies, the corporate world, the government sector etc would be a standalone, scriptable, conducive to creating machine readable output CLI tool in the same vein as wp-cli and Drush. Trying to shoehorn Composer into that role sounds like a train wreck waiting to happen. Composer is great for many things, mass distributed applications IS NOT one of them even if it's something like beyondcode/expose (see the massive issues they have upgrading to 2.x, several versions into it!) and definitely not a PHP CMS if you value your and your users' sanity.

PS: Before you assume I only ever write software for Joomla and WordPress please bear in mind that I've already been managing an OctoberCMS installation on a shared host with SSH access. It was far from being an enjoyable experience. I am also maintaining my own server where I do use Composer to deploy my custom code BUT I am in complete control of it which makes life far easier. However, the latter is not something that the vast majority of a mass market CMS audience can or should do. Composer is truly magnificent, as long as it's used for the purpose it was written instead of being shoehorned into roles it has nothing to do with.

PS2: Also remember that OctoberCMS is a Laravel app, its minor version updates have historically sucked hairy balls leading to worse migration experiences than Joomla 1.0 to 1.5 (which, BTW, make a rather unsavory point on the feasibility of using anything other than an idempotent database schema management engine anywhere close a mass distributed application which is not under the developer's absolute control) and it's now a paid project exactly because it required so much maintenance that its development could no longer be volunteer–based but had to be a profitable full–time venture! It was funny reading their blog announcement because it echoed most if not all of the arguments I had made back in 2015 against what you'd want to do with Joomla 4 which later became Joomla X and now is dragged back from its grave. To me, October CMS is a cautionary tale, not something anyone in their right mind would want to copy.

Prediction: October CMS will flop with its current business model and cease to exist by mid–2024 (when the update cycle of most sites will bring them into a different CMS or reinvented as proper Laravel apps), forks of it will persist for another 5–6 years in the same catatonic state Mambo forks other than Joomla continued existing well into the 2010's and maybe one will continue existing for the same unholy reasons a certain Mambo fork (NOT JOOMLA!) still exists, with an interface that's by now as charming as it retro.

Anyway, that's my 2 cents. I know it's me shouting into the void and expect nothing to come out of it. I just had enough of everyone's spells of amnesia regarding what was said and done the entire day of Saturday in the Joomla 4 Working Group Athens sprint six years ago or what I was saying around 20th January 2020 in that Joomla forum in Spain. Hence writing this in public view. Verba volant, scripta manent.

[brianteeman]

@nikosdion You can add ddev and cdev to drush and wp-cli

[nikosdion]

@brianteeman True that. I only listed the tools I have used myself.

[brianteeman]

cdev is worth checking out - its developed in the best city in the world by some of my drinking buddies