How do I create a good Sitecore solution?

This blog post is part 1 in a series on “Creating good Sitecore solutions”. You will find part 2; “The page template mistake” here.

Having now worked as a Sitecore consultant for well over 8 years – sometimes in regular employment at one of the many Sitecore Partners in Denmark and the UK, but more often as a freelance consultant/contractor for the very same clients – I have been exposed to pretty much all aspects of what it means to create a Sitecore solution.

Sometimes I’m brought in to help a new and upstart Sitecore partner get some of their first Sitecore clients. They usually need help in scoping, defining and estimating the proposed project. Sometimes they keep me on to help in the actual implementation of the site as well – more often I am kept on to help train their existing developer resources in the practices and uses of Sitecore.

Other times – and these days, this is more often the case – I am hired as a Sitecore Architect for a project. In many ways the tasks I perform are the same as what I just mentioned, but the title Architect tends to imply doing all the above, alongside ensuring that whatever implementation eventually ends up getting built; will also fall in line with the almost mythological Best Practices for Sitecore implementations.

I say mythological with some irony, of course. While a lack of documentation used to be a problem, we now have nothing short of 1000s of pages of documentation and “cookbooks” available to us. These cookbooks will describe in detail, all the intricacies of implementing your Renderings, Rules, Templates. How to set up security, how to set up cloud solutions – pretty much how to do everything you’d want to with your Sitecore solution.

And this is it, really. If one was ever to define Sitecore Best Practices, this complete set of cookbooks would be it.  NOT this – The Sitecore Recommended Practices Cookbook. While I would certainly recommend that the practices described in this cookbook be followed, it in no way can be said to hold a complete set of “Best Practices” for a Sitecore solution. There’s so much more to it than that.

There simply is no single “manual” that will tell you everything you need to do. Everything you need to be aware of, everything you need to consider. There is no substitute for experience, as the proverb goes. This certainly holds true here.

And that actually brings me closer to the point I was wanting to make, and has brought me back to the keyboard after such a long absence from blogging. See the thing is – when I first started blogging, it was mostly about technical details. “The little things”. Information on Sitecore was somewhat scarce, and sharing whatever information we learned was the name of the game. With all the information now available, not to mention the probably 100s of bloggers who has taken to the blogosphere – I find myself in need of a new game. Experience. I will start using this blog to write and share some of the information you will not find in cookbooks, other peoples blogs or even John West’s book.

I’ll kick this off by beginning to answer the very question I pose in the title of this post. You will find it is going to take quite many posts to follow, to arrive at any sort of answer – but we have to start somewhere.

To create a good Sitecore solution; you must first decide to create a Sitecore solution.

“What?  That it!?”

No. That’s not all of it, but this is most definitely where you need to start.

See the thing is; as any project I’ve been part of goes through the same motions – the same pattern. Doesn’t really matter if the process in place is Agile or Waterfall. If you have a Scrum Master or a Project Manager (or both).

In the beginning (or as you go along, if you are truly Agile. I have yet to see my first truly Agile Sitecore project implementation); everyone is on about features, design and (usually most importantly) the cost. If you’re in an agency, your agency has to win the bid. If you’re building in-house, the project will still have a cost and will need an approved budget.

Then comes the construction. Developers, designers and whatnot get to work. Here the focus becomes jQuery libraries, lightboxes, valid HTML, performance and of course the actual Sitecore implementation. The perceived necessary stuff from the cookbooks mind you, whatever it takes to make it work.

And if all goes to plan, eventually the “site” (which is usually what a Sitecore project will be – the delivery of a “site” for Company A, or a re-make of a “site” for Company A – and herein lies the problem) will get handed off, go live, start receiving visitors and everyone shakes hands.

I know, I know. I am both simplifying the whole process and adding a bit of irony on top. Bear with me, this post is already turning out to be much longer than it seemed to be in my mind.

My point. The project is about a “site”. Or new features on a “site”. Very very rarely – if ever – does it get discussed, how the end user (the Sitecore end user, not the “site” visitor) will be interacting with the Sitecore solution. One simple – and when you look at it; astonishing – fact, and no-one usually thinks to ask it.

What happens is; the “site” gets built, gets handed off, gets approved – all from looking at the “public face” (if you will) of the “site”. If it ticks all the boxes, “we’re done”.

Sure enough, depending on the actual level of experience (see above) of the team that actually did the scoping and ultimately the Sitecore implementation of the “site” – parts of it will also be content manageable. Not all of it – very rarely – but parts of it.

Is this a good Sitecore solution then?  Well I would argue; “no”. It’s a “site” running on Sitecore and could therefore in the strictest sense be dubbed a “Sitecore solution” (as the customer ordered, and got). But a good one?

At this point, if you don’t really know what a good Sitecore solution should feel like, I would recommend you contact your local Sitecore office and have one of their excellent sales people demonstrate the “Nicam” site for you. But in summary, I would say that a good Sitecore solution should at the very least tick the following boxes:

• It doesn’t restrict the use of the built-in Sitecore tools
  • The Sitecore Page Editor
  • The Sitecore Debugger
  • The Sitecore Profiler
• It allows you to use at least the basics of Sitecore functionality – probably the very reasons being why Sitecore was chosen over a competing system to begin with
  • All components on any page can be M/V tested
  • Sitecore Analytics Goals and Failures can be defined for relevant parts of the site
    • Alternatively that these are triggered in the code, hardcoded
  • Editor User usability has been considered
    • Placeholder settings have been set up
    • Insert Options
    • Permissions, if necessary
• It can run on a single-server environment or scale to multi-server

I mean… The CEO (usually) who ultimately approved the considerable license fee for a Sitecore solution was told by Sitecore sales people; “Sitecore can do all this”. In most cases I have seen, the CEO doesn’t dig deeper into the subject matter – he or she will sign off, and (quite naturally) expect to be getting exactly this. As well as the “site”, mind you.

Less than 5% of all the Sitecore solutions I have seen delivered, would tick all of the above boxes.

Yes. This includes some of “my own” – albeit delivering any Sitecore solution can probably never be put down to just one persons influence.

The “reasons” are many, but the most common one that gets passed around is this. “It would require extra work for us, if we were to expand the “site” with the necessary “stuff” so you can work with it in Page Editor/Set it up for Sitecore Analytics/Configure bespoke security settings”. Extra work in this business means “more money” or at the very least “more time” – none of which any of us has enough of to pass around in this economic climate.

And so it usually ends. From time to time customers will put in tasks like; “We want a split-test set up for our Add To Basket button – how much time will that take/what will it cost?”. Small improvements like that are made over time – everyone is happy. Except – if you’ve read this far, you will once again sense a slight irony behind my words – perhaps me.

Over the posts to follow I will demonstrate how most of these boxes can be ticked, and actually not cost you any more time or the client any more money. Not to any significant degree anyway.

It comes back to experience. It comes back to what can only be read between the lines in the cookbooks and blog-posts. It comes back to first deciding:

“I want to build a Sitecore solution”

And if you get at it from the onset with that attitude, and start considering what that actually means – you are on the right track.

And if you’re in the other end; the person buying the solution. Don’t go “I need my “site” on Sitecore by the end of this year”. Go: “I need this “site” implemented as a proper Sitecore solution. I’ve seen the impressive features of Sitecore and I want to use that platform to improve my business/user experience/conversion rate”.

Decide to build or get a good Sitecore solution, and you’ve at least started with the right mindset.

Email Confusion - Configuring SMTP options for your Sitecore (Modules)

I’ve been working a lot with the different modules in Sitecore, and it seems everytime I need to send out an email I run into difficulties. The reasons for this are quite numerous.
In web.config we have the default MailServer settings, which are used through-out the system:

      <setting name="MailServer" value="" />
      <setting name="MailServerUserName" value="" />
      <setting name="MailServerPassword" value="" />
      <setting name="MailServerPort" value="25" />

Now.. No statement without exceptions, so firstly: The Email Campaign Manager(ECM) uses its own provider settings – this makes sense, since you might not want to send out 10k+ emails through your regular SMTP provider ;-). So you either use the Sitecore Message Transfer Agent(MTA) though the Sitecore App Center with a subscription, or you setup a local MTA.

Secondly: Web Form For Marketers(WFFM) has it’s own send email action (/sitecore/system/Modules/Web Forms for Marketers/Settings/Actions/Save Actions/Send Email Message) which by default overrides your MailServer with it’s own "example.host” – not to keen on their choice of default values here, but just remove it and it will default to your web.config settings.

The trouble begins

This is all well and fine, until you have a client that want to use a SMTP service with either SSL or TLS – The default Sitecore send mail method (Sitecore.MainUtil.SendEmail) do not implement SSL. This is curiously handled in both ECM and WFFM, just not in the base Sitecore system.

In ECM, when using a local MTA, you have the option to set the “SMTP.StartTLS”. And in WFFM send mail action, you have some undocumentet settings available (not really a surprise to experienced Sitecore developers ;-)) but add the “enableSSL” attribute in you “send email message” parameters section, and this will ofcourse not enable SSL – it will however enable TLS :-P.You can verify this by sending trough gmail. To make it work you need to send trough port “587”, and not “465” which is for normal SSL encryption.


This is because Sitecore uses the System.Net.Mail.SmtpClient which states

The SmtpClient class only supports the SMTP Service Extension for Secure SMTP over Transport Layer Security as defined in RFC 3207. In this mode, the SMTP session begins on an unencrypted channel, then a STARTTLS command is issued by the client to the server to switch to secure communication using SSL. See RFC 3207 published by the Internet Engineering Task Force (IETF) for more information.
http://msdn.microsoft.com/en-us/library/system.net.mail.smtpclient.enablessl.aspx

Now we still have a problem with the rest of Sitecore – Password recorvery, Sitecore Ecormerce Services and so on.. But since Sitecore uses the System.Net.Mail.SmtpClient we then have the option to “enableSsl” trough our web.config file. Just add this entire segment to the bottom of your webconfig file (before the end </configuration> tag)

  <system.net>
    <mailSettings>
      <smtp deliveryMethod="Network">
        <network enableSsl="true" />
      </smtp>
    </mailSettings>
  </system.net>

This enables the rest of Sitecore to use a SSL(with TLS) SMTP provider, like gmail, for all email functions. Just set your MailServerSettings to:

      <setting name="MailServer" value="smtp.gmail.com" />
      <setting name="MailServerUserName" value="yourAccount@gmail.com"/>
      <setting name="MailServerPassword" value="yourGmailPassword" />
      <setting name="MailServerPort" value="587" />

And you are good to go. Be aware that you still need to include the <enableSSL>true</enableSSL> tag in WFFM “Send Email Message” or it will specificly set enableSSL to false.

Also Sitecore may include this in a later version, and then you should remove this and use the provided Sitecore settings. This is testet on a Sitecore CMS 6.5.0 rev 111230 with WFFM 2.3.0 rev 120216. using .Net 4 Framework

Back into the core ;-)

Followers of this blog will probably have noticed, there has been a distinct lack of posts lately. Truth be said, I have had a very busy 18 months working intensely with Sitecore. In fact so busy, I’ve not had any spare time at all to share my thoughts and insights with you.
This, however, I intend to change now. And not only that, I’ve also invited my friend and colleague Finn Sandbeck Nielsen to co-author this blog with me. Finn has been working with me on a series of complicated Sitecore projects over the past couple of years and has lots of insights, tips and tricks and nice gotcha’s to share with you. He already has a handful of posts on the scetchboard, so expect things to liven up a little around here soon.
Other than that, I myself will be sharing more insights into the art of integrating external data into Sitecore – something which has been a professional pass-time for me ever since I started working with the product. And as always, there’s be bits and pieces of information from the trenches at the fronlines of Sitecore implementation-land.
We hope to see you all at Sitecore Symposium EU later this year.

5 years of Sitecore blogging

Without any fanfares, ticker-tape parades or national holidays, this blog’s 5th anniversary came and went just this last week

Now I can’t be certain, but I think that might just qualify as being the earliest Sitecore blog outside Sitecore itself. Certainly should qualify me for the Old Boys League, if nothing else *g*

I do remember people like Lars F. Nielsen was blogging back when I started (his archive stretches back to October 2005), and there was also various grassroots projects going on, on communities such as Yahoo and probably more.

I figured I’d use this post to do some sort of recap over the past 5 years of Sitecore blogging, at least from my own little narrow perspective of the world.

 

5 years ago

Apparently, it all started with some comments on the IDTable.

I remember we were working a lot with integration of external data and Sitecore. This was in part due to the song of the Sitecore Evangelists – this feature was being marketed back then as one of the key advantages to Sitecore CMS over its competition – and back then, putting too large quantities of data into a Sitecore solution wasn’t really a great hit in terms of performance either. So we used data sources and data providers.

It’s actually quite funny, but the key document we used to guide us - Integrating External Data Sources is still on the SDN today and as far as I can tell, completely unchanged.

Now if you’ve never had to work with custom data providers, you probably don’t know this. But it’s a matter of extending your Sitecore database’s capabilities and feeding it from multiple sources (other than just your scSolution_Master database, keeping track of the relations between the Sitecore ID and your external key, setting up Proxy items, enabling Virtual Item publishing…  all sorts of black magic in short, and while we did eventually get things working – it was never a happy marriage.

Ironically, Sitecore eventually cracked this problem. By means of a complete re-architecture – with the release of 6.3 (I believe it was, perhaps 6.4) and Item Cloning. I’m not sure this feature was specifically targeted at solving the same types of problems we were having back then, but it certainly seems to be a side effect.

All fine and well     Except I very rarely do these types of integration today. I import the data into Sitecore instead, since it just makes a lot of things a lot easier once you’re inside under the Sitecore Feature Umbrella to take care of “boring” issues such as Versioning, Language Versions, Workflows, and so on.

So anyway…

By no means was this blog ever meant to be a commentary on the workings of Sitecore Data Integration, even if there has been a lot of posts about that over the years. It so happens that this type of work fits my personal developer profile quite nicely, so I seem to end up doing those types of jobs quite a bit.

Looking back over the early posts, this blog partly came to be out of frustration. Back then, the Sitecore product was highly unstable in many areas, and each new release seemed to remove a couple of issues only to introduce a handful of new ones. And none of this was being documented, no release logs of any note, no real change logs, barely a “Known Issues” list. At least that’s how I saw it at the time, because the information COULD have been there – and just very hard to locate. SDN, while still looking almost like I remember it, wasn’t the same either – searching for content was near impossible – and that lead myself (and I suspect others) to start putting information out where Google (well… Yahoo! in my case) could find it. The thinking was; “If I can save some other developer the grief of spending 4 unscheduled project hours on combatting this problem by putting the information out there for him or her to find, it’ll be worth it”

Up through to today

Of course, most of this has changed today.

“Aah you young kids of today, you know nothing about the hardships us old folks had to endure”

I think it was probably best summarised in Showing Sitecore how to improve, where the number one grief about it all was the inability to find absolutely anything on SDN. Documentation was starting to come out at that time, and has now evolved even more – there’s a Sitecore Cookbook on how to do just about anything with the product – now it’s actually more become a problem of finding the right document your information is located in. *g*   Still, I’d much rather have that problem, than no information being available at all.

SDN search itself is better too. While it’s still not perfect, I think it is certainly good enough so as to silence the critique.

So over the years, the nature of posts in this blog started to change as well.

For one thing, I started becoming more proficient in the use of Sitecore. It could of course mean that I’ve learned to avoid the grey areas of Sitecore functionality efficiently and therefore don’t as often fall into a pit from which there can be no hope of returning. It could also mean that the product has stabilised, and there are in fact not as many pits to fall into any more.

I think both.

The core product has become very stable, with the only issues I really run into these days being related to only the newest of features and language handling. Releases are being well documented and there’s enough cookbooks out there now to probably even shut Gordon Ramsey up

So this blog turned, in part, from it’s original function into something else. I am still motivated by sharing information to save my fellow Sitecore developers some grief, but the posts are more informational these days. Of course, the entire scene has changed as well. There’s a virtual army of corporate Sitecore bloggers now (The Sitecore Corporation does seem to assimilate Sitecore professionals quicker than the Borg collective) and on my blogroll I get on average 6-8 blog posts a day related to everyday Sitecore usage. Most of these guys are being paid to blog, and I certainly won’t pretend to be able to keep up with the sheer volume of information they output on a monthly or yearly basis. I am worried though. Sitecore never liked public critique (despite what is being said in public), and now that 90% of all Sitecore related blogging is being moved and syndicated with Sitecore.net itself – how will this affect the public debate that they themselves have always encouraged (yet not truly sought)?

I wonder what will happen, if one was to start commenting critique on their posts on servers that is under corporate control…  

And onwards

I can’t predict what the future will bring. I’ve been working – without pause – with the Sitecore product since I started blogging about it. I think it’s a safe assumption that I will continue to blog about it for as long as I have something to say, add or comment about it. My target group will continue to be the Sitecore developer base, possibly shifting the focus slightly upwards towards the Solution Architects and Project Managers.

There’ll still be no post schedule. And English will still be my second language, not my first

To the next 5 years….