Symphony.

Hi all. Been lurking for a few months, but this is my first post.

I know that some folks choose to have a master page that controls which templates are applied. I’m working on a project where that makes sense, but I’m a little stuck on how to automatically generate the navigation. The utilities I see for navigation are page oriented.

I’m still early in confronting this issue, so any thoughts, general or specific would be very welcome.

Welcome :)

You’ll have to tell us a little more about what you’d like to accomplish. Where will your navigation data come from?

Thanks. Sorry if I was vague; I’m still hashing this out as I go. I figure I need to validate my larger concept of how this should work before I start running specific technical problems past the collective brain trust here.

My goal was to have users able to add content via a “page content” section, choose a content type (which will determine the template to apply), and easily assign a location in the navigation hierarchy for that content.

My first serious effort to get this working was to create a navigation structure via the Nested Categories extension, then include that as a select box in the “page content” section. However, I ran into issues filtering the content. I figured it was wise, considering my inexperience, to see if there isn’t a better approach before I sit down to hack this out.

Rex,

So it sounds like you’d like to use a slightly different model than Symphony guides you toward (i.e. using some internal piece of an entry’s data to determine the view XSLT rather than having the view XSLT decided by the Page that is loaded).

That’s fine & I think fairly common, because as you say, it’s much simpler for a user to add an entry (like your ‘Page Content’ entry) then it is for them to create a whole new Page, adding datasources and such.

Will the organization of the navigation be determined by the content type, or will different content type pages be arbitrarily located in the hierarchy of the site? Alos, how deep will the page nesting be?

Thanks for the bit of validation, Andrew. :) I’d gotten the idea via the forums here and it fit what I was trying to provide, so I was hoping I wasn’t being overly exotic.

The navigation organization is independent of the content type, so the latter preferably.

The page nesting is 6 levels, at maximum.

You’ve definitely got the right idea asking, lord knows I ask a lot of questions, and there’s always an answer!

I currently am building a site that uses the Pages Field select box extension which gives you pages to associate entries to, so I can have a simpler implementation of what you’re after. Although I would like to see Pages turn up like sections in normal select boxes, so that it could be used with Nils’ Subsection Manager field. That way you could create pages on the fly from an entry and get the effect you (and I) are after (I think).

Craig, any way this can be achieved with the 2 branch? Or are Pages and Sections too diverse to put together for select box links and the Subsection Manager?

What you’re describing about pages on the fly is just about what I’m thinking, as long as you could control where those pages ended up in the hierarchy.

As for you asking lots of questions, I’ve learned a fair amount from the answers to them, so keep up the good work and thanks!

The roadblock you’ll hit taking this approach to its ‘exotic’ extreme, such as only having 1 Page for the whole site, is the URL parsing. Since it isn’t really how Symphony is designed, as you mentioned, you won’t be able to filter your datasources. You won’t want to be querying, then XSLT-processing all of your site’s content with every request, so that’s a non-starter.

So you’ll need to create some Pages. For a solution similar to your needs, in the past I’ve only managed to avoid creating Pages 1 level above the lowest level. In that setup, you’re basically using a single URL parameter to filter your ‘page content’ entries, with special handling for the page-content entry of the Page’s content.

Creating Pages through the entry interface would be nice. Ideally, it would use a Page template (I think Craig made an extension for page templates, and it was awesome). Anyway, the field would be 2 dropdowns: the first would be Parent Page, and the second would be Page Template. Conceivably you could define the template while adding the field to the section, and the contributing user could select the parent page while generating the entry.

I’m in an early stage of writing a static content management extension that allows users with the author role to create pages with custom templates, reorder those pages and relate content to them. I’ll keep you posted.

I agree Andrew, you’d definitely need more than one page, so if users could create pages on the fly, they wouldn’t be locked in to any page structure defined by the developer.

My only concern would be the control over the structure of the website, but if that is the job of the authors, then it wouldn’t be an issue.

I just don’t know what the core teams thoughts are on this, and whether it is feasible as it would take a rewrite of the core code to get pages to show like sections. Maybe it could be something to think about for Symphony 3.

I like your thoughts on using the Nested Cats extension, I think it’s a real good addition to Symphony. It would be good if it could work with the Subsection Manager extension (i.e. like a normal section does) but as it’s a custom section, it unfortunately doesn’t which is a shame.

The Root Page Params extension is useful too when having to use a lot of nested url params, but as it only works on one page, I don’t know whether it can be implemented twice with different class names to get the same effect on multiple pages, although that may be off topic.

@klaftertief: Please do keep me posted. That sounds tremendously useful.

@designermonkey: Thanks for the comments.

Actually, thanks everyone for the thoughts. I’ll keep hacking to see how close I can get to what I’m hoping for.

I’m in an early stage of writing a static content management extension that allows users with the author role to create pages with custom templates, reorder those pages and relate content to them. I’ll keep you posted.

We normally do something similar without any extensions. Normally, I have a menu section (orderable, contains only title and description) and content sections.

The content sections can be linked using a SBL to the menu items (pages!), and the different pieces of content from different sections get a different template in xslt.

If you name your sections right, this should be pretty straight forward for any editor. (for medium sized websites atleast).

Hope this helps!

@creativedutchmen: What do you do about the restriction an SBL has on the number of items it displays? Do you just set an arbitrary high value for maximum items? I was a bit surprised to find neither blank value, 0 or -1 didn’t mean “unlimited”.

How do you handle nested menu sections? And do you customize the .htaccess to enable URLs which represent the menu structure (menu1/submenu2/../submenuN).

@creativedutchmen: Thanks for the tip. And I’m also wondering about the points froded raises.

My workflow for static content uses normal pages and sections with the Pages Field extension to connect entries with a page. The extension will be a wrapper/interface for authors to simplify the workflow.

I like using pages for static content because this way you can mix static and dynamic pages easily in menus and you have support for nested menus and corresponding URLs.

@klaftertief: That’s exactly what I’ve found nice with using normal pages for the overall site structure and thus static content as well. Hierarchiy just works, and you can easily mix types of pages. I’m looking forward to your extension simplifying the process of creating new static pages.

The main “hassle” is that you end up with a lot of template files for the static pages which is completely the same in a lot of cases. Obviously there’s the bonus of easily being able to customize parts of the static pages if need be, but for simple sites all static pages could really just use the same template. I’m thinking about possibly using symlinks to a common static page template.

The main “hassle” is that you end up with a lot of template files for the static pages which is completely the same in a lot of cases.

Craig’s extension used a ‘template’ page but generated iterations of that page that were then editable. I wonder if you could create a template that would actually be used for every instance of the page (to avoid this problem).

This discussion reminds me of the older one here. From the standpoint of developing a site and handing it to a client to maintain content, this page organization / creation issue is one of ExpressionEngine’s killer features (even though you have to buy the commercial Structure module to get it.) I think Concrete5 has also worked this out pretty well.

I’m excited to hear @klaftertief is working on an extension — I would be much more inclined to use Symphony as a client CMS if this capability was available…

@froded: There shouldn’t be the need for symlinks. You could create a page template utility and just import it from your static page template, optionally create with the Page Templates extension. THe template would look something like this.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:import href="../utilities/static-page-template.xsl"/>

</xsl:stylesheet>

@ashooner: Yeah, actually that’s where I was planning to go with the successor to Page Templates. It was called “Archetypes” or something, and I wanted to allow a user to have the choice to either spawn independent iterations, as before, or to create dependent pages that just sort of “extended” the archetype itself.

Never got far with it though because then I wandered off into thinking about whether it would be possible/desirable to decouple templates from pages altogether and just combine templates and utilities into a library of XSLT stylesheets that could have hierarchical or even OOP-like relationships. And then I wondered how you might be able to give that a usable UI… And then I wondered whether that approach would really be an improvement anyway… And then I wondered…