I’ve posted my recent work on how to avoid receiving a specified path or file name to long error while doing a deployment on Sitecore’s Azure.

In an attempt to better understand the Sitecore Azure API and find the files/paths preventing a successful deploy, I built the Sitecore Azure Build Verifier. This tool will execute a dry-run of a Sitecore Azure deploy, alerting you of files and folders which fail validation.

Read the full post and see the screenshots on my blog:
Sitecore++ Dave’s Sitecore Development and Research Blog


I’ve posted my recent work on how to set up Sitecore’s Azure API settings on GitHub and have embedded the code into the post on my blog.

Details within this post outline how to obtain basic settings, global variables and Azure module items from Sitecore’s Azure API. Included are also some pitfalls to be aware of when working with the library.

Read the full post and see the screenshots on my blog:
Sitecore++ Dave’s Sitecore Development and Research Blog


I recently posted my research on how to hack Sitecore’s web forms with Razor View for Marketers and Blade.

Web Forms for Marketers provides flexibility on part of content editors to create and manipulate simple forms for collecting user data. While there’s a great deal of flexibility on the back-end, customizing the format and layout of the form can sometimes be a more difficult task.

Knowing what some of the limitations are regarding the rendered markup of Web Forms for Marketers, I wondered how difficult it would be to override the rendering of the form to allow drastic changes to the standard look-and-feel of the out-of-the-box implementation. Sure, content edits can add CSS classes to content, but I wanted to push the envelope and see how far we could go.

Read the full post on my blog:
Sitecore++ Dave’s Sitecore Development and Research Blog


I recently developed a new tool to optimize the output of the Sitecore media library, Dianoga.

There are some other image optimization modules out there for Sitecore, so how is this one different? First, this one is automatic (no clicking a button in the content editor, or forgetting to). Second, this one optimizes as the media is served to the client, which means that if you’re using Sitecore’s image resizing functionality (which is perfect for modern responsive techniques like srcset and Adaptive Images without tons of work) each size of the image is individually optimized – which is important because the act of resizing the image deoptimizes it.

Read the full post on my blog: Kam’s Idea Log.


Reported by Dave Peterson:

On April 17th, The Philadelphia Sitecore Users Group met at CityCoHo Philly Nexus to discuss the new features of TDS, a product by Hedgehog Development. Version 5 is the latest release to date and requires minimal effort to convert a version 4 project to version 5.

New features include:

  • New option for creating a “TDS Project with Wizard”
  • Additional project properties to separate base template references by project
  • New package bundling options.
  • ORM code generation.
  • Testing and validation of deployment settings prior to execution.
  • Whitelisting dlls for update packages instead of blacklisting.

In addition to the new features, ability to connect to TDS through Sitecore Rocks is available. Through Rocks, developers can manipulate TDS settings directly through Visual Studio.

Validation was seen as a particularly interesting aspect to the new version as validation allows for pre-defined checking of TDS configuration rules at compile time. If any member of the development team violates one of these rules, a build error is generated forcing the developer to resolve before proceeding with deployment.

TDS, paired with RAZL (also a Hedgehog product) offer some interesting scenarios regarding continuous deployment. RAZL, offering the ability to generate deltas of content between environments and leveraging TDS to carry those changes across environments. Consider a scenario where changes are carried from a production environment back to a QA server to refresh content in a nightly process.

Overall, the group was impressed with Hedgehogs demo of TDS and excited to learn more about the new features.


As the weather gets nicer, the user groups get a little sparse. Here is what’s going on at ISITE sponsored Sitecore User Group(s) around the country in Philadelphia in May:


On May 21st at the Philadelphia Sitecore User Group our own Dave Peterson will be presenting ISITE’s Unicorn utility for Sitecore. Charlie Darney of Delphic Digital will also be presenting.

Unicorn is a utility for Sitecore that solves the issue of moving templates, renderings, and other database items between Sitecore instances. This becomes problematic when developers have their own local instances – packages are error-prone and tend to be forgotten on the way to production. Unicorn solves this issue by using the Serialization APIs to keep copies of Sitecore items on disk along with the code – this way, a copy of the necessary database items for a given codebase accompanies it in source control.

More Details: Philly Sitecore Meetup – Spring 2014

Stay tuned for more information on what was shared at our user group meetings!


Hedgehog Development recently hosted the April edition of the Sitecore Virtual Users Group meeting. The guest speaker for April was Nick Wesselman CTO at Active Commerce. Nick gave a great presentation and demo of Active Commerce’s latest release Active Commerce 3.1.



Nick covers a range of topics including:

  • Active Commerce 3.1′s Architecture
  • Why Active Commerce chose a server-side adaptive approach to mobile instead of using a responsive approach
  • How Active Commerce uses Angular

You can watch the video below.  Added Bonus: At the 37 minute mark our own Dave Peterson gets a mention for his terrific posts on Angular.

Dave’s Angular + Sitecore Blog Posts

Building a Single Page Application with AngularJS and Sitecore: Part 1

Building a Single Page Application with AngularJS and Sitecore: Part 2



Here is what’s going on at ISITE sponsored Sitecore User Groups around the country in April:


On April 17th at the Philadelphia Sitecore User Group Sean Holmesby of Hedgehog Development will give a hands on demonstration of Team Development for Sitecore 5.0.

Team Development for Sitecore 5.0 Team Development for Sitecore has become the best practice tool when it comes to Sitecore development. By giving developers to check their code into Source Control, fire off Continuous Integration, and safely work as a team it allows developers more freedom than ever before. Since its initial release in 2009 TDS is now getting ready to launch TDS 5.0. With plenty of new features including cross project referencing, new project wizard, validation scans, and many more features developers can use to improve their development.

More Details: Team Development for Sitecore (TDS) 5.0 Demo


New England

On April 23rd Matt Friedlander of Hedgehog Development will giving a hands on demonstration of  Hedgehog Team Development for Sitecore 5.0 at the New England Sitecore User Group.

Team Development for Sitecore has become the best practice tool when it comes to Sitecore development. By giving developers to check their code into Source Control, fire off Continuous Integration, and safely work as a team it allows developers more freedom than ever before.  Since its initial release in 2009 TDS is now getting ready to launch TDS 5.0. With plenty of new features including cross project referencing, new project wizard, validation scans, and many more features developers can use to improve their development.

More Details: Hedgehog Team Development for Sitecore 5.0



On April 28th Coveo will be presenting Coveo for Sitecore at the Portland Sitecore User Group. Representatives from Coveo share details about:

  • Coveo Sitecore Integration
  • Behavioral Search Features including geo-location and boosting rules
  • Coveo Developer Support

More Details: Coveo for Sitecore

Stay tuned for more information on what was shared at these user group meetings!


Dave Peterson, ISITE Design Developer and 2014 Sitecore MVP, is a well-known figure in the Sitecore community. Along with his hard-earned MVP recognition, he’s a co-organizer of the popular Sitecore Users Group in Philadelphia and a frequent contributor to open-source code libraries and other parts of the community.

We spoke to Dave from his home office in Philadelphia, just before he left for Oregon to join his technical colleagues at our first-ever internal “T Week”.

Q. Tell us about yourself, Dave. Sitecore MVP Dave Peterson

I grew up in Brookline, MA, a suburb close to Boston. After high school, I attended Drexel University in Philadelphia where I studied computer science and met my wife, Melanie. We moved back to the Boston area after graduation and I worked as a software developer with some companies in the area.

In 2012, I joined ISITE Design and, soon after, relocated with my wife back to Philadelphia. We live outside the city, have 2 beautiful daughters, Katelyn and Emily, and are expecting a third girl in June. Life is good!

Q. How did you become so passionate about technology?

My dad worked in IT so even as a kid I was exposed to computers and software. In high school—this was just before the web really caught on—I was already going online with AOL and even running a small bulletin board service. It wasn’t that long ago that I was using a dial-up phone modem! I also had the chance to take a number of computer-related courses before I got to Drexel. With this background, my decision to study computer science and make it my career was pretty easy.

Q. Why did you gravitate towards Sitecore development as your core skill? 

I was working at a company that was still using a custom-built content management system. As they thought about replacing it, we looked at several enterprise solutions. Sitecore came recommended by a trusted friend so I looked into it pretty closely.

Sitecore has many strengths, but two things really caught my attention as a developer. First, Sitecore’s extensibility meant I’d be able to build custom functionality on top of it. This means more flexibility to solve very challenging problems. Second, I found Sitecore’s developer and user communities to be extremely supportive. From the start, I felt welcomed and knew they’d help me succeed.

Q. Congratulations on being named a 2014 Sitecore MVP, Dave! How did that come to pass?

I honestly never saw myself being named a Sitecore MVP at this point in my career. While I’ve worked hard at ISITE, been exposed to some tough problems, and done my best to be a leader in the community, I knew that the MVP bar is quite high. I work with Kam Figy, also a Sitecore MVP, and see that standard of excellence in everything he does.

So, it was a big deal to even be nominated. As I’ve told my friends, I would have been happy if it had all ended there. When I got word that I’d made the final MVP shortlist, it was an extremely special moment. The recognition from my peers perhaps meant the most to me.

Q. What advice would you give to up and coming young developers?

That’s easy: Get involved! Software developers may be part of larger teams, but we often work by ourselves on a day-to-day basis. It’s easy to overlook the skills and experience of other developers if they’re not part of your immediate team. That’s a big mistake in my mind.

I really like getting involved and have always found it fun. Outside of work, you’ll find me active in several online Sitecore developer communities, contributing to open source code libraries for other developers, and attending the Philadelphia Sitecore Users Group (which a few of us started up a while ago). Together, they represent a big commitment of time and energy, but I’ve learned a lot and met some great people through these side efforts. Get involved with your peers—you won’t regret it!

Q. Thanks for your time, Dave. How can people contact you?

I’m on Twitter a lot, so that’s the best way. You’ll also find me at most Philadelphia Sitecore Users Group meetings if you’re in the area. Or, you can call ISITE Design and talk to not only me but a whole bunch of other great Sitecore developers. We’d love to hear from you!


This post was originally published on Kam’s Idea Log by Kam Figy on November 16, 2013. 


There are many times where you need to extend the Sitecore data architecture in some way. One of the most obvious, and most used, is attaching an event handler to one of the item events (e.g. item:saved, item:renamed) but this is not by any means the only way to manipulate items before they get to the database.

This blog post came out of a discussion I had with Alex Shyba about the DataEngine, a few hours on a plane, and a lot of decompilation. I’m going to attempt to show what happens when an item gets saved and where you can plug into that.

The entry point

The most high level API is of course the Item class. Saving an item using this API is very simple:

using(new EditContext(item))
    item["MyField"] = "newValue";

When the EditContext goes out of scope, this causes item.Editing.AcceptChanges() to be invoked, and our journey down the rabbit-hole begins there.

The Item Manager

Our next step is the highest level item data API in Sitecore: the ItemManager. At first blush ItemManager appears to be a rather ugly giant static class, with tons of manipulaton methods: SaveItemAddVersion, etc. However, it’s not as bad as it looks. ItemManager is basically a static facade around the current ItemProvider.

The Item Provider

Here’s where things get interesting. You can register multiple item providers in the config under itemManager/providers. While this appears to provide a lot of power as an extension point – being able to plugin your own high level provider – it unfortunately seems to be rather ungainly. If multiple providers are registered you can access them directly using ItemManager.Providers, but the other ItemManager methods only execute against the default provider. You could replace the default provider with your own, but this is less than ideal as it can lead to contention for whose item provider gets used if more than one module wants to extend using it.

Extension points aside, the ItemProvider is the most broad data API Sitecore provides. It deals in high level objects and abstracts lower level concepts like databases and item definitions away. Most all methods in the ItemProvider result in invocations of the next lower level construct, the DataEngine.

UPDATENick Wesselman pointed out that some queries will bypass the Item Provider and go directly to the Data Engine. This gist has some examples of the types of things that bypass the Item Provider. In light of this I’d say the item provider is generally not a good candidate for extending things.

The Data Engine

DataEngine (generally accessed by databaseObject.DataManager.DataEngine) is a very interesting component for extension. Unlike the item provider, the DataEngine is database-specific. This is also the layer at which item event handlers (e.g. item:saved) are processed, but more interestingly is also a place where you can hook events in an uninterruptible fashion. Regular event handlers, such as item:saved, are vulnerable to being disabled when someone scopes an EventDisabler. Generally this is good, as events are disabled for performance reasons during things like serialization bulk load operations. But occasionally, such as in Unicorn, you need an event handler that cannot be disabled. Having a Unicorn event not fire would likely mean data being lost.

The internal architecture of DataEngine works something like this: – An engine method gets invoked – The engine creates and initializes an DataEngineCommand<> object, using a stored prototype of the command – The DataEngineCommand has its Execute method invoked.

The EngineCommand is a generic type, and each action that the engine can take has its own implementation – for example, there is a Sitecore.Data.Engines.DataCommands.SaveItemCommand class. Each of these command types is bootstrapped by a prototype system on the DataEngine itself. The engine, by way of its Commandsproperty, stores copies of each command type. When a new command is needed, the existing prototype command is cloned (Clone()), initialized (Initialize()), and then used to execute the action. These prototypes are settable, including via configuration, so this allows you to inject your own derived implementation of each command and thus inject ‘event handler like’ functionality into the DataEngine.

Item Buckets utilizes this type of functionality injection, replacing the AddFromTemplatePrototypewith its own extended implementation. This is the relevant section of Sitecore.Buckets.config:

  <database id="master" singleInstance="true" type="Sitecore.Data.Database, Sitecore.Kernel">
      <obj type="Sitecore.Buckets.Commands.AddFromTemplateCommand, Sitecore.Buckets" />

This same functionality could be used to inject non-disableable event handler type functionality into other events, for example by replacing the SaveItemPrototype. Unfortunately this method also suffers from possible contention issues if multiple modules wished to patch these commands, so be careful when using them.

The DataEngineCommand

Once the DataEngine creates and executes a command, the command generally does two things: * Pass its task down to the Nexus DataApi to be handled * Fire off any normal item event handlers (item:saved), as long as events are not disabled

Most of the methods on DataEngineCommand are virtual so you could extend them. The most obvious candidate, of course, is the DoExecute method that performs the basic action of the command.

Further down the rabbit-hole we arrive to the Nexus APIs.

The Nexus DataApi

The Nexus assembly, due to it containing licensing code I believe, is the only obfuscated assembly in Sitecore. This makes following what the data API is doing rather difficult, but I’m pretty sure I traced it back out as a call to the databaseItem.DataManager.DataSource APIs, which thankfully are not obfuscated. It’s worth noting that the Nexus APIs appear to also be using a separatecommand-class based architecture internally. Given the sensitive nature of the Nexus assembly however, I would look elsewhere for extension points.

The DataSource

The Sitecore.Data.DataSource appears to largely be a translation layer between slightly higher level APIs, where things like Item are used, and the low level API of the data providers (which use constructs like IDs and ItemDefinition instead). The data source is very generic and does not appear to be designed for extension, which is fine because we can extend both above and below it.

Methods within DataSource eventually make calls down to static methods on the DataProviderclass.

The Data Provider

There are two faces to the DataProvider class. The internal static methods that the DataSourceis invoking are helper methods that invoke non-static methods on all of the data providers attached to the database. (Yes, you can have multiple data providers within the same database, which may not even look at the same backend database at all…hehe) The actual data provider instances are the lowest level data APIs in Sitecore. They deal with primitive objects and have a lot of unspoken rules about them that make them tougher to implement than most other extension points. However they are also the most powerful extension point there is. Using a data provider you can manipulate the content tree in nearly any fashion for example Rhino, a data provider that makes serialized item files on disk appear to be real content items in Sitecore.

You’re still reading this?

Hopefully this is a useful post for some crazy nuts like myself who like to bend the guts of Sitecore. It’s definitely a long and byzantine road from saving an item to it getting to the database. Rather amazing that Sitecore is as fast as it is with all of these layers. Part of me suspects that some are baggage from Sitecore 4 for backwards compatibility.