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…
There have been a few posts which list and explains the various Sitecore Admin Pages and what they do, such as this post by fellow MVP Nikola Gocev, this post by Bjørn Klinggaard and numerous other posts as well.
I won’t repeat the useful info already in those posts. But did you know there are a few new tools in the admin pages?
Wondering how you missed them? The release notes for Sitecore 8.1 Update-2 states the following:
The main highlights of this update:
– Includes all relevant fixes from Sitecore 7.2 update-6
Like you, most of us probably skipped over that line for our Sitecore 8.1 upgrades, but there was some useful info in those release notes.
Often when working in Sitecore we extend the solution using pipeline processors, one of the most common being the
httpRequestBegin pipeline. This is also where a lot of the Sitecore goodness happens – site resolving, database resolving, device resolving, language resolving and item resolving – amongst many others.
Resolving things can be expensive. It takes up precious processing time and cpu cycles, so when you have to run a piece of code you only want to do that once. It’s the same reason that Sitecore puts a lot of data into the Context object for use throughout the request. So it would be handy if we could resolve our own code only once and make it available during the request as well.
Have you ever had the need to mass upload media into Sitecore? Maybe you are migrating to Sitecore or your editors now want to upload a big set of images into the media library. Tired of
Right Click >
Upload File over and over again?
There are some built-in ways in Sitecore to easily do this.
Read my previous blog post about SEO Friendly URLs? Go have a read, I cover several methods of achieving SEO Friendly URLs.
Did you read it? Did you read that part about
encodeNameReplacements? Yeah, I still don’t like them, but it seems like now we all have to deal with them at least.
The RTE field in Sitecore is a little bit old fashioned and a little stricter than the most of us would like, especially when you are working with tech savvy editors who may prefer to work directly in the HTML. The current project I am working on is based on the Foundation framework and like most frameworks a lot of the features are enabled using data-* attributes.
Unfortunately the Telerik controls used in Sitecore try to be super helpful and strip out any invalid XHTML. Also unfortunately data-* attributes are HTML5, and not XHTML😦