So You Want to Create a Sitecore Module
Sitecore modules come in all shapes and sizes. Some drastically alter core pieces of Sitecore, some provide small quality of life changes, and other are separate applications altogether that simply support a Sitecore developer or customer.
If you're interested in writing a Sitecore module, here are some questions that can help get you started in the right direction:
Why am I creating this module?
"Why?" may seem like the simplest of questions, but it's the most obvious one. One of the most common reasons for writing a module is to add new features to Sitecore. Sitecore's strength is that can be molded to support almost any business or technology need. On the other hand, this flexibility means that many common features have to be developed from the ground up. By packaging custom features into a module, you can quickly expand upon Sitecore's base when building on fresh instances.
Even without a business or technology need, writing a module can help you learn about Sitecore from the inside out. Sitecore is a big, complex system, and writing a module is a great way to learn about hooks, pipeline processors, configuration patching, SPEAK, the Sitecore API, and much more.
What value would my module bring to Sitecore as a product?
A module designed to solve a specific business need may have a very narrow use case. On the flip ide, a module that alters or augments a more generalized aspect of Sitecore could potentially be used across many different Sitecore implementations. Does your module simplify a common Sitecore process? Does it fix a known issue? Does it provide new features that many customers would find useful? A "yes" to any of these questions means your module is adding value to Sitecore.
What value would my module bring to the Sitecore community (as open source code)?
Creating and maintaining an open-source module is one of the best ways to get involved in the Sitecore community. Putting your work in front of community peers is a great way to get code reviews, honest feedback, and bug reports. This kind of collaborative effort will only improve the quality of your code and module.
Does a similar module already exist?
The Sitecore Marketplace hosts hundreds of modules. There are many more available elsewhere online. Before diving into your module, be sure there isn't an existing module that does the same thing or provides similar functionality. If there is, check to see if your idea provides anything new to that module, then contact the author to see if you can contribute to it. An existing module that isn't maintained and doesn't work with the latest versions of Sitecore is also ripe for replacement. If you're writing a module just as a learning exercise, you can use an existing module as a point of reference and learning tool.
Can I maintain my module for future versions of Sitecore?
Sitecore releases updates several times a year. Occasionally a major release introduces breaking changes. It is important for a module - especially a widely-used one - to be updated to support those changes. It's also important to address security issues that may arise (even the simplest modules may have non-obvious vulnerabilities). Finally, as Sitecore interface conventions change over time (read: Sitecore's UI from 7.5 to 8.0), a module that updates to match the newer look helps keep it fresh - sometimes appearances make a big difference in staying relevant.
Set Up Your Development Environment
Developing a Sitecore module starts the same as any other Sitecore development: right on your local machine. Even if you already have a local environment set up, it's important to keep a few tips in mind:
- Develop against a fresh instance of Sitecore that matches the minimum version you're targeting. Sitecore 8 and 8.2 brought a lot of quality of life improvements to the frontend and backend, but Sitecore 6 and 7 are still widely deployed around the world. Balance platform reach with newer API features. Reference the Sitecore Compatibility Table for information on minimum requirements for all major versions of Sitecore.
- Use the Sitecore Instance Manager (SIM) tool. You'll want to test your module across multiple versions of Sitecore (from your minimum supported version to the latest release of the platform). SIM makes building up and tearing down Sitecore instances super-simple and quick.
- If you're using Visual Studio, set up a fresh solution for your module and remember to configure it to build to your new local instance of Sitecore. Remember that your module may be used on newer versions of Sitecore than you're targeting, so be ready to deploy across multiple instances for testing purposes.
- Test, test test. Seriously. Even superficial unit tests are better than none. If you're open-sourcing your module, the community will commend you for having well-tested code.
Get To Work!
When developing your module, keep in mind the following tips:
- Don't tie any code or logic to your specific instance of Sitecore. Modules are meant to be... wait for it... modular. If you rely on a specific feature or custom code from your instance of Sitecore, you can't count on your module working on other instances. Instead, make sure all necessary configuration, code, and tools are packaged into the module.
- Mimic Sitecore's code patterns and namespaces to provide consistency when your module is being studied or deployed. When in doubt, use dotPeek to explore the Sitecore codebase and see if you're following conventions.
- While mimicking Sitecore conventions, remember not to trip over them. Make sure you properly namespace your own classes so you don't run into conflicts. Sitecore's codebase is extensive, but all namespaces do start with "Sitecore" so they are easy to identify.
- Use the Sitecore module implementation practices as a guide and checklist to be sure you're on the right track with best practices, code patterns, configuration, and module packaging. The guide goes into a lot more detail on some of the tips provided here on Spark.