Symphony.

If I understand you correctly Mediathek allows me to do that.

Yes, that’s exactly what Mediathek does.

Often clients need to be able to manage files in the CMS: add (multiple) images, preview them, rename, etc.

This is still a missing feature in Symphony. And a perfect solution still needs to be found. In a few use cases Mediathek might help here as well: It’s possible to drag and drop items from the Mediathek into textareas. They are inserted depending on your text-formatter settings (Markdown, Textile or plain HTML). You can then manipulate the output on your (frontend) page easily using some advanced XSLT techniques.

As for a file/asset manager: Often clients need to be able to manage files in the CMS: add (multiple) images, preview them, rename, etc.

I usually use sections in an Assets navigation group to manage different types of files. The different sections have an (unique) upload field with validation rules for the according file types and some fields for metadata. I can link entries of those sections with the different section link fields (Select Box Link, Mediathek/Subsection Manager, …) to the content sections.

The static-/content-pages issue is far more important to me though, so hopefully extensions like @klaftertief’s Page Prototypes will soon address these.

The Page Prototypes extension is a building block for an upcoming static content management extension. There are some screenshots attached to this post. I still have do think about the feature set. There are many ways to implement static content.

Attachments:

scm_pages_content.png, scm_pages_edit.png and scm_pages.png

@klaftertief looking good. What I don’t understand, however, are the ‘entries’ in scm_pages.png

Would the entries in those static pages be various ‘blocks’ of content? Like the ‘pages’ and images you explained in your first image?

(Forgive my ignorance)

Would the entries in those static pages be various ‘blocks’ of content? Like the ‘pages’ and images you explained in your first image?

Yes. The idea is to define different types of content as sections (“Text” and “Images” in the example) and to connect entries from those sections to the page using the Pages Field extension. I’m “just” building a new interface that puts the Page as the main context to display entries.

Hey guys,

So I was studying Symphony a little more, but I just couldn’t get the mechanism of ‘filter’ in ‘sections’ straight. I would greatly appreciate if some of you could help me understand just a little further.

As I have mentioned earlier in the post, I have 1 section with 4 entries(which ultimately serves as the menu and its contents; ie. Home, About us, Menu, Contact us, etc) underneath, and 1 Data Source with DS-filter($page-title).

An alternative was suggested by @ashooner, and I was able to filter with $current-page-id by using the page-field extension. This also worked.

Then I started to wonder, ‘Wouldn’t it be much simpler if I just filter by the entry id in the first place?’ so I tried using some parameters that I could think of, like {$entry-id} but it didn’t return anything.

The 4 entries that I’ve created seemed to have their own ‘id’ assigned but is it possible to call it directly without having to filter by its ‘page-title’?

Thanks in advance for your help.

The most simple way to define a Data Source filter is to put some static text in the filter input element. Some fields provide a list of sensible candidate values, like page names from the pages field. They appear as a list of values under the filter input element and you can click on them to fill the input element. It depends on the field how the value of the filter input element gets processed. The pages field knows how to filter by page name and by page id.

Do add some dynamic behavior to the filter you can use parameters in the filter input element. You have to use the curly braces syntax then, like {$current-page-id}. This tells Symphony to parse the content of the input element input, it evaluates the parameter. You can find predefined parameters ready for filtering when you got to a front-end page and append ?debug to the URL (you need a backend session for this).

To make it really dynamic you can define URL parameters in the pages administration. Adding foo/bar in the URL parameter field of page dynamic-page sets the values of the parameters $foo and $bar to value1 and value2 when you visit /dynamic-page/value1/value2/.

Does this make sense?

And have a look at Data Source Filter and URL Parameters parts of the documentation.

@klaftertief I am wondering how things are with your plans for a static content management extension. I noticed you updated Page Prototypes (with which I have no experience yet) to Symphony 2.2 but are you still planning/working on some magical Static Content/Page Management extension?

I haven't done any further work for the static content management extension. Not enough time and the lack of a project for it. The Page Prototypes extension was one piece of the puzzle, but it's still useful on its own.

I'm still thinking about better static content management, it would make a nice ensemble. But I'm not sure if the backend is the place to create an interface to map entries or a list of entries to a page. I just doesn't fit the philosophy of Symphony. And with a soon to have proper members extension it's going to be easier to build such a system in the frontend.

So, no proper plans, just loose ideas. And I don't really want to build a page-tree based CMS on top of Symphony.

I understand. How best to manage static content (and hierarchies therein etc.) is one of the aspects of Symphony that I find most difficult to grasp.

There are so many ways to handle this (a plus) but at the same time the constraints of a page-tree based CMS (such as Wolf or Wordpress) make this much of a no-brainer. The amount of Discussion posts on this topic testify to the fact that I am not the only one struggling with this. Truth is also that my clients have come to appreciate and expect this functionality (even though it's seldom used).

It might be unrealistic but I would be greatly helped with some more direction on how to best approach this issue. An article like "3 ways to manage static content" (with pros/cons and tips/tricks) would be very welcome in the Symphony Docs. At the moment I (and others) must dig through threads and threads of forum posts and put the pieces together.

Don't get me wrong: I love Symphony and the freedom it provides. I understand that the request of static page-tree-like functionality might not be appropriate for this system. I love this helpful forum and I (actually) love finding puzzle pieces and putting them together by myself.

I am just a little bit frustrated that I can build a Symphony site that magically pulls in, and transform, XML data through a REST Api from another site, while magically transforming images on the fly, in minutes […] but that I can not seem to find a nice way to structure and manage (static) content pages… ;-)

I totally agree, and have said so before on the forum. I love Symphony for complex projects, but I often hesitate to recommend it at work with simple sites because clients have come to expect a hierarchal page setup where they can visually see the relationships and easily create parent/child relationships.

I've been thinking about this quite a bit, too. My current opinion is that we should build an extension like EE's Structure, which completely overrides the default way EE handles its page/template rendering (I think you do this selectively on a per-section basis.) Trying to force tree-based page hierarchy on top of Symphony's existing philosophy for Pages just isn't going to work. We need a standalone extension that handles this specific use case.

The challenge, of course, is doing this while not losing any of the other cool stuff you can do with Symphony's Pages. However given that we have no such capability now, I'd be willing to forego a lot of other functionality to do simple nested pages.

Jonasd agreed A Structure-like extension would be great. This should (I think) completely bypass Symphony pages (except maybe for a 'base' /page/ page or something). This way you could still use the default Sym.Pages.

@jonas and @david: wouldn't this be pretty possible using standard sections/entries?

Ofcourse, the ordering in combination with the child/parent relations are not as easy as that, but still. These changes will be a lot easier to implement than a complete rewrite of the fundamentals of pages.

@Huib probably. I don't think, however, that a "rewrite of the fundamentals of pages" is needed. I'm thinking of an extension, working with Entries, rather than Symphony Pages. Just another way of doing this (besides using Symphony pages).

I keep struggling with this. For example: at the moment I run into a very simple issue (I think) that's driving me nuts: I have a Section Page Content with entries that are linked to a Symphony Page through a Pages Field. This is a familiar setup for many Symphonians I believe.

On some pages I need to display the Page Content of subpages but I cannot seem to find a way to properly get the parent page. There is no {$parent-page} and the Navigation DS (which I could use to get that data since it can filter on parent) does not output a ds-param!

I could, obviously, add another SBL 'Parent' to Page Content entries with a recursive link but that would require editors to both select a Symphony Page and a Page Content 'parent'.

Why can't the Navigation DS output a ds-param? Why is there no {$parent-page} param available ({$parent-path} is…)?! I might approach this completely the wrong way but it seems too hard for something this trivial…

I'm thinking of an extension, working with Entries, rather than Symphony Pages.

Oh, my bad, I misunderstood.

Why can't the Navigation DS output a ds-param? Why is there no {$parent-page} param available ({$parent-path} is…)?! I might approach this completely the wrong way but it seems too hard for something this trivial…

I agree, I think this is a bug (or a missing feature, at least!)

If there was a $parent-page param, this would be relatively easy, right?
You can always add this yourself if you are comfortable hacking the core.. (line 328 of lib/toolkit/class.frontendpage.php)

@Huib, I'm not sure if it's technically possible to build upon Symphony's standard capabilities to achieve the desired results (I'm probably not the guy to ask!) But it seems like every time someone proposes a solution using built-in functionality, there is always a comment like, "this works fine except you won't be able to do any sorting, or pages deeper than three levels, or it's mainly a javascript hack..."

Structure keeps coming up because EE is like Symphony in how it treats entries and their relation to pages (nee templates) for URLs and routing. That method, and Symphony's, are fantastic for lots of things, but for this particular problem they don't work very well. It seems like working around it (and maybe just using entries as David suggested) would actually be easier.

@Huib thank you for your reply.

I believe it is a parameter that should be part of the core. At least because {$parent-path} is… Bauhouse agrees :-)

If there was a $parent-page param, this would be relatively easy, right?

Well, I have no 'parent' in my Page Content entries. And, in this case, I need all childpages of the current page. So in this particular case it would be better if a Navigation DS could simply output a $ds-param. The Navigation Source can be filtered on parent so I can feed that {$current-page} and get all child Symphony Pages. This output could be used to feed another DS ("get all Content Pages").

You can always add this yourself if you are comfortable hacking the core.. (line 328 of lib/toolkit/class.frontendpage.php)

I'll take a look, thanks.

@Jonas: Well, technically this would definitely be possible.

The only (fundamental!) problem I see is with pagination. As described before: how would you re-order between pages? If you have a large sub-page list spanning more than one page, what would the next page show (parent / no parent)? Ofcourse, this can be easily worked around by just removing the pagination.

Hi all, thought a bit more about how I'd like to handle static content for new pages with clients and Page Prototypes is a really great way of setting up this functionality, not working with multilingual content at present though :(.

Question for the core devs: How easy/difficult is it to attach a content box (with optional wysiwyg) to each page created under the Blueprints>pages admin area? i.e We already have the Title of the page and the url structure as well as any datasources we want attached.. is there any scope to add a default content block that creates it's own datasource when the page is created and the default template includes a $page-content param maybe? This would serve a very basic requirement for any page created and allow the admin to decide to include the DS or not when setting up the page. Just a thought from someone who finds the idea of creating a new section for each page a bit annoying.. not to say I haven't used it.. but just wondering if static content association was available as an option from the off when creating new pages would be a great help.

I believe there is a delegate that allows you to inject new fields into the page editor already (going from memory here, on my phone :)) Could someone please add an issue in the tracker about implementing output parameters for the navigation datasource? Same with $parent-page. Thanks!