Dan Galvez and I had come up with an idea for a, sort of, Twitter based Sitecore Scrum. In essence, people would post on Twitter what they are doing today with the hashtag #SitecoreScrum. Interestingly, another Sitecore developer (Mike Reynolds) started this exact same thing the very next day with this tweet. I've reached out to Mike and we are going to try and keep up with a daily #SitecoreScrum at 10am Eastern time. I don't know what will come of this, but it can't hurt knowing what others in our realm are doing with Sitecore.
When using Team Development for Sitecore (TDS) you may need to tell your source control system how to handle certain files. This post is mainly targeted to folks using Git as their source control system, but it could be a general guideline for people using any source control system that isn't integrated with Visual Studio.
Disclaimer: This post was in a draft state for many, many, months. It was started and subsequently turned into my Sitecore Symposium 2012 talk. Now that SitecoreSym is over I am making this post and the associated code available.
I had discovered a little bug revolving around the Sitecore.Data.Fields.Field.ContainsStandardValue property in Sitecore (at least 6.4.1.101221 through current). You cannot trust the value returned by Field.ContainsStandardValue if you have made any of the following calls:
A common practice in all of my Sitecore sites is to have some sort of content fallback. What this means is that a field's value can come from somewhere other than the field itself, the source item (if it is a clone), or its standard values.
Content fallback is an excellent way to increase editor productivity and reduce content redundancy! Here are the three most common scenarios I run into with every project.
One of the major pain points when deploying Sitecore based web sites has always been configuration management. Sitecore has thousands of lines of configuration scattered across more than a dozen files.