Search

Just a thought from someone who finds the idea of creating a new section for each page a bit annoying..

i almost exclusively use this method in conjunction with the beloved static section extension and publish tabs for pages with several unique pieces of content. i can see your point in that it is repetitious and probably frustrating to create a section and a datasource for every page - i finished one project in december that had ~50 unique pages.

however, i have won clients' hearts with this approach because not only is it easy for me to quickly adjust the structure of the content at the client's whim (think of turning a static page into a blog-style, picture gallery, or file repo) but i can easily leverage symphony's main menu to almost exactly mimic the front end's navigation, which is what the client is most familiar with.

combine that with some well-named fields and a simple wysiwyg and you've got a pretty solid simple site that makes even the least literate client feel like they have complete control over their content.

@fawx, thanks for your comments. How does your 50+ entries look in the section on the backend? If each PAge is a section entry.. doesn't the backend become a nit unmanageable with regards to editing the static page content?

@moonoo2 quite the contrary. at first it may sound overwhelming because the size of the menu is larger than what most people might consider an orthodox symphony setup, but for the user it's extremely convenient because they'll find the section they need to edit in the same place (structurally) as the front end of the site, rather than having to read through a list of a) pages or b) entries in a large "page content" section.

edit: example

Ahh Gotcha! that's a neat way of doing it! thanks for sharing.

@brendo, oooh I'd be interested in knowing if it is possible to inject new fields in the Blueprints Pages entry... would this be a core hack though? or would I need an extension to perform this? Refering to your post

@fawx

I'm using the same idea with 1 section / static page. If you are kind enough to enlighten me regarding the image with menu:

  1. If all your pages reside in menus, what's the point of All Pages tab?

  2. Is "About our school" a static page or only a container for other pages?

@vladg:

"all pages" is content that spans the entire site. in this instance, there is a small image slider in the footer as well as some footer links to documents that may be updated by the client.

"about our school" is a top level navigation item which in itself does not have any content. it's simply a container. should the user click on that rather than selecting a submenu item (since semantically, it is a link), i use huib's amazing redirect to subpage extension.

Thanks for making it clear, fawx.

no problem! i love finally feeling like i have something to offer, and building the simplest, low-budget websites with symphony is most certainly my expertise ;)

@fawx, I have not used my redirect to subpage extension in a while, would you say it is still compatible with the latest versions? If so I will update the extension page.

the last version i used it with was 2.2 and it worked just fine.

I know this is a bit old, but it pops up high in a search for how to handle static pages. I'm really new and had the same initial question. For a site like the one originally described, with a low number of static pages, why couldn't you just create a page and include all the content in the template itself?

For my idea of a small site you may have a very small number of truly static pages ("About Us" or similar that are always easily accessible in the navigation areas) as well as Blog, News, Forum or other similar sections. It seems like the quickest and easiest way to establish static pages is to write them in the individual templates. Then the real capabilities of Symphony (Sections, Data Sources, etc.) are applied only when creating more dynamic pages that would be much more difficult to handle without Symphony or that would require much more interaction from a client or user.

Am I overlooking something?

For a site like the one originally described, with a low number of static pages, why couldn't you just create a page and include all the content in the template itself?

This is the route I take for my personal site, because I’m comfortable sticking that static content into the template itself. It’s fine, but it does have a few disadvantages:

  • Clients can't edit the content the same way they can section content, so it's undesirable if you have non-developers who need to change that content.
  • It isn't accessible through data sources. You can't serve up the content elsewhere (e.g., excerpts in the navigation dropdown, search results, widgets on another page). Symphony makes Create Once, Publish Everywhere easier, and this method short circuits that.

Like I said, I do it, and Symphony has not eaten me (yet). Just be sure that content isn't better off accessible through the database.

@tachyondecay - Thanks for breaking that down. It was very helpful. However, after working with Symphony for a couple more weeks as a beginner, it is getting clear that:

Symphony makes Create Once, Publish Everywhere easier, and this method short circuits that.

can have a bigger impact than I expected. I thought my site was pretty simple so I was happy creating independent pages for almost everything I considered static and adding code to individual template files. Now I have 20+ "static" pages (including sub-pages) and I wanted to add an administrative menu that would pop up on any page if a user is logged in. Should be pretty simple right?

I used the logged-in-author data-source and some lines from the master.xsl and navigation.xsl files in the sample site that comes with 2.3 to do this. But, in order to get the menu to appear everywhere, it looks like I need to add that data-source to every page I've created. I would have less updating to do if I had put more thought into serving content with Symphony's tools. It's still better than adding the menu code to individual .html pages.

Adding datasources and events to pages has been greatly facilitated in 2.3. Just so you know, I never really enjoyed attaching ds on every page... :)

To kanduvisla:

For example: www.yoursite.com/page/about-us could load page.xls with handle ‘about-us’. The datasource could filter on this handle to only show the entry of your content where the handle is called ‘about-us’.

How do I do this? Explain beginner do not understand. Or show how the pattern looks about XSLT.

Or step by step? It is better to see once one.

Its pretty easy.

  1. You should have create a page (from blueprints > pages) named page
  2. Created a section to contain your pages (structure as you please)
  3. Create a datasource from the above section with filter for the title field matching {$title} assuming you have a title field in your section.
  4. Attach the datasource to the page
  5. Design your XSLT > If this looks too hard I suggest you look at examples and research a bit. if you don't know how your XML is going to look like just add ?debug at the end of the url when logged in as admin

Did everything as you wrote. Have difficulty with XSLT. I can not find examples. Can show?

You should be able to find plenty of examples in these ensambles (pre-set up symphony installs). And you shall find some XSLT utilities that you can download and use. I would suggest that you start looking at those examples and do some research when you do not understand.

Yo try some things you might also want to use xpathr

The majority of Symphony users are willing to help if you've spent time researching your issues. I know most here find that Google is helpful, and when you have an idea of how to do it, we can help you refine that correctly.

There are resources out there.

How do I do this? Explain beginner do not understand.

No one ever learns anything by being told how to do it outright ;)

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