SXA Best Practices Audit

Sitecore SXA Best Practices Audit

Leave a reply

Are you following best practices in your Sitecore SXA implementation? If not, there can be consequences down the road in the form of technical debt or a full re-implementation down the road sooner than expected if the best practices were never adhered to in the beginning of development. A Sitecore SXA audit is the way to go up front, during, and after your implementation to ensure that your Sitecore SXA development team are giving you the most robust implementation that will stand the test of time with upgrades to SXA and Sitecore while providing your Content Authors the flexibility they need to author content.

Preparing for a Sitecore SXA audit can help you to examine the current architecture for your client, then compare to the best practices recommended by the Sitecore SXA Team, then make recommendations based on your findings. These findings can, and should, steer development efforts after going through your audit. If there is a commitment to adhere to best practices, based on the audit, then there may be low – high impact to your solution and Sitecore architecture based on the technical debt accumulated over SXA development efforts in the past.

Below in each of the recommended practices, I will provide my thoughts on what may be necessary to bring the solution and Sitecore architecture to be in line with Sitecore SXA best practices before, during, and post development.

These best practices came from the SXA Team via an SXA Recommended Practices document that was put together awhile back by Adam Najmanowicz. This original documentation was used as the basis for the documentation that is in place now as official Sitecore documentation on SXA recommended practices. Big ups to Adam for putting that initial documentation together that we can use today as a baseline for a solid SXA implementation for clients!

Page Structure

https://doc.sitecore.com/developers/sxa/18/sitecore-experience-accelerator/en/recommendations–structuring-pages.html

  • Design page layout in Partial Designs

    Partial designs will be your best friend with SXA along with Page Designs. Just think of a partial design as the old Standard Values for Page Types. You will use Partial Designs and then use them with Page Designs to create your pages. Using Standard Values is not recommended so you will need to get out of that thinking. Standard Values will still work, but it’s NOT considered best practice.

    Partial Designs Folder

    Partial Designs Folder

    If you revert to this best practice down the road you are looking at medium level of rework but high level of regression testing.

  • Put complex reusable structures in Partial Designs or composite components

    The point of SXA is to make your life easier not harder so put complex reusable into composite renderings like SXA has Carousel, Accordion, and Tabs out of the box. Those are typically complex components so if you have one that you are set to create then put it into a composite component like a Snippet, which has many components in one. These are things you will want to teach your developers as you build your SXA site out to be aware of. Snippets are very powerful so use them!

  • Remove unnecessary components from your site’s “Available renderings” to allow usage of styled components only

    This is basically to only show what your Content Editors will actually use, that of which is styled and looking good. If it’s not pull it out so nobody uses it. Be kind to your Content Authors.

    Available Renderings Folder

    Available Renderings Folder

    There is no real impact on what has already been done here so low level of rework here.

  • Set up placeholder restrictions

    This is so you can stop your Content Authors from inserting a component into a placeholder that they shouldn’t causing confusion and introducing possible bugs when the component should never have even been allowed in the first place.

    Placeholder Settings Folder

    Placeholder Settings Folder

    Your Content Authors will love you for helping them help themselves and is low effort to fix.

  • Do not use Standard Values to set up presentation details on your pages

    As I stated earlier, use Partial designs instead or possibly Snippets. Standard Values are a thing of the past with SXA.

    If you revert to this best practice down the road you are looking at medium level of rework but high level of regression testing.

  • Make use of Partial Design inheritance where it makes sense

    This should be thought out up front BEFORE development as changing this down the road can be erroneous and lead to data loss if you try to inherit from base partial designs post-development.

    Base Partial Design Inheritance

    Base Partial Design Inheritance on Partial Design Item

    If you revert to this best practice down the road you are looking at medium level of rework but high level of regression testing.

  • Prioritize setting component size directly on the component over using splitters

    This is more of a Content Author activity that can enhance the speed of the Experience Editor. Ensure that the Content Authors know this approach and the Front-End developers can account for this in CSS/JS and such. No need to change anything here, but good to know as a best practice.

    Component Sizing

    Component Sizing

Use of Renderings

https://doc.sitecore.com/developers/sxa/18/sitecore-experience-accelerator/en/recommendations–using-renderings.html

  • Use proper renderings for the job

    This should be thought out up front with your developers on how best to put together the component in question. A lot of the times the OOTB components can work for a lot of the needs. When there is a one-off then clone a very similar OOTB component and extend it for your needs. With that being said, though shalt not clone everything and make everything custom in my honest opinion. Take a hard look at the OOTB componets and see if you can get what you need accomplished with OOTB components and/or a Rendering Variant and then if you can’t make it happen ONLY then go custom with cloning. There is not a need to refactor every single rendering down the road as that would be a high level of effort, but do adjust to this best practice by knowing it up front and preach it to your SXA Development Team.

    SXA Out of the Box Examples

    SXA Out of the Box Examples

  • Use Snippet rendering to prepare sets of components

    Snippets are able to house multiple components essentially so if you have pages that use the same set of components then consider using a Snippet. The same snippet can be used with many different pages and all point the same datasource so changing the original Snippet will change them for all referencing that datasource.

    Snippet Component

    Snippet Component

    There is no hard and fast rule on this one I think, it’s based on the project, but if you do go down this path later to use as a best practice it can be a medium level of effort with high regression testing.

  • Do not use Plain HTML component for content that is edited by Authors

    This is almost always a bad idea unless truly warranted. Don’t let the Content Author have the whole rope, they may hang themselves. Hence, think about if there is a better alternative that will restrict them a little the help them from frustration and mistakes.

    Plain HTML and Plain HTML (Reusable)

    Plain HTML and Plain HTML (Reusable)

    Modifying this down the road to refactor open components like this would be a low level of effort with better results for Content Authors.

  • Rich Text field content should be fully editable using the Design view

    This one is great and is a great bang for your buck with your Content Authors, which is giving them the ability to choose a CSS class from within the Rich Text Editor keeping them from using the HTML tab to have to add in a CSS class in the other interface.

    Rich Text Editor using Class Drop-Down

    Rich Text Editor using Class Drop-Down

    This is very low effort to implement to help out your Content Authors. Here is a link to instructions on how easy it is to Add Custom Classes to the Rich Text Editor.

  • Provide previews for rendering variants

    This is subject to opinion, but I am firm proponent of all preview images that help the Content Authors make their job easier, and a picture is worth a thousand words! The ability for the Author to see what it is that they are about to add as a component leads to less confusion and can go a long way in keeping our Content Authors, who are our end user as a developer, very happy!

    This is considered low-moderate effort to go back and do but is well worth it!

Proper use of Rendering Variants

https://doc.sitecore.com/developers/sxa/18/sitecore-experience-accelerator/en/recommendations–extending-sxa.html

  • Limit the number of rendering variants to 15 (preferably below 10)

    This is going to be a task you will want to work with at the beginning of development of the components at hand to ensure you DO have some variants, but don’t overdo it. But DO make sure to give meaningful names to your variants when you have many. Make it easy for your Content Authors to understand what the variant is directly from the drop-down in the Experience Editor!

Development

https://doc.sitecore.com/developers/sxa/18/sitecore-experience-accelerator/en/recommendations–extending-sxa.html

  • Never put any custom items in SXA controlled branches of the tree

    This is simple, never do it, and preach it to your SXA development team! During your PR reviews ensure that this violation is not happening, otherwise your SXA components will be defaulted back to the original state and/or worse your SXA instance is broken.

    Experience Accelerator Folders

    Experience Accelerator Folders

    This is a must do item in any SXA audit and is moderate effort that can lead to high effort to rectify so best to adhere to and have knowledge of from day 1!

  • Do not modify the OOBT SXA items

    This is simple, never do it, and preach it to your SXA development team! During your PR reviews ensure that this violation is not happening, otherwise your SXA components will be defaulted back to the original state and/or worse your SXA instance is broken.

    Experience Accelerator Folders

    Experience Accelerator Folders

    This is a must do item in any SXA audit and is moderate effort that can lead to high effort to rectify so best to adhere to and have knowledge of from day 1!

  • Do not replace the SXA “MVC Layout” with a custom implementation

    This is directly from the words of the SXA Team, “By replacing the layout with your custom implementation, you risk losing compatibility with future versions of SXA thus increasing the maintenance cost for the site owner in the future considerably.”

    SXA MVC Layout

    SXA MVC Layout

    Hence, heed the warning, and to go back and fix this would be in my opinion high effort in regression testing every component that would now go back to using the default version.

  • Create an SXA module for your components

    For simplicity’s sake this will aid in adding in custom components via an SXA module, and will help with new sites / tenants. May be on a case by case basis depending on your implementation but keep in mind that if you choose to go down a custom path for a component then this would be considered a best practice.

    Adding a Site Module

    Adding a Site Module

    This is considered low effort, but will help with future tenant / site implementations.

  • Follow Helix principles when adding functionality to your solution

    Make no mistake about it, SXA follows the Helix Patterns, Principles, and Conventions, and your development team should as well in working with SXA. When working inside Sitecore, ensure you are following Helix by creating sibling folders to the Experience Accelerator folders. If you have never worked before with Helix this is your opportunity to see exactly how Helix is used widely in the Sitecore architecture as well as in the solution. You can even gain an immense amount of knowledge from reflecting on the .dll’s with DotPeek or .NET Reflector to see what’s going on under the covers! Learn from those at the SXA Team that have come before you, and adhere. SXA is built to take full advantage of Helix!

  • Consider using existing renderings before building a new one

    This is not only a recommendation, but it should be a standard practice for an SXA Development Team to sit down with the Architect, or the Architect to provide guidance on the “how to” build for the component. One of the major benefits of SXA is that you have out-of-the-box components that truly are good enough to get a lot of what you need done. Hence, ALWAYS consider using the OOTB components versus reinventing the wheel. It will save you time and the client money. Once they are built, they are now Technical Debt if you come to find out later that you could have used an OOTB component for what you built a custom component for so be diligent in these efforts and put this down as a sub-task on the User Story to research the OOTB component to see if it will work for your component requirements unless your Architect had the time to give the direction and/or component stubbed out ahead of time to make that decision for you. Rendering Variants and Snippets are your best friend!

    SXA Out of the Box Examples

    SXA Out of the Box Examples

  • Consider cloning existing renderings before building a new one

    If you MUST go custom for your component, choose the component that is closest to yours and clone it. Cloning is the way to go always, as this will do everything behind the scenes for you. You CAN do this via reflection using your favorite tool, but it is considered a best practice to use the cloning feature provided by SXA.

  • Limit scope of fields linking to items

    One of the coolest features that you can take advantage of with SXA are the tokens that limit the scope of items that Content Authors can choose. You can use these tokens in most data source fields and they are powerful to help you give the best experience to your Content Authors to place them in the correct folder the minute they attempt to choose any data source for the component!

    Examples of SXA Tokens in Datasource Fields

    Examples of SXA Tokens in Datasource Fields

    To fix this is considered low effort for a big win with Content Authors!

Theming

https://doc.sitecore.com/developers/sxa/18/sitecore-experience-accelerator/en/recommendations–working-with-themes.html

  • Do not modify platform themes

    This is simple, never do it, and preach it to your SXA development team! During your PR reviews ensure that this violation is not happening, otherwise your SXA components will be defaulted back to the original state and/or worse your SXA instance is broken. This is a must do item in any SXA audit and is moderate effort that can lead to high effort to rectify so best to adhere to and have knowledge of from day 1!

  • Assign custom styles to components

    This is similar to setting up Allowed Renderings or for only Allowed Components to use a Placeholder. With SXA you can setup a Style to only be used with certain components, otherwise it will be available to all components (which is a no-go). You definitely don’t want Content Authors to use a style that is NOT made for their components leading to a bug, confusion, etc. so make sure to set this and have your FE Team aware of this. Going back to do this would be a low effort, but is definitely worth it in terms of less bugs, questions, and Content Author happiness.

  • Clean your styles folder of unused styles

    Simply stated this cleans up unused styles and is another big win for your Content Authors so use it, so the Content Author happiness remains in bliss. This is extremely low effort at any time.

  • Place your style items in sub-folders of your site’s Styles folder

    Honestly, what can be easier than this? SXA even organizing things for you, awesome! You can simply click on “Organize Styles” button and it takes care of everything! Yes, use it for Content Author bliss. This is extremely low effort at any time.

Data sources and media

https://doc.sitecore.com/developers/sxa/18/sitecore-experience-accelerator/en/recommendations–working-with-data-sources-and-media.html

  • Don’t put media items directly under the site’s Media folder

    Here is what is also nice about SXA is that your Media folder is in the main content tree available at any time for your given site. It has it’s own set of folders to be used and those are expected to be used by SXA, not the typical folders you can use in a traditional Sitecore implementation. Use them, they are there to make your life during development easier, as well as the Content Author’s life easier as well. Fixing this if it hasn’t been done is low effort, but definitely should be done as an SXA best practice.

    Media Folder in SXA Site

    Media Folder in SXA Site

  • Give site data sources meaningful names

    If you have a multi-site implementation for SXA, then make sure to enforce a “meaningful name” convention policy with your Content Authoring team so they can adopt best practices for Content Authoring when data sources are shared across sites. This is a best practice overall in my honest opinion, both locally at the page level as well as shared, but most definitely at the shared level. A data source that says, “FAQ Accordion for 2019” is much more valuable than “Accordion 1” that nobody has a clue what is in it until they open it, and start looking through the item details. Set this standard at the Content Governance level with the Content Authoring team early. Depending on how many data sources there are in shared, this can be low – moderate effort to change all the names, but is definitely worth it for Content Author bliss.

  • Organize site data sources in folders

    This is very similar to organizing your styles to keep things nice and tidy for Content Authors. Again, if you think of your Content Authors as your end user, you will succeed in your Sitecore efforts most, if not all, of the time. This is extremely low effort at any time.

  • Clean up unused site data sources

    This is made simple with the Cleanup Data Folder script provided by SXA. Use it to ensure that your Content Authors are not selecting unused data sources by accident, that are no longer valid, etc. in your shared site Data folder. This is extremely low effort at any time.

    SXA Data Folder Cleanup

    SXA Data Folder Cleanup

Multisite & content sharing

  • Consider using Shared site as the exclusive style container in a tenant

    Nobody likes duplication so when you are in a multi-site SXA implementation be sure to remove styles from other sites, and use the shared site styles so there is no duplication in the Styles section of your components. If you need to do this after an SXA site is up, but this hasn’t been done, I would work with your FE team to first Cleanup the Styles, then start removing. This would be considered low-moderate effort after setup, so best to think about up front during SXA implementation.

  • Consider defining your rendering variants in the shared site and remove their redundant versions from the local sites.

    This is definitely considered in my opinion a definite to-do when using multi-site. I have seen the duplicates in the Experience Editor, and leads to confusion and can be considered a bug. This is low-moderate effort to fix, but should definitely be a top priority!

  • Consider using delegated areas for pages that share content across multiple sites

    This is considered a best practice, and is very similar to the cloning in traditional Sitecore development initiatives. A great example is blogs. Modify a blog post in your main delegated area, and it propagates to all the sites that are using it. Very effective for content used across multiple sites. To do this after an SXA implementation is setup you I would consider this low-moderate effort based on the content and how many sites are going to reuse the content.

  • Consider creation of blueprint/master site to be cloned for roll out to new markets

    This is considered a best practice when starting up new sites, and seems like a dream, but is achievable after you have your components and architecture in place in one site. you can then clone it, and you have a site setup with all the basics. Think about this when you know that you will be bringing in other sites / tenants to make life easy!

  • Consider defining your Page Designs and Partial design in the shared site and reuse them in other sites in a tenant

    This is definitely a best practice when you know you can use your Page Designs and Partial Designs across sites. Make use of this as it will help with the next site you build out so you can reuse instead of reinvent the wheel. You can move your Page Designs and Partial Designs to your shared site later, but you will need to regression test all the pages and components after doing this just to ensure all is working correctly as intended, so I would consider this a high amount of effort. Think of this up front when you know you are bringing on a new site / tenant.

Language & Globalization

  • Always configure and create items in the language of the content

    Simply stated above. Even if you create the site in a single language it’s considered a best practice.

Performance

https://doc.sitecore.com/developers/sxa/18/sitecore-experience-accelerator/en/recommendations–enhancing-sxa-performance.html

  • Limit the number of components directly on a page to under 30

    Too many components will contribute to slow Experience Editor issues so the recommendation is to put common elements in the Partial Designs so they are not directly design-able. Well, in order to do this after an SXA site is up I would consider this to be moderate effort to analyze those common elements, and then get them into Partial Designs.

  • Disable Content Testing for editors that do not require the functionality

    Speed up time in the Experience Editor! No brainer here. This is extremely low effort at any time.

  • Consider configuring HTML Caching settings for components

    Truly this should be considered across the board with your components along. Caching can really help out with performance optimization, and SXA provides 4 different ways of caching. Use them up front during architecture setup, and component development as well. To enable after an SXA site implementation is considered low effort, but is a “must-do” in my opinion.

  • Verify that Asset optimizer is enabled for your site

    This is recommended to be enabled and used in Production, and while I can’t verify the performance increase gained by the usage, I would recommend as well and is considered a low amount of effort for a good gain in performance with concatenation of files into one asset and caching.

To summarize, you have things to think about up front with your SXA implementation/s. Think early, and often when working with SXA about best practices as their is an adherence with SXA that ensures that you will have a successful implementation each and every time, maintain that SXA implementation all the while making your Content Authors excited to work with SXA. Happy SXA’ing Sitecore community!

4 Steps to Package Management with Sitecore Powershell Extensions

Leave a reply

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

1 Reply

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:

<!-- SERVICE BASE ADDRESS
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

Leave a reply

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

5 Replies

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

1 Reply

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 4.4.0.199. 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 “4.4.1.328-beta (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 4.4.1.328-beta (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

Leave a reply

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

2 Replies

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!

Sitecore Sandbox Reviews

Sitecore Sandbox Video Reviews Introduction

Leave a reply

In an effort to help out all the developers in the Sitecore Community, I have created a channel on YouTube that is dedicated to essentially putting Sitecore things and stuff in the Sitecore Sandbox for review and then sharing with the community! This way we all can benefit from the review.

What is it that will be reviewed?

Anything that is related to Sitecore that will make our daily development a more productive enjoyable experience. Typically, we will review modules in the Sitecore Marketplace, Accelerators, or even just features in Sitecore Launchpad. In either case, I am sure we will unlock some more tools that can be added to your toolbox, and help us all reach our true Sitecore potential.

The videos will ONLY be targeted at being 3-5 minutes in length so they will be something you can watch very quickly. In addition, they will be broken down into series. For instance, if we are reviewing the Sitecore Instance Manager features, we will break it down to one feature per video.

Make sure you subscribe and pass on to your fellow developers, and you will be alerted when new videos are out:

SUBSCRIBE NOW!

 

Rebuilding Reporting Database for Experience Profile Data

Leave a reply

Are you familiar with the Experience Profile in Sitecore?

This is a phenomenal tool for Marketers that have audacious goals for their organization. The Sitecore marketing team talks about the Experience Profile as such, “Data-driven marketers who want a 360-degree view of their customer’s interaction with all digital channels over time and in real-time will find just that in the Sitecore Experience Profile”. If you have never taken a good look at what is possible with the Experience Profile, check it out!

Now, what does this have to do with rebuilding the reporting database? Good question! Experience Profile is completely dependent upon the Sitecore_Analytics_Index. If there is no data in the Sitecore_Analytics_Index then there will be no data in the Experience Profile. So, how does data get into the Sitecore_Analytics_Index? Let’s a take a look:

In this example using a typical model of a 1 CM (Content Management Server) with 2 CD (Content Delivery Server) environment, the CD server/s will be delivering customer experience data to MongoDB during the customer session/s. When the session/s ends, typically after 20 minutes (unless set to end earlier) then the data gets flushed using the xDB Processing Server/s. If you have not setup the xDB Processing Server/s on a standalone server then the processing will happen on Content Management server. The processing will take this data and migrate it to your Reporting database, where it will reside, and then be indexed, for performance reasons, by the Sitecore_Analytics_Index for use in the Experience Profile.

Now, why might be ever want to rebuild the reporting database and how do we even do that? Good question! If you don’t see any data in the Experience Profile, and you have a license for the functionality, then, “Houston…we have a problem”. Below are some steps to troubleshoot:

  1. Check the logs using Sitecore Log Analyzer on the Sitecore Marketplace, and see if you have any Mongo connection errors. Connectivity may either have been disrupted or never configured properly. If you are using SOLR look for SOLR errors relating to the Sitecore_Analytics_Index as well.
  2. Ensure you have MongoDB connectivity by using RoboMongo to ensure that data is truly being collected in the collections.
  3. Check the Reporting database tables to see if there is any data being collected. If not, then the xDB processing may not be working for some reason OR you have a connection string missing or incorrect to the Reporting database.
  4. Ensure if you are using SOLR that your cores are setup correctly along with configsets particularly for Sitecore_Analytics_Index.
  5. Check the Sitecore_Analytics_Index for any indexed records. More than likely you will see no records.

If you went through 1-4 and the data is all there, but still don’t have any records in your Sitecore_Analytics_Index then you are now looking at rebuilding your reporting database.

But wait, why don’t we just rebuild the index for the SItecore_Analytics_Index? Good question! Adam Conn explains this in his blog post, but we cannot manually do this, as it is done behind the scenes in Sitecore. There is a workaround to get the Sitecore_Analyics_Index to show up with the rest in the Select Search Index dialog box, but it can be problematic as Adam shows in his post.

Now is when the Rebuild Reporting Database tool comes to the rescue. When you rebuild the reporting database you also then set the Sitecore_Analytics_Index to be re-indexed through this process.

To rebuild your reporting database you will actually need to create a second reporting database to use with the Rebuild Reporting Database administration tool. Instructions on how to do that can be found here. Now, once you have a second reporting database in place you can then use this tool in the Administration Tools area of Sitecore:

Rebuild Reporting Database

Rebuild Reporting Database

When you run this tool you will rebuild the reporting database thereby re-indexing the Sitecore_Analytics_Index. At this point, you should start seeing data flow into the Experience Profile. Happy coding!