Error parsing XSLT file: \xslt\BlogMetaWeblogChannel.xslt Error parsing XSLT file: \xslt\BlogRssFeedLink.xslt

Blog Categories in Blog4Umbraco - Take Two

So my first attempt at manipulating Tag Groups by using Events didn't go so well.  Sure, it created the tags with the correct group, but it also left the original tags in the csmTags table, and if you went back and edited the blog entry, the tags would be gone because the Tag Data Type was ignoring anything that didn't belong to the default group.

So. Back to the drawing board.

Edit (10/11/2010): The first package download didn't go so well and failed dismally.  I've uploaded a new version of the package and this time double-tested it, so it should be all good.  Leave a comment if things go awry...

This time I decided to try and tackle the problem at a deeper level - what if I introduced a new Data Type that could intercept the tag group and inject the Blog Category instead?

Package Download: You can download an Umbraco Package to install the Dll that will do this for you from here.  It contains a single Dll that has a couple of Extensions in it aimed at Blog 4 Umbraco, but is not dependent on it being installed.

Enter the Blog Tag Data Type.

I didn't want to have to re-create the entire Tag Data Type, it's Editor Control, or it's Prevalue Editor, so I took advantage of the fact that almost everything can be extended in Umbraco, and just derived a new Data Type class:

 

public class DataType : umbraco.editorControls.tags.DataType
    {
        #region IDataType Members

        private IDataEditor _Editor;

        public override IDataEditor DataEditor
        {
            get
            {
                if (_Editor == null)
                {
                    var preValues = ((umbraco.editorControls.tags.PrevalueEditor)PrevalueEditor).Prevalues;
                    int? nodeId = int.Parse(umbraco.helper.Request("id"));
                    if (nodeId.HasValue)
                    {
                        string category = (string)BlogExtensionsLibrary.GetValueRecursively(nodeId.Value, "category");

                        if (!string.IsNullOrEmpty(category))
                        {
                            if (preValues["group"] == null || (string)preValues["group"] == "default")
                                preValues["group"] = category;
                        }
                    }
                    _Editor = new umbraco.editorControls.tags.DataEditor(Data, preValues);
                }
                return _Editor;
            }
        }

        public override string DataTypeName
        {
            get { return "Blog Tags"; }
        }

        public override Guid Id
        {
            get { return new Guid("BD8B240F-0DE3-47E5-A172-2DE212CC30B6"); }
            // this was the core umbraco tags datatype GUID.
            //get { return new Guid("4023e540-92f5-11dd-ad8b-0800200c9a66"); }
        }

        #endregion
    }

 

Basically, I stripped out all the stuff I didn't want to duplicate from the tags DataType class, and overrode the DataEditor property.  A few interesting things to note:

  • I could have left the Id property alone and not overridden it.  If had done so, my DataType would have taken over the core Tags DataType, and you would basically not have to do anything more.  However, I'm trying to be a good Umbraco Citizen and behave in a right neighbourly fashion.
  • The code has been designed so that if the category attribute doesn't exist in the Document Type or one of it's Ancestors, then it will not try to inject anything into the group, so it would be quite safe to replace the Core Tags Control with the new one.
  • BlogExtensionsLibrary.GetValueRecursively() is described in my previous post attempting to deal with Blog Categories, so not going to go into it here.

Ok, once you have compiled your code and copied the dll into the bin directory of your Umbraco installation, the remaining steps are as follows:

Update the Tags Data Type, or alternatively create a new one.

You will need to go and change the Tags Data Type so that it uses the new Blog Tags control instead of the Core Tags control.  Note that if you decided not to play nice, and let the new code override the Core Tags control by using the old GUID, then essentially you shouldn't need to do anything here!

Blog Tags Data Type

Update the Blog Post Document Type

You would only need to change the Blog Post Document Type if you created a new Data Type instead of modifying the Core Tags Data Type.

Error parsing XSLT file: \xslt\BlogPostListComments.xslt

Post a comment