By Cathy Dew
Kentico offers almost two dozen different standard page types out of the box, for you to use or extend as your content needs evolve. We provided an overview of the three main page types with our Understanding Kentico Page Types article. The Standard Page Type and Container Page Type are pretty easy to understand, and are the primary way you are going to display content if you are not using the MVC (Model-View-Controller) option within Kentico.
With the MVC model, you don’t want all the extra bells and whistles of the Standard and Container Page Types. Therefore you want to use the Content Only Page Type. Because you are storing only content, there are some best practices you need to know about to utilize this page type correctly.
What Is Content Only Page Type?
When Kentico started to support the Model-View-Controller programming design pattern there was a need to just have the content stored, minus all the display options / templates / etc. The MVC model forces you to separate the content (via the controller) from the display (via the view). This necessitated stripping down the Standard Page Type to just the base attributes.
This means you no longer have presentation properties, like a URL or navigation tabs, and are limited to one page/document alias. However, the content only page type allows your editors to focus on only the content and off-load the display needs to the team that needs to worry about it. (e.g. you don’t have Editors changing the look and feel of their articles during the editing process.)
Content Only Page Types have their own table in the Kentico Database to store their information, and can be extended like other page types. We recommend that you build a custom Content Page Type that will provide the base fields / attributes for all your other content only page types – even if you only have one primary content only page type. You then inherit from this parent content only page type for each new content only page type you need and extend the fields / attributes for anything specific you need.
Drinking the MVC Kool-Aid
It’s also important to understand the when you start looking at using the Content Only Page Type as your primary content delivery model you are going to want to use the full MVC method of content delivery. Unless you are looking at designing and building your own custom display mechanisms, to use these tools correctly you’ll have two Kentico sites: “Admin”: for content editing, and “WWW” for content display. This setup is necessary for you to maintain the separation between content generation and content display. Having two different services for Editing and Public Display is not much different than the original content staging design that comes with Kentico, the difference here is the Editors and Visitors can be using the same DB.
Another benefit of building your Kentico sites as distinct services, is you can setup a “test” site for display development that also uses your content database. This setup will allow you to build and test new display options – even a whole new look and feel – without impacting the production service while still utilizing the production content.
3rd Party Delivery
Kentico has always had a strong API that allowed you to tap into the power of Kentico via RESTful API calls. With Content Only Page Types, you can provide 3rd Party Access to your content without all the template and display baggage. Your 3rd Party Content providers can then display your content within their own look and feel and provide a seamless integration between your content development and their content presentation.
Alternate Forms
Kentico has always provided additional options that can stream line your content editing processes. One of the more powerful options are Alternate Forms. By setting up different forms and assign them to different roles, you can ensure that your content editors and approvers work on the content attributes that are specific to their needs. This is a feature you need to understand and utilize with all content types you might be using within your site
Indexing Content Only Page Types
One of the challenges with content only page types is setting up your indexing to make sure your content is available to visitors using the search features. Because the Content Only Page types do not have a path like Standard Page Types, you cannot use the internal object search to index your site, you have to use Kentico’s Smart Search or Web Crawler option. The benefit of this approach is you are indexing exactly what the visitor sees, and when you are providing more than one language for content, you’ll have to have multiple crawlers / indexes to index the different content for different languages.
Building Friendly URLs
When you are providing content through the MVC model you need to ensure that your URLs are friendly, which basically means you want the URLs to be human readable. Making your URLs human readable directly translates to improving your Search Engine Optimization. If you visitors can’t read your URLs, neither can the web indexers like Google and Bing.
When building Macro expressions, the best practice is to use a URL pattern that has the NodeID along with the NodeAlias. For example: /News/{%NodeID%}/{%NodeAlias%}. Because the Node Alias is only unique for the current node level, having the Node ID as part of the URL ensures you have enough information to find the content programmatically and make sure the URLs are unique when sending to the browser.
Content Modeling
If you are not going the full route to MVC content delivery, the Content Only Page Type is still extremely useful with setting up Content Modeling. When constructing pages, you can add the Page Field to your custom Page Type, and on that field allow editors to select targeted Content Only pages for display on the target page. Things like Call Out Boxes, Calls to Action, Author Bios, etc can be stored in a Content Only area of your site and then added to target pages during the editing process. The benefits are obvious for page reuse / sharing, as well as, you can update the Content Only record once and everywhere it’s in use is updated immediately.
You should note that updates to the Content Only record are not covered under workflow when added to a Page via Content Modeling. The changes to the Content only record itself might be under workflow, but the content displaying on the target pages where it’s shared cannot track the changed content themselves.
Kentico has many terrific features that can be implemented in multiple ways to assist your content delivery needs. If you need help learning the basics of Kentico or want to take your intranet or Public Web Site to the next level, 2Plus2 can help. Go online to schedule a free consultation with our team or call 510-652-7700 today.