4 Steps to Package Management with Sitecore Powershell Extensions

Did you know there is a feature in SPE (Sitecore Powershell Extensions) where you can create your own Sitecore packages from the content item without leaving the Content Editor? What is even better is you can choose to get related items to that content item that you are packaging up for another environment. What is even better BETTER than that is that you need only simple Content Editor permissions to do this not the all encompassing Admin access we all know and love. Hence, Developers with limited access can create these packages not having Admin access in upper level environments as needed for your development team!

In this example we are going to create a package based on the About Us item and it’s related data templates that support it with the media also that it needs for an upper environment. For instance, we want to create this package from Local / DEV to install on QA or simply send to another developer to see what you are working on.

Step 1: Start New Package

Run the Start New Package Script

Run the Start New Package Script on About Us

Step 2: Add Tree to Package

Add Tree to Package

Choose Add Tree to Package for your Content item

Step 3: Choose Options via Installations Options Dialog Box

Now for the great part that Sitecore SXA developers will love! You don’t have to remember where all the data is living in Sitecore any longer with SXA packaging. You just need to choose the correct options in this dialog box and SXA will pick it up for you and place in the package! Use this dialog box to manipulate your package as needed. Below are the options:

Installations Options Dialog Box

Installations Options Dialog Box

Items to Include in Package Options

Items to Include in Package Options

For this example, I choose “Roots and descendants” to gather up all my data sources that are local that Content item as seen above.

Installation Options Drop-Down

Installation Options Drop-Down

For this example, I choose Overwrite so I can overwrite the legacy items as seen above. This can be modified depending on the situation and environment so use it accordingly.

Lastly, I know that my Templates, Workflows, and Layouts are in source control and synced via Unicorn, so I only need to choose the “Include Media” option.

Final Installations Options

Final Installations Options

Step 4: Download Package

Here is the interesting part, when you click on “OK”, the script will run but you will not get any feedback as to what you just did. Let me help you, just click on the same item, in this case “About Us” and when you navigate the fly-outs to the same place where you started a new package you will now have some other options as seen below where you can now “Download Package”:

Download the Current Package

Download the Current Package

Once this package is in place for that item you can modify at will as well using the many options. Sitecore developers rejoice as the world of development gets a little easier and more streamlined every day with SPE your friendly Sitecore Powershell Extensions module!

Install Multiple Instances of SOLR for Sitecore Development

Did you know that you can run multiple instances of SOLR on a machine for local development as a Sitecore developer?

Since we have moved on from Lucene to SOLR in our development efforts starting with 9 it makes sense to move to SOLR starting in version 8 as the move will be inevitable. With Lucene as our old index provider this didn’t used to be a problem having several instances of Sitecore on our local machines, but when you start using SOLR you need to be cognizant of a few things so you can set up your development environments quickly.

I read a great blog post earlier that gave me what I needed to get 2 SOLR instances setup on my local machine. This can easily be increased as Sitecore projects come into play in your Sitecore travels. Below is the blog post I mentioned, which was a great starting point:

Install Multiple Instances of SOLR for Sitecore on a single server

What you need to know when setting up many instances is that there needs to be a common JRE that will work for ALL SOLR instances on your local machine!

I am currently using SOLR 6.6.2 for SItecore 9, and SOLR 5.5.2 for Sitecore 8.2. When I tried to start my SOLR 5.5.2 instance I got an error that I needed “Java 1.7 or higher” even though I had JRE 9.0.1. Makes no sense right? Bottom line is that SOLR 5.5.2 doesn’t play well with the later versions of Java.

Again, I needed to have a common JRE that worked with both instances of SOLR (5.5.2 & 6.6.2) and that was Java 8 (8u162). Once I uninstalled 9.0.1, installed Java 8 (8u162), and then modified my JAVA_HOME environment variables to point to the freshly installed Java 8 (8u162) instance, I was able to start both SOLR instances as Windows services with NSSM on port 8985 (5.5.2) and port 8986 (6.6.2) respectively.

Once you make these changes you will then need to set your Sitecore instances to point to the correct SOLR instance accordingly using a patch config in the following config file “App_Config\Sitecore.ContentSearch.Solr.DefaultIndexConfiguration.config” in the “ContentSearch.Solr.ServiceBaseAddress” setting below:

Base url of the Solr server. (minus any cores and minus a trailing slash)
<setting name="ContentSearch.Solr.ServiceBaseAddress" value="http://localhost:8985/solr" />

Once you have that in place per Sitecore instance you are all set. Happy coding!

Item:Saved Event Error Message Installing Sitecore 9 Forms

Over the course of the past 6 months I have been working a lot with Sitecore 9 forms and have gained a lot of knowledge. Here is one error you may run into when installing Sitecore 9 forms from one instance to another that may stump you. The error comes when you are installing a package of forms and forget to include the dependencies needed for the forms. Here are what I refer to as the typical dependencies:

Data Sources Used in Dynamic List Items

Let’s say you have a Checkbox List used in your form and are pointed to a fictitious list similar to this as your data source below:

Example Data Source

Example Data Source

If you package up the Forms folder, and forget to include the data source items that your lists are pointed to in your forms you will get the infamous Item:Saved event error. Make sure to include them along with your forms package and/or make sure they are installed on the destination Sitecore instance BEFORE installing your forms package.

Custom Form Functionality Items

Below is a list of the most common places in Sitecore that you will be creating custom form items to achieve the desired custom functionality from Sitecore 9 forms:

Custom Form Fields:
  • /sitecore/templates/System/Forms/Fields
  • /sitecore/system/Settings/Forms/Field Types/Basic
  • /sitecore/system/Settings/Forms/Field Types/Lists
  • /sitecore/client/Applications/FormsBuilder/Components/Layouts/PropertyGridForm/PageSettings/Settings
Custom Form Validations:
  • /sitecore/system/Settings/Forms/Validations
Custom Submit Actions:
  • /sitecore/client/Applications/FormsBuilder/Components/Layouts/Actions
  • /sitecore/system/Settings/Forms/Submit Actions

If you created custom form fields, validations, or submit actions, and these items are not already installed on your destination instance, then you will receive this error. Again, make sure to include them along with your forms package and/or make sure they are installed on the destination Sitecore instance BEFORE installing your forms package.

To summarize, Sitecore 9 forms has dependencies you must be aware of when your team starts building out the forms. Make sure that these are included in your source control and deploy with confidence. Happy coding!

No Forms To Display

“There are no forms to display” in Sitecore 9 Forms designer

In working with Sitecore 9 forms, you might occasionally get the “There are no forms to display” when you go to the Forms designer area as seen below:

No Forms To Display

No Forms To Display

This is pretty typical actually as the Forms are indexed in the “sitecore_master_index”, and I have seen this happen after doing custom form fields, validations, and submit actions. But  simply re-index and voila, you will see your forms. Our fellow MVP brethren, Jason Wilkerson, put up a post about this, which you can read in much more detail regarding re-indexing:

Sitecore 9 Forms: form doesn’t show up after creation

Now, with that being said, I have found that this is NOT the only time this can occur. At some point, my forms disappeared from the Form Designer completely, and no matter how many times I re-indexed they never came back to existence.

If re-indexing doesn’t work try renaming the form to something else, then save the form, and go back into the Forms Designer. You should see the form now there. Now, rename the form back to it’s original name, and you are good to go. I have seen this odd behavior in Sitecore 9.0 (Update 1). If this doesn’t work then continue on with this blog post.

After a couple weeks of not seeing my forms it was a MUST that I had to have the Forms Designer back not only me and my local development, but for the client as well. This bug had propagated it’s way from LOCAL to DEV & QA at this point. Before we are to go-live it MUST be fixed. So I really started getting after finding a solution!

My first stop was the always trusted and solid Sitecore community. I went to the Sitecore Stack Exchange at https://sitecore.stackexchange.com for help. I posted up this question and the community had nothing for me, but I quickly learned that I was NOT alone with this bug:

No forms are displaying in Sitecore 9 Forms area

Being that Sitecore 9 Forms are a tad bit new to the community we are all still learning these forms one day at a time so there wasn’t much to go off of for any of us in this situation, and most were busy, and didn’t have time to look into. So my next stop was Sitecore Support. I put in a ticket with Sitecore Support. About 24 hours later they came back asking me for my .configs and me to run a test through Fiddler to see what was going on. Once I got them what they needed, they got me what I needed, which was the answer. The Sitecore Support team saw from Fiddler that the requests for available forms returned an error, which is below:

4268 07:53:01 ERROR [Item Web API] Value cannot be null.
Parameter name: item
Exception: System.ArgumentNullException
Message: Value cannot be null.
Parameter name: item
Source: Sitecore.Kernel
   at Sitecore.Diagnostics.Assert.ArgumentNotNull(Object argument, String argumentName)
   at Sitecore.ContentSearch.SitecoreIndexableItem..ctor(Item item)
   at Sitecore.ItemWebApi.Pipelines.Request.Search.RunSearchPipeline(RequestArgs args, String searchText, String languageName, Boolean showHiddenItems)
   at Sitecore.ItemWebApi.Pipelines.Request.Search.Process(RequestArgs args)
   at (Object , Object[] )
   at Sitecore.Pipelines.CorePipeline.Run(PipelineArgs args)
   at Sitecore.Pipelines.DefaultCorePipelineManager.Run(String pipelineName, PipelineArgs args, String pipelineDomain)
   at Sitecore.ItemWebApi.Pipelines.HttpRequest.LaunchRequest.Process(HttpRequestArgs arguments)

They had me navigate to the {60F35FD9-88CB-4DF5-8E78-1E9BF5FE181C} item in the core database. That item is seen below:

Sitecore 9 Search Config Item

Sitecore 9 Search Config Item

As you can see from above the Root field is pointed at {B701850A-CB8A-4943-B2BC-DDDB1238C103}. When I put this ID in my search bar and searched the Master database content tree, there was NO results. I decided to get with one of my co-workers who had a working instance of Sitecore 9 Forms, and had them search for this item in the Master database content tree. BOOM! Once they ran the search, the Forms folder, which contains all the forms, came back as a result.

Wrong ID For Forms Folder

Wrong ID For Forms Folder

When I saw that I had the wrong Forms folder ID, I knew that somewhere along the check-in source control travels someone must have deleted the original Forms folder, and then created a new Forms folder with a different ID. Because of this one simple change by a developer the Forms Designer was now rendered useless and ineffective. This is something to be aware of!

The solution to this issue is this:

  1. Do NOT delete the Forms folder and create a new one if you don’t need to!
  2. If you do delete the Forms folder, get it from another instance of Sitecore 9.
  3. If for some reason you want to run with a Forms folder with a different ID then you must change to this ID for your new Forms folder in the Root field of these items below in the Core database:
    SearchConfig: {60F35FD9-88CB-4DF5-8E78-1E9BF5FE181C}
    AllFormsSearchConfig: {60F35FD9-88CB-4DF5-8E78-1E9BF5FE181C}

My recommendation is to NOT opt for #3 as this will get away from you, and your client down the road unless you document it, keep for future reference, and refer to for future upgrades. Ain’t nobody got time for that! Just opt to get on Slack and ask someone for the OOTB Forms folder item in a package, move all your forms into the correct OOTB Forms folder and you are all set. Happy coding!


Sitecore 9 Experience Editor

Glass.Mapper Experience Editor Issue with Sitecore 9

My team and I were doing some development over the past couple of weeks with Sitecore 9 and Ignition, which uses Glass.Mapper. We updated Ignition in the project to use Glass.Mapper Version All was working fine for rendering out the fields to the page, but when it came to rendering out the text fields to the Experience Editor and having them be Experience Editor friendly, “Houston, we had a problem”!

We were using the HTML helper below:

@Html.Glass().Editable(Model, x => x.Title)

When we got to the Experience Editor, the page looked liked this due to all the text fields we had using the HTML helper:

Experience Editor Issue

Experience Editor Issue

My assumption, was that Sitecore 9 was not playing well with the older Glass.Mapper versions, but I could not be for certain. Luckily, thanks to this awesome Sitecore community, I got on the “Glass” channel of Slack and asked what might be the issue, and Mike Edwards got back to me right away stating, that I should use the “ (Pre-Release Version)” as that is the first one to have all the changes for Sitecore 9. I was right on track to fix the issue, but after looking in NuGet I could not find it! Turns out I needed to check the “Include prerelease” checkbox pointed out below (image thanks to Mike Edwards). Good lookin’ out Mike!

NuGet Pre-Release Version

NuGet Pre-Release Version

Once I updated my solution to the (Pre-Release Version), the strings were then Editable in the Experience Editor making me, the development team, and the QA people happy campers now that they can test functionality of our components. Happy coding!

Sitecore Ignition Logo

Accelerating your Sitecore solutions with Helix and Sitecore Ignition Development Accelerator

Over the past month or so, I have had the opportunity to work with some fine talent here at Perficient who are showing me the ropes on the Sitecore Ignition Development Accelerator as well as how this framework adheres to the Helix patterns, principles, and conventions. Helix is a growing passion of mine, along with our development team, and the more I develop using these patterns, principles, and conventions along with the Sitecore Ignition development accelerator, I am quickly seeing the benefits of Helix & Sitecore Ignition as a great development practice.

Helix gives me the ability to maintain enterprise level Sitecore solutions a lot more easily with the Project, Feature, Foundation approach as well as SOLID patterns, principles, and conventions behind the reason why you should develop in this manner. If you have not started development with Helix, truly consider a shift toward this as it is now considered a best practice, and recommended by Sitecore at this point.

The Ignition framework allows me to hit the quick-start button when starting a new project for a new client, but in addition it allows me to work with Helix patterns, principles, and conventions to accelerate development time. There is more than meets the eyes with the Sitecore Ignition framework, and I felt it best to share my findings now that I have some hands-on experience in both areas.

I started out speaking with Jon Upchurch, major contributor to the Ignition team, who gave me a handful of links to “Ignite the Helix”, those of which are below:

GitHub repo for Ignition: https://github.com/sitecoreignition/SitecoreIgnition

Sitecore Ignition Documentation: http://sitecoreignition.readthedocs.io/en/latest/

Getting Started with Sitecore Ignition (Initial Items & Project Template for VS): https://github.com/sitecoreignition/Ignition.Foundation/wiki

Getting Started with Sitecore Ignition (10 Minute Video): http://blogs.perficient.com/microsoft/2016/06/sitecore-ignition-getting-started/

Getting Started with Sitecore Ignition 2.0 (50 Minute Video): https://www.youtube.com/watch?v=ZX4sAcQFqGM

Webinar on Sitecore Ignition:http://blogs.perficient.com/microsoft/2016/06/sitecore-ignition-a-webinar-overview/

Sitecore Ignition 101 Blog Post by George Chang: http://blogs.perficient.com/microsoft/2016/06/sitecore-ignition-101-overview/

Facebook Page: https://www.facebook.com/Sitecore-Ignition-1714108435506468/

Twitter Ignition Team: @ignition_sc

The links above will help you to learn more about the Sitecore Ignition accelerator as well as stay informed via your social media favorites Facebook & Twitter.

Initial setup of Sitecore Ignition is not very hard at all if you are following the directions in documentation and videos, and rather than go through the setup in this post, my focus is really on the benefits of why you should consider using the Sitecore Ignition development accelerator for your Helix based Sitecore projects. Below, are a few benefits in relation to Helix that will speed up your Helix initiatives:

  • Ease of setup to initially get started to add into your Helix based Sitecore solution
  • A Visual Studio Sitecore Ignition project template
    • When you add a new “Feature” project, which could be many, then this ability alone to have a template will speed things up dramatically in your daily development.
    • Sitecore Ignition project template comes pre-loaded with a Controllers, ViewModels, and Views folder for you to start creating your modules and get to work quickly.
    • Pre-configured Unicorn predicates for the project setup in the App_Config/Include folder.
    • When using symbolic links with Link Shell Extensions, then you won’t even have to set up the serialization folder for the project because Unicorn will place the serialized items in the right spots in your feature to be included for check-in to your repo. Brilliant!
  • Ignition.Foundation.Core includes SimpleInjector for IoC, and Glass.Mapper as the ORM. So when you create the new project, all you need to do is reference Sitecore.Kernel.dll & Sitecore.Mvc.dll from the official NuGet feed for Sitecore. This will make Glass.Mapper happy during Ignition.Foundation.Core package installation. Once the Sitecore Ignition.Foundation.Core NuGet package is installed, your project is ready to go!

Below are some benefits I have run into in a short period of time using the Sitecore Ignition framework:

  • No Global.asax or RouteConfig.cs you need to worry about in the solution. Which is just less files/folders you need to worry about and more clean in my opinion, which is always good. When doing AJAX work you simply need to setup on your JSON returning methods for them to use [PublicRoute] along with [HttpPost] and that’s it. The rest is done behind the scenes for routing. Pretty slick!
  • Experience Editor friendly just met developer friendly when the Sitecore Ignition team created a way for you to simply name a .cshtml file with a certain naming convention i.e. “_EE”, and now that view is automatically Experience Editor friendly. Big win for teams with juniors!
  • Dynamic placeholders are OOTB with this accelerator so there is no need to roll your own, download one off the Sitecore Marketplace, or pull one in from NuGet.

Overall, I am very excited about working with Helix patterns, principles, and conventions now in my every day Sitecore development role as well as the ability to accelerate that development with the use of Sitecore Ignition. Thanks for the hard work Sitecore Ignition team!

I have a good feeling that I will be working with the contribution team when I can to help make this accelerator even better than it already is for the Sitecore community. Looking forward to when that time  comes. Now go and “Ignite the Helix”!


Parameter Templates for Pointing to Content Items

Dynamic Parameter Templates for Pointing to Content Items

Have you ever been in a predicament, in code, where you need to point to an item in the Sitecore content tree?

For instance, you are building a Search Component, and when the user clicks search, you are going to send over the keyword/s in a query string to the Search Results Page for use in processing and displaying the results. In code, I will need that URL in my Search Component in order for me to send over the results. Let’s analyze what our options are on this scenario:

For sake of simplicity, I will leave the null checking and exception handling to you. These are simply options to get ultimately to my point:

Option 1 (Rookie Option):

var searchResultsPage = Sitecore.Context.Database.GetItem("/sitecore/content/Home/Search Results");
var searchPageUrl = LinkManager.GetItemUrl(searchResultsPage);

We can get the item using the path, then get the item URL at that point. However, we NEVER want to do this with content items! If that path changes then now you have a broken Search Component. Just because we can use paths to get items in Sitecore, doesn’t mean it’s a good practice. As a matter of fact, I would consider it bad practice all around, so steer clear of this method.

Option 2 (Better Option):

var searchResultsPage = Sitecore.Context.Database.GetItem(ID.Parse("F6778EA3-1B76-4BBF-AD21-63E9EA847FDE"));
var searchPageUrl = LinkManager.GetItemUrl(searchResultsPage);

A better method to pointing to items is with the ID using the item GUID. Why? Performance reasons. Sitecore will pick that item up faster using the ID. More importantly the ID is tied to that item ONLY and anywhere the Content Editor moves the item, Sitecore will still be able to fetch it, and nothing will break on the Search Component.

Option 3 (Even Better Option):

Typically, in most solutions that I have come across for Sitecore, there is Constants file that has ID’s in the Constants file something like this:

public class ItemIDs
     public const string NewsCategoriesFolder = ID.Parse("{B866EC76-54ED-447D-9AB2-5E05A0699586}");
     public const string SearchResultsPage= ID.Parse("{F6778EA3-1B76-4BBF-AD21-63E9EA847FDE}");

As you can see from above there is an item for the News Categories Folder and the Search Results Page. Both of which need to be referenced in code, and the reason why they are in the Constants file. Using the method of putting those ID’s in the Constants file makes it easier to manage those ID’s in one place. When doing so, you can then get your item more clean and like so, in this case the Search Results page:

var searchResultsPage = Sitecore.Context.Database.GetItem(Constants.ItemIDs.SearchResultsPage);
var searchPageUrl = LinkManager.GetItemUrl(searchResultsPage);

If you make a change to the Item ID, then it will make that change across your solution versus having that ID out there in 5 other components you will need to change manually.

Option 4 (Best Option using TDS & Glass.Mapper with Code Generation):

Option 3 is definitely considered a best practice, but what if we can make this even easier to manage dynamically using TDS & Glass.Mapper, and keep ID’s out of the Constants file altogether except for rare circumstances?

Now that you have seen a few ways to point to the item in the Content Tree, let’s discuss Parameter Templates. Parameter templates are a way for you to add fields to your rendering that can help out the Content Editor in their daily Content Editing experience. Below are links to helpful information regarding Parameter Templates:

Now, that you have a good idea of what Parameter Templates are and how to set them up, let’s talk about why we would want to use them as a best practice in components for item pointing.

Parameter templates help to manage the solution while providing a better experience for your Content Editors. We simply create a Parameter Template to be used with the Search Component that has this criteria:

  • Name: Search Results Page
  • Field Type: DropTree
  • Data Source: /sitecore/content/Home/

We create a Standard_Values for the Parameter Template and set it to the Search Results Page by default.

When added to the Search Component, it is by default set to the Search Results page, but if the Content Editor ever wanted to point to an alternative Search Results page (for whatever reason), they now have that option. But more importantly, you bypass having to now add this to the Constants file, if your Parameter Template is strongly typed as one of your Models. Using TDS with Glass.Mapper “Code Generation”, this will allow you to create your Parameter Template for the Search Component, then have it auto-generate the Model in your solution for use where you can then call on the Parameter Template like so using Glass.Mapper (notice Search_Results_Parameter):

var renderingParameters = GetRenderingParameters<Search_Results_Parameter>();
var item = Context.Database.GetItem(ID.Parse(renderingParameters.Search_Results_Page));
var pathInfo = LinkManager.GetItemUrl(item, UrlOptions.DefaultOptions);

The Search Results Parameter is now dynamically generated anytime there is a change in the item in Sitecore. Hence, you never had a need to create the model OR add the item ID/path to the Constants file.

Keep in mind you can still do this without TDS/Glass.Mapper “Code Generation” feature, but then you will need to create a model manually for your Parameter Template. The benefit is that you have given the Content Editor the ability the point to the Search Results page versus having this functionality in code that needs to be changed by a developer, and that is the benefit to the client. To my knowledge, you can also do this same type of “code generation” functionality with Unicorn/Synthesis as well.

I have found going this route equates to maximum productivity for the development team once the concept is understood, and helps in manageability of your solution overall. Happy coding!