Symphony.

Hi -

I have just taken a look at Symphony and it looks great: I’m keen to start using it. However I’m a seasoned ExpressionEngine guy so I was just wondering what the benefits of using Symphony over ExpressionEngine might be?

I expect this could be more of a question of what the benefits of XML and XSLT are: I understand the concepts, but I’m struggling to understand the benefits.

If anyone could shed any light on this that’d be great.

Thanks!

Once you have been using XSLT for a while, you probably won’t like those “self-made templating languages” anymore. XSLT is a serious transformation language which allows you to output everything you might need (XHTML, CSS, JavaScript, XML, you name it…).

But, no, it’s not just a question of using a different templating language.

EE:

• tons of “features”
• giant backend
• you are more or less “clicking your way through it”

Symphony:

• not “feature-oriented” but really (!) flexible
• some possibilities (like member management/forum) are still under development (well, nearly finished…)
• open source

Actually Symphony feels much more like “having control” to me. (I have been using EE before I switched to Symphony.)

Here’s one example: Have you ever tried to move an EE website to a different domain? Congrats if you succeeded (after hours of work)! In Symphony it’s a breeze.

Also, EE you have to pay for and keep paying for if you want updates. You have to pay for extensions and modules. You have to pay to get support.

Symphony is free.

I must admit I have very little experience of ExpressionEngine beyond their own website and a few tutorials I have read with screencasts.

The main differences as I see it:

• EE is still more aimed at blogging it seems to me, since each container for fields is called a “weblog” (I think). Symphony calls these “Sections” and they closely resemble a database table. There are nine core field types (Author, Checkbox, Date, File Upload, Select Box, Select Box Link, Tag List, textarea, TExt Input) and 20+ others as extensions
• EE appears to prescribe your URLs as you build page templates (http://domain/template-group/template/entry-title whereas Symphony makes no assumptions and leaves URL structure up to you when you build Pages

• EE has its own proprietary templating language which also means you embed your content queries into your HTML such as:

    {exp:weblog:entries weblog="articles" limit="20" order_by="entry_date" sort="desc}
  

  Whereas Symphony uses the W3C standard XSLT (Web Standards are generally a good thing) and doesn’t force you to couple your data queries with your HTML. In Symphony your queries are created as Data Sources (which contain the configuration for the query) which are then attached to a Page. A Data Source’s output is XML, which is transformed by the XSLT in the Page to create the final output. It’s a more MVC way of doing things and forces separation from the data and its rendering.

Symphony lacks the “website in a box” approach of other CMSs such as Joomla and phpNuke, and possibly ExpressionEngine. Symphony is seen as more of a content management framework than a content management system — it blurs the boundaries between a CMS, and library and a framework. It’s more like Lego in that it provides the elemental building blocks for you to slot together to build something focused.

I think Nick has described it better than I could there, but my points would essentially be the same, especially about using open standards such as XML and XSLT.

ExpressionEngine is a very capable platform and I would not personally wish to criticise it, but the simple fact remains that Symphony is both free and open source so you can use it in any way you see fit. It is also the only system I have ever used that is truly free in the way you define data and use it, and that freedom is very powerful in itself.

I think it’s worth mentioning that XSLT isn’t as intimidating or difficult as it may appear on the surface, read a few of the tutorials here and the excellent stuff from Steven Bau and you’ll be up and running in no time.

Great - thanks for all these replies guys. I’ll definitely try Symphony for a project in the near future to test it out.

Thanks.

Unlike other CMSs, Symphony makes no assumptions about the content you want to manage.

I think that’s the shortest statement I can make that differentiates Symphony from other CMSs.

Off topic: This very thread may be of inspiration to the team in order to improve the documentation.

This very thread may be of inspiration to the team in order to improve the documentation.

Do you mean improving them by writing docs for EE users?

Do you mean improving them by writing docs for EE users?

Yep. The same applies to this thread, which explains differences between Symphony and Drupal, and this concerning Textpattern. I think one single “transition guide” for each CMS (perhaps an article?) could do the job. I’ve noticed that some efforts were already put into writing an article summarizing pros and cons of using XSLT as a templating language, in constrast to other engines out there. Any news on that front?

I think one single “transition guide” for each CMS (perhaps an article?) could do the job.

I see. As I’ve mentioned elsewhere, it’s definitely in our plans to whip up some guides for users of other systems. But it probably won’t be soon. The priority in the short-to-medium term will be to solidify to the core of the documentation, since much of that content is still incomplete.

One thing we’ll likely do is ask community members who are familiar with other systems to help us draft them up. More on that soon…

The priority in the short-to-medium term will be to solidify to the core of the documentation, since much of that content is still incomplete.

I think you (and everyone who contributed) already did an amazing work writing the current documentation. My concerns aren’t about the content itself, but rather the way this is arranged and presented to users (that is, information architecture). Keep up the good work and thanks a lot for the time you and the team constantly put into the project to make Symphony shine.

Now I suppose it’s time to get back on track, sorry for going OT. ;)

I’ve used EE recently for some sites and extension development and for me Symphony is always akin to a breath of fresh air. After the experience, I’ve decided that I’m not a big fan of EE - I have concerns about their community and the “pay for everything” attitude that seems to prevail. It doesn’t help that EE is also really inflexible when compared to Symphony.

The main thing you’ll miss if you choose to move from EE to Symphony is the member management functions - in my opinion, everything else is smoother and more flexible in Symphony.

I really, really, really appreciate the fact that Symphony does not force content structures upon me. I build what I need - and the users only see what I’ve built (as opposed to EE, which forces certain fields and approaches upon all data models).

Oh, and free :) That’s a huge bonus in this industry!

To paraphrase @michael-e: Once you go XSLT, you never go back ;)

Symphony is seen as more of a content management framework than a content management system — it blurs the boundaries between a CMS, and library and a framework. It’s more like Lego in that it provides the elemental building blocks for you to slot together to build something focused.

I’d go so far as to say that packages like Wordpress and ExpressionEngine aren’t really content management systems. As far as I’m concerned, if I can’t build custom data types to represent my information, and then push those data blocks through a templating language, it’s not a CMS. EE certainly comes close, but it still forces you to use it’s own idea of what your information should look like.

OK, evangelist mode == off.

I’ve gotten the question of the benefits of the extra layer (that is the semantic ‘source XML’ layer) before.

I would say that the benefits really depend on your usage. I spent last weekend getting reacquainted with Wordpress theming, and I have to say that for simple sites that just need a raw content dump, it is very simple to implement, and has what I would argue is a somewhat more refined back-end user experience than you often end up with in Symphony.

So I would say Symphony is ideal when you are dealing with the opposite; that is, highly semantic/modeled content, and you need a fine grain of control over structuring that content, and the views you are producing from it.

Wordpress … has what I would argue is a somewhat more refined back-end user experience than you often end up with in Symphony.

Hopefully we’ll change this with 2.1 ;)

Hah. It sounds nice, Craig!

I’ve gotten the question of the benefits of the extra layer (that is the semantic ‘source XML’ layer) before.

I would argue there is no “extra” layer, as the xml+xslt part is normally done by a templating engine (smarty, pure php, etc). Ofcourse, for some xslt is a new language, but the layer itself is present in nearly all (good) cms’es.

For many CMS platforms you would have to learn a proprietary template language anyway, you may as well learn one that is standardised and a transferable skill.

I would argue there is no “extra” layer

By that I just mean converting php data objects into XML, then transforming that XML. Rather than PHP -> XML -> XHTML, I’ve had questions about ‘why not just PHP->XHTML’ even if it means implementing a template language in PHP.

Tangentially related, I love Wordpress’ rebranding of the php function call as a ‘template tag’.