I have been designing websites using Symphony for the last 6 years, I love the system, I like its flexibility, I love its clarity. Nevertheless I have been thinking about this a lot recently:

What is Symphony about?
What is it for?
Why should a client us it?

Here in Germany, companies still tend to use other systems. Either old fashioned ones (my opinion) like Typo3 or more decent ones like Drupal. One problem is that clients almost never heard about Symphony before. Another problem is that it's hard to explain to clients what Symphony is about: it can be anything, it's flexible – fine. But if it's about everything, it's not focussed, it's about nothing. There is no story behind it.

There once was a story, a story that convinced me to try the system years ago: it was about content aggregation (fetching RSS/XML feeds from other services), web standards (XML/XSLT) and it was about simplicity (UI). But things have changed: many XML feeds have been replaced by JSON, web standard advocates simply ignore XSLT and other systems have done their job: cleaning up their interfaces, simplifying their user experiences.

This is what we say on the front page of this site:

XSLT-powered open source content management system

Approaches content management with the underlying goals of simplicity and openness, so you can build anything.

Gives designers and developers complete control over data structures, URL schemas, and every bit of markup.

Puts the Web's most exciting APIs at your fingertips with an easy-to-use, XML-centric data engine.

Provides a lean, flexible core complemented by a rapidly growing extensions library.

Neither does this sound sexy nor does it sound special (beyond the fact that Symphony is XML/XSL based).

What is Symphony's story today?
Why do we need it?
Why do clients need it?

These are serious questions – I think we need to work on this.

I've been reading a lot on the XML vs JSON debate recently, and I think this is the crux of the issue. Personally I think XML is the ideal method for describing structured content on a document level, whereas JSON is the ideal method for streaming abstract objects (which may or may not translate into content). I'm fairly sure this is the common perception (developer bias aside). The fact you can manipulate HTML "natively" with XSLT adds a huge chunk of elegance to Symphony. It's something you can do with JSON too, but you still have what's essentially a half-XML and half-JSON approach. At the end of the day, your content (i.e. what comes from your content management system) will always be XML-based markup, and until browsers start rendering various object notations as content, it will stay that way.

However, going by my last few projects, a content-document based web is very rarely at the forefront of client's concept for their site. As much as they want to document and market their services, they increasingly want "something shiny" and interactive to show it off (typically they want something that looks akin to an iOS UI for their website because that's what they know as something well-marketed). Javascript/scripting in general is often more suited to this approach, and both interactivity and UI components are much better described by JSON than by XML.

This is veering slightly off the topic I know, but as you said, the main draw to Symphony (for me too) was a standards-directed, open, lightweight and flexible system that spoke "the language of the web". This is mostly why we as developers need it, rather than clients. My clients priorities are about being able to market their services effectively without having to jump through too many hoops. Symphony can offer that, but then again so can most other CMSs. We picked Symphony because it allows us adjust or reduce those hoops.

Just a few unordered thoughts on the matter.

Totally shameless plug, but I go some way to explaining why we like it on our blog:

But unfortunately to some extent I just parrot those 4 selling points, as ultimately that is why I use Symphony - it's the combination of flexibility and simplicity that makes it what it is. As someone who is pretty new on the Symphony scene I have to say that's what got me through the door, and kept me pinned to my seat.

What is Symphony about?
What is it for?
Why should a client us it?

Nils, you make a valid point. I think you broke it down quite nicely. However, in order to answer these questions we must define Symphony's audience. I believe the intended audiences are developers and designers. I don't think there is a reason for a client to use Symphony over another CMS. However, a developer or designer should use Symphony over another CMS if it allows them to accomplish a client's goal or even if it makes it easier on the developer or designer to accomplish that goal.

Of course, developers and designers are the ones to build sites with Symphony. But clients are the ones to work with Symphony and this includes making sure they buy a good tool and have the option to switch developers if needed.

So Symphony needs to communicate with this audience as well. What do you tell a client who says: "I don't know much about the technical part, but I heard Typo3 is good tool. What's that Symphony you are proposing for my project? Why is it better than a tool we know hundreds of agencies are using out there?"

Symphony is MVC flexibility + CMS simplicity + Extension possibility + Passionate community. It's a tool for developers, designers, and generalists to make a custom CMS without writing any boilerplate whatsoever. A client will love it and should be told about it after someone else sets it up, not before.

I must admit I've been fortunate in that my clients usually don't want any involvement in the choice of CMS, most of them aren't thinking beyond the initial build.

I would point out that I'll be able to rapidly prototype their spec more accurately and often faster with Symphony than with anything else, due to a mixture of previous experience and the flexibility of the system. Case studies might be a nice talking point to highlight advantages?

I'd also make a point of the events model allowing you to give them a "backend" that is as simple or as complex as the requirements dictate. Not all of the simpler CMS offerings provide that extensibility as far as data entry is concerned.

I also think the balance of the Symphony philosophy and workflow allow it to meet a huge number of needs (in this case: anything that client might have now, with what they might have in future) without burdening the end user with an impenetrable UI or mentally-taxing workflow.

This is just my opinion, but i think the biggest reason behind symphony being more of an "unknown" is down to the documentation and the learning curve for new developers coming to terms with using symphony.

I am new to Symphony completely, however I have been learning how to use it for well over 6 months now. I still get totally stuck on what is very basic functionality sometimes because of lack of findable documentation to help me through. I spent ages trying to find the way to make images display through i am spending ages trying to get parent/child pages to show in navigation. Stupid, STUPID little things which could really be explained in the docs better.

The more people using symphony = the more people USING symphony.

I love the system (when i know what i am doing with it), but I have always felt that the lack of more basic functionality walkthroughs have set me back massively in my learning.

I would personally write a guide or reference of all these basic things to give starting out front end devs a bite of symphony properly if i knew all the little nooks and crannies of the system...

I never sell my clients on Symphony. I sell them on what I can do with it.

Nils said:

Why is it better than a tool we know hundreds of agencies are using out there?"

Better yet, why are hundreds of agencies using an inferior CMS? It's all subjective. In the end I think each agency chooses a CMS as its primary tool based on how well it integrates with the agency's philosophy and workflow. It just clicks. Symphony clicks for me.

I agree you're never going to make a real success of selling Symphony to clients. It's not their job to make technical decisions such as what framework to use.

How many here have ever had to justify choosing Symphony over something else to a client?

One thing that I think makes Symphony an attractive package if a client were to have doubts is the logos in Who’s using Symphony? on the homepage.

I have had to Justify using symphony when bidding on a project, because the client hadn't heard of was fairly easy with the elevator pitch and an in depth explanation of my reasoning for using symphony.

Maybe I should make one thing clear: I know why we here in the forum chose Symphony – the main features described on this website are still good reasons to use it. Two points are important in my experience:

  • Clients still want to know what they get. At least ours do. They want to know if it's a technically matured system which is widely supported. If I give clients the URL to this site, they won't understand anything. Xslwhat?
  • Developers and designers have to take a look at technology: is XSLT something that convinces newbies because it eases their workflow? I'm not sure. The learning curve is hard and – as I mentioned above – it's nothing that is pushed in the web standard community nowadays. So there is a good chance people think it's outdated.

So while we still know why we chose Symphony, I think we are not doing a good job in explaining the system's idea to others and convincing them to try it out.

While most clients don't really care what the developer uses, most do search the internet to see what's available. I've never heard a client say: "We heard about this Symphony thing. They say it's great. Could you build our website with it?" – but wouldn't that be nice?

Or has there been a single tweet by any influential web advocate pointing to Symphony?
We are a very small community – this makes us proud but it also makes us lonely.

How many here have ever had to justify choosing Symphony over something else to a client?

"We would like to have your quote for the [insert company or institution name here] website. It should be built using Typo3 as our IT suggested."

Now you have to argue for Symphony, if you like to get the job.

One thing that I think makes Symphony an attractive package if a client were to have doubts is the logos in Who’s using Symphony? on the homepage.

From my experience that doesn't work for medium sized companies/institutions here in Germany.

That's interesting. I suppose my clients are less technical/keen to make technical suggestions than some.

I think we are not doing a good job in explaining the system's idea to others and convincing them to try it out.

Perhaps we need to show the links between Symphony's approach and how XSLT can work with the popular technical topics of the day as they come up in the world of web development, such as write once publish anywhere, responsive design, separation of content from presentation, etc. I'm thinking really latching onto and piggy-backing these developments, and tying them closely together with what Symphony has to offer.

I imagine that once a CMS/CMF has become popular with a substantial number of developers, it's then that there's a chance it will pick up momentum and become more of a household name to those who are not part of the industry such as clients (and not before). So I think Symphony can't hope to reach the majority of clients directly at this stage.

That's not to say we shouldn't be providing the messages clients want to see when they do visit the site, of course.

Agree with David, I think reaching out to developers, designers and agencies first and foremost will result in the client promotion for Symphony.

As for the immediate problem of arguing with wilful clients' IT departments, I don't really have a solution to that.

Interesting anecdote about this: During my first ever project with Symphony I was accused of adapting the client's IT dept's requirements in order to match the capabilities of a limited CMS. This was seemingly without him even looking at the development site, which wasn't even finished, although as a gesture of goodwill I had given them full access (this project was a little nightmarish from the start, already 4 months behind when I signed on, with a rigid sitemap and no actual content). However, turns out the IT guy who raised it had been working on his own version of the site in Wordpress and was just fabricating nonsense as he didn't approve of the project being outsourced and wanted it for himself. He was quickly shot down by my agency and consequently their board of directors after we figured that out. I think what I'm saying is that not all clients are super-professional and there will be potential jobs where office and technology politics (don't even get me started on IIS) will mean you have to decide whether the project is going to be more hassle than it's worth.

Do you get a lot of clients requesting you use a particular CMS?

Just to clarify the point i made earlier on....

Without giving developers the best possible understanding of symphony and providing them the tools to go out there and "use" it, you will find more developers will sit there and choose wordpress or drupal over symphony every time.

Symphony needs more critical mass in it's userbase in order to gain popularity. CMS popularity stems from it's userbase and word spreads from those developers into the industry and then leaks out into public domain; this is where you get requests from clients to use Symphony.

Symphony has a great little community, but with a small community come big limitations. Docs are half finished. Tons of "articles awaiting" tags next to the kind of content i would expect to find from any other popular and/or growing cms.

I love symphony because it gives me the tools to create my own application from the ground up, all wrapped in a great interface.

This (to me) is Symphony's USP, and the reason why i chose to spend a silly amount of time wrapping my head around it. Plenty of developers and/or agencies simply do not have the time to spend learning a whole new system without a really great reason to do so.

Basically, the current marketing package and website do not do the system any real justice. It doesn't demonstrate the true power and passion of it's community, nor does it really go into any great depth about the benefit of the system other than the fact it uses XML and have to do the digging yourself to really get to grips with it.

We need Fazal to weigh in on this, if anyone can sell Symphony to a client it's him.

I don't really work with a lot of clients, at this point in time.

However I've had to explain why we should be using Symphony at my workplace a couple of times to my seniors including both technical people (Who wanted to move new sites back to WordPress) as well as to Management who I doubt have any clue of the web technologies out there.

Showing them the big list of people using symphony didn't really work out in either case. What worked for me was using metaphors, I said something on the lines that WordPress would be your standard finished apartment/house, and Symphony would be more like your plot of land, with which you can do whatever you like.

To make it worse I had to back this up with a Symphony site which was taken over very badly designed... Had to use comparisons from minor personal projects which showed that Symphony performance is much better than that of WordPress. In the end I convinced them and got a go ahead.

In any-case I would agree that we need to make some selling points - why its easy for the clients. Because after all they would be using it. Though it is also fair to say that ease-of use would be part of the developer's work, so its important that as Symphony Developers everyone puts in with their work to help promote Symphony.

What is Symphony's story today?

It's a professional tool for professional developers and demanding clients.

Why do we need it?

  • Flexibility.
  • No assumptions.
  • Easy and fast development due to strict separation between front- and backend.
  • Easily extendable later.

Why do clients need it?

  • Custom made backend for THEIR project.
  • Simple and beautiful (elegant) user interface.
  • Easily extendable later.

Agree with David, I think reaching out to developers, designers and agencies first and foremost will result in the client promotion for Symphony.


Symphony will never be a mainstream CMS like Wordpress, Typo3, Drupal or Joomla. And that's a good thing in my opinion. It's a professional tool for professional developers, not for the masses.

As mentioned before, what we definitely should be aiming for is making Symphony better known among professional developers and agencies.

A good selling point for clients would be more agencies using (and talking about) Symphony.

Many of these developers already use systems with very similar concepts, like Drupal or MODx, so we could outline those similarities and highlight where Symphony does a much better job (simpler and more beautiful UI for clients, stricter separation between backend and frontend for developers).

XSLT is a tricky thing. It could attract more 'enterprise' developers (with a .net-background, for example), but at the same time Symphony/PHP lacks support for XSLT 2.0 which most of these devs might expect, so I don't consider XSLT a big selling point.

I'm also a bit sceptical about the "Symphony Network"-approach. Extensions and documentation should stay part of the main website (or at least be reachable under the same domain and not treated like external resources).

Things we should also consider to attract more developers and agencies:

  • Changing the name (I LOVE the name, but there's too much confusion with Symfony)
  • Keeping the website up to date (currently under development with Symphony Factory)
  • Better documentation/tutorials for extension developers (most PHP frameworks do a pretty good job in that regard)
  • Improving overall code quality (core AND extensions)
  • Switching to a more common versioning pattern (2.4 doesn't look like a major release to most people)
  • Keeping features and changes for major releases, sticking with bug fixes for point releases (larger changes like a new hashing method for user passwords shouldn't go into a minor point release)
  • Having a more regular and reliable release cycle
  • Releasing bug fixes faster and more often between major releases

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details