Symphony.

I’ve had another idea for a cool extension. In my opinion, the main obstacle for using Symphony as a client friendly CMS is the lack of a simplified page manager, you can set one up using sections but you end up having all pages with a uri like www.domain.com/pages/contact-us instead of www.domain.com/contact-us/.

What I’d like to see in Symphony is an extension similar to ngen’s Structure Module for Expression Engine, which uses the same concept as symphony (creating sections like databases).

So you’d have a list of all entries in say the “Pages” section, any child pages associated have a show/hide toggle, each page would be re-orderable, when you click to add/edit a page you get the usual entry form except there’d be an additional space for adding the master utility that’s associated with that page (template) via a drop down, also meta tags like title, keywords, description, character set (maybe a way to add extra meta tags via js).

When displaying these pages we’d probably need to use .htaccess to remove the section from the url.

I dont know if Symphony could actually facilitate something like this but I think it’d be pretty sweet if it could.

Any opinions welcome.

There is an extension that may be doing a little bit of what you are thinking of: Improved Page Resolve.

It simply catches all requests to non-existent Pages and sends them to the index-Page, passing the URI as parameters.

For example when you have the following pages: /blog/, /pictures/, /p/ (index)

/blog/article/ -> /blog/article/
/some/page/ -> /p/some/page/

@eoghanobrien: I agree, and I’ve been thinking about building an extension along the lines of Structure for a while. Hadn’t really nutted out any of the details yet—but something including the Improved Page Resolve and perhaps the Page Template extensions might be a good start.

If you have any idea/suggestions for implementation let me know.

@eoghanobrien,

I’ve pursued a setup as you’ve described; it’s still a long way off from ideal. Here’s what I do:

I have a ‘static pages’ section, which contains all the extra fields you’ve mentioned (metadata, doc title, etc. as well as the content areas for my static page model). This section has 2 structure related fields: “Symphony Page” which is a ‘page select’ field, and ‘section index’ which is checkbox.

When I create the Symphony Pages (now very easy thanks to the page template extension), I use a single $static-page-handle url param. When one of these Symphony Pages is requested, the associated static-page is loaded (with the entry checkd off as ‘section index’ being loaded when there is no static-page-handle value.

My navigation DS is generated dynamically using xsl that integrates the standard Symphony nav with my static-pages data.

I used to keep the static-page data totally independent of the Symphony Pages (using a select box pointing to itself to specify the parent page) but that got messy b/c it required naming the static page entries the same as their corresponding Symphony Pages.

You mentioned changing htaccess, and I think that would be required to modify the way Symphony handles Pages. The way I organize my sites, I completely abstract different page ‘types’ into page applications; I have a static page application, a blog application, etc. Unless I have some special module that is being dropped into the content of one of those apps, the only thing unique about my Symphony Pages are their location in the site (DSs, events, and xsl are all the same for each page type).

I would love to be able to specify a page ‘class’ and be able to map those classes to urls into a sitemap.

I’ve also implemented user pages functionality in the way described by @eoghanobrien and @ashooner. It works well but a way to control the URLs better would be excellent.