Search

Hello,

I'm relatively new to Symphony and I'm starting to love the flexibility it gives. There is one thing though that seems to greatly limit that flexibility and that is the Pages concept. I don't seem to understand why Symphony uses Pages instead of using Templates and letting the url/params be managed differently.

From what I gather the Symphony philosophy is that the core should be extremely flexible and that extensions should be used for different scenarios. To me the Pages management seems to be the opposite of that philosophy. You end up using extensions to make it more flexible.

Why not use a Template for pages, sections and data sources so when a users creates a new page, for example "blog2" and selects a template than symphony creates the "blog2" page, the "blog2" section (be it one entry or not depending on the template) and the "blog2_ds" datasource.

This goes out to the more experiened Symphony developers, maybe you could explain why this architecture was chosen and what do you think about this.

Thank you and sorry for my english.

Alex, first of all, welcome!

From your post it seems to me as if you misunderstood how pages and sections within Symphony work. I had typed a whole response trying to explain it, but I came to the conclusion that the best thing to do is to install the default workspace, and take it for a spin.

Anyway, here is a very brief explanation of the key concepts. What you are suggesting right now is pretty much how it already works. The only difference is that within Symphony you don't think in Pages and Posts as you would in any other system. Instead, there are entries. Entries can be anything you want them to be: pages, posts, tweets, comments, anything. They are essentialy your building blocks.

Now, because Symphony needs to know how to display these entries, you have pages. What pages do is they take entries (from a datasource), transform them into something beautiful (usually html, but json and XML are possible, too) and give them a place to live on the internet (a URL).

Because of this, you can use the same page for all your entries in the blog section. The only thing different is the parameter in the URL, which you will use to filter the entries that are fed to the page. So, this makes it possible to have urls like; example.com/pages/page1 and example.com/pages/page2 served by the same page, transformed by the same template, fed by the same datasource, taken from the same section, but with different content (entry).

If you need a real-life example: this website is built using Symphony. If you look at the URL you can see you are currently on the thread page, which filters the threads section by its ID (currently you are looking at thread #95634.) If you were to visit a completely different thread, you'll see only that ID is different.

I hope this makes a bit of sense!

Thanks for the response although I already understand what you wrote. I think I didn't explain too well what I meant.

In your example you propose to keep all entries in the same section and filter them by page.

When you create a page you must specify your data sources but you can't specify a model (template). I dont want to specify a certain data-source (which in turn works with a certain section). I want to be able to dynamically create new data sources and sections based on a certain page template.

For example I want to be able to create a section named "Site pages" and let the user add any kind of page he wants. If he adds a static page than a new one entry section and it's corresponding data source are created based on a predefined template.

Thanks

I want to be able to dynamically create new data sources and sections based on a certain page template.

For example I want to be able to create a section named "Site pages" and let the user add any kind of page he wants. If he adds a static page than a new one entry section and it's corresponding data source are created based on a predefined template.

Well now ... :) This is the holy grail for site builder, don't you think? For sure this functionality can be achieved through Sections, Pages, Datasources and some custom PHP code (residing in extensions).

Symphony is flexible enough to allow you to build that system but you will have code it yourself.

PHP is not really my strong suit but I'll come up with alternatives. Is there any reason why Symphony couldn't/shouldn't treat the pages, sections and data sources like templates?

BTW, thanks Vlad for all your multilanguage extensions. I'm starting a project soon involving some hotels and their making my life a lot easier. If you're ever in Bucharest I'll buy you a beer :)

For example I want to be able to create a section named "Site pages" and let the user add any kind of page he wants.

What do you mean exactly there? If you say you want to create a section which basically allows the user to apply different templates to a page this is very much possible.

What you have to keep in mind is the data-sources required for each of your templates for example when a user says he wants his page to be static, you are just creating an entry in your static-pages section (rather then a new datasource I presume) however if its a fancy-list-page you should have a datasource somewhere which allows you to create this fancy list. What you would need is some sort of link or portal to jump in between sections & linking them together. One example could be sub-section manager but I don't think that its ideal.

I'm not sure if I grasped what you want to do; but if yes I'm sure I could help you discover how to do the template-switching part, as I've worked on something somewhat similar before.

@gunglien Although I deeply cherish the existence of the Subsection Manager it's not always the right tool for the job. In essence, as I explained, I want to be able to dynamically create sections and data sources based on templates.

I know there are ways to make it work but I find them a little counterintuitive. So, the question remains: Is there any reason why Symphony couldn't/shouldn't treat the pages, sections and data sources like templates? I for one think it would be more flexible this way but I would love for the more advanced users or the core devs to chip in.

I never said the answer should be Subsection Manager it could be one way of achieving the target albeit inefficiently.

To Quickly answer your question; I don't think there is dynamic need to have templates the way you describe.

This is simply because

  1. You have a pre-defined number of pages that you are already defining
  2. Creating identical copies of sections is not Ideal, with your template concept I understand that creating a page of type X will create section Y with datasource Z. You should in-fact focus on having a singular XSLT template a single section and a similar data-source; and you would just add a field within your section which links up the content to your page type, then pull these accordingly using the datasource.
  3. Concept of data-source templates already exists to a certain extent however not how you describe it. It is now possible to have custom data-sources being easily extended (through the data-source interface)

Other then that there's an extension Scaffolds in the making which would allow you to easily port Sections & Datasources across projects; and use it as a base for imports. Currently however only the sections bit works.

The concept you seem to be hinting at is a page based CMS, which are probably the most common and as a result, developers expect all CMS's to have the same workflow. In a page based CMS, a user would say, let's build a contact page and then expect to add contact information on that page, the forms to be added automatically etc.

Symphony is not a page based CMS. It is a content first CMS. What that means is you essentially build your sites in reverse where you will decide what content you need and create a Section to best structure content that way. data sources then expose this information to a page (or pages) on the frontend.

For a user this incredibly powerful as they can create content once and have it displayed in different ways across their site. It takes a while to adjust to this way of thinking, but in my experience when the penny drops for clients, they couldn't be happier.

Hope that helps explain why Symphony is the way it is :)

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details