Blog Posts in MVC: Months

Posted: 3/24/2019 4:01:08 PM by Chris Bass | with 0 comments

In MVC, we no longer have Kentico dictating to us a site structure - it's handled entirely within the MVC routing engine. And while we can still easily set up routing, when we browse the CMS tree looking for that data, it's still helpful to have them sorted out into months, especially for a busy site.
Kentico previously handled Blog Post creation in the Document Engine - specically, it looked for the CMS.BlogPost page type, and when it found you'd created one, it would automatically put it within a parent. 

We can actually recreate that logic in Kentico - whether to do it in MVC, or even just to do it with other page types and other logic, when we want to reorganize documents on creation.

So, the simple version: If you're just making a custom BlogPost type, and you are fine using the existing CMS.BlogMonth, and your post still has a BlogPostDate field, then it's easy, just add it as a global event: 

  protected override void OnInit()
    {
        base.OnInit();
        DocumentEvents.Insert.After += Document_Insert_After;
    }

    private void Document_Insert_After(object sender, DocumentEventArgs e)
    {
        TreeNode tNode = e.Node;
        if (tNode.ClassName.ToLower().Equals("custom.blogpost"))
        {
            TreeNode NewParentNode = CMS.DocumentEngine.DocumentHelper.EnsureBlogPostHierarchy(tNode,tNode.Parent, e.TreeProvider);
           if (NewParentNode != tNode.Parent)
            {
                tNode.NodeParentID = NewParentNode.NodeID;
                tNode.Update();
            }
        }

And you're done. 

Now, if those preconditions aren't true, you're going to have to write your own EnsureBlogPostHierarchy method, but the logic in that method is actually pretty straightforward.
If we're looking at a page of our custom type, then decide what the parent type should be, and where it should go (in the above case, it's tNode and tNode.Parent, respectively). 

First, make sure your target location, isn't already of the parent page type - it's entirely possible the editor's targetted a blog month specifically, not just the blog itself, as the parent - you don't want months inside months., Next, figure out what you want the new document's properties to be (in the Blog Post case, you can get the current Document Culture in order to figure out the month-name / year, and use that), and a unique identifier for it... That's so, next, you can make sure you aren't creating a duplicate parent (for blog posts, you'd be checking 'does this month already exist', for example). Once you've determined you need a new document, create it under the target parent, set what its template should be (to use the default, remember there's a "SetDefaultPageTemplateID(ID)" method on your new document, and that the DataClassInfo for that pagetype has that Default Page ID - just pass it into that method. Finally, you can move it along the workflow into the published step (assuming your workflow process agrees - generally these automatic pages don't really need 'validation'.  Then you can proceed along to move the child document into its new subparent, and you're done. 

I recommend decompiling the DocumentHelper.EnsureBlogPostHierarchy method if you want to see this example, even in that state it's pretty straightforward.
 

Comments
Blog post currently doesn't have any comments.
 Security code