Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

We've moved the forum!

Please use forum.silverstripe.org for any new questions (announcement).
The forum archive will stick around, but will be read only.

You can also use our Slack channel or StackOverflow to ask for help.
Check out our community overview for more options to contribute.

Themes /

Discuss SilverStripe Themes.

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo, swaiba

multiple Page.ss files i.e. in the theme and subthemes?


Go to End


1454 Views

Avatar
inCharge

Community Member, 102 Posts

10 June 2011 at 10:02pm

Edited: 10/06/2011 10:07pm

Is it possible to have multiple Page.ss files in the main theme and subthemes?

e.g. mytheme/templates/Page.ss and mytheme_blog/templates/Page.ss

If a theme has a subthreme, the subtheme's Page.ss is used for all pages, even page types that aren't in the subthemes module.

So if you have mytheme/templates/Page.ss and mytheme_blog/templates/Page.ss then the former is never used, even for pages that are nothing to do with the blog.

The objective of the subtheme is to override module templates without needing to hack distributable code. But should templates that aren't even in that module be overridden?

e.g. in a standard 3 column layout, you might want to have a blog sidebar in the right column of the blog, but not in the rest off the site. The easiest way to do that would be to put
in mytheme/templates/Page.ss ...

<% include StandardSideBar %>

...and in mytheme_blog/templates/Page.ss ...

<% include BlogSideBar %>

But that will not work because mytheme_blog/templates/Page.ss is used for all pages.
So at the moment the only way to do this is to have one Page.ss without the right column and put includes in every layout file, right?

It IS possible to have multiple top-level templates if they are given different names, and page classes in the module are derived from a unique common class e.g. ModulePage instead of Page.

e.g. If BlogTree and BlogEntry extend BlogPage instead of Page then you can have

mytheme/templates/Page.ss and

mytheme_blog/templates/BlogPage.ss

// The base class for all blog page classes
class BlogPage extends Page {
	public function canCreate() {
		return false;
	}
}

class BlogPage_Controller extends Page_Controller {
}

// Change blog page class definitions to extent BlogPage instead of Page
class BlogTree extends BlogPage {

class BlogTree_Controller extends BlogPage_Controller {

class BlogEntry extends BlogPage {

class BlogEntry_Controller extends BlogPage_Controller {

So should all SilverStripe modules adopt this as standard? i.e. all module page classes are derived from a module base class instead of Page.ss. The overhead is negligible. And there may be other benefits e.g. enabling all pages in a module to be decorated.