$root = Get-ChildItem -Path "master:/sitecore/content/site/root"
New-Item -Path $item.ItemPath -Name "components" -ItemType "/sitecore/templates/Common/Folder"
This script was created by my colleague Adam Honore, when I realized that I had forgot to include a “components” folder in my Sitecore master – after I had created my 100+ items. Thanks to Adam for the help.
The blob storage container name. This is the name in the list of “Blobs”.
I have previously stated my enthusiasm for the Sitecore Pipeline concept. This article describes how to create your own, how to add parameters, and which properties to use.
WHAT IS A SITECORE PIPELINE?
It is best described as a simple form of dependency injection pattern, or maybe more of a config-file-configurable method chaining pattern. The idea is, that if you have a task to perform, and this task requires several independent sub-tasks to run in sequence, you can split these sub-tasks into separate methods (called processors), and then run them in sequence using the same parameters for each method.
WHY NOT JUST MAKE ONE BIG METHOD? OR ONE CLASS THAT USES DEPENDENCY INJECTION?
Extensibility: You can easily add another processor to any pipeline, thus adding to the functionality of that task.
Replaceability: You can easily replace any processor with one of your own, replacing the way Sitecore works.
Testability: Pipelines allow you to break your code into very small processors. Any change of one processor does not interfere with any of the other processors, making testing easier.
It’s easy: It’s really easy to work with. It’s standard .NET code.
A pipeline consists of a class or Arguments, inheriting from Sitecore.Pipelines.PipelineArgs, and a configuration section that describes which tasks (processors) to execute in which sequence.
HOW DOES THE PROCESSOR LOOK LIKE?
// value of MyParameter is "value"
In fact the same advanced configuration rules apply to pipelines as all other Sitecore items.
runIfAborted: Processors with this attribute set to true will run even if the pipeline is aborted. This is useful as a cleanup property if something went wrong.
resolve: Set this property to true to allow the Sitecore Dependency Injection engine to resolve the type name to run.
reusable: This property allows your processor to be run in a transient scope.
If you throw an exception in any processor, the pipeline will stop its execution, and the CorePipeline.Run() also throws an exception. This means that your “runIfAborted=true” processor will not run. You should therefore catch any exception in the processor, and use the args.AbortPipeline() method to control execution flow.
Make your processors as atomic as possible. Some of my best processors consists of one line of code. Your processor should do one task and one task only.
You can debug the performance of your processors, but this slows down the performance of all pipelines, so use this with caution.
Processors are only created once and kept alive for the entire application lifetime. Any constructors are only called once and local variables are not reset, so treat your processors as a stateless piece of code.
This is true unless you use the reusable=”false” property, but beware that object construction takes time and this feature will slow down your pipeline.
Any configuration error will result in an exception when CorePipeline.Run() is called. If the method or class is not found for one processor, the whole pipeline is not executed.
Every time an Internet user visits a specific Web site, a new session ID is assigned. Closing a browser and then reopening and visiting the site again generates a new session ID. However, the same session ID is sometimes maintained as long as the browser is open, even if the user leaves the site in question and returns. In some cases, Web servers terminate a session and assign a new session ID after a few minutes of inactivity.
… the browser will remember the session ID forever, even when a new session is started.
I have enabled the “Continue where you left off” feature in my Google Chrome.
This is my current session ID.
ASP.Net will fire the Global.asax Session_Start() event as expected, since a new session have been created.
This behavior means that you cannot use the session ID to identify one user session. Any data collection cannot rely on the session ID as the unique identifier. Collecting anonymous user statistics based on session ID will become skewed because you will have multiple session_start events for one session ID.
As an edge case, we risk that the session ID will no longer be considered as anonymous. The GDPR rules clearly states that any user-identifiable data cannot be collected without the consent of the user. When the session ID does not change, one could argue that the session ID is user identifiable just as the IP address or the user name, because it will live on the user machine forever.
It is possible to generate a new session ID, but it requires to do some postbacks, so this solution is only feasible as a method to generate a new session ID when you log in, or when a user have finished a shopping transaction.
This StackOverflow thread discusses the possibilities of creating a new session ID.
From Sitecore 9, Sitecore changed the default behavior when creating items in the content editor. As per default, any item is locked when created, and will only be unlocked if the user unlocks it, or the user saves the item, and the AutomaticUnlockOnSaved config property is true.
Unfortunately, Sitecore forgot to include a DoNotLockOnCreate property, so it is impossible to get rid of this feature – unless we do some coding.
This piece of code is a collaboration between Sitecore Support and myself, and will work ONLY WHEN CREATING ITEMS FROM TEMPLATES. Items created based on a branch will stay locked.
The addFromTemplate pipeline runs every time an item is created. We add a new processor that will create the new item, and then call the item:checkin command to unlock the item.
The code will now run every time you create a new item, unlocking the item immediately after. As stated before, this hack will only work when creating new items based on templates. Items created from a branch will keep a lock on the top branch item.
Are your Sitecore editors version-trigger-happy? Is your master database items drowning in old versions that will never be used – or is just exact replicas of the previous version?
Fear not, you can in fact – with a little bit of code of course – recycle versions of items.
Serilog is more or less the default file logger when developing .NET Core applications. The simple logger can easily be modified to – for example – add the thread ID.
11:22:48.232 (0001) An error happened.
11:22:49.236 (0002) Another error happened.