Extending the CMS to a blog

To make the blog, we will use the basic CMS we created in the previous chapter, but we will add a few extra field and make the editor have to login to add and edit entries. We also need some more fields in our table to hold tag and author. We will also create a few new pages to handle what you expect from a blog.

New fields

author	text 40	The username for the author of the document, we will extend on this later to give you a proper name and a own author table with more information.
type	choice	This will be the type of article. We will have article and blogentry as choices for this first version.
tag	text 40	We want to be able to tag our blog entries so we can sort on that as well, we will allow one tag in this first version, then we will expand on this to allow more later

We will later add more elements to the articles table and support tables for tag, make it possible to dynamically add elements we can pick from a drop down. We might want to be able to add more than one tag for our blog entry, so we will need to find a way to allow that as well. Luckily we have DQLs and filters that will help us to make this happen.

Pages to add

First we create a new folder called blog to group the new documents. This makes it easy to find all blog related code as our solution grows.

editblogentry	based on the what we did on edit article, we create a new document that can create new blog entries and edit old.
viewblogentry	this will show one blog entry in the same way as our cms show the articles, just some more information
viewblogentries	this is the standard view where you show the last few entries with the newest on top. We will later expand this to also hold the list of articles pr. month and tags used

Create restriction on pages that should be internal

Since we now have added authentication to our solution and a superuser for our self, it's time to add restriction on all our edit pages. There are two ways of doing this depending on the type of solution you are creating. You can set default restriction on all pages by using the settings on the settings section and then loosen up on pages you want to make public or as we will do now just set restriction on the pages we want to be behind login. The best solution for any projects made for a customer where the users should be logged in most of the time is to set default authentication on all pages and just remove restriction on a few pages open to the public. DG3 supports both ways. It will first check for override set on a page and in none, use the default. If you have no default on any pages, this mean no login.

The site security settings

The page security settings