At SUGCON EU 2016 I presented about the different options of using Content Delivery Networks with Sitecore. At the time, I had been working on a particular task to offload large media items into Azure Blob storage and serve them to via Azure CDN and wrote a number of posts detailing how I achieved this.
One of the options that I presented was utilising Azure CDN to serve your media, allowing you to benefit from Azure’s Geo-located Edge Servers meaning that assets are served from locations closer to your users, your own servers can focus on just delivering content (possibly meaning less content delivery servers and licensing costs) as well as improving browser response times by domain sharding the requests.
Use of Azure CDN will work with any version of Sitecore, and is not specific to Sitecore 8.2 Update-1 which added Azure Web Apps support. In fact, you don’t even need to be hosting your servers in Azure to utilise the CDN service.
I’ve been asked by several Sitecorians about configuring CDN, so I thought I would share a step-by-step guide in setting up Azure CDN with Sitecore.
Have you ever had the need to rollback your Sitecore deployments? Or maybe an upgrade went wrong and you need to rollback the changes?
Well you should’ve taken proper backups then, shouldn’t you! Learn your lesson yet? Now go back and add proper back-up steps to your deploy process… Good. Jeez. Shortest blog post ever! Moving on…
The problem with backups is it takes time, which seems to exponentially increase as your Sitecore database increased in size, and an equally heap load of time when you need to restore that database. The other problem with the backup is that it is just a point of time restore, what about changes that have happened since that backup had taken place?
a.k.a “Rendering Wrappers”
tl;dr; MVC HTML Helper and custom CSS styling to add chrome highlighting around renderings in Experience Editor mode.
I presented this module at the Sitecore User Group London on 12th January 2017. You can download the slides for that lightning talk here.
A few months ago I presented Session 4 of the Unofficial Sitecore Training sessions that Akshay “Be My Friend” Sura and Mike “Blog All The Things” Reynolds have been hosting. If you’re new to Sitecore or need a refresher course then I suggest you head on over and watch the videos on the series, there’s some really useful info in there from some seasoned Sitecore developers and gurus.
Anyhow, I decided presenting stuff and virtually pointing things out is hard so I added a fairly early version of some code that we had been using and experimenting with on our current project. This would make it easier to see components in Experience Editor mode and therefore easier for the audience to follow along with what I was doing. Some people noticed this at least 🙂
tl;dr; Install the module, set the config value to match your environment, have a stylised login screen and header bar per environment.
Have you ever sat there working on some task and then suddenly someone asks you to take a look at an issue on the Production environment? So you log onto that server, resolve the issue, get distracted for a few minutes by cat videos and then get back to what you were doing. But you suddenly realise that those changes you were just making was not on your local environment, you still had the Production site open in your browser tab! Oh noes!
The problem is that all the environments all looks exactly the same… the only difference being that teeny tiny URL bar, the URL in which probably also looks very similar apart from some environment prefix.
A question popped up on Sitecore StackExchange asking how to remove the default items when installing using SIM. As we all know, Sitecore installs some sample items and provides the “lady with the phone” sample homepage. Normally I just ignore them, the items will be there in the deployed solution but since they are not referenced anywhere we don’t really care.
Anyway, there are no steps in SIM to clean the default items from the install of Sitecore. I’ve previously blogged about running scripts using PowerShell and TDS Post Deploy actions, but that requires SPE to be installed and the scripts to be deployed but TDS generates .update packages so that would be no good to install with SIM. However Sitecore packages themselves can contain Post Install Steps, they are not TDS specific – post install steps are used as part of the upgrade process or when installing packages such as WebForms For Marketers for example.
So why not create a custom package with a Post InstallStep to delete the default (or any) items?
I’ve previously written a couple of blog posts about Organising your Sitecore Patch Include Files and the subsequent Re-organisation of Include Config Patch files in Sitecore 8. As mentioned in that blog post, in order to ensure that our custom configs are patched in last we can place our own files in
/App_Settings/Include/z.Project. I also raised a Sitecore userVoice request to add additional folder locations for patching.
Recently when providing an answer on Sitecore StackExchange about alternative ways of disabling config files and taking a peek inside the Sitecore.Kernel to post some code for the answer I noticed something…
If you looked at the code snippet in my original post then you would have noticed that the method was
private static 😥
Something had changed…
I’ve recently been spending some time to upgrade our solution as well as perform some tweaks, optimizations and clean up on our deployment process. Even though I am the creator of UniCorn, I’ve almost exclusively been using Team Development for Sitecore in all the projects which I have worked on 🐘
The release of TDS 5.5 allowed developers to add their own custom deploy steps. Previously these might have been conducted manually (urgh!) or we had deployment steps added to our process in Octopus Deploy to conduct these. The post deploy steps however are better since they can be developer controlled and added to source control. Win!
The Hedgehog Team has been asking for the community to share their post deploy scripts. You can find a number of scripts here. There are some great scripts there, similar to what we currently have. But the way that script are added and managed in the TDS projects was a bit annoying to me…
So it got me thinking about that great quote by J.R.R. Tolkien:
One Script to rule them all, One Script to find them,
One Script to bring them all and using SPE bind them
One Sitecore Best Practices is on rendering and sublayouts is to make use of all the setting that are available to make Content Author lives more friendly, namely:
- Setting a thumbnail which is displayed when they select a component to add
- Restrict the datasource location to allow better grouping of content types and direct authors towards where datasources should be created to help keep everything organised
- Associate a template with the component so the correct datasource type is created
- Setting Compatible Renderings to allow authors to easily switch between renderings without causing errors
- Make use of Experience Editor/WebEdit Buttons to add custom funtionality
Did Vasiliy do a Friday Best Practice on this yet?
The launch of Sitecore 8.2 just a few days ago brought with it a a huuuuuge list of updates and enhancements. One of those great new features is an update in the Experience Editor to make the life your content editors much simpler and better to managing the content through workflow.
Component based design/architecture seems to have gained a lot more traction again in recent times especially with the Habitat project. But Sitecore itself has fully support component based design since version 6.4 (at least) with the numerous enhancements that were made to the Page Editor in that release to add better support for Datasources. In order to fully utilize all the analytics and personalisation features, you have to use datasources, you’ll be fighting the framework if you don’t.
Due to its page-based nature, the Page Editor/Experience Editor has also had problems giving appropriate information to the editors when dealing with heavily data-sourced pages and content items that may be used on several pages.
This leads to numerous problems:
- You don’t know where a datasource is used. Making a change on a component in one page may affect several other pages when the datasource is shared or used on multiple pages.
- You can’t be sure that a page will not be broken after publishing. When you workflow content, you don’t know what state a page is in as a whole. Although the page item itself is in the Approved/Final state of workflow, the associated content used on that page may not be. Therefore publishing a page even with the “publish related item” option would still not publish those non-final datasources.
Have you ever had to create a lot of users in Sitecore? Maybe you are setting up a new Content Management server and the users will be managed in Sitecore and you have to set up all the new users? Or maybe you need to create a whole bunch of users for the testers to be able to check different types of functionality for different user roles? Or maybe conduct some performance testing?
All of the above was true for us and rather than going Sitecore > Security Tools > User Manager > New then type, type, type and click, click, click, we headed for SiteCore PowerShell Extension. Cos…