Symphony.

From TheJester12:

Why wouldn’t we want features that help us to do simple stuff like update the software, change some configuration options, allow member registration, add images, etc.?

Unfortunately, the features you noted are not wanted or necessary for every project for all users. I like the fact that I can have as many of these features or as few of these features as I would like.

Here’s a good analogy… say you want to buy a new computer. You have two options: buy something premade or build. You are an experienced user so you know exactly what you’re looking for but you can’t find it already on the market. So, you decide to build your own and get exactly what you want. If you couldn’t build exactly what you want, you would have to buy a premade computer and swap parts, uninstall unnecessary software, etc.

From TheJester12:

I don’t care whether its in core, but the more “official” plugins the better. I really, really hate when you choose a 3rd party plugin and then 2 months later the guy is nowhere to be found and never updates the plugin again.

Really, there are no third-party plug-ins. We’re all one big community. And I don’t say that to sound corny; everyone is driven by their own agenda. Don’t confuse “the core” and “extensions” to mean supported and unsupported, respectively.

It appears to me, and I want to encourage this, that more and more extensions are/will be included with Symphony. When the community finds themselves downloading an extension time and time again, it doesn’t mean “core”. It should mean “default extension”. For the few that disagree, all they have to do is highlight the folder and press delete.

From nickdunn

I’ve flicked through the whole list of all extensions and decided that only these six would personally be useful as default extensions bundled with Symphony. In fact I’m of the opinion that some of these should actually be in the core — re-ordering, number field, unique text and unique uploads.

I support additional default extensions (regardless of the developer). I think it might help new people and overcome the perception that Symphony is lacking.

TheJester12 does have a point in the second quote. More often than not, this is my experience with plugin-based projects.

I usually find myself rewriting extensions anyway regardless if they’re being supported or not just because I have high coding standards :)

I don’t care whether its in core, but the more “official” plugins the better. I really, really hate when you choose a 3rd party plugin and then 2 months later the guy is nowhere to be found and never updates the plugin again.

Having an extension “official” or not doesn’t guarantee it’ll get more or less attention. In fact, the more extensions the Symphony team have to support the less time we have on the system itself. There are some very talented developers that have managed to make really awesome extensions, better than what the Symphony team can do with the already miniscule time we have outside of the work that we do.

The beauty of open source software is that if an extension is no longer in active development, if it is useful enough, someone else can pick it up and take the lead.

We’ve already seen some of these extensions changing hands and improvements have been made. The links above, one with the image cropper is one such example.

Adding features to the software does not guarantee it’ll be any better than if it’s an extension.

Having an extension “official” or not doesn’t guarantee it’ll get more or less attention.

Exactly. I was going to say in the initial post but was hoping you would :-)

Yeah, I see what you guys are saying, and I understand. But because I’m a designer and not a programmer, I don’t have much ability to create/edit any plugins for myself. When I’m thinking about using a CMS for a project, I want a couple of things:

1. A basic set of functionality that could apply to a variety of situations
2. The security that those functions are going to continue working with updates to the system

I don’t think Symphony’s situation is much different than Wordpress. Wordpress has a core, which is blogging, and you can extend features to make it do more with plugins. Symphony has a basic core for managing data. If you need extra functionality, you install an extension.

You always run the risk of updates breaking extensions with any CMS update. You have to test first to make sure. I’ve had a Wordpress update break an extension many times. It’s part of dealing with an open source CMS.

I do know that because Wordpress is so popular, I have to update no matter what because of security updates. You don’t have time to test and then you have to scramble to fix, or replace broken plugins. With Symphony, security flaws are few and you can either plan an update and test, or not update at all. I have several sites still running on S2 beta r5 and they still work fine. Unless there is a security problem, I’m not going to mess with them.

With the release of documentation for Symphony extensions, we will be able to write better ones that are less likely to break. For instance, my Color Chooser field (Thanks for the shout out, @Allen!) Makes a new field type so I can simply add a css class to the field. It would be better if I could just make it an option on a regular text field to have it be a color chooser field. Then if the extension is uninstalled or broken, the system simply reverts it to a normal text field. Basically, if the extension breaks, your site won’t.

I would much prefer this scenario than have something like Expression Engine that has everything and the kitchen sink in the core install.

A streamlined core is simpler for the developer and it’s way simpler for the client. The client won’t have to manage and see all kinds of options that they can’t use. If they see the option to have a forum in the admin area, it might make them think it’s an easy thing to turn on. Then the developer has to come back and explain how they don’t need a forum and it really is a lot of extra work.

@MrBlank: Thank you for this clear evaluation.

I would much prefer this scenario than have something like Expression Engine that has everything and the kitchen sink in the core install.

This is what I mean when I sometimes say “Don’t bloat the core”. I’m not joking in most of these cases, because I experienced EE myself.

People often think about “features”. But too often features are no more than promises. Making things work is something different. Symphony made things work for many of us – this is why we discuss so emotionally here. We shouldn’t simply cry for features, but for improvement. And we should trust in the core team which made it all come true: A Symphony CMS that we love so much.

Let’s say we have one new client who needs a special “feature” – should we accuse Symphony for not providing an out-of-the-box solution? After all these things which Symphony made come true? No, I wouldn’t blame Symphony, because is has been the core foundation of my whole damned business for a long time now. How could I forget this?

So what did I try to say?

Core vs. Extension

Rely on the Symphony Team’s decisions. As far as I am concerned, they have never disappointed me.

If your solution is provided by an extension, try and evaluate it, Then use it, or build your own. Be happy, you are lucky to have Symphony.

Great comments everyone. Let’s move on unless there are other perspectives.

I support additional default extensions (regardless of the developer).

Lets debate this please.

I support additional default extensions (regardless of the developer).

The direction we area heading is to move away from on the concept of “default packages/theme/ensemble”.

We are looking at putting a focal point on Ensembles.

Each ensemble will have its own page, complete with screenshot gallery, version control and bug tracker (we’re still discussing this one) – basically it will function like a product page.

The core team will release a set of Ensembles that represent a good selection of website types (weblog, bug tracker, forum, news publication, etc.)

Each of the ensembles will utilise a variety of extensions suitable for its purpose.

@Allen, that sounds awesome!

Very cool. Sounds like what I’ve had in mind: building sets of extensions that can be easily assembled and updated for use in different types of ensembles.

This is what I mean when I sometimes say “Don’t bloat the core”. I’m not joking in most of these cases, because I experienced EE myself.

While I think “Don’t bloat the core” is a good basis for development, it can be some kind of “knock-out argument” (“Totschlagargument” would be the German word for it).

I think Symphony’s core needs to be simple. It should not care about image or video management. It offers all we need to build extensions for it. But I’m convinced that improving the core is not only about reducing clutter and removing unneeded things but about thinking of new features and improved user interaction, too. Symphony should offer the best core solution – so it has to be the goal to create a perfect core and we all know it’s not perfect yet (and probably never will be).

There have been a few smart things in Symphony 1.7 that were not bloated that made Symphony a lovable system. Symphony 2.0 is a bit “unemotional” in comparison. To often discussion about tiny but good ideas are interrupted with the reminder of not bloating the core.

In my opinion the core should be simple but a simple core should not result in a folder with hundreds of extensions that aim to add a system information here and there. If it’s the concept of the core to have a huge extensions folder then at least the concept of managing extensions needs to be revamped and the extension API should be simplified and clarified. The extension API is still not documented and while it sounds simple for a PHP developer to throw in functionality here and there it took me some years to do so - and I think many people will walk away instead of trying to understand the underlying extension concepts.

I like the concept of using ensembles to provide pre-configured CMSs. The new ruby framework Monk has something similar with its skeletons I think. Maybe it could be extended to have a custom download builder, like the one jQuery UI has. There you could mix sets of configurations and extensions (ensembles) with separate extensions.

But I’m convinced that improving the core is not only about reducing clutter and removing unneeded things but about thinking of new features and improved user interaction, too. Symphony should offer the best core solution – so it has to be the goal to create a perfect core and we all know it’s not perfect yet (and probably never will be).

Agreed. I don’t think we’ve communicated the concept of system elegance and simplicity well enough. It’s definitely not equivalent to “basic”.

For example, content types. Pages should inherently allow configuration of content types. Pages should also be able to easily handle redirection based on URL parameters and DS results. There are a lot of things we are working on that adds these kind of ‘core level’ functionality.

The philosophy of “don’t bloat the core”, is not about keeping things so basic it’s inconvenient for developers. However it’s always a good first rule-of-thumb to have. We’ve had times when we added a feature and regretted it later but was too late for us to remove.

I think 37 Signals had written a piece that touched on this topic. While I think it’s on the extreme end of the argument, there are some good take-out points.

The philosophy of “don’t bloat the core”, is not about keeping things so basic it’s inconvenient for developers.

I know. I just wanted to make clear that there are always two sides that need to be balanced.

@bauhouse said

Very cool. Sounds like what I’ve had in mind: building sets of extensions that can be easily assembled and updated for use in different types of ensembles.

Yes, I thought what you did was a pretty cool idea! Git definitely makes the management of extension a lot easier by modifying the submodule too.

@Nils, I agree very much with what you said.

There have been a few smart things in Symphony 1.7 that were not bloated that made Symphony a lovable system. Symphony 2.0 is a bit “unemotional” in comparison.

I couldn’t agree more with the statement above. It was my hope that with the addition of JQuery, the user interface could be improved to offer some more love.

The philosophy of “don’t bloat the core”, is not about keeping things so basic it’s inconvenient for developers. However it’s always a good first rule-of-thumb to have.

The “don’t bloat the core” argument, however, is not helpful in the sense that it does not definitively support one action or the other.

I think it’s important to make the distinction that the core features are independent of any one data type.

To take this discussion to the next level and perhaps provide a working solution for the future, what three criteria should a core feature meet? For instance:

1. Must be independent of any one type of data.
2. Must not break existing functionality.
3. Must make managing content easier.

That’s the best three I can come up with at the moment. Do you think differently? Do you think there is additional criteria?

Let’s keep the healthy debate going guys. New perspectives welcome!

I think it’s important to make the distinction that the core features are independent of any one data type.

That puts it very neatly. Feature requests are often turned down on the grounds that they are too specific — a “Dashboard for showing recent comments” for example. Symphony isn’t purely a blogging tool and so the core needs to be generic enough for all scenarios. Adding a feature specific to a website type and we begin to hint that Symphony is for building this website type.

I do think that as an extension evolves the functionality it provides could be integrated into the core. One such example is the Order Entries extension. It’s a very simple idea, and it would be relatively simple to add this functionality directly into the core. I would love to see this, since I find myself adding this extension to every build because I always need it, regardless of the site type.

I could add another point to your list:

#4 Improves emotional engagement with the system. Both from a developer (“wow, this is built-in, that’s saving me time and thought”) and client (“wow, I can manage my content like this?!”) perspective.

A topical discussion I just found:

http://lists.drupal.org/pipermail/development/2005-September/010324.html

Chris Messina (the OpenID and microformats evangelist) posting to the Drupal mailinglist back in 2005 suggesting taking inspiration from Symphony (at the time) and building similar features into the core. The response…

I guess you will agree with me that wasting screen space and code lines on a button that one needs once every few months isn’t worth it…

Worth noting the follow up response as well Nick. I don’t disagree with your position, but it’s not clear cut:

The more general approach and issue here is that this problem – though possibly seldomly used – is one that very few non-developers would ever have a clue how to do.

In addition, such thoughfulness begins to make Drupal look like an actual “community-friendly” environment, instead of just “community-plumbing” with lots of sharp edges and ugly design that it takes a whole community to brute-force in order to figure out how to use it.

If it’s just a couple of lines of code and an extra button and it saves 10 people 2 hours each, that’s what will make Drupal a success, not the microscopic size of the download.