Sitecore Implementation Best Practices

These practices focus on the development process around data templates and renderings and general serialization and deployment practices.

1. Data templates should have a Standard Values item.
2. Data templates and Standard Values items should have icons specified.
3. Insert Options should be set up on Standard Values where needed versus on content items.
4. Field name and Item template should have a proper naming convention. If you are creating any common template please start with _ as a name. example _pageContent

1. Rendering should be either a Controller Rendering or a View Rendering or a JSON Rendering.
2. Experience Editor should be supported. This can be either inline editing or managed with surfacing the fields with a WebEdit Frame.
3. When Data Source items are used, the rendering should be setup to restrict the item by data template, path where item can be associated or created.
4. Icons should be added to renderings to assist with content editor experience.
5. Try to add a thumbnail in the rendering so it will really be helpful in EE.
6. Rendering Parameters should be avoided for general content editing experience. They should be used as deemed necessary.
7. Rendering parameters can be used to pass information to component rendering code. Make sure to only use them for settings and not content.
8. Before developing new functionality or rendering, check if there is already a module created for that.

1. Every component should be editable in EE. Make sure all fields in the component are editable.
2. Use the EditFrame control for editing complex item fields. FieldRenderer control can only render simple field types such as an Image or a Link, however, fields like Multilist or TreeListEx will require an EditFrame control to make them editable from the Experience Editor.

1. Ensure proper Experience Editor support by configuring Sitecore placeholder settings. Placeholder settings allow specifications such as which areas are available for editing and where certain components can be used.
2. In Placeholder, if configured properly, it allows control fields value. It’s important in EE.

Search/Solr

1. If you have large data to get use SOLR only. If you use GetChildern() method it will load the page performance.
2. User proper SOLR Query and facets for filtering.
3. Sitecore provides default master and web index. But if you want to search specific blogs/news/events etc please create new custom indexes.
4. Implement “Switch on rebuild” strategy with Solr. This practice helps make sure that website search is not affected when a full re-index is performed. By default, Sitecore drops the entire index first in such cases and starts gradually rebuilding it; if the website implementation relies on search indexes, the user experience can be negatively impacted to the point of a site outage.

1. Data templates and renderings should be serialized by TDS/Unicorn and never be promoted by Sitecore packages. Some exceptions do apply.
2. If Sitecore package is needed for a deployment, that package should be referred and tested by another developer. Instructions should be written so the deployment of the package is done consistently across environments. That package should not change after once it starts moving through DEV otherwise DEV should be refreshed to prove out the next package.

In cases of deprecation of a legacy rendering, the developer should provide a Sitecore package to update content and instructions for the sandbox environments for all developers. We should avoid breaking sandbox for ongoing development.