Integrating XBlog into a Custom Sitecore Project – Part 1

Sitecore Helix has provided us with a uniformity that has been great for the community. It has given us a set of standards to work from and to ultimately make the stuff we make more plug and play. With the update of XBlog to Sitecore 9 we also invested time in converting this to the Helix architecture. I recently led the development of a news based project in Sitecore 9 and used XBlog as a foundation layer to accelerate the process. Here is how it was done.

Articles vs Blogs

The first struggle we hit was the fact that we were creating a news site and not a blog site. It can be argued that they are basically the same thing, a collection of items that are presented with a date, author, categories and tagging. Yet how you name things is certainly important to communication. The last thing you want to do is tell your authors to “add a blog item”, when what they want is to “add a news item”.

The term “article” is much more neutral. (Something I am considering rewriting XBlog to at some point.) With our current scenario we had to push forward with changing all references of “Blog” to “Article” in project namespaces, variables, and Sitecore items. This did bring up the fundamental problem of breaking any chance of an upgrade path to future releases of XBlog. But it is important to remember that XBlog can be downloaded, installed, and used as is or you can download the source and customize it to any extent you need. By doing the later you are most likely customizing this beyond any possibility of upgrade and would instead cherry pick future changes to integrate into your project. Justifying this path made the name change an acceptable solution.

The other obvious hurdle was simply the process of changing all references of “blog” to “article”. Overall it was not terribly difficult. Search and replace for the win, followed by a healthy list of compile errors to walk through. The biggest hurdle was around plural naming. Making sure that the concept of blog vs blogs was maintained when converting to article vs articles.

The process took a few hours and by the end of the day I was able to create a base XBlog instance with the new naming. Overall this was well worth the investment knowing that we had a strong base to work from that the client would also be able to recognize.

What was used?

The XBlog foundation, now known as Article foundation, has a lot of great features that extends upon Sitecore functionality. Not everything was kept, but what was kept, helped accelerate the development process. Here is an overview –

Bucket Publish Date structure – Xblog has an onSave pipeline that when an item is saved the bucket is restructured with year / month / day reflected on its custom date field. It was later determined that this had no value on the front end as we used Mike Reynolds approach to bucket less folder structure – https://sitecorejunkie.com/2016/05/31/omit-sitecore-bucket-folder-item-names-from-page-item-urls/ . However it still had value on the back end as the client preferred to dig through folder structures in some instances to find articles.
Wild card links – XBlog maps link structure of /category/<category name> and /tag/<tag name> to their named items. We reused this logic to present this through the site.
Bucket search customization – This was probably the simplest component to reuse as it introduce some base filtering in search based on category, tag, and authors.
Templates – All templates were reused. This provided a base line set of fields for our articles as well as a pre-built structure to build from for the settings that come out of box for XBlog. It is simple enough to create fields in Sitecore and piece the templates together, but I found the pre-built / vetted structure of these templates and folders was a nice approach to getting over those initial hiccups you always have when doing this from scratch.
WordPress importer – Along with creation of this news based site, we also had to import thousands of previously written articles. The WordPress Importer functionality was a great starter point to accomplishing this. We started with the base XML that is used to import WordPress items and extended upon it to introduce our custom fields. Other than importing articles themselves, this tool also has some great logic around searching for categories, tags, and authors and adding them if not present. This was all used, and helped speed up the process dramatically.

What was not used?

Models – XBlog has a manually built set of model classes to work with all the fields and templates. There is some pros and cons to this approach, but we chose to work with TDS and Glass generated classes for all our solution work, so it made sense to migrate to this as well.
Views – Outside of the Foundation layer, the views make up the majority of our feature layer. All though, these were used for reference, there just was not enough similarity in the html and front end functionality to justify leaving these intact.
Configuration settings. For the most part all the settings that were used to modify the front end behavior of the views were removed. Instead we went for more of a direct custom approach specific to the clients needs with some configuration moved into item settings and rendering parameters.
CSS – XBlog comes with some very basic styling. Alongside our views, this was eliminated as well.

In summary I would say that about 70% of the foundation layer was reused to accelerate our project, while none of the feature layer was used. The feature, mainly views, were to generic for our needs. Instead we opted to build from the foundation and create a new feature level layer to support the news direction we needed.

In the second half of this blog post we will go into more detail of how XBlog foundation layer logic merged with our custom feature project.