Symphony.

Hey Symphonians,

I'm looking for a new CMS to build my future websites/intranets/extranets and I've narrowed down my options to Symphony and ProcessWire. Both seem very lightweight, flexible, extendable and assumption-less. A real relief after coming from Wordpress and Drupal... I've test-driven both but that isn't enough to see all advantages and limitations so maybe u guys could help me in making the right choice?

Pro Symphony:

• Rock solid and clear MVC architecture (pages/events, data-sources, templates)
• Around for a while and production proven
• Great community
• Page debug tools

Pro ProcessWire:

• Clear mapping between content and front-end site structure (very client friendly)
• Easy for clients to add new pages without having to deal with templates
• jQuery style API to retrieve and edit content

Concerns Symphony:

• See the points at Pro ProcessWire
• The number of data-sources and events seem to get a bit out of hand on big websites.

Concerns ProcessWire:

• Templates seem to act as models, events and views?
• Relatively new open-source project: smaller community and how long will it be supported?

Both seem quite similar but maybe I'm missing things. So what do you guys think about Symphony and ProcessWire?

This is based on a cursory look at ProcessWire's demo install & intro tutorial:

The query syntax for ProcessWire looks really cool. I like the idea of being able to code the Symphony equivalent of a 'datasource'. That said, I also really like the extremely simple interface that Symphony provides.

I don't think the template (ie the view) is the appropriate place for it though, like you mentioned. It seems a little muddy in that sense: the data model the template is applied to can be defined through the UI, or through the template (or both). That opens the door for some confusion on the part of UI-only users. This also means you are more or less likely to have to duplicate these data queries on multiple page templates, which is a significant drawback to me. Symphony's structure allows reuse, and is much clearer.

One of Symphony's relative weaknesses is that it does not do much to accommodate arbitrary page hierarchy. PW actually looks similar to Symphony in that a 'page' is more likely to behave as a site section rather than a single available url on the site. I was anticipating PW to win in this category (since most other CMSs usually do), but I'm not certain; it looks like the process would be similar to Symphony.

Beyond this, I would say it comes back to your thoughts about XSLT. Over the past year or so, I've found myself working more in WP and Drupal than Symphony, and I cannot stand writing templates in PHP. After working with XSLT, there is no question to me that templating should be declarative rather than procedural, but that is just my opinion.

Hope that helps!

@ashooner

I've found myself working more in WP and Drupal than Symphony, and I cannot stand writing templates in PHP.

I feel you, man :)

One of Symphony's relative weaknesses is that it does not do much to accommodate arbitrary page hierarchy. PW actually looks similar to Symphony in that a 'page' is more likely to behave as a site section rather than a single available url on the site.

In PW each page has their unique url where it is accessed. But you don't have to limit yourself to that and it is really easy to pull data from other pages. Sometimes you have pages (ie. you can build stuff like banner carousels, tags etc using pages) that don't have public urls, but they still have their "place" in page tree.

Templates seem to act as models, events and views?

Basic usage of PW is super simple, but flexible. Template is model (ie. content type) but each template has their own template file. In most basic use this file is also the file that outputs the final content (ie. what most system means with templates). But if you want more structured MVC then you use your template file as a controller. Just modify or add data to your $page-object and then choose what file you use to output it. Here you could use smarty or any other template system if you want to (I have never found any reason to do this - maybe in large team that would be good?).

So how I use PW is that Template is model, template file is Controller and then I have views as separate files. Not sure I understand Symphony well enough to say where events go in PW.

You could also skip controller all together, and use your templates as models and template file as a view.

Beyond this, I would say it comes back to your thoughts about XSLT.

I have to agree. I gave symphony good test drive about a year ago. Biggest gripe was that not me (or anyone) at our company knew XSLT good enough - so it felt like unnecessary complexity. If you have good XSLT skills, then I think that is probably great tool and big reason to use Symphony.

I spotted this thread from a tweet and since it mentioned ProcessWire I thought I'd chime in. My experience with Symphony is somewhat limited, so I'm only able to answer questions from the ProcessWire side. But I will say that Symphony is a product that is very respected in the ProcessWire community. From what I can tell, the products and the audience share some common ground and are working towards similar goals.

That being said, I also think that Symphony and ProcessWire are quite a bit different. I'm not sure that anyone can say you should use this or that because everyone has different needs and preferences. This being a Symphony forum, I would expect that the needs and preferences of this audience will point towards Symphony since that is the focus of this forum. Likewise, if you asked the same question in the ProcessWire forum, the resulting points and discussion would likely lead towards ProcessWire. But this is not a question that anyone else can answer for you, so I hope you get the opportunity to explore both. I wanted to respond to some of the questions that came up about ProcessWire:

Templates

First I wanted to clear up that a Template is not a view. In ProcessWire, a Template is the literal dictionary meaning of a template rather than the meaning used in other CMSs. It's the pattern used to define a type used by one or more pages in the site. It's where you select what fields will be given to pages using this type (called the fieldgroup), what access is required to view/edit/create pages of this type, where pages of this type may live in the content tree, and other details (nearly all of which are optional).

Every template can optionally have a file associated with it, called the "template file". It is a PHP file that is handed a copy of several API variables at runtime and executed when a page of the given type is accessed from its URL. One of the API variables it is given is called $page, and that is an object containing data from all the fields defined with the template. What you do with your template file is up to you. If your needs are simple, you might treat it as your view and output your markup right there. This is how we introduce template files in ProcessWire because it's easy to understand by anyone and easy to use for that may not have a programming background.

But template files are in fact designed to be used as controllers. Whether you create your views with includes, nested template files, or modules is up-to-you. ProcessWire provides a great class for creating views from your template file, but you aren't required to use it. If you want to use your template file to bootstrap and send data to another application, go for it. If you want to use your template file to power a web service, then do it. The point here is that if you develop web applications and sites for a living, ProcessWire wants to support your workflow rather than dictate it. If you are an MVC purist, you'll be right at home once you use it as a framework.

Fieldgroups (as components of Templates)

I want to clarify that Templates and Fieldgroups (where fields are assigned) are technically two separate things in ProcessWire, underneath and from the API. But on the front-end they are presented as part of your template. After years of using them separately, I realized that the templates nearly always corresponded with the fieldgroups with such a strong relationship that keeping them separate was more compromise than keeping them together. In a constant drive to simplify, they were brought together as a component of templates. This is for presentation. Behind the scenes they are separate things. Furthermore, a given Fieldgroup can easily be used by multiple templates should that be your need. But it's not the default behavior for the reasons stated. The advanced user of ProcessWire may want to delegate and utilize fieldgroups to their need, but it's one less thing that the average user doesn't need to think about.

"Symphony: Around for a while and production proven"

"ProcessWire: Relatively new open-source project: smaller community and how long will it be supported?"

ProcessWire is also production proven on some relatively large scale sites (and has been for years), but I doubt our installed base is anywhere near that of Symphony's. ProcessWire has been in development (in other non-open source iterations) since 2003. Though the current iteration (v2) is only a year old. As an open source project, ProcessWire is very new. As a CMS in production use, it's as old as WordPress (and that's the only thing in common with WordPress). :)

ProcessWire's reception as an open source project has been great. We were going to keep developing it either way (it's where all our business comes from), but it's reception only means we'll be putting more resources towards it. It is a long term project either way.

If you are comparing Symphony's depth of marketing, resources, documentation scope and site with PW's: ProcessWire hasn't been around as an open source project for long enough for it to even be a fair comparison. I think we're doing really well in this area relative to our project age and resources, but also recognize we have plenty of room for growth in this area. We look to Symphony as a role model in this area.

"Great Community"

This should be in the "pro" column for ProcessWire too.

"It seems a little muddy in that sense: the data model the template is applied to can be defined through the UI, or through the template (or both)."

While it's technically possible to use the API to create fieldgroups and templates, it's something that I don't think I've ever seen someone do in a template file. The only time that you really see the API being used to create such things is when plugin modules create their own assets (which may include fieldgroups and templates).

"This also means you are more or less likely to have to duplicate these data queries on multiple page templates, which is a significant drawback to me. Symphony's structure allows reuse, and is much clearer."

I'm not sure that I understand this one – I can't think of any situation in ProcessWire where you would want to duplicate queries. While someone could do it if they wanted to, it would be a practice I'd strongly discourage. Lack of duplication and encouraging reuse is a foundation of building any site in ProcessWire. If you'd like to post an example of a reuse situation in Symphony I'll do my best to follow-up with an equivalent example for comparison.

To wrap it up, I hope that I've been able to clarify some points on ProcessWire, but also don't want to steer you towards one or the other. Everyone is looking for something different and nothing can substitute for hands on experience specific to your own needs. I hope that you get the opportunity to use and enjoy both.

@apeisa & @ryancramer,

Thanks for all the info! Like I had mentioned, I had just had a quick look at ProcessWire, so I appreciate the detail & corrections. I think any in-depth side-by-side CMS comparison can be really useful for both.

My comment about duplication was really just based on the 'find()' function, but I think I may have mis-understood how it is implemented.

Take for example creating a nav menu composed of page/post/entry categories. In Symphony, you would create a 'category menu' datasource that would pull just the fields you needed from the category content type (or 'section'). You would then attach that datasource to any page you want the category menu. Likewise you would include the 'category menu' XSLT that you've written to consume the output of that datasource. When that page is requested, the XML created from the datasource would be processed by the xslt, producing your output for the menu. How would you do this in ProcessWire? My impression was that you'd need to write the find() function for every template file in which you wanted to add the menu, but it sounds like I'm mistaken.

Separate question: Do template files handle the inputs (e.g. POST requests)? In Symphony, these are usually handled with 'events' that are assigned to pages.

Generally, it seems like ProcessWire gives a php coder a really solid and flexible API to work from, whereas Symphony goes the other direction, giving an admin UI and templating layer (xslt) to actually avoid/prevent writing php.

Hi, Ryan. Thanks for jumping in on the discussion. It's always good to see open discussions about other open source projects but it's even better when integral members of such projects join the discussion to help answer and clarify things.

ProcessWire has been in development (in other non-open source iterations) since 2003.

This is very interesting. Symphony started off as an in-house system called ModMatrix around the same time, then moved into a closed-source for-pay system called TypeWorks early 2005 before we decided to take the journey to become an open source platform. Seems like our projects have similar origins.

If you had the time, it'd be great to have a Skype call and chat about our experiences with our projects. I feel that we can learn a great deal from each other.

@aschooner: The way you avoid code duplication in ProcessWire is the same as how you'd do it with PHP. If you have a block of code that you are going to be using more than once or in more than one template file, then you bundle that code into a function and/or an include file. You might create a common.php include with several shared functions if your need dictated it. On a typical site, it would be fairly rare to have a template file that isn't calling upon other includes, template files or modules to some extent. Most sites that I build have a 'main' template that contains all the core markup for the site, and the rest of the template files contain any necessary logic to pull data that is populated in dynamic sections of the main template.

Using the category menu example, the absolute simplest (though probably not best) example would be to use an include file. So you might bundle this block of code into an category-menu.inc:

foreach($pages->get("/blog/categories/")->children() as $cat) {
    echo "<li><a href='{$cat->url}'>{$cat->title}</a></li>";
}

The template file that needed the category menu would include it like this:

include("./category-menu.inc");

Every template file has full API access and can pull anything it wants from anywhere in the site. Perhaps you want to delegate a view layer with access to nothing but the data it needs to render. You can use PW's TemplateFile class to do that:

$t = new TemplateFile("./views/category-menu.html"); 
$t->set('categories', $pages->find("parent=/blog/categories/")); 
echo $t->render();

Another approach is that you might keep a template in your system that does nothing but output a category menu. You can assign that template to a page and then render that page from any other template:

echo $pages->get("/tools/category-menu/")->render();

Lastly, the approach that I use very often is to build upon PW's API with site-specific modules. If I know I'm going to need something that renders markup for any list of skyscrapers with pagination and sorting, and can be used from anywhere in the API, I like to make it a function in PW's API. This is done by creating a plugin module. The end result is that any template file can do something like this

$pages->skyscrapers("floors>=20, floors<=50, body~=granite limestone");

…to get this.

Or this:

$pages->skyscrapers("architects=/architects/john-burgee/);

…to get this.

These are just examples, but the possibilities here are quite broad. ProcessWire doesn't enforce one way to do things and instead goes in the direction of giving the developer really easy access to pull any data they could want so they can work the way they want to. But we do suggest best practices and development guideline to maximize scalability. The intention is to support a more front-end approach that gives a jQuery-like [easy and fun] development experience when you want it, while ProcessWire does the heavy lifting behind the scenes.

Separate question: Do template files handle the inputs (e.g. POST requests)? In Symphony, these are usually handled with 'events' that are assigned to pages.

Template files have full API and PHP access, so they can handle POST or GET vars if they want to. Though we recommend using the API $input->post or $input->get rather than PHP's. Such requests may also be handled by plugin modules, which may be more similar to what Symphony is doing with events. Templates can also choose to handle URL segments (segments in the URL that appear after the page's actual URL). A common example of dealing with a GET/POST var might be to perform a site-wide search, like that search box in the sidebar of this page. For example, here's how a template file might handle a GET var called 'q' to perform a text search in the fields 'title', 'body', 'summary' and display all matching pages:

$q = $sanitizer->selectorValue($input->get->q); 
if($q) echo $pages->find("title|body|summary~=$q")->render();

By the way: ~= means find all the words wherever they appear, whereas *= means to find the exact phrase.

Generally, it seems like ProcessWire gives a php coder a really solid and flexible API to work from, whereas Symphony goes the other direction, giving an admin UI and templating layer (xslt) to actually avoid/prevent writing php.

ProcessWire definitely embraces PHP. Some people like that and some don't. Though the API is kept simple enough so that one doesn't need to know much about PHP to make a lot happen. I would liken it to not needing to know Javascript in order to use jQuery (though perhaps simpler than that). On most sites, developers use the API to find and get the data they want to use. While you can also define, create, modify and save that data at the API level, most use the admin tools that instead (and those tools use the same API).

There has been some interest in a more ExpressionEngine-like 'tag' syntax to have as an option for those that shy away from PHP. We are planning to build a module that lets one use the entire API from a non-PHP syntax. I personally won't use it, but I do understand that the term PHP carries some baggage in the minds of some designers (a good portion of our audience), and an option for a tag-based syntax would open it up to a broader audience. So we do plan to provide such a syntax option before long, and the API translates pretty cleanly to alternate syntax.

This is very interesting. Symphony started off as an in-house system called ModMatrix around the same time, then moved into a closed-source for-pay system called TypeWorks early 2005 before we decided to take the journey to become an open source platform. Seems like our projects have similar origins.

@Allen: Good to hear from you and thanks for your message. I'm really impressed with what you all have done with Symphony. That's interesting to hear about the similar origins. I wish that I'd jumped into the open source route much sooner.

If you had the time, it'd be great to have a Skype call and chat about our experiences with our projects. I feel that we can learn a great deal from each other.

Thanks–I'd definitely enjoy and value the opportunity to talk with you. I'm thinking you may have my email from the forum, but let me know if not. Please contact me any time or let me know how best to reach you.

Thanks,
Ryan

I've visited PW site, the strange part is, it keep casuing my IE8 web browser crash on any links I tried to visit. Anyone encountered the same issues?

I've visited PW site, the strange part is, it keep casuing my IE8 web browser crash on any links I tried to visit. Anyone encountered the same issues?

@proyb2 - Since you are having an issue with the ProcessWire site, it would be to your benefit to post in their forum. @ryancramer is their lead developer and I'm sure he and the Processwire community would want to know about that specific issue in their forum.