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
The post is related to the image resize vulnerability fix introduced in Sitecore 7.5. To read more about the Sitecore fix go to theRelease notes pageand search for ?Media request protection?. While I was holding off for a number of months on the publication of the post as it puts the attack vector in plainer sight that I would like it to be (while the community figured out how to work with Media Resizing in a neat way) - but recently I’ve seen voices raised considering turning the Media Request protection off which I hope you will not be doing after reading this post. The post will also tell you how to enable such security on your older versions of Sitecore.
So here’s the story…. At some point in Cognifide we have performed a research around Sitecore security and one of my colleagues (Marek) found out that you could easily kill any Sitecore instance by performing an image resize attack on it. While the CMS did some rudimentary checks and limited the values of height and width you could still perform an attack by harvesting the images from the site and perform multiple parallel & iterative size increase or just plain use the scale parameter to achieve any image size. A result of such attack would be a a denial of service due to 100% CPU & memory usage and would potentially allow for filling the server drive by creating the endless number of scaling calls.
Marek was even kind enough to provide a proof of concept code that confirmed the hypothesis by performing attack on a few of our internal servers. The program would load the home page; parse to find images linked from it and perform resizing of the images in a number threads.
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.
This post describes how you can deliver JSON/XML/HTML APIs quickly with Sitecore PowerShell Extensions.
Technically this was also available earlier but the API was not refined to the state it is now.
As Sitecore is constantly progressing from predominantly serving as a CMS towards becoming a mobile and web application delivery platform (which is very apparent by the recent increase of SPEAK popularity, the introduction of Item Web API and the app centric nature of the new Sitecore 8 interface there is an increased need to rapidly deliver APIs for those those front end applications to work seamlessly with the CMS back-end.
PowerShell Extensions can help you with that move by enabling rapid prototyping of APIs that are either JSON or XML in nature.
This is just a short post to supplement the “Working with Sitecore items in PowerShell Extensions” as we now have a new cmdlet of retrieving items in SPE 3.0.
Find-Item cmdlet allows you to leverage the glorious new search API Sitecore introduced in the 7.0 version of its CMS to retrieve items using the Sitecore Content Search indexes.
You will find the available parameters on it as follows:
Recently the Sitecore PowerShell Team has been reflecting on the progress of the Sitecore PowerShell Extensions (SPE) module. We appreciate all the feedback and contributions from the community. Without the many great people in the community, the module just wouldn’t be where it is today. The team is proud of the accomplishments for a module developed purely by the community with no formal Sitecore support.
The new year has revealed some exciting news out on the Marketplace for SPE.
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*
I’m really excited to see the 3.0 version of Sitecore PowerShell Extensions released. There have been more effort, love and sweat poured into this version by the whole team than I would ever expect. This blog has been written to assert the smoothest upgrade experience possible. While we’re always striving for the smoothest upgrade possible - this version introduces some changes that require you to perform a manual step or two. While those could be automated to a degree, making those manual was a conscious choice as I didn’t want to break e.g. your Insite instance that stores some of its files in the “Console” sub-folder of the Website folder.
Before upgrading your instance from Sitecore PowerShell Extensions 2.x to 3.0 please make sure you have your scripts backed up as the upgrade process might cause some of your scripts to be removed. This is especially true if you used the integration script libraries and you are upgrading from SPE 2.7 or earlier. If you’re upgrading from version 2.8 and your script live in your own modules You should be safe although it’s always smart to back up.
The steps you need to take prior or after installing the new version of the PowerShell Extensions:
This has been on my plate for a while and to be honest I’m not sure what took me so long as it literally took around 4 hours from start to completion which I consider a testament to how easy it is to create additional integrations with PowerShell akin to the Gutter integration or the login/logout integration Michael West has recently introduced in the platform.
What this integration allows you to do is to eliminate the need for code deployment when you’re in need for a quick action here and there for when a user executes a workflow command.
You might find this article helpful by a Cognifide colleague of mine. I especially like this image which illustrates nicely where actions fit in a Sitecore workflow.
A large problem with Sitecore PowerShell Extensions up to version 3.0 was the lack of proper separation of solutions provided on top of it from the core of the module. The problem is that all integrations look for scripts in the main Script Library but they look for them solely in their single libraries. The specification outlined in this blog aims at solving this issue.
The current structure of the tree looks somewhat as follows:
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 blogsfrom 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.
How do I retrieve my Sitecore items the PowerShell way?
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 been meaning to write this article for quite a while since the functionality to remote into the Sitecore environment exists in the module at least for at least a couple of versions now and the recent email from one of the Sitecore PowerShell Extensions users convinced me this cannot wait any longer.
When would I remote into my Sitecore instance?
You would probably need this as part of your Continuous Integration or installation scripts. If you need to manipulate Sitecore data from your deployment script remoting is the right solution for you.
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:
There was a breaking change in the Console 2.1, if you’re using version 2.1 or newer use Download-File commandlet instad of the “Get-File” as shown in the code below.
You might have have found yourself hunting around in the Sitecore interface for something that would allow you to download all the the log files in a fast and convenient way once time or another. Have you found one? Me neither? but luckily I had the PowerShell console installed on my server so I started looking for a script to zip all files in a folder and luckily because we have a full PowerShell power in the box I could stand on the shoulders of giants and get the zipping part from Stack Overflow – again (which is the majority of my script. The rest was super easy – just call the function and download the file?
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.
What does it take to integrate PowerShell with Sitecore events?
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.
Reading some time ago the Item Buckets documentation I discovered something really cool called code data sources. We delivered something similar in our internal libraries and it proved super useful ever since. I’ve also recently read a nice article by Ronald Nieuwenhuis on NewGuid about their approach to the subject.
So what a PowerShell and Sitecore nut does when he sees stuff like that? Obviously delivers a scripted data source!
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.
A while ago Jakob suggested that putting the Sitecore PowerShell Console in Visual Studio might not be a bad idea. He even provided me with the boilerplate code that served as a stub for the module (Thanks a million Jakob!).
So after some struggling on my part the new module is now on the Sitecore Marketplace. There is really not much to write about. If you like PowerShell and Sitecore Rocks you will find it pretty neat. Otherwise I’m afraid those are not the droids you are looking for
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.
All of the PowerShell blog posts so far were about using the console. Being the developer however, you probably think – well that’s good for admins, but what’s in it for me? How can I benefit from it in my code? Well you can. With the latest update you can run the PowerShell environment in your application and take advantage of its scripting power, by getting the results out of it and pulling them into your app.
There is a lot of new stuff in the imminent 2.0 release of the PowerShell Console for Sitecore. Some of it is fairly obvious like the improved console window, some of it not so much. The aim of the console has always be to enable Sitecore developers to extend the CMS in new exciting ways. For this to happen it had to become a mini-platform on its own. So far you could use it to add scripts to ribbons and menus, write scripted tasks and execute scripts just by launching them from a URL call.
That’s extending Sitecore with PowerShell but what about PowerShell itself?
One of the coolest features introduced in 2.0 is the ability to write your own commandlets. Sure you could always use PowerShell to do it and write commandlets in script. But then the caveat was that you had to attach such commandlets to your own scripts (or put them in the initial script that would have to execute prior to the console). Now I’m talking about writing the real commandlets, just like those that come with the PowerShell console itself. Starting from 2.0 the console does not default to only attach commandlets that come with it, but can also scan other assemblies to attach your commandlets. To add your own all you have to do is well.. write them but then? all you have to do is to use the standard Sitecore include mechanism to enable the console to find them.
While I’m updating it on a separate page I thought for the purpose of having a record and further tracking - it would be interesting to capture the state of the PowerShell knowledge in the Sitecore community here as well.
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: Sitecore PowerShell Console cheat sheet – Part 1. In all cases where it made sense I’ve converted the samples to establish them in Sitecore scenarios.
How to Write Conditional Statements
To write an If statement use code similar to this:
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.
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.
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.
The aim of the PowerShell console for Sitecore is to create a command line interface to your data so you can automate and aggregate mundane tasks as well as create statistics and a discoverability layer on top of your content.
Have you ever found yourself:
having to make a mundane change to a large number of pages?
in need of getting statistics field or template usages?
being curious of e.g. what’s the oldest page on your site?
in need to find out how many authors really create your content and how active they are?
having to copy or move a large number of files from one folder to another?
renaming or deleting files in your file store en-masse?
publish pages that match some specific feature rather than a whole branch?
If the answer to any of those (and more) is something akin to “yes I did!”, I believe you might find my little plugin useful.
The idea is to create a scripting environment to work within Sitecore process, being able to make native calls to Sitecore API and modify content on a per-property level. The goal was to make it familiar to your IT and developers so they can reuse their skillset with it or if they rather learn it here, this knowledge will benefit them in the long run as clearly PowerShell is becoming an industry standard. The plugin’s aim is to manipulate not just sites, but files and pages on a large scale or perform statistical analysis of your content using a familiar and well documented query language. The console allows you to execute and test scripts interactively, but also gives the admin means of exposing scripts to end users within context menus and in the ribbon. I’m sure in the long run I’ll come up with more applications. Scripted pipeline processors? Scripted renderings? Scripting campaigns statistics and engagement workflow steps? You name it…
Now there is Rocks interface that performs similar task which I think is brilliant, however slightly - yet significantly different. Rocks integrates with your Windows PowerShell console and allows you to work on your remote website as if it was a file system on your machine. Rocks also features a number of commandlets that help you with some common tasks. The definite bonus of this approach is that you can simply use it in your deployment script and integrate some common content modifications, or clear caches/recycle bins on your server in a timely manner from your monitoring environment. I think the solution is a really needed addition to your Sitecore toolbox, but… it’s somewhat limited. Namely whatever new idea you want to employ in your script, is either supported by the commandlets provided – or impossible. You have access to all the goodies of rocks, but any extension must first be imagined and implemented in Rocks (both server and client side).
The Sitecore Console however works within the process of your Sitecore site and therefore can instantiate and execute any API Sitecore features. The only limit is that of the imagination. this comes at a price too though. The most important thing is security. The PowerShell plugin by itself does not run with elevated privileges, nor does it circumvent the rights, but since you can use any Sitecore API a malicious person could potentially do it themselves – therefore you need to be careful whom do you grant access to the PowerShell Console.
The console comes with some sample scripts when you install it – review the script and press Ctrl+Enter to execute and see some of the interesting use cases for it.
By default the console creates a “drive” for each of your databases so you will definitely have a “core” and “master” drives, and you will most probably have a “web” drive.
Since this is only an introductory post I’ll let you discover the full list of commands by yourself, just use the following script within the console:
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:
