Global Office Directory
Share this page
Home > Community > Technical Blogs > John West Sitecore Blog > Sitecore Differentiating Factors Blog Series Extensibility
One of the things that I feel makes Sitecore unique in the web CMS industry is the extensibility of the product architecture. Because no CMS can provide every feature that every organization requires, it is important that each customer can enhance the CMS with the custom functionality they need. Extensibility is especially important when you consider the pace of change on the web today, and that extensibility allows for integration with other systems. This blog post about platform extensibility is part of a series about Sitecore Differentiating Factors.
Sitecore clearly designed its CMS product with extensibility as a high priority. Far from being a canned solution providing a few data types and presentation options, you can implement any data structure or presentation format with Sitecore. All of Sitecore’s modules, such as the amazing Online Marketing Suite and all of the shared source components, demonstrate various forms of extensibility. More importantly, you personally can extend Sitecore using a variety of techniques. Using event models, scheduled processes, pipelines, data providers, and and other techniques using Sitecore's extensive Application Programming Interface (API), you can integrate virtually any application with Sitecore.
Sitecore uses the web.config file almost like a dependency injection container. You can override almost any feature defined in the web.config file. You can even do this using a web.config include file.
You can override existing commands and embed custom commands in existing user interfaces as described in the post Sitecore Ribbon Command to Debug Any Item in Any Database on my old blog.
You can develop custom applications within the existing user interfaces in a number of ways. For example, the Presentation Usage Reporter shared source module adds a custom editor to report usages of presentation components. You can add features such as warnings in the Content Editor as described in the post Content Editor Warning to Display Publishing Status. In addition to using the Sitecore Client roles to control which users can access each feature, including individual buttons in the Rich Text Editor, you can use logic to control whether to enable or disable commands. Sitecore provides a rich API that makes it easy for developers to implement these kinds of features.
You can alter pipeline processes or entire functional components. For example, you can implement your own logic to resolve the web client’s preferred language as described in the post Overriding Sitecore's Logic to Determine the Context Language on my old blog. This is just one example of tapping into a pipeline to customize functionality – the possibilities are literally limitless.
Sitecore uses ASP.NET providers for membership (user authentication), role, and profile information. You can easily replace the default providers with Active Directory, Microsoft Dynamics CRM, or a custom solution.
There are probably a number of additional ways to extend Sitecore, such as using data providers and custom field types. If you know of additional techniques, please add a comment to this post.
Next in the Sitecore Differentiating Factors series: The Layout Engine.
Tags: API, Architecture, Infrastructure, Sheer UI
John has over ten years of experience in the CMS industry. His areas of focus include the Sitecore community, Web industry research, Sitecore technical documentation, and product management.
This website is designed to be fully functional with scripts disabled in browser. Please contact the webmaster for any suggestions