Skip to content

Instantly share code, notes, and snippets.

@elkuku
Created November 10, 2012 23:28
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save elkuku/4052966 to your computer and use it in GitHub Desktop.
Save elkuku/4052966 to your computer and use it in GitHub Desktop.
Andrew Eddie: Thinking out loud about the future of the Joomla! CMS

Ref.: https://groups.google.com/d/msg/joomla-dev-general/bK4r4m3VEBg/i9N8J5hNGkcJ

...start simple, though it would take a bit of time to set up. Thinking out loud too, I'd take these steps:

  1. Strip down a "Joomla Core" version to the bare minimum (Platform, Content, Menus, Users, etc) and put that in a new github repo.
  2. Create Phing (or Hudson) scripts to create the "build" and delta's (just clean up what we already have for the full CMS - just put them in a repo too some people know what happens).
  3. Treat every other extension suite like a 3rd party addon and give it its own repo. For example, put com_banners, it's modules, language files, etc into a new repo.
  4. Create build scripts for those individual extension suites so they can be installed manually as required (I and others have many variations on this theme).
  5. Create of distro build script that can merge Joomla Core with a "list" of extensions.
  6. Work out a strategy for sample data that can be included in each component.

Doing that does some interesting things. On the Platform, the growth we are seeing is due to the fact that you can achieve a lot quickly and see a result. For example, you can add three or four API calls to JGithub in an evening, or maybe spend a week on a new package. Send a pull request and, bam, you are done and satisfied you've made the world suck less. That's not so easy with the CMS because the whole monolith is sort of in the way. Break up individual extensions and you can potentially increase the interest and innovation because now you can see what you are doing (for example, component developers don't store their code as a part of a fork of the whole Joomla CMS).

Another thing it would do is foster more consolidated efforts on extensions. What I mean by that is you don't have to have 10 different free extensions doing the same thing on the JED - people can just work together on the official one (much like Drupal does, but without the "there can only be one" attitude).

It also makes it trivial (hopefully) to add new extensions to the stack. Each extension suite would need to have a stable master branch but that's not difficult to achieve. The JBS would take responsibility for the core and the overall strategy, but the other extensions could have teams of owners and they manage the bugs for those extensions.

In the future, you build a UI so people can dial their own distro stack.

But for now, that's where I'd start and it's just a matter of putting the build scripts into Hudson so you can just push the play button to get it rolling.

On the topic of UCM, well, the reality it shifts you from "extension" building to "content" building. You only have one content component but you'd need to have the ability to add new content types in a sensible way. I'm still trying to work out how that would be possible but I think that's something for "Joomla Next", not the current CMS architecture (especially given the fact it would make most existing extensions redundant).

Regards, Andrew Eddie

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment