Sitecore Best Practice Series:


Sitecore Developer Best Practices


1. Configure placeholder settingsEnsure 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 itemsThis 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 SolrThis 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 RolesThis 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 propertiesAvoid 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 ParametersRendering 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 EditorThe Developer strip provides handy functionality such as serializing database data and restoring it back without throwing off your solution serialization.
8. Simplify code and contentIt 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 fieldsFieldRenderer 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 CSSAlign 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 intakeAvoid 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 itemsChanging 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 thatDon't reinvent the wheel. Check the available modules an Sitecore Marketplace and Git.
14. Use item IDs to access items instead of pathsThis 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 classesSitecore 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” loopC# 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 pagesThis 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 filesCreate 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 methodsSitecore 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-inSitecore 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 templatesIt 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 itIncreases sublayout load time and HTML weight; this practice is for those still on Web Forms.
23. Use UserSwitcher instead of SecurityDisablerAllows 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 rendererSitecore resizes images on the server based on these parameters, which may improve page load speed.
25. Avoid using XSLT renderingsXSLT 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 contentField 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/homeSitecore 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/systemItems 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 profileIf 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” fieldItem 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 serializableSerialization 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.

%d bloggers like this: