#Sitecore Meetup Chicago Impressions

I finally attended my first Sitecore Chicago Meetup. This is my high level overview in a few words and pictures.

I got dressed for the occasion with my freshly made Sitecore Runner t-shirt. I took the train to Chicago. It is only 1.5 hour commute for me. 🙂 I am the first/last train stop to/from Chicago.


I had some time to kill when I got to Chicago and Rightpoint invited me to check out their offices and have a beer. I got to tour their offices and talked a little about my Sitecore experiences and my current company I am at Paragon.

We got to the meeting a few minutes late. After banging on the door since it was locked we were let in. 🙂 The first thing I saw was the food. They served Lou Malnati’s pizza my favorite, along with refreshments and dessert. Regrettably I forgot to take a picture of the food.

The first presentation was “Experience Marketing Presentation: High Level Review of the latest from Sitecore. Lead by Tim Ahlenius (Sitecore Digital Strategist MVP from Americaneagle.com)”. It was great and very informative of a feature that I can see being very useful.

The second presentation was “Sitecore Publishing Service. Lead by Jim Noellsch (Senior Technical Architect from Rightpoint)”. So good to hear about how much the publishing has improved with Sitecore. I know this change will make Sitecore clients happy.

The meetup ended after the second presentation. I can’t wait for the next one. I hope I can eventually do a presentation at one. If you are interested in attending a future one check out the meetup website here. Listen to Yoda.

Yoda (2)

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?