Blog

Posts written in October 2018.

  • Published on
    -
    2 min read

    Kentico - Call 404 Page From Code

    There will be times when you want to direct a user to a 404 page based on certain conditions from within your code. For example, when dealing with pages that use wildcard URL's, you might want to redirect the user to a 404 page if the value of that wildcard parameter returns no data.

    In my blog I have two wildcard parameters to allow the user to filter my posts by either category or tag. At code-level if no blog posts are returned based on the category or tag value, I have two choices:

    1. Display a "no results" message
    2. Redirect to a 404 page

    As you can tell by the title of this post, I wanted to go for the latter.

    From a Kentico perspective wildcard parameters in a URL aren't what I call "proper" pages and the CMS routing engine won't send you a 404 page as you'd think. So we need to carry the redirect at code-level ourselves based on the conditions we provide. As far as I'm aware, Kentico doesn't have a method in code to do this and settled for a workaround suggested by Sébastien Gumy in the following DevNet post.

    I made some minor changes to the code and placed it in a helper method for use throughout my project with ease:

    using CMS.Helpers;
    using CMS.PortalEngine;
    using CMS.URLRewritingEngine;
    
    namespace Site.Common.Kentico
    {
        public class PortalContextHelper
        {
            /// <summary>
            /// Redirect page to 404.
            /// </summary>
            public static void SendToPageNotFound()
            {
                PortalContext.Clear();
                CMSHttpContext.Current.Response.StatusCode = 404;
                URLRewriter.RewriteUrl(RequestStatusEnum.PageNotFound, string.Empty, ExcludedSystemEnum.Unknown);
            }
        }
    }
    

    The SendToPageNotFound() method can then be used in the following way:

    #region Get Querystring Parameters
    
    string tag = QueryHelper.GetString("Tag", string.Empty);
    string category = QueryHelper.GetString("Category", string.Empty);
    int pageNo = QueryHelper.GetInteger("PageNo", 1);
    
    #endregion
    
    int tagId = TagLogic.GetTagIdFromQuerystring(tag);
    
    // A custom method to get back blog posts based on parameters.
    BlogListing postData = BlogLogic.GetBlogPosts(CurrentDocument.NodeAliasPath, category, tagId, (pageNo - 1));
    
    if (postData.BlogPosts != null)
    {
        BlogListing.DataSource = postData.BlogPosts;
        BlogListing.DataBind();
    }
    else
    {
        // Send to 404 page.
        PortalContextHelper.SendToPageNotFound();
    }
    

    Please note: This has only been tested in Kentico 10.

  • Published on
    -
    2 min read

    The Journey To Kentico Cloud

    From working at Syndicut, I have had both the opportunity and pleasure of working with many different platforms. The most exciting development for me over the years has been the shift on how content management systems are being decoupled from the very applications they push content to. I have blogged about this many years ago when I first used Prismic, which at the time seemed the most viable option. Even though there were pros and cons.

    I always felt the cons were more related to the restrictions on what the platform offered and not the architecture itself. I write my thoughts on the journey to how [at Syndicut] we've used headless CMS's in the past, to now using Kentico Cloud. Kentico Cloud is indeed a very promising headless CMS platform. Even though it hasn't been in the market that long when compared to its competitors, but it embodies something more:

    • Proactive development team who take an active step towards bugs and improvements.
    • A wide variety of boilerplate templates to accommodate different code frameworks.
    • Boilerplate templates updated regularly.
    • A clear roadmap to the features developers can expect and release deadlines.
    • Accessible and quick to respond support team.

    Some highlights to take away from the post:

    The common misconception we get from clients is on the surface, a headless based CMS can appear restrictive compared to platforms they are previously used to. However, that cannot be further from the truth. Once there is an understanding of how data can be given a hierarchy, category, relationships and workflow, they seem to run with curating content fairly quickly.

    For agile projects where there is a need to manage content for multiple channels, or for creating tagged content hubs for digital marketing purposes, Kentico Cloud is the best option.

    Headless CMS is a ticket to freedom for those who wish to take it. Why waste time worrying about hardware infrastructure, security and platform updates when you can invest that time in purely building your application and content?

    As a business or developer, you might be hesitant to make the change. When I first read about decoupled architecture, I too had some hesitation as a lot of faith is invested in the platforms scalability and features. But with services like Kentico Cloud, who are pushing the boundaries with every release, they are changing our perception for the better on what we think we should expect from a headless CMS.

    Take a read here: https://medium.com/syndicut/our-headless-cms-journey-to-kentico-cloud-b26c4eb39ed7