7

We are considering using Sitecore 9.0 on a new project but we have a requirement to use Habitat. The Habitat example is designed for Sitecore 8.

What do you see as the main pain points in using Sitecore 9 with Habitat? Search functionality won't work out of the box with the Lucene configuration.

Any experiences yet?

  • 7
    Habitat is a demo site used in order to help you build following Helix. I would recommend you read through the Helix documentation and start with a new solution. – Michael West Oct 31 '17 at 23:03
22

I don't really see any. Keep in mind that Habitat is just an example site that demonstrates the Helix principles. So really the requirement should be to build a Helix implementation on Sitecore 9.

Also they have a branch specific to Habitat for Sitecore 9: Sitecore 9 Branch of Habitat. So it might be beneficial to review that.

Some features that are part of Sitecore 9 that will be different from a Sitecore 8 implementation consist of the following:

  1. Dynamic Placeholders
  2. The use of Solr instead of Lucene throughout
  3. Changes to how the configuration is setup
  4. And more...

But those will just affect how you implement your helix implementation, and won't really impact how your Helix project is architected from a fundamentals standpoint.

9

Having taken the path of building a project using Habitat (in Sitecore 8.2, not 9) I can give you the following points:

Benefits

  • Good example of how to structure a Helix solution.
  • Some useful Foundation modules which you could re-use. Some of these help you to adhere to helix guidelines such as the Multisite foundation module which includes a Datasource configuration feature to allow you to set site-specific datasources for renderings.
  • Can probably re-use Project\Common module as this consists mainly of bootstrap related structures.

Drawbacks

  • Bloats your project with lots of code you won't use
  • You will spend time removing Feature modules (or if you leave them in your solution, you will slow your build and synch processes), OR
  • You will spend more time trying to adapt Feature modules to suit your needs than you would spend building from scratch.
  • You will need to learn about the Habitat build process and will likely have to modify this if you use the solution in a CI process. This might take quite a bit of time if your usual build processes are very different.

Summary

I would look at Habitat as a useful solution for first learning about Helix - if you create some sample modules it will be good practice for working in this manner. But do this with the goal of learning, not building something for a client project.

Another way to think of it is: do you prefer (and is it quicker) to create your own solution, a greenfield project; or do you prefer to work with an existing solution knowing that you will add the learning curve for this existing solution to your work burden.

  • 3
    I would add that a lot of the code in Habitat is not production worthy and while it may follow good Helix practices, it does not always follow good development practices - see the FAQ module for examples. – Richard Seal Nov 1 '17 at 15:37
2

I've upgraded Habitat to Sitecore 9 and there are several things to note. There's an existing Github PR for SC9, so you may want to check the progress on that too. In the meantime, here are things to watch out for (not inclusive of course):

  1. If you're going to use SOLR (the default from the install), you will need to update the configs (particularly field names) and some code such as the constants to reflect field names and facets handling. Since the ContentSearch API mostly abstract any provider specific code, most of the code works.

  2. You will need to switch from the DynamicPlaceholder module to the built-in DynamicPlaceholder. You can simply remove the dependence to the module then update the HtmlHelper to use the native one (and update the Views if you're using them)

  3. XConnect is the biggest change and thus the biggest challenge depending on how much xDB code you have. So, if you are using the Demo code and SitecoreExtensions in Habitat, you will need to rewrite most of those.

  4. Remove the old WFFM Forms. Use the new one. Although WFFM should still work, it's being replaced obviously. So, Habitat code for WFFM like the Outcome action will need to be replaced if you use it. FYI: Experience Forms doesn't allow site-specific forms location in this version. I've reported that to Sitecore already.

  5. Like #3, since Marketing Automation is part of xDB, if you were using previous versions and have code against it (i.e. the Demo project has code to look at the user's Marketing Automation state), then you will need to redefine and recode all of that as well.

Anyway, SC9 to me is like SC6 to SC7. It's a major update specifically architecturally. It's definitely for the better. As what everyone else said, Habitat is an example but has some really good software architecture concepts in it. But it's not for EVERY project. So, pick and choose.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.