Symphony.

I have a site in mind that would have one home page, which would most likely be constructed the standard way, with a (probably automatically generated) list of projects on it. Each project would be a link to a custom page that will fit the style of the project, meaning both the HTML and CSS would be different for each.

My question: Is Symphony suited to this kind of site, and if so, how would you approach it? If not, do you know of a CMS that would be better suited to it? I’m comfortable with XSLT (of course), PHP (Wordpress-style), and variable-based (Tumblr) templating. If it comes down to personal preference, though, I’m best with XSLT.

My question: Is Symphony suited to this kind of site

Absolutely, yes.

how would you approach it?

Oh my, there are a million different ways! Without knowing specifics it is difficult to advise. But I would suggest you would have a section “Projects” which contains fields about your project such as name, client, descriptions, dates, uploaded assets (images, video) and so on.

How you go about templating each project is entirely up to you.

You could create a range of template types, one of which a project will assume. So say you created three different “themes”, and a project would be assigned a “theme”. This could be achieved by adding a Select Box to your Projects section with three options, one for each theme. Then in your XSLT you could add conditions matching each theme name to swap HTML/CSS. Using this method you would probably have a single Symphony page (XSLT) to which you attach a Data Source that returns the selected Project (based on a URL parameter). For example:

/projects/{$project-name}/

An alternative is that you create a separate Symphony XSLT page for each project:

/projects/project-1/
/projects/project-2/
/projects/project-3/

This would give you a separate XSLT file for each project URL which you can customise as you need. Getting content into these pages could be done in several ways.

Firstly you could hard-coded all of your project content into the XSLT, which means you’re using Symphony just as a way to use XSLT, rather than as a powerful CMS. (Pointless?)

Secondly you could hard-code all project content into the XSLT but maintain a list of projects (name and URL) in a section in Symphony, so that you can dynamically build a list of projects. More useful, but still overhead and lack of real content management.

Thirdly you could build a separate page for each project, but store project content in Symphony as my initial suggestion. You can then tie a project entry to a Symphony page using the Pages Field, which creates a dropdown select box in your entry from which you can select a page.

Symphony gives you the freedom to achieve this in whatever way makes most sense to you.

I’m currently revising my site structure and having a Service and Projects page, so my templating is centred around the Services, with the Projects as add ons to the specific services - which obviously go off to a Project page.

So it’s possible to do pretty much anything as Nick has already said.

Thanks, Nick and, uh, Nick.

Thirdly you could build a separate page for each project, but store project content in Symphony as my initial suggestion. You can then tie a project entry to a Symphony page using the Pages Field, which creates a dropdown select box in your entry from which you can select a page.

This is what I had thought of doing, but then came to the question of how to input the project content, since each page would have different display of images, different numbers of individual text parts (e.g. a tagline, description, perhaps image captions, release notes…). I would probably use the Publish Tabs plugin to separate the home page info from the project page, but how would I define fields for the project page? It would be neat to do it on-the-fly similar to the Dashboard plugin, but I don’t think anything like that exists and I don’t have the skills to create it.

Another thought I had was a tab for HTML and one for CSS, which would somehow use the CodeIgniter plugin — or perhaps a field to edit the actual files for the CSS and HTML (in the form of an XSL utility).

Then there is the probable possibility that I’m making this all far too complicated and should just go with your second method, which seems like the best compromise.

@Beiju, I think a more simplistic approach is probably best. I’m trying something new myself using Keys, but I may be going to complex. :)

Can you not add a different class to the body and display a different CSS that way? Or if you want to serve a different CSS file to a different page, you could create a section for Meta Data and do some kind of trickery with that.

I believe this extension gives you the chance to display different meta data depending on the page you are on. Personally I would go with having 1 stylesheet and several body classes that show different styles.

each page would have different display of images, different numbers of individual text parts (e.g. a tagline, description, perhaps image captions, release notes…).

Ah, in which case a single section may not work for you. If your projects are significantly different then they’ll be pretty tricky to content manage, since a section is geared towards storing data with almost complete commonality.

You could therefore go with two sections: a master “Projects” list (just a name and page association, to allow you to build a list of projects through a Data Source) and a separate section for each individual project. The Static Section extension allows you to create one-off sections that will only ever have a single entry in them. You could tie the entry in each of these sections to a page in the same way.

This does however create a slightly messy content creation workflow:

• create an XSLT page to represent the project
• create the “placeholder” project in the Projects section, assign it to the page
• create a new section for this project with whatever fields you need, also assign it to the page
• create a Data Source querying this section, attach to the page
• modify your XSLT page to render the fields

Kind of negates having content management at all :-/

I would probably use the Publish Tabs plugin to separate the home page info from the project page, but how would I define fields for the project page?

So I take it projects have a common set of meta data used on the home page, and then a set of custom fields? If your custom fields are relatively simple (name/value pairs) then you could use the Subsection Manager section to achieve this. And unfortunately no, creating fields of different types on the fly isn’t possible.

Another thought I had was a tab for HTML and one for CSS, which would somehow use the CodeIgniter plugin

Which plugin is that? You could certainly have two large Textarea fields into which you can paste code, and split these into tabs.

A lot of your design decisions will come down to how flexible the content management needs to be. Do projects change frequently? Will it always be you adding them, or do less technically-proficient users need to administer the content too?

This is what I suspected would end up happening, but I thought it would be worth asking. Since it’ll always be either me or someone else who is proficient in web development adding them, I’ll probably keep the project pages in HTML (in the form of XSL files).

The revised plan is to have Symphony handle the project list and the rest of the home page. One field in the project list will link it to a Symphony page for each project, which will be hand-coded.

The other thing I considered was using Root Page Params to link project pages to XSL utilities via a ‘slug’ field in the project list. I would like this idea better, except that it requires mashing together the home page and the project pages, which seems very messy.