Symphony.

Hello everyone!

I’ve been looking around for a good CMS for some time now. After reading lots of reviews and comparisons, I’ve ultimately narrowed down the choice to Symphony and SilverStripe. I’ve also looked into the tutorials of Symphony, so I have some idea about how Symphony works. However, before I try out one of these, I’d like to know what you guys think about SilverStripe compared to Symphony - especially from someone who has used both.

What are the advantages, what are the disadvantages?

It seems to me that Symphony is very powerful but more developer-oriented, while SilverStripe is probably better for simple websites that do not require parsing of xml streams etc.

Regards, Mark

PS. Why can’t I make a simple line break in this forum?

It’s markdown. Two spaces does a line-break.

I’ve never heard of SilverStripe before but the biggest differences seem to be: item- vs. page/module-based CMS and the templating-languages.

Symphony CMS is a 100% item-based CMS. This means there are no “simple content pages” as there seem to be in SilverStripe (or Wordpress for that matter). You can create every bit of your content according to your needs, much as you’d create a MySQL table. (I believe SilverStripe calls this “payables” but I might be wrong)

So for a blog you need two sections: Articles and Comments. Add a couple of DataSources (to pull the data), Events (to let visitors create Comments) and Pages (to display the data) and you’re set. In SilverStripe, you’d have to install the Blog-module and adjust to what the author of that module thought a blog should have.

Same goes for the forum: This forum is built entirely out of Sections, DataSources and Events, everything Symphony brings out of the box (custom DataSources and Events, though. You need experience in PHP to do that).

Then there is the templating-language. I have no idea what SilverStripe uses but it seems to be a little bit messy. PHP classes to push your content on the stack and <% if %> tags to deal with it.

XSLT on the other hand is fully XML-based. Your DataSources return XML and your XSLT templates transform it. This makes debugging very easy (you’ll hear “show me your XML and XSLT” on this forum quite often) plus, this makes your templates “markup-aware”. You can strip certain tags from the text or only allow a limited amount of them (to prevent commentors from posting malicous code), all in your templates.

XSLT might be a bit frightening at first but it becomes handleable very quickly. And after you’ve used it for a while it becomes so much more powerful, structured and cleaner than any other language you’ve used so far. I’m serious, you’ll probably won’t want to touch anything else again. Plus, it’s very old and a W3C standard so you will find lots of information and help about it all over the web.

Heh, I do see that difference. I bet the item vs page-based part is something that sets Symphony apart from almost every other CMS on the market.

However, to me this approach does seem to have some disadvantages as well: Many things remain uneditable without editing the templates. For example, looking at the Blog Tutorial, they put some of the page content into the template.

<h1>Symphony Greets the World</h1>

To me this does not seem to be a good practice because a user who does not know anything about webdesign is forced to edit the template in order to change the content of a page. Also, I do not see a better way to do this right now… of course you could create a new section with one single field for this thing and fetch the data from there - but that does not look elegant to me. In my opinion templates should only be used for design and not hold any content at all.

Well, that’s a very simplistic example but it just comes to my mind… anyway, I think I’ll just try them both out.

To me this does not seem to be a good practice because a user who does not know anything about webdesign is forced to edit the template in order to change the content of a page

But that’s the point :-) Symphony gives the developer the control to prescribe which parts of the site are editable. If you allow a non-technical user to edit all text across every page, even creating pages wherever they like on a whim, you risk losing stylistic and architectural control over the site.

of course you could create a new section with one single field for this thing and fetch the data from there - but that does not look elegant to me

Try not to think about “pages”, but instead think about “types” of content. If you have a blog you have different types such as Articles, Categories, Authors and Comments. You would model these in Symphony as content that is editable by users, and then build the pages to render these content types.

On some sites you might have a single “page” that you need to be ediable. Think of this as a content type too — a “page” is much like an article, it will have a title, some body content and perhaps some other pieces of meta data such as keywords, last updated date and related links. You would define what content comprises a page, and mode a Symphony section and name it “Pages” (if that’s the naming convention that makes sense to your users).

Symphony is about building sections that house your content. Look for patterns in your content, and build a re-usable section to match.

The template language from SilverStripe is an isolated application!

doc.silverstripe.org/templates

Hi goldmar,
I too myself have spend a fair amount of time looking for a good CMS.

Although I don’t think it suitable for every occasion, I personally think Symphony can handle most of what you throw at it.
As you have spent some already time comparing different system I thought you may appreciate an in depth comparison between the two. So I have included such below.
This is also a reference for anyone else who may find it helpful.

With regards to which (of these) systems is best for a simple website I would tend towards Symphony. Even though you need to use XML and XSLT (although…). You do not need to delve into PHP, as you would probably need to with SilverStripe.
It all depends of what you requirements are, and other factors like your skill level and so on. There may also (dare I say it) be more apt solutions then either of these CMSes, for a simple website.

Feel free to ask questions, and I will try my best to anwser them, concisely(!!) that is.

Regards,
Nathanael

I started making a website in SilverStripe a while ago. But did not get on very well (and in the end I finished the site in Textpattern, I believe, although at the time I did not know about Symphony).

Let me try and give you some comparisons, they should hopefully help you in your choice. Although you should note this is from a while ago, and things may have changed a little. I believe I used the 2.2 release. From now on I will refer to the two CMSes as SS and Sym.

Overall

I should start by saying that both systems are entirly valid options, and out of the plethora of CMSes they rate highly in my book. The difference between the two are not huge, only minor. Although still present.

My general impression after using the two is that I just felt Sym to be much more stable and streamlined. I suppect that this is becuase there is a lots of bloat in SS. It just does not seem very well organised, and somewhat hapharzard. Sym is also a lot smaller in size, and much learner. Sym being about 2MB and SS about 20MB. It is clear why this is, because the two work on different principles.

Ethos

Sym does not aim to be a one size fits all solution. It simply gives you a solid foundation on which you can build upon. It does not build much for you, but instead makes it easy for you to do so. You will also, generally, be able to use the work done by those who have have similar requirement/problems.

If you just compare the feature list of Sym to SS then SS will win. But at the expense of a more tailored solution, and having to put up with lots of stuff you simply will not need. I wrote a little more about this here.

If you have not already I also would give the features section a good look. This will tell you more about the purpose of Sym. But simply Sym has a greater emphasis than SS on providing a basic framework, which is then extended upon using extensions.

Flexiability in Content

SS and Sym are both wonderful in letting you define the content structure. Both letting you define your own sections and fields. However without meaning to sound bias, I think Symphony does this slighty better. In SS every section is a PHP class, and within that class you set the field types. This is nice, albeit potentially daunting for those not expereinced in programming. But I rather felt that once you had set out the site structure, that it is quite hard to change things around, what with having to change PHP code for every slight change. It can be laborious.

Symphony however provides a simply interface that does not require access to the code. Each field is an extension, that you select from a drop down list, then change the options. Where as in SS, you need to import annother class. (Although if I am right I believe sections are currently stored in the database in Sym 2, but will be changing to classes in Sym 3).

One advange of using PHP classes is greater control. One thing that Sym misses compared to SS is inheritance. You can set subsections that inhert code from that class above. Inheritance is also true for the templates.

Flexiability in Templates

Which brings us nicely onto templates. This is a mixed area. In some places SS wins, in other Sym wins.

In Sym each page has its own template, then extra code can be stored in utilities.

SS however works with themes. By using Inherance each page can either take the default template of make changes for each page. Sym sorta does this, although not as well, because of the syntax it uses. SS uses its own (I believe) <% %> code, to process template files. Where as Sym uses; now this I really LOVE; uses XSLT. I love it because it is a standard. Not only can XSLT be used else where, there is also lots of support on the web incase you get stuck. Like this or this. Although not perfect, you can use XSLT to do most of the tasks you need.

Again Sym lets you make changes in the interface, where as SS requires you to open up code files to change anything. On the other hand it is easier to have separate themes in SS, and just switch from one to another.

Admin Interface

The SS admin interface can be somewhat overwhelming at first, especially for those have limited computer skills. Spoilt for choice in some ways, there are so many options! Can be a good thing, but does not make it simple to use. Don’t underestimate the importance of this.

I have also found the admin section to be very slow at times. When I say slow I mean waiting a minuite for a page to save. I know this has improved with versions, as they are making the move over to jQuery, from prototype, what with rewriting the JS. But it is still slugglish. Because the admin is all Ajax there is not the normal confirmation (just a loading bar, no page change) with each change you make. This can be annoying, and confusing especially if anything goes wrong.

Where as Sym has a simple interface in my opinion. Although it can take a bit of getting used to, it is fairly easy to find what you need.

Other Areas

There is so so much more to be said, I could talk about the communites (both great) or the fact that SS has a great asset mangement, as well as being better at handling database relations. Or the fact that Sym is has a great collection of Extensions, or that both are connected to a companies so you can get paid support. Then there is wondeful debugging…

Conclusion

For me, in the end it came down the their ethos. Symphony is “designed to be extended”, and does not assume anything on you, but gives you a clean slate to work on. With other systems I felt like I was undoing so much of what had been done already. SS does some of this, but I feel that Sym handled this better.

I really could go on, but I shall not bore you any further. This post is way too long already! But hopefully this has been of help, and given you an impression of the two, and given you some more things to think about. Other people has also given to great reasons for using Sym.

Thanks, Nathanael, for the really thorough, thoughtful, and seemingly balanced comparison (I say “seemingly” only because I’m not all that familiar with SS). Hopefully people interested in both systems will find this helpful.

The one thing I’d like to add is the fact that you can completely choose the whats and hows of symphony to whatever degree you want is exactly why I chose it (that and the JIT Image Manipulation extension).

For example, I’m working on a new site for myself and the majority of it is probably going to be static HTML but there are a few parts of it that will be Symphony powered. Basically, the contact form and the image slideshows are going to be Symphony powered, even though they don’t technically have to be.

The reason I’m doing that is I want to have a simpler way to edit the slideshows, a better form system than a basic PHP form, and because there are other site sections I plan on adding where having a CMS already in place is really going to help.

Wow, thanks a lot for the really insightful comparison! :-)

Of course I did not expect to get votes in favor of SilverStripe in the Symphony forum but anyway, you’ve convinced me to try Symphony. Right now it seems to me that Symphony fits better for my purposes. Some time ago I had been using Mambo CMS and I really hated it for its complexity; it was really hard to get a custom theme up and running, it wasn’t xhtml-compliant and it was extremely difficult to add custom features or adjust it in any way. Later I’ve used Wordpress for some simple projects, however, it’s really a blogging platform and not a CMS… so I didn’t like it that much, either. (Though, if you only want to blog, it’s great!!) The last time I made a website I just used static pages and php-includes for the header/ footer etc. It worked well in the beginning but over time the client had more and more wishes and it got quite messy in the end.

Anyway, Symphony really has a charming and minimalistic design and I like it. Therefore, I’ve already installed it and played around with it.

What I don’t like is that the templates have to be edited in the browser; I ususally end up copying the template into a real editor and back because I want to use the autoformatting options that exist in good editors and I want to have the ability to indent code with tabs (which you don’t have in a browser). Also, editing such things in the browser is dangerous because you risk loosing your changes due to a wrong click or a browser crash. What do you think about this?

Glad you like it!

What I don’t like is that the templates have to be edited in the browser

You don’t have to. All templates are located in /workspace/pages/.

I have to say, I am quite new to Symphony as well. I started using it with version 2.0.6, at the beginning of this year, with absolutely no experience in XSLT.

I worked with various CMS-es before such as ModX, Joomla, some in-house CMS-es and WordPress (if you can call that last one a CMS). In the beginning I was also thinking in pages instead of content. So my first sections where called ‘Pages’ and the site was build dynamicly according to this section (even the main navigation). The sites I build now have more logical sections such as ‘Articles’, ‘News items’, ‘Events’, etc…

I am now a couple of sites further (5 or 6) and everytime I start on a new Symphony project I start loving it more. Each time a new quarter falls. ;-) And XSLT is great as a template language! I don’t want to go back to Smarty or some other in-line PHP template language.

The thing I like most about Symphony is that you allow your clients only to edit that content that matters. For example, in ModX where I used to work with for over a year, a client was still allowed to create (sub-)pages everywhere, hence destroying the site’s architectural structure (“why isn’t there a sub-sub-sub-submenu in my main navigation?”). Also a lot of fields weren’t even used so it was only confusing for my clients.

With Symphony, each section and each field in it’s section has it’s purpose. Now if I give my clients a CMS demonstration they are like “Is that all? I thought I would need weeks to learn this, not minutes!”. So sometimes it looks like my clients are even happier with Symphony then I am.

Also a great thing about Symphony is how low-level it is. It basicly provides the functionality to model your data and that’s it. Therefore in my opinion it’s a very solid base instead of some other CMS-es out there who try to ‘do it all’. And if you need that extra functionality Symphony is easily extended with additional extensions.

To make a long story short: I think I’ll stick with Symphony for a while ;-)

What I don’t like is that the templates have to be edited in the browser

As phoque said you can easily edit the template files directly. And also the files Data Sources and Events. The next version of Symphony takes this even further so that the Views/Pages and Section configuration is stored in XML files and not in the database. Then you can spend more time in your editor of choice and you can version-control the structure of your website.

@goldmar, @czheng Glad it was of help.