Why Do We Need Base Page Types?

As it was mentioned before, SCORE's philosophy is to build component-oriented sites not template-driven sites so we start with two basic templates - Home Page and Content Page. It is likely that your site's home page will use a unique layout so that's why we start with the two. We also create a special Snippet page type that is used by the SCORE Snippets feature.

In this section:

Purpose

Page Types are Sitecore Data Templates that will define the structure of the page items. SCORE puts very little emphasis on page types inner structure (that is the fields defined on the page items).

With components orientation the content will primarily reside in components' datasource items, rarely on the page items directly.

You will see that SCORE page types only introduce fields that are very generic and probably applicable to ANY page (e.g. Metadata like page title and open graph tags)

Home Page data template is for the site's home page, the item that responds to the / URL.
Content Page is for all other pages of the site.
Snippet is to be used by Snippets

Layout Document

Each page type can define its unique layout document. With SCORE we recommend that you try to keep your layout document as generic as possible unless you need to "lock down" your page layout or have other business requirements that drive you to have more specific layout documents. Home Page and Content Page are scaffolded to use the Main layout document and Snippet is set to use its own Snippet layout document.

Insert Options

Another reason you would create different page types is to control the types of subitems a page can have as its child page items. We recommend that you define insert options on the data template's standard values.

Placeholder Settings

We don't recommend relying on global placeholder settings as it's not multi-tenant friendly. SCORE's approach is to localize placeholder settings to the specific page types which makes it scoped to a specific tenant site. You can basically use SCORE components on two tenants of the same Sitecore instance simultaneously and have different placeholder settings for SCORE carousel component, for example. That said, static placeholder settings defined on the page type's standard values may not be expressive enough (e.g. having different placeholder settings for the "Right" placeholder of a "Wide Right" structural component inserted into "Page Content" vs. when it's inserted into a "Tab Panel"). SCORE comes with the rules-driven placeholder settings implementation.

Workflow

Yet another reason to create multiple page types is to control what type of workflow a page item goes through (e.g. section landing pages may need a branding review/approve cycle while content pages in the "Articles" group may be allowed to go live without marketing approval). Note: SCORE does not come with any pre-built workflow configurations

Security

Similar to having different workflow associated with different page types you may have different security requirements that would support via creating different page types.

Inheritance

If you decide to define your own page templates we recommend that you inherit from the provided Content Page template or SCORE's Site Content Page template.

Many SCORE extensions (event handlers and pipeline extensions) are scoped to only work on SCORE items and we determine that based on whether an item is a descendant of SCORE base page types.

Page Types, like any other Sitecore data templates, can inherit other data templates. Page Types scaffolded by SCORE inherit from:

Home Page inherits from Site Home Page

Content Page inherits from Site Content Page

Snippet page inherits from Standard Template. It is not really a page per se and it does not need metadata attributes.

Scoping and Querying

SCORE is using certain techniques to query shared content elements using @@templateid not to introduce hard dependencies on item IDs or their exact location in the content tree. We highly recommend that you use same techniques to refer to the Driver Lists for example in the site shared content. Droplink and Multilist field types, for example, can be "sourced" using relative queries like:

query:ancestor-or-self::*[@@templateid='{1469DFF6-C07C-4EAA-9E07-2D42D996E57E}']/
                        *[@@templateid='{0A122790-CCAF-416B-85C8-952B04E7AE67}']/
                        *[@@templateid='{857D2D74-0619-435E-926B-6ABFE75C37F0}']/
                        *[@@templateid='{91627636-6D7B-4E54-AF5C-F085FD611A83}']/*