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 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😦
This wasn’t supposed to be a blog post series, and my original reason for this code was to just offload the hosting of large files. But whilst writing the first draft of the blog post I started to investigate various areas since the potential for this module became greater. It was supposed to stop at part two, but I supposed I suffer from the same thing as most of you: programmers OCD. And so a series is born and expect another post or two to follow until a final solution is attained.
In my previous code I noted that the code did not work with the attach/detach handlers in the Media Library:
During another recent conversation on Sitecore Slack chat we discussing solutions with a large number of projects, and the fact that it is recommended to set
CopyLocal=false for references (see here and here) since it optimizes Visual Studio builds and can reduce build times. The problem however is that setting this value causes you to lose Intellisense from your Razor Views/Webform controls, although everything should continue to build and work as expected though.
That’s a fairly big price to pay! Another advantage of setting
CopyLocal=false is that those DLLs are not included in the output directory of your build. More than likely you have a process to deploy a vanilla instance of Sitecore to the server or it is installed on the server, so there is no need to re-deploy the basic DLLs like
Sitecore.Mvc.dll for example. More recently, we had an issue where the local version of our Coveo install was a slightly different version to the ones on the server, which meant that these assemblies should not be deployed either.
Just before the Christmas break I got into a conversation with Robbert Hock on Slackchat about Sitecore fields and specifying a queryable source for the Treelist field in Sitecore 8.1. As you may be aware, several of the Sitecore fields support specifying an XPath query in the field source and others support an enhanced syntax using parameters.
From Sitecore 7.2 Update-2 the Treelist and TreelistEx fields also started to support specifying a query in the Source field.
Released Sitecore CMS and DMS 7.2 rev. 140526 (7.2 Update-2)
The Treelist and TreelistEx classes now support Sitecore query in the source for these field types. (319249)
The WordPress.com stats helper monkeys prepared a 2015 annual report for this blog.
Here’s an excerpt:
The concert hall at the Sydney Opera House holds 2,700 people. This blog was viewed about 17,000 times in 2015. If it were a concert at Sydney Opera House, it would take about 6 sold-out performances for that many people to see it.
Click here to see the complete report.