Symphony.

So building a new CMS built off of symphony and the question has been asked: "SO will we be able to add new pages and content ourselves?"

Which I answer Yes and NO.. Thinking that Yes is the long winded answer at present, where I would need to explain the sections and Data sources and also templates maybe.. short answer is obviously, No and come to me when you want to add a new page… Seems like a dilema we’re all facing or just my narrow minded approach to a CMS for a client!

So, what is the easiest workflow to allow users to create new pages and populate them with content from sections?

Is page templates the way to go? heard it was not gonna be developed anymore for 2.0.6. Peoples thought here would be greatly appreciated.

We define producer flow on a case by case basis, often going so far as to interview stakeholders, define user cases, document data flow and IA the user interface. Sometimes we’ll build out a unique interface, tailored to a client. Sometimes we’ll give them access to the standard Symphony administrative interface.

I guess what I’m saying is that there is no right or wrong way to tackle this.

For what it’s worth though, we’ve had very little trouble in those instances where a client has been given full access to the standard backend. One of the reasons for this is that we also provide training, which goes a long way to mitigating the issues that you would expect with a hands on client.

I think a client user should not have to deal with xslt, even if it is copying and pasting xslt from an existing page toa new one. I would not expect a client using Wordpres to have to edit a php-based template; to me its a matter of professional expectation.

Often client contributions don’t require actually Page creation, since they are creating entries that will generate their own URLs (blog posts, or whatever). When there is a need to add an extra ‘static’ page, that is where I run into problems b/c that does also require a Symphony Page.

Since I am creating an entry to go along with every Symphony Page I’m using for static content, I’ve thought about trying to create an extension that would combine the Page Templates extension with the Pages Field extension. This could let a client user create a new static page(both the Page and the entry) through the entry creation interface.

Often client contributions don’t require actually Page creation, since they are creating entries that will generate their own URLs (blog posts, or whatever). When there is a need to add an extra ‘static’ page, that is where I run into problems b/c that does also require a Symphony Page.

I think it’s a case of managing client expectations from the beginning. If you develop a site map early on, be clear about where clients can and can’t create content. Since Symphony is an object-based CMS and not a page-based CMS, you’re making problems for yourself if you tell the client they will be able to “add pages anywhere in your new website”.

As Joe says, at Airlock we often give clients a login to the backend. However these logins are seldom developer accounts with access to the Blueprints. Clients are trained carefully on editing entries within sections, but we don’t cover creating (Symphony) pages. In Symphony-land, that is reserved for developers.

Maybe you need to define content with your client? Are they expecting to modify the hierarchy, structure and RESTful URLs of their website (content), or are they wanting to edit the text information of their website (also, content).

Depending on your requirements, it can be done. On one large project we needed pages to sit anywhere, and for pages to be infinitely hierarchical:

domain.com/page-1/page-2/page-3/page-4/...

To build this there is a single section “Pages”, which contains:

• Title (input)
• Content (textarea, Markdown)
• URL (custom field)
• Parent (select box link, recursive)

“Pages” are assigned as parent/children using the Select Box Link. The custom URL field, upon saving, stores the relative URL to that page, e.g. for a page titled “England”, its saved “URL” text would be:

universe/earth/europe/united-kingdom/england

(Where the other URL parts are parent pages).

With some hacking of the .htaccess, these requests are intercepted and sent through a single Symphony page “Show Content” which accepts a single URL Parameter “url”. The Data Source takes the above string, filters the “URL” field, and returns the entry.

It’s not particularly elegant because it needs a level of customisation, but it worked for this one example.

If you pages don’t need hierarchy, then a section-based approach can still work. Create a single section “Pages” with whatever fields you need (perhaps Title, Content, a Mediathek field for images) and filter the Title handle on your home page.

So your Home page has a URL Parameter “handle”, and you filter your “Pages” section on the Title field with the value {$handle}. If you have a page titled “Woo Yay” you’d display it as:

/home/woo-yay/

Would this be enough for the client to have the illusion of creating new pages?

Nick, thanks for the in depth heads up here! I think the no hierarchy approach is best suited and would satisfy the clients need to add new (static content pages) and the dynamic ones (blog entries/news etc) are sections built for them before site deployment by myself with no scope for alterations by client unless requested.