[noun] - \ko-'da-la-te\ - Code and Effect - solving problems with just enough amount of code - by Adam Najmanowicz
One of the things I love about Sitecore XM/XP with SXA is that site definitions live in items rather than config files. You add a site, you rename a site, you delete a site, and nobody has to restart the application. The SXA site provider reads from the content tree, rebuilds its internal site dictionary, refreshes MVC routes, clears caches, and the instance is ready. Elegant.
Until you have two thousand sites.
While profiling a Sitecore XM/XP 10.x solution I noticed something that made me do a double take. Hundreds of SQL calls per single page request. Not complex queries either - simple, repetitive child item lookups hitting the database over and over again.
This turned out to be a missed caching opportunity in Sitecore’s SqlServerDataProvider. Specifically, the GetChildIdsByName method gets called every time Sitecore needs to resolve a child item by name under a given parent. On a content-heavy site with deep trees and lots of renderings, that adds up fast.
Creating back-end integrations is inevitably linked with having to authenticate against a remote endpoint. Be that a Rest API, FTP or an APM - secrets (credentials, api tokent, shared secrets) of some sort will be involved in the process.
Those credentials must be stored somewhere. At this point I hope no one even considers hardcoding those but even if you extract them to configuration - having them exposed in your repository may be a bad idea and is frowned upon by tools like SonarQube.
I’ve received this nice comment on one of my earlier posts and I thought it might warrant a blog post since it is a nice little challenge and might be useful for more scripters in our community.
Hi Adam, thanks for the pointers on PowerShell! There’s one in particular I’m hoping to get some help with, if that’s ok? I have created a Branch Template in Sitecore, and I want to deploy it under every item in the Content Tree that uses one particular page template (about 200 instances of deployment, in this case). For an added bit of fun, there will be several different language versions being deployed along the way, so I guess that prevents me doing a blanket rollout. Could you please recommend a script that is along the lines of “Add this Branch Template under this Item ID in the following named language codes”? I realise I would then be repeating that line 200 times with varying parent item ID and languages, but I can live with that if that’s the easiest way to do it. Many thanks for your help! Phil Neale
In one of my previous posts I described how to create reports in Sitecore PowerShell Extensions (SPE for short) that allow you to leverage the joint power of Sitecore and PowerShell to deliver complete and elegant reports in little to no time. In this post I’ll tell you how to take this a step further and operationalize them into full blown Sitecore Desktop applications. The secret sauce is in the actions you can place on the report, the additional parameters that I haven’t mentioned in the previous post, and the use of Sitecore rules engine with some rules that come with SPE. For the purpose of this post I will limit the scripts to samples that are (mostly) in the vanilla SPE deployment. Let’s begin with describing the actions and how you can configure them to appear in your reports.
Since we’ve seen some interest from developers wanting to join the Sitecore PowerShell Extensions team, I thought it might be worth documenting how my development environment is put together to allow for easier on-boarding of new members (Yes, we’re hiring! No, we can’t pay you ;) ). Maybe you just want to compile it yourself to make sure we’re not up to no good, or just plain see inside and play with it… First of all you need to have Sitecore installed somewhere (obviously). For the purpose of examples I’ll assume your instance is located at *C:\inetpub\wwwroot\Sitecore8* and has the 3 standard folders Data, Databases and Website in them as it normally has. For that very same reason I’ll also assume that your Sitecore PowerShell Extensions project folder is located at *C:\Projects\SitecorePowerShell*
It’s been a while since my last summary on April 2012 but finally getting to update the Reference page with the latest community summary for Sitecore PowerShell Extensions.
Following are the updates I will be pushing onto the reference page I’m trying to keep up to date and failing miserably most of the time.
If you’re reading this, chances are you’ve probably read about the ways of putting scripts in the Content Editor ribbon or Context Menu. Those are some simple and quick ways of extending the Sitecore UI to do quick actions accessible for your users without them having to even know about the existence of PowerShell in your system. Up until now however we’ve not been very vocal about the fact that those does not really have to be quick one-off actions but they can indeed form a broader solution to your problem through the use of persistent, named sessions. In fact Sitecore PowerShell Extensions (SPE) allow you to manage sessions and decide that it should stay in memory after the script have executed. In fact SPE does quite a bit of session maintenance itself that you might want to be aware of.
Creating reports is probably a task that every developer dread. I for once always felt like listening to Tennessee Ernie Ford’s ?16 Tons? every time when I was supposed to do it for yet another project audit – especially this part resonated with me:
I was born one mornin’ when the sun didn’t shine I picked up my shovel and I walked to the mine I loaded sixteen tons of number nine coal And the straw boss said “Well, a-bless my soul”
Reading some of the blogs from the Sitecore community I find it pretty apparent that we didn’t do a great job advocating the optimizations that PowerShell Extensions have introduced for working with Sitecore items. This blog attempts to rectify this problem to a degree.
The most natural way to retrieve Sitecore items is with use of Get-Item and Get-ChildItem commandlets. That is because those 2 commandlets add a PowerShell wrapping around them that allows the functionalities that I’m going to describe in the next section of this blog after I’ll tell you all about retrieving items. If you have retrieved your item directly using the Sitecore API you can still add the nice wrapper when you pipe them through the Wrap-Item commandlet as well. Some of those enhancements work in the older versions of PowerShell Extensions but I would encourage you to upgrade to the latest version (2.7 at the time this blog was written) to leverage the full potential of the environment.
I’ve decided to 1-up the game from my previous post and zip something that isn’t really a real file but rather a blob in a Sitecore database. The script below is based heavily on the last post but instead of just zipping content of a flat folder traverses the Sitecore item tree and zips all files beneath the current folder. If you have downloaded the 2.1 version of the Sitecore PowerShell Console from the Sitecore Marketplace you will actually have the script deployed on your system already. Here’s how it looks like for your user in the Content Editor:
Last night I needed to reproduce really quickly a site structure we will be moving from another CMS and create a matching item hierarchy in my Sitecore instance… I could face an hour or so of boring clicking and copying and pasting and hoping I’ve not missed anything or… I could write a short PowerShell script to do the work for me… Guess which path I chose?
Before you use the script you should customize the script parameters:
Kieranties must be the biggest PowerShell nerd (together with yours truly) I’ve had a privilege to chat with (I guess this implies I talk to myself?). So it shouldn’t be a surprise when the two started talking PowerShell/Sitecore pixie dust started sparkling.
This time – events integration.
This is a fairly easy task that Sitecore pretty thoroughly describes in the ?Using Events? SDN article. So there is little point for me to reiterate it here.
One thing I always wanted to add to the Cognifide PowerShell Console for Sitecore but never had the chance to investigate properly, was GUI and user interaction. For example in a regular PowerShell console when an irreversible action needs to be taken or one that user needs to be notified about – a question is asked:
Unfortunately due to the stateless and non-persistent nature of HTTP connections this is not easily achievable in Sitecore Sheer environment especially since in our case a PowerShell session usually lives in a separate thread within a Sitecore Job.
There are 2 more ways I’ve managed to find and implement that you can control data sources with PowerShell:
The motivation would be similar to what I’ve described in the ?Part 1? blog post. So without further ado let’s cut to the meat?
You might want your roots to be dynamic and you can deliver those using a PowerShell script!
So I’ve finally found a moment (well a few days actually) to follow up on the previous article, and just about time as there are quite a few more tricks that PowerShell can help you with when assessing the quality of your Sitecore solution. One thing that you need to keep in mind when reading the recommendations is that they are exactly that – recommendations. While Sitecore strongly encourages you that you follow them – I can see how most of those are perfectly fine to be ditched in some situations, you just need to be careful about picking those situations. By the general rule of thumb though, following vendor recommendations is a good thing and they are usually a good metrics of a well put together solution. Most of statistics provided in this post are hard to gather without a scripting solution like Sitecore PowerShell Console or Revolver.
Recently I’ve been asked to audit a site for one of our clients. Overall for a fairly seasoned Sitecore developer it’s rather obvious what to look for in a site and get a feel for whether an a solution is thoroughly thought through or just put together using brute-force development. You can usually tell if the implementation is sloppy or excellent, but how do you quantify that feeling to give the objective view to the person reading your report? Looking at the Sitecore Developer Network I’ve found the following set of recommendations. This is a great help with codifying how a proper Sitecore implementation should look like, what should we pay attention to and most importantly it’s a great reference when you’re trying to prove that your feeling is something more than just nitpicking but rather an industry standard that the developers should adhere to. I recommend strongly that you look at it and think how closely your practices match those that Sitecore recommends.
I’m realizing time and time again that the learning curve for PowerShell can be steep without a proper guidance. While most people I talk to are very excited about the concept they become discouraged after a having some tries and not realizing its full potential. Therefore I decided it’s worth spending some time introducing some basic principles to help scripting alleviate some of the initial pains.
I have gathered some literature available for free about the topic of PowerShell in general you might want to read, but I also think that a distillation of the basic concepts is really important so you can have some quick wins while you begin your PowerShell journey.
A few days back a budy from our Sitecore team has alerted me to this interesting question on StackOverflow which asks for automation of content promotion from one Sitecore instance to another. He suggested - and rightly so – that the PowerShell Console could be used in that scenario. While this was always possible by simply writing it as a PowerShell code the latest version of the console added a few commandlets making building packages much easier.
So now that you can easily create the menus and ribbons executing PowerShell scripts, it might be a good time to do some more administrative tasks? let’s start with scheduled tasks. I’m not going to go deep into the task scheduling, you can find an excellent post by John West on his blog regarding task scheduling. Currently the PowerShell module supports one of the ways described in the post – the section describing how to configure them is called ?Scheduled Tasks? in the blog.
Sitecore is built from the grounds up with extendibility in mind. Be that plugging into any place in its internal pipelines or any aspect of its User eXperience, therefore when I’ve managed to extend it’s context menu, I expected to have no problems whatsoever doing the same to its ribbon. Mind you I was right?
Using the PowerShell Console Module it took me less than 10 minutes total to add a nice piece of functionality that I thought was missing – Publish items I have modified.
In the he latest update of PowerShell Console for Sitecore, I’ve started experimenting with further integration – context scripts. What is that and what can it do for you?
You can safely assume PowerShell is not something your regular users will aspire to learn, but it does not mean they cannot harness its power if you enable them to.
If you look closely at the latest Microsoft solutions you may notice that a lot of what GUI does is running some scripting behind the scenes. This is true for a long time with the SQL Server Management studio where pretty much for any action you can generate a script that will let you automate a common task.
List your available site providers. You will use the name provided in the “Name” column in place of where I use “cms” in the later samples.
1get-psdrive `
2 | where-object { $_.Provider.ToString() -eq "CmsItemProvider"} `
3 | format-table Name, Root
For the same of brevity I’m assuming your location is already somewhere within a Sitecore tree (e.g. you did something akin to cd master:\content prior to executing the following scripts.
Should you put your Sitecore site behind a load balancing proxy you will run into a bit of a problem with analytics where all the Engagement Analytics app would ever report would be your own load balancing proxy’s IP address. Needless to say that is fairly big loss as you are unable to reap a host of benefits of the Sitecore CEP like page personalization, automation and reporting. While our website was running on Sitecore 6.4 this problem was already solved and we have implemented something akin to the solution from Jeroen’s blog. Meanwhile Sitecore has reimplemented its analytics engine from the grounds up in version 6.5, and I should say they did a great job on that. However in the process the API for the analytics has changed to a degree that made our current solution obsolete, basically what we got logged looked as follows:
We had a situation in the company this week which required us to deliver the whole EPiServer virtual path provider file structure to the client – zipped. Easy enough? go to the EpiServer VPP directory and? well? ok? hmm? so the path provider is versioning and as a consequence the physical organization of files on the disk does not make any sense for a human trying to browse it. Fine! So let’s create a native provider and do a copy and paste within the file manager?. hmm an exception complaining about the provider incompatibility? Naturally, my knee-jerk reaction is – let’s do it with the PowerShell? which I recall was doing something like this in it’s previous version? The example I’ve tested and placed in the ?Samples? tab was:
Most of this post is also based on the Microsoft’s Windows PowerShell Quick Reference however despite the sharing scripting runtimes the nature of the both shells differ considerably as described in the previous post: PowerShell for EPiServer - cheat sheet - Part 1. In all cases where it made sense I’ve converted the samples to establish them in EPiServer scenarios.
To write an If statement use code similar to this:
The PowerShell plugin gets an update once again to support Admin mode script collections in addition to the context scripts.
1<ContextScriptCollection>
2 <Title>Statistics Scripts</Title>
3 <Description>This script collection ... </Description>
4 <Area>Administration</Area>
5 <Scripts>
6 <ContextScript>
7 <Title>Restart Application</Title>
8 <Description>The script restarts this instance of EPiServer...</Warning>
9 <Script>Restart-Application</Script>
10 <Icon>/App_Themes/Default/Images/Tools/Refresh.gif</Icon>
11 <Groups>
12 </Groups>
13 </ContextScript>
14 </Scripts>
15</ContextScriptCollection>
Ok, so I’ve got my shot of endorphins writing about PowerShell last week (damn, it’s nice to be able to code again!), and I got pretty determined on making it usable and achieving all the goals I’ve initially envisioned. and in the process build a usable tool and a library of scripts that people can use either directly or to modify to meet their needs.
The goal for this week: Context Scripts
This one definitely took more time than I initially expected, and before I devote even more to it I would very much like to hear your opinion. Do you find it useful? Which way should the development be going? But first things first?
Have you ever found yourself:
If the answer to any of those (and more) is a ?yes!?, I believe you might find my little plugin useful.
One of the most frequently and eagerly used programming constructs of the Microsoft.Net Framework is Enum. There are several interesting features that make it very compelling to use to for all kinds of dropdowns and checklists:
Surprisingly enough EPiServer as it stands right now does not have an easy facility to turn Enums into properties. To give credit where credit is due, the EPiServer framework provides a nice surrogate that mimic that behaviour to a degree. The relevant property types are:
Aparently I have written something on that note before for CMS 4 and it looks like someone still needs it as I got a request for an updated version for it a couple of days ago. So here we go:
for the most part the syntax for the call is equivalent to what is was before so go to my previous article regarding that (check out the old article for details). What I’ve added this time around is:
Have you ever (or have your customers) created and edited a page in one language only to realize that their selected locale was wrong? Have you ever wished you could delete a master language branch of a page after creating its localized counterpart but you could only delete the newly created slave language instead? Have a customer ever requested that they could copy a whole branch and you convert it to another language so that they could then translate in-place?
Immediately after you implement the VirtualPathProvider proxy from my previous post you will notice a one fairly serious lack in it. Namely all the files within that provider will be hiding behind the registration form. That is not cool for a couple of reasons?
So how do you discriminate the files that you want locked from those that you want to be publically available, and potentially from those that you want only the logged in users to be able to get?
Just a daily time saver, for reuse at another time. Any old time windows developer, will remember the fun of using the ini files with GetPrivateProfileString. As much as ini files sucked there is one nice aspect of that call - you can setup a default value it is to return in case a value is not specified in the file. Similarly in a daily episerver programming you usually want to read a value but if one is not epcified you will usually want to use another value and just move along with the progress, and not really care to have an if there to do the filling in. Not to limit the property to any specific type - the task can be nicely solved with generics to handle pretty much any type of property.
I’ve recently been asked by one of our new dotNet developers whether it’s possible to cast your regular everyday .Net 1.x System.Collections.ArrayList or the like onto a generic System.Collections.Generic.List
1 PerformanceCounter pc = new PerformanceCounter("System", "System Up Time");
2
3 //Normally starts with zero. do Next Value always.
4 pc.NextValue();
5
6 TimeSpan ts = TimeSpan.FromSeconds(pc.NextValue());
7
8 MessageBox.Show(Environment.MachineName +
9 " has been up for \n\n" +
10 (ts.Days < 1 ? "" : ts.Days + " days, ") +
11 (ts.Hours < 1 ? "" : ts.Hours + " hours, ") +
12 (ts.Minutes < 1 ? "" : ts.Minutes + " minutes ") +
13 " and " + ts.Seconds + " seconds.");
Nice, neat and simple. Get a compiled executable here
[Edit: I’ve posted it on CodeProject and there are some greatl people commenting on it that did the investigation on ho to wrap it in a STA Thread and make it a part of your ASP.Net solution - really cool stuff!] An interesting use case. Darek (our beloved sys admin - we all bow to him and worship his skills) has recently asked if it’s possible to write a .net application to make a thumbnail of a website. Which is pretty trivial with Windows forms actually. All you really need to do is drop a WebBrowser on your form and once it’s loaded the page call:
