Page types are the most fundamental building block on any Episerver project. Websites are built up of pages, you might have a homepage, a contact us page, a blog post page etc.. a page type is the way Episerver provides developers of representing these pages in code.
Every Episerver page type will need to insert from the PageData object. The page data object represents and stores all the content and meta data about a specific page. The PageData class is located in the EPiServer.Core namespace. The PageData class has a lot of properties and methods. Some of the ones you, as a developer, will be using the most, include the page name, the page id (for finding the page) and LinkUrl (to link to the page).
Page types and content types
As we discussed, a webpage will need to have a number of different pages, like a homepage. Your homepage might need a carousel at the top, a call to action or newsletter sign-up block and some text at the bottom. The properties that are available to a page are defined in its page type definition. In every project I've worked on, I've always needed a Homepage template, as the homepage will always look very different to the rest of the site. First, you will want to create a Homepage Pagetype.
The above code snippet shows you everything you need to get started creating your own pages. All you need to do is decorate a class with the ContentType attribute and inherit from Page Data and your page will show up within the CMS. If you taker a closer look at the code, you can see a page type can be customised quite extensively. A page type is basically a class that defines a number of public properties.
On application start, Episerver looks at all the classes in the project, finds any that has the ContentType attribute defined on it and then creates the template in the database with all of the properties defined within itself. If you want to think purely in terms of coding, the reverse is also true. When a content editor creates a new page type, by creating that page a new instance of the homepage class is created. Content editors can add values to a page, e.g. adding data into the classes public properties and then save the page. Saving the page will then store all the data into the database.
Before Episerver 7, all developers had to worry about was page, however, in Episerver 7 onwards the CMS now supports a whole range of content and is no longer limited to just pages. Episerver has been designed to work with 'content'. Content can be anything you want it to be like Images, YouTube videos, even Wordpress blog posts. To make something to be recognised by Episerver as a content type, it has to implement the IContent interface in the EPiServer.Core namespace. What this means is that any class you create that inherits from IContent can be saved to the Epi Cms database using the Epi API. For reference, the PageData class implements IContent. On most projects I have worked on, I've never really needed to create my own IContent. If you find yourself needing to create your own content for whatever reason, then the IContent interface at the time of writing, has the following members that you will need to implement Name, ContentLink, ParentLink, IsDeleted, ContentTypeID, ContentGuid.
Configuring Your Page Type
Now we've talked about the differences between PageData, Page types and IContent, let's talk about how you can define your own pages.
To define an Episerver page you need to decorate it with the ContentType attribute. ContentType is located in the EPiServer.DataAnnotations namespace and has the available properties:
Defines if the page will be available in the editor for content editors to use. By default this is always set to true and you will only need to use it to prevent users from using it.
This will define the brief blurb in the editor when a content editor is deciding which page to use.
The name of that will get displayed in the CMS for the page type.
The position where page will be displayed in the new page dialog. TIP Always increment this number in 100's. After you set-up your page-type if you need to add in a new property at a later date and you only increment the order by 1, you can waste time having to re-numbering the sort order on the page.
A unique identifier for the page. This is used to ensure your page type is unique. I always recommend you use this. If you don't have a GUID and you do a lot of data migration from older versions, this can burn you. If you want a quick way to generate a new page-type ID you can use this tool, Guid Generator.
The name of the group the page will be displayed in when displaying them for selection in edit view.
Defining Where Your Pages Can Be Built
In most projects, we create a site map that defines what pages can be created under each other, for example a content page may only want to be created under a List page. To do this you can use the AvailableContentTypes attribute.
Defines if all or none content types should be available. If none is set, other settings on the attribute are ignored.
Specifies which page types can be created under itself. My recommendation is to just use for all your page types as it creates the least amount of code.
Specifies the content types that are not allowed to be available under itself. I find if you use this you end up copying a lot of code in all of your page-type definitions.
This way allows you to define all the rules about the page within itself. It allows you to define from itself what pages it should be allowed under. Again, I'd stick with just using Include
The inverse of above.
Defining an image
In Epi preview mode, you can create an image of your page type. After some experimenting, I would recommend you implement this feature, however, doing a screenshot can look a bit naff as the image is so small.
If you are stuck for ideas to use for your page type preview images, then I'd recommend using: http://cooltext.com/Logo-Design-Fun with the following configuration:
File Format: PNG
Background Color: #7975BA
Text Size: 45
Image Height: 300 (uncheck auto)
Image Width: 300 (uncheck auto)