Sitecore Best Practice Series:
| # | Practice | Rationale |
|---|---|---|
| 1. | Configure placeholder settings | Ensure proper Experience Editor support by configuring Sitecore placeholder settings. Placeholder settings allow specify which areas are available for editing and specify where certain components can be used. |
| 2. | Use Sitecore Buckets for content areas with more than 100 items | This practice helps improve Content Editor performance, where load speed starts degrading in the areas of content tree where the item count gets close to 100. |
| 3. | 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. |
| 4. | Serialize Security Assignments and Roles | This practice helps automate environment setup by automating security assignments. Using this practice in combination with Remove inheritance rather than explicitly denying access rights practice will allow to quickly recreate an environment with the entire content tree, if needed. |
| 5. | Cast fields into the corresponding API type to access its properties | Avoid using raw field values to keep type-safety and abstract yourself from raw data, cast the field into a certain type and use the types properties instead. |
| 6. | Use Rendering Parameters | Rendering parameters can be used to pass information to component rendering code. Make sure to only use them for settings and not content. |
| 7. | Use the Developer Strip in Content Editor | The Developer strip provides handy functionality such as serializing database data and restoring it back without throwing off your solution serialization. |
| 8. | Simplify code and content | It is easy to get carried away with creating checkboxes that would trigger certain items to be shown or published, while ignoring the native Hidden field or removing or archiving the item. Make sure you are not reinventing the wheel by recreating already existing functionality. |
| 9. | 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. |
| 10. | Componentize CSS | Align CSS implementation with the component-based nature of Sitecore development. Set a class on the parent element of a component and use that for styling that way it looks and acts the same no matter where it is placed on the website. |
| 11. | Use Sitecore Forms to capture user intake | Avoid implementing custom forms, use Sitecore Forms (former WFFM) instead, as it integrates with the xDB, provides drop out analytics, flexible form creation interface, a large library of controls, various options for structures, and submission actions. |
| 12. | Store frequently changed settings in Sitecore items | Changing Sitecore config files resents the entire application and should only be done for system administration-level settings. Avoid unforeseen errors caused by editing configuration files and store frequently changed settings in Sitecore items then restrict access using Sitecore's Security Editor. |
| 13. | Before developing new functionality, check if there is already a module created for that | Don't reinvent the wheel. Check the available modules an Sitecore Marketplace and Git. |
| 14. | Use item IDs to access items instead of paths | This practice helps improve application performance; item access by path is slower as it is handled through iterating over each level of a content tree. |
| 15. | Use Sitecore utility classes | Sitecore has a some commonly used functionality built into its utility classes of the Sitecore namespace, use them instead of creating your own. |
| 16. | Iterate through the ChildList instead of the Children property of a parent item in a “for” loop | C# will evaluate the item.Children statement with each loop; prevent this by creating a ChildList and iterate through it instead. |
| 17. | Remove file extensions from web pages | This is one of the practices from the past. URLs without extensions are easier to memorize and can be used to represent different file types, such as .htm, .html, .aspx …etc. removing the need for custom redirects when switching technologies. |
| 18. | Separate custom configuration out into patch files | Create website and module-specific configuration patch files and use the patching facility to add, delete, or update the default configuration. This practice helps dramatically reduce the level of effort in future upgrades. |
| 19. | Stay away from depricated types, properties, and methods | Sitecore continuously improves its API, deprecating old code and introducing refactored classes with new functionality. It is vital to keep up with the latest changes and avoid using the deprecated code, making client’s Sitecore upgrades in the near future easier to implement. |
| 20. | Use Sitecore Rocks Visual Studio plug-in | Sitecore Rocks is a useful Visual Studio extension that makes content management available from the IDE, as well as provides additional development tools, making Visual Studio a centralized Sitecore development environment. Sitecore Rocks makes Sitecore developers happy! |
| 21. | Create an abstraction layer in code for content items based on item data definition templates | It is a good coding practice to use abstraction, Sitecore development is no exception. Abstract each template with an interface or class using an ORM. |
| 22. | Disable ViewState for sublayouts that do not use it | Increases sublayout load time and HTML weight; this practice is for those still on Web Forms. |
| 23. | Use UserSwitcher instead of SecurityDisabler | Allows switching to a particular user instead of disabling security layer restrictions completely, which enforces need-based access. |
| 24. | Specify image dimensions as parameters of the field renderer | Sitecore resizes images on the server based on these parameters, which may improve page load speed. |
| 25. | Avoid using XSLT renderings | XSLT may only come up in Sitecore trivia these days, so that here is the reason for avoiding it - it is unable to match the functionality of C#, MVC, JSS, etc. and mixing technologies adds significant overhead to maintenance. |
| 26. | Use FieldRenderer control to render field content | Field renderer provides the ability the edit field values in Experience Editor. Field renderer is abstracted away by MVC or JSS syntax nowadays. |
| 27. | Create content items under /sitecore/content/home | Sitecore uses the full item path in URLs for items outside of the /sitecore/content/home by default. SXA customizes this functionality to allow Tenants and Sites in the path, however, without the SXA we would want to stick to the legacy-mandated path; the echo of the old days when Sitecore was a single-website CMS. |
| 28. | Do not store content items in /sitecore/system | Items stored under that path are meant for system configuration and Content Authors should not have access to that area of the content tree. |
| 29. | Set a default RTE profile | If a particular RTE profile is used frequently in item data definition templates, it is easier to set it in Sitecore configuration instead of having to specify it manually in the Source of the field definition every time. |
| 30. | Define separate “Navigation Title” field | Item names may get unnecessarily long for SEO purposes, to make sure this does not affect the display of the item in any menus, use a separate field for a navigation title. |
| 31. | Make classes serializable | Serialization is used by Application Session and ViewState in .NET; if objects are serializable, the client can easily upgrade to a clustered Sitecore server environment without changing the code. |