My First #Sitecore Module in the Marketplace

So now the dust has cleared after the Hackathon why not add what we did to the as #Sitecore #Module in the Market Place. I hope the following helps you if you are publishing your first Sitecore Module.

First thing I did was create a new Helix based project that would be used to generate the Sitecore Module. I also stripped off any thing that was not out of the box Sitecore. Such as Glass Mapper. The less dependencies the better.

To get to the Sitecore Marketplace click here. When you get to the page you will see the following.

When you click on Contribute Now the below screen appears.

After clicking on the CONTRIBUTE NOW button and entering in the module name the following message appeared.

Soon after the space was created and added the necessary information under the about and documentation tabs.

I then upload the installation package. The package was then in review.

After that I received an email message letting me know that my changes were submitted and will be reviewed by the marketplace coordinator.


So for a week or so I saw this when I checked my modules under my profile.

I was notified a little more than a week later my module was published.


Here it is:

Now I just need to add some more contributors.

#Sitecore and field labels. So many options to render them, but what is the best option?

Discussing programming techniques can be like discussing religion and politics. There might never really be a correct answer, but everyone thinks they know it. In the case of rendering labels (first name, last name, address for example) in #Sitecore we have more than a few options. In my example I have a label called Introduction. I have three different ways to render this field on the site.

The first line uses the Sitecore dictionary. The second is set in the controller from a settings page and the third line is coming  from the home page item.

 @Model.HomePage.Fields["Intro Text Label"].Value

They all render the same. As you can see below.However which way is the best way to do it?


I prefer using the dictionary to do it. It is quick and easy to render a field that way. I worked for one company that only used a settings item or the content item. Another company I worked for preferred the dictionary. So which way do you prefer?

My Sitecore Hackathon 2017 Adventure

I like things that challenge me. Don’t we all? I have done numerous races all different distances that were very challenging. I even had to give myself some Rocky speeches while doing them. Sure physically/mentally that stuff is hard, but how about doing something professionally/mentally challenging? Enter the #Sitecore Hackathon 2017 #SDHackathon. A 24 hour coding frenzy. Now I have done some all nighters for work at times, but doing something that was going to challenge me to show the world what I could do that is a different story.


My team consisted of two other developers that happened to be coworkers.Our team name was the X-Men and we named our project WeaponX. Who doesn’t like comics right?


The contest started at 8 eastern time. We were giving instructions at that time and decided to do a Sitecore module. After brainstorming for a bit I came up with a blog importer. I have done something like it in the past, but never as a Sitecore module. My teammates agreed that is what we will do.


So after having an idea in place next was figuring out our parts. One team member would be doing the documentation, presentation and Git Hub setup. The rest of us would do coding, analysis and researching.

One of the requirements of the contest is to make sure that we create the project in a Helix format. Well that was new to all of us. I was able to use a Helix generator though and we had a project started. Meanwhile one of my teammates started creating the Sitecore items we would need. Another teammate was getting the Git Hub stuff ready. I started adding all the stuff to the project that we would need to develop as a team. Such as TDS and Glass Mapper. When the project and Sitecore items were done I was ready to start coding. Before that I did my initial check in though. Always back up your code. 🙂

As it was getting late the team started dropping off. At this point there wasn’t much for them to do as I was full heads down coding. I stayed up until about 3:30 AM central time. I got the code to where I wanted it and made any Sitecore updates I needed to do. There was still a lot to be done though and I was having trouble getting Glass Mapper to cooperate. So I set the alarm for 6:30 AM and called it a night.

In the morning I woke up tired, but ready to go. I did shower and do all the usual morning stuff before logging back on. 🙂 I met with my teammates and gave them my status. Throughout the day we communicated, collaborated and stayed in contact as much as possible. We all have lives though so we had things to do people to see.

It was touch and go there for a while, but finally there was light at the end of the tunnel. We were finally code complete and we had our install package created/tested. There was not much time to spare though. Documentation and video presentation had to be done.


As each minute ticked by we were approaching the final hour. Code, install package and documentation was handed in. However YouTube was taking it’s sweet time rendering the video. It finally finished and we had all the necessary stuff done and handed in. We could finally breath a sigh of relief. Check out our finished Sitecore module presentation here.

Things we learned:

  • Setting up a Helix project.
  • Keep things basic. GlassMapper is nice to have, but getting that going took us more time than if we used standard out of the box Sitecore functionality.
  • You only have so much time. Stick to getting the basics done first. Add the nice have stuff later.
  • The right people make things happen. We worked well together.

So next year will we do this again? I believe the answer is yes.


Unicorn vs Hedgehog TDS for Sitecore. Hmm what to choose.

So let me just start out by doing #Sitecore updates with packages only can lead to a lot of issues. My first site using Sitecore I had to do that. It was with a company that was new to Sitecore and I had to learn it at night with a certified Sitecore developer they contracted to help. Some very long nights, but many years later it was all worth it. While creating packages and installing them it always seemed something was missing especially the bigger changes. It was also not always easy to reverse the changes if something went wrong. (I know now there are ways to do that.)

My next company I was introduced to Hedgehog’s TDS product and never looked back. Sure at first there are some learning curves. There were sync issues when working with other developers especially when working on the same things. It seems those issues have been worked out and I don’t see many of the issues I had when I first used it. Most Sitecore developers are familiar with TDS. In case you are not it allows you to sync Sitecore items (templates, content etc…), integrates well with Visual Studio, Glass Mapper and also has settings that make it easy to deploy your site. It does many other things.You can check out their site here.

Recently I was introduced to Unicorn. It is an open source utility used to sync Sitecore changes. Quoted from GitHub: “Unicorn is a utility for Sitecore that solves the issue of moving templates, renderings, and other database items between Sitecore instances.”  You can find Unicorn on GitHub here. I have wrote some blog posts on my experience with it. I think it a great product and it keeps getting better. It syncs Sitecore changes and helps integrating changes between team members much easier and safer than packages. I like the control panel page that is part of Unicorn. It explains step by step what you need to do to sync changes. It does not do everything TDS does, but it is still evolving and may do some additional things TDS does.

So which one do you choose? Either option in my opinion will be better than using just packages for everything. TDS is supported by a major software company and does a lot of things that make it convenient setting up a Sitecore environment. Unicorn is great if you want something simple and clean to do your Sitecore updates with other developers. Unicorn sums up the main differences below from their GitHub site:

Unicorn solves some of the same issues as Hedgehog’s TDS. The major difference in approach is that because Unicorn forces all of the merging to be done on the disk, you never have to manually select what to update when you’re running a sync operation or remember to write changed items to disk. Unless you have actual collisions, this saves a lot of time because you can take advantage of Git, SVN, TFS, etc to do automerges for you. That said, TDS and Unicorn have different feature sets and goals. TDS is a monolithic product with commercial support and marketing that does a lot more than just serialization. Unicorn is relatively simple, free and open source, and does one thing well. Use whatever makes you happy 🙂

So what do you prefer and why?


Unicorn for Sitecore Setting up Separate Core/Master Database Serialization

After getting the Unicorn sync to work I wanted to have separate folders for the Core and Master database items. It will keep things organized much better that way IMHO. After researching an asking around in Slack I came up with the following solution.

First  based on the Unicorn.Configs.Default.example I created two new configs. Unicorn.Configs.Core.config and Unicorn.Configs.Master.config.


In each file I changed the configuration name and description. Also it is very important that you add an entry for the physicalRootPath. This will override the default path.

This is what I did for the Core database. You will notice that the path ends in \Core.

 <configuration name="SitecoreTestSiteCore" description="This is my Sitecore Test Site. I am testing Unicorn and syncing CORE only.">
 <targetDataStore physicalRootPath="C:\Projects\SitecoreTestSite\src\WebApplication1\WebApplication1\App_Data\Unicorn\Serilization\Core" type="Rainbow.Storage.SerializationFileSystemDataStore, Rainbow" useDataCache="false" singleInstance="true" />

This is what I did for the Master database. You will notice that the path ends in \Master.

 <configuration name="SitecoreTestSiteMaster" description="This is my Sitecore Test Site. I am testing Unicorn and syncing Master only.">
 <targetDataStore physicalRootPath="C:\Projects\SitecoreTestSite\src\WebApplication1\WebApplication1\App_Data\Unicorn\Serilization\Master" type="Rainbow.Storage.SerializationFileSystemDataStore, Rainbow" useDataCache="false" singleInstance="true" />

After Initialization I did a sync. Look it is a cool looking unicorn.


Now I have two separate directories for Core and Master files.


Let me know if you have any questions.

Unicorn for Sitecore and Version Control First Time Setup

After I got #Unicorn for #Sitecore setup for the first time I noticed the folders and yml files were created in my sites data folder. I want those files as part of my project and source controlled similar to TDS. So doing some research I found this setting in the Unicorn.config folder.

type=Rainbow.Storage.SerializationFileSystemDataStore, Rainbow

I changed to my local folder in my project. I created two new folders under App_Data (Unicorn\Serialization).

type=Rainbow.Storage.SerializationFileSystemDataStore, Rainbow

*Please note there is a Unicorn.CustomSerializationFolder.config.example that you can also change this setting in. Just remove the .example to use it.

When I went to [site]/unicorn.aspx I received the following error. If you receive this error either change the path to a smaller length or in my case I changed the value in App_Config\Include\Rainbow.config.

I changed this line:

<setting name=”Rainbow.SFS.SerializationFolderPathMaxLength” value=”103″ />


<setting name=”Rainbow.SFS.SerializationFolderPathMaxLength” value=”105″ />

Now after going back in to the Unicorn Control Panel I was able run an Initial Serialization. I had to do this since the folder path changed.

Then Sync Selected.

SitecoreTestSite sync complete: 1767 items evaluated, 0 items modified (0 added, 0 updated, 0 recycled) in 6331ms (~3.6ms/item).

Now back in my solution I show hidden files and folders and there are my files. I can then include them in my project.

So now you can make the files part of any source control sytem you are using. It is worth mentioning that there are other methods you can use like Sitecore Courier and Sitecore Ship. Also since projects are sometimes setup different locally for developers using something like slowcheetah might be a good idea to have your own development configuration for the Unicorn.config and Rainbow.config.

Update. In your publish settings I recommend checking the box that says Exclude files from the App_Data folder. You probably don’t want to publish those files.


Now I need to figure out how to sync someone else’s changes. I suspect it might be using the Publish Unicorn and Replace Unicorn from Server options.

Unicorn for Sitecore Setting up for the First Time

Most of my #Sitecore projects have been spent using packages and TDS to get Sitecore items updated. I was told recently about another tool and decided with a cool name like Unicorn I had to try it out. I like the name being that in my house at one point my kids believed Unicorns were real. I told them they are real, but Noah forgot to take them on the Arc with him. Anyhow let’s get started.

I started with following the documentation. It was straightforward.

How to get the Nuget package.

Included in the installation is a sample config file. You can copy it and change the extension from sample to config. I just kept it simple and named mine Unicorn.Configs.Default.config.

In the config file under the predicate section you can add paths here. You can see ones already defined with include tags. I just changed the stuff highlighted in yellow.

<configuration name=”SitecoreTestSite” description=”This is my Sitecore Test Site. I am testing Unicorn.“>

    <predicate type=”Unicorn.Predicates.SerializationPresetPredicate, Unicorn” singleInstance=”true”>



                The predicate controls what items are included in the configuration.

                Each include can also exclude specific subitems in various ways. For a reference of the most current predicate grammar, consult the tests here:


                NOTE: after changing what is included or excluded, you should reserialize all items, or at least the added items for additions.

                NOTE: the “name” attribute controls the folder name the items will go into. If unspecified, the last path segment is used. Names must be unique across the configuration.

                NOTE: You cannot use excludes with Transparent Sync. See


                <include name=”Layouts” database=”master” path=”/sitecore/layout/Layouts/ ” />

                <include name=”Templates” database=”master” path=”/sitecore/templates/” />

                <include database=”master” path=”/sitecore/system/Languages” />

                <include database=”master” path=”/sitecore/system/Tasks”>

                    <exclude path=”Schedules” />


                <include database=”master” path=”/sitecore/system/Workflows” />

                <include database=”master” path=”/sitecore/system/Settings” />

                <include database=”master” path=”/sitecore/content/”></include>


After publishing your site just go to http://[Your Site Goes Here]/unicorn.aspx. You will see a message about not having any valid serialized items and to do an initial serilization.

No problem. The developers included a button to click to do the initial serialization.

After clicking the button the following came up.

Now I get the following option.

Clicking on the checkbox you get a Sync Selected and Reserialize Selected option.

After clicking on Sync Selected. An awesome Unicorn appears with messages below.

Now in my data directory I can see Unicorn created folders and within those folders are yml files (more about these types of files

On a side note. I installed a Unicorn utility that caused a dll version issue. So I had to copy back some files to get it to work again. So if you run into this issue make sure all the file versions are the latest even the MicroCHAP dll.

So that is it for now. As I use this more on projects I will blog about it some more. Let me know if you have any questions. Thanks.

Attaching to Sitecore Sites with Smart Debug Attacher

I’m sure everyone has a set of tools they use for speeding up debugging. One of my favorites to use is the Smart Debug Attacher.

You can find the Visual Studio extension here.

It is very easy to use. After you install it you will see the following on the Visual Studio tool bar:

If you haven’t used it before and attached to a process you will see the following message. Just click OK.

The following display appears. Simply find the process you want to attach to,select it and then double click. Then click on the Attach button. Visual Studio will then attach to the process and go into debug mode.

The nice thing about this tool is that you can see the app pool so if you have several sites you can attach to the correct one. It will also remember what you attached to last time so you don’t have to keep selecting the process you want to attach to.

So does anyone else have a good tool for debugging?

xGenerator is Installed in Sitecore Now What?

So after installing xGenerator for #Sitecore I started poking around to see what changed and to check out the xGenerator interface. This blog is more for seeing what gets installed and getting started. As I work with xGenerator more I will blog about its features.

After the installation in content editor you can see different items that were installed.

After the installation I noticed some new things on the LaunchPad.

Clicking on the Experience Generator I get the following tabs.

I’m still learning what each tab does. One of the tabs I tried was the Landing Pages tab. By clicking on the Add landing page button an explorer window popped up. In this case I just chose the home page.

Once you make changes to any tabs you can save your settings on the lower right. You can also select and load your presets again.

Clicking on the Profile Experience Generator I get the following screen. Looks like a way you can setup different contacts.

The xGenerator tool looks to be a very powerful testing helper. I am going to keep looking at all the features of xGenerator and get some things set up. I will blog about what I find. If anyone knows the original author of it I would like to have a conversation with him and get a general overview.

xGenerator Introduction and Installing

Recently I was given the task of installing xGenerator for a #Sitecore site. I haven’t used this tool before so I started doing some research on it. It is a great testing for creating realistic traffic for your Sitecore site. I found that you can download the code in GitHub. I didn’t find an installation package, but the code contains a package definition that you can use to create a package with Sitecore Rocks.

I got the code from here:

I followed the instructions here After following the steps and publishing I noticed I was getting a lot of version errors on my local Sitecore test site. The mistake I made was that my site was version 8.1, but the code was for version 8.2. So I had to go back and get a version pre 8.2. I went to the releases page. I ended up downloading the nightly commit. For some reason the download that came after that was still 8.2. Maybe I overlooked something. In any case the nightly commit worked.

So after redoing the steps in the build instructions I was able to publish to my Sitecore site and get it to work. Building the package was easy.

I already have Sitecore Rocks installed so I double clicked on the package.

Sitecore Rocks brings up a connection window. You just need to connect to the instance of where you installed the xGenerator updates with Unicorn.

Now you can easily generate and download a package.

Just for my own piece of mind I created a new 8.1 site and installed the package. Just to make sure it worked. It did and I was off and running. I want to play around with this tool more and get familiar with it. Stay tuned for another blog on xGenerator in the future.