Symphony.

Branches are collapsible and Pages are sortable.

This would be a very cool extension

I’d love to see something like this as well, to the point that I’d pay for the development cost, I’ve spoken about it before, its the main barrier at the moment to using Symphony for client sites at work.

I agree, would be very useful to have this sort of view for the pages display. I’ve been wanting to develop an extension to make dealing with “static” content and hierarchical easier and this would be a good a start to that.

Does anyone have opinions about the best way to deal with “static” content fields? I’m wondering if perhaps distinct sections tied to a page is the right solution.

Regarding static content: At the moment I am a big fan of the Static Section Field extension. Still have to use it on a bigger website to see the pitfalls (if any).

@michael-e: I’m not sure I see how you’d use the Static Section Field for general static content. Doesn’t that extension simple lock a section to only allow a single entry? Or am I missing something.

Simon’s Page Fields seems to be more suited to the idea of tying data tightly to a page—I was thinking of an add-on to that which lets you tie specific sections to pages with a page field. Thus you could have various sections for different template/page structures in your site but then be able to tie them together in a hierarchical interface.

If you lock a section with a Static Section Field, you will always directly be taken to your single entry for that section – just like the Page Fields extension does. Now simply name this section “Static Page 1”, build a Datasource for it and use this for your page Static Page 1. Using navigation grouping, you can put your section under a Pages tab – the result is rather close to what you do with Page Fields.

I haven’t tried out the Static Section Field but it looks like an interesting alternative to my extension. I’d be interested in knowing what people’s thoughts on the different approaches are and if there is an even a better approach that takes elements of two.

To be honest (and this just my take…) for Symphony to really get a large adoption this type of functionality needs to be in the core along with the “entry order” concept and a handful of other extensions. Having used other tools/programs that also rely heavily on plugins/extensions it’s inevitable that a lot of extensions stop working and stop getting supported over time. It’s also another thing that makes it difficult for people trying to get their head around the system. - If someone was using Symphony for the first time, for example, how easy is it for them to know that: * The entry order functionality isn’t built in. * That there is an extension to do this. * That the extension is called “Entry Order Field”. * What versions it’s compatible with. * What state of working it’s in.

?

Sorry, my misunderstanding—those two extensions indeed do very similar things. My misguided impression was that the Page Fields extension let you define a single section for associating with multiple pages.

It feels a little messy to me to have a different section for every page you want to define content for. I think it’d be great to extend the idea of the Static Section/Page Field extensions to let you do what I mention above. Namely define a various hidden section as the main “content” block for pages within Symphony. That way you can have a couple of different sections for static page-y content if need be but without having 27 individual sections alongside your 27 individual pages.

I don’t think my solution is particularly perfect either because you don’t necessarily want to create Pages in Symphony for each URL endpoint within the site. In the page I’ve generally created hierarchical page structure using a single section with parent-child relationships using the Select Box Link and while that works it’s not particularly intuitive from an authoring perspective and doesn’t give you the flexibility of structure that the approach outlined above perhaps might.

@skeary: Yes, I have also thought about a feature request for “static sections”. It would be great to have something like this in the core.

@Makenosound: Different sections for pages may be very useful if there are lots of custom elements (“fields” in Symphony speak) on pages. If the elements are the same, you do not need static sections at all. You may work with a standard section and include a page select box (using the Pages Field extension, maintained by the Symphony Team – this is not the Page Fields extension we are talking about here!). Then you can easily filter the output of your datasource to match the current page.

You may work with a standard section and include a page select box

@micheal-e: that’s the method I prefer. One filtered data source. Works well.

Yes, so do I, normally. But when it comes to a combination of complicated HTML pages and authors without any HTML knowledge, a static section method will come to the rescue. It will allow you to have editable content fields and do all the HTML magic via XSLT.

I’d like to hear what Alistair thinks about this. I don’t think a section for pages will ever really cut it because of the amount of possible pages/sub-pages you could have, the interface would quickly become unusable, deep tree structures would be difficult to figure out. I had to use Expression Engine over Symphony recently for that very reason.

I’d say that to do an all-in-one page management module for Symphony would be a fairly large undertaking and would probably mean a core re-write. Maybe I’m wrong? (Hopefully!)

If you’re familiar with Expression Engine check out Structure it pretty much nails it.

Symphony is about simplicity plus flexibility. So should the solution be. I was thinking about a checkbox in the section editor saying “static section” (close to the “hide this section…” checkbox), providing the same result as the Static Section Field extension. Everything else, like navigation grouping, could be done by existing Symphony features.

Regarding the original theme of this thread: Yes, this would be a nice addition to Symphony. I have websites with nearly 100 pages in Symphony – hard to administrate sometimes. I am curious if someone can write an extension for this. Maybe grouping could simply be done with jQuery using the URLs of the pages which are displayed in the table (Symphony 2.0.6)?

Just stumbled across this thread again.

Shouldn’t we post a feature request on the bug tracker regarding the “static content/static section” functionality?

Again I played with the Page Fields extension. This approach is very interesting, especially for big websites. If we think about new Symphony features… I love the Static Section extension because of its simplicity, but I love the Page Fields extension because of the streamlined workflow it provides. You do not even have to create a datasource, nor attach it to a page – everything is done automagically for you. Besides development speed this has a second, maybe greater advantage: Your admin area won’t get cluttered.

Is there a scope for explaining if using a Section called Pages could be used to add entries and construct hierarchy in the nav tree that way? Then we effectively have a dynamical way of building static pages with Title, Body meta and published fields for each one that way.. anyone point me in the right direction to topics on this approach?

Shouldn’t we post a feature request on the bug tracker regarding the “static content/static section” functionality?

This is very much on the radar for the next major release.

This post was useful in gathering a lot of info as to how the structure can work. Allens input on Pages as Section

A tutorial showing the steps would be a great introduction for noobs and a great ease in to one of many methods that symphony can be used for site structuring. And the suggestion of some sort of extension to list the Pages by hierarchy would be sweet.. Nested Categories was an extension that looked quite interesting as a starting point before, but it wasn't working on a 2.0.4 install when I last tried.

to the point that I’d pay for the development cost

Funny how often ppl say that in open source projects and the feature still won't show up for ages if ever.

I wonder if a Kickstarter or similar fundraising method might actually work for adding popular features to an opensource project.