Symphony.

I was chatting to some friends last night who’ve set up their own agency in the last two years. Historically they’ve used Drupal but they’re interested to find out more about Symphony and I think it would really suit their development ethos.

They’ve been using Drupal for a few years - and are quite realistic about its misgivings - but nonetheless it is their CMS of choice and I was keen to understand what the draw is (to them and so many other developers). It must be doing something right, I wondered what we could learn / do to make the transition to Symphony easier?

There are a few obvious things; the size of the community and level of documentation being one, but I think it generally boils down to the sheer number of “off the shelf” modules available.

From that there are probably just a handful which really win people over, for example:

• Front-end authentication (user management)
• Video encoding and distribution
• E-commerce module
• Built in cron manager
• Rating/Voting module

Have I missed any obvious ones?

Some of the above are already available as Extensions for Symphony, others are partially developed but just need to be packaged up. I’d be interested to hear your thoughts.

Convincing clients to use Symphony is the easy part. Convincing developers, so ensconced in other systems that they rarely consider switching, is the real challenge.

Jean-Luc

i’m don like some drupal so many time. drupal is the powerful ones but for symphony is the easy ones with the power in the behind. So developers must come to try.

Rhinomaster, you’re a strange fella.

Jean-Luc, the main thing to sell developers is that for front end specialists like myself, it’s a lower barrier of entry, which in turn makes it easier to seperate the core/backend logic and the front end. Moreover it would actually cause the two parties to work in closer conjuction with one another.

I’ve worked with Drupal in the past, and I have to say that alot of the tools that Drupal developers find invaluable such as views and panels/layouts are already part of Symphony in the form of DS’s and XSL itself.

In my experience, as un-/misinformed as it may be, XSL is usually a brick wall. Many would actually rather deal with php-based proprietary templating.

Add to that a different model for ‘modules’ (ie split between modular extensions and non-modular ensembles) and you lose alot of window-shoppers.

Personally I may move to Expression Engine for my client work. Seems to be more advanced from a certain aspect.

NickToye you are grumpy man. like diva somthing no good for you becauseyou cant understand some things - all some time. im see you number 2 in posts, but you always moan some too much, not so much try to understand. always, you know a chef who cant cook, he blame him cabbage. but problem not cabbage or in pot. problem in chef. maybe chef need be something else, like a bus driver.

@Nick: Have fun with EE. My CMS history is the other way round…

@ashooner: you make a good point about “different model for ‘modules’” and it’s something that’s been difficult to easily describe to a newcomer. People have a certain predisposed notion of an add-on/module/extension and Symphony’s model subverts those.

I think the other issue we need to solve is Symphony’s position in the spectrum of CMS v.s. framework. It has a lot of framework-like concepts yet it’s rooted as a CMS.

My criteria for a cms are usually:

• Can I reasonably quickly fulfill my immediate needs with this app?
• Is the flexibility of the app such that I’ll be able to leverage preliminary experience/knowledge for more specialized or sophisticated needs?
• Are their sufficient support resources (docs, community, extensions) to make both of the previous criteria realistic?

Assuming someone gets over the mental hurdle of XSL, I say Symphony scores an A+ for #1, a B+ for #2, and a C- for #3 (due completely to the documentation, and despite the increasing amount of extensions & ensembles).

Don’t know about you all, but I check out an app’s docs before I even get into its full feature set, b/c to me, the style/nature of the docs are a quick way to know how efficient of an experience I’ll have overall.

@jean-luc: I think you’re right—people are looking for simple “off the shelf” functionality/modules as much as possible. Aside from releasing solid extensions that fill those gaps, I think have detailed tutorials/screencasts that show the power and flexibility that the Symphony-way offers over a plug-n-play model would go a long way to convincing people to give Symphony a go.

The only other module I think you’ve missed is a clean workflow for media management in general—dealing with uploading random images, documents, etc and then linking to them inline.

@makenosound Perhaps Nils’ Mediathek update will take us a step closer to that?

http://getsymphony.com/community/discussions/26361/

Hey Fazal

You mentioned that you might create a definition list comparing the terminologies in Symphony and Drupal, where there are crossovers or commonality …

e.g Sections (Symphony) are a bit like Panels (Drupal)

That would be really helpful.

JL

@jean-luc: Forgot to reply to this. I think, with a bit more polish, the Mediathek extension will go pretty close to filling that gap. Will add more when I get a chance (about to board a plane).

Landed.

What I was going to add was that I think, beyond Mediathek, there will still be a need for some ‘generic’ media management. For example I’d love an easy way for clients to:

1. Upload random files to a random folder structure without having a Section
2. Embed those files in their content.
3. Browse and link to photographs in their Flickr accounts (or similar)

Te new Mediathek will be very useful for cogent that is tightly tied to a particular section, but it won’t fill the role of dumping ground that many people need (I think).

Hi Jean-luc,

and anyone else who is interested in understanding the parallels between Drupal and Symphony. My experience as a Drupal developer has been as a “Themer”, which is the Drupal community reference to someone with more front end skills. In Symphony we don’t have such a naming convention as we all tend to do it all, but we’ll leave that for another day. One thing to note is that both are item based CMS’s and therefore the parallels and concepts are easier to grasp between the two.

I’m going to draw upon my experience in working with Drupal 6.

Surprisingly, Drupal shares a lot of concepts that are similar to Symphony, albeit they are exposed and worked with in a different manner.

Some of the concepts and things to be aware of when working with Drupal are:

• Blocks
• Nodes
• Content Types
• Taxonomy

The above terms should be familiar to a seasoned Drupal developer. Although there aren’t always direct comparisons with Symphony, I’ll get them as close as possible.

When developing a Drupal site, typically you’re advised to download and install the following modules:

• Views (with Views UI)
• Panels
• CCK
• Contemplate
• Image/Image API

There is a plethora of additional modules, however I won’t go there otherwise we’ll be here forever.

---

Please refer to the Symphony Documentation for a full explanation of the Symphony terms.

---

Blocks

Blocks are predefined areas of content within your page. I find this a drawback in Drupal. It assumes you’re going to be building a website all the time, although I’m sure a good Drupal developer can make it work beyond this. Symphony doesn’t make this assumption, and therefore you don’t have to specify this in Symphony. Instead you would actually do this in your XSLT through a Template or Utility.

Blocks = XSL

Nodes

Nodes are every single piece of data in Drupal from a textfield, to an image. If it’s been defined in drupal, it is a node with a specific ID. This is the same in Symphony. Although they aren’t exposed to you directly unless you query the DB directly. Usefully though, each entry you make in Symphony is given an ID which is exposed to you in your XML.

Nodes = Entries

Content Types

In Drupal you have to declare types of content you are going to publish. i.e blog, product types, image gallery etc… In Symphony you do the same through creating Sections. You are free to call them what you want and add any and as many fields as you want.

Content types = Sections

Taxonomy

In Drupal you need to (or should) define a taxonomy in with which you are able to tag your content for the purposes of filtering, ordering and sorting your content. In Symphony you can achieve the same through defining “Params” at a page level or at a Data Source level.

Taxonomy = Params

Views

Views are baked into the core of symphony and we commonly refer to them as Data Sources. In Drupal, when you want to create a specific feed of data, you would use Views UI to create this feed, which can be filtered by taxonomy, field, relationships, sort criteria etc…

In Symphony you would build a Data Source and would filter out what you need in a similar fashion i.e choosing specific fields, sorting and grouping by field.

Views = Data Source

Panels

Using panels you can define custom layouts for reuse throughout a site. In Symphony you wouldn’t need to define this in the CMS itself. Instead you’d do this as part of your XSL in the form of a utility or a template and then changing it’s appearance through the use of modes.

Panels = XSL templates using modes

CCK

From the outset you need to define what type of data each field is in Drupal. You achieve this through downloading modules and letting Drupal know what type of Data this is. Symphony isn’t as pedantic, instead you do this as you are adding fields when you build your Section. Chances are, your requirements have been met already. If not, you should be able to find additional field types in the extensions directory.

CCK = Fields

Contemplate

Contemplate allows you to view the output from Drupal and construct your output i.e html. Not everyone uses Contemplate as most developers can just do this themselves. Theming in Drupal is done through things such as Smarty templates.

In Symphony, as of 2.0.4 you would download the Devkit extension and view your output here, by doing yoursite.com/?debug This is essential otherwise you stand a slim chance of understanding the output from Symphony. In Symphony all theming is achieved in XSL.

Contemplate = Devkit/XSL

Image/Image API

Although not a prerequisite in Drupal, Images are handled as pieces of data, thus making them nodes, and pretty hard to work with when you intend to use them as part of the page’s layout or data. To get around this, you would download Image/Image API and take advantage of things like GD Library.

In Symphony we have the JIT extension which allows us to change and manipulate images as they are delivered to the browser. Images are one of Symphony’s bugbears at the moment as people come from other CMS’s and expect certain behaviour. Having said this, there is no reason whatsoever that you can’t work with images and use them at your will. And recently we’ve seen some pretty amazing work from the community to make this task even easier. I’m looking at you Nils

Image/Image API = JIT + more

If I’ve misinterpreted or glazed over anything, or got something wrong, just let me know!

I hope this helps some.

I hope this helps some.

Most definitely! I'm just deciding what CMS/frameworks to use for a few client sites and Drupal is on the list. Thanks for the insights and comparisons.

Hi DavidOliver, welcome to the community, I'm glad it helped!

Although I wrote this post over a year ago, the comparisons are still relevant. Drupal 7 was released recently and I couldn't help but think that it actually took more steps towards the way Symphony works.

The recent releases, extension development and contributions to the XSLT utility library have made developing with Symphony a lot more fun and the learning curve isn't as sharp as it used to be.