Optimizely CMS RSS Feed Integration Library — Version 2 Release

Posted on Saturday, November 15, 2025

Optimizely CMS Easy RSS Feed Integration Library — Now in v2

A while ago I launched a NuGet-package called DavidHome.RssFeed to make RSS feed generation from Optimizely CMS really easy. Back then, I focused on a simple, opinionated design: container and item types marked by interfaces, Azure Blob Storage as the backend, and a scheduled generation job. (If you missed that, you can still read the original post.)

Today, I’m excited to announce that the library has matured significantly — welcome version 2.0.0. This isn’t a small patch: it’s a major rewrite and refactor, and I think it will serve more complex scenarios much better, especially for multi-language, multi-site Optimizely projects.

Here’s what’s changed, why I made these changes, and how to upgrade.


What’s Changed Since v1

  1. Improved Processor Pipeline
    • The processor architecture has been clarified and formalized. Rather than ad-hoc processors, there are well-defined builder and processor interfaces.
    • Better extension points: it’s now much easier to write custom processing logic (filtering, transformation, enrichment).
  2. Multi-Host and Multi-Language Awareness
    • Feeds are now scoped per host (domain) and language. Each container type can generate distinct feeds depending on the hostname and language.
    • This is a big deal if your Optimizely setup supports multiple sites or localized content — no more “one feed for everything” workaround.
  3. Storage Provider Contracts
    • The storage abstraction (IRssFeedStorageProvider) is stronger and more flexible.
    • The Azure Blob provider now handles host- and language-based folder structures, e.g. /mydomain.com/en/MyFeed.xml.
    • This means the library can be extended more reliably if you want to implement a different storage backend.
  4. Breaking API Changes
    • Many core interfaces have changed (builders, processor callbacks, storage signatures).
    • If you wrote custom processors in v1, they may need to be updated to match the new generic types and discovery model.
    • Registration style in Startup.cs is slightly different: you must pass assemblies for discovery, and you register things in a more modular way.
  5. Better Error Handling & Logging
    • The new pipeline makes it easier to surface problems during feed generation, so malformed items or storage errors are more diagnosable.
    • This should make production issues less mysterious (especially in complex, multi-language sites).

Why These Changes Matter

  • Scalability: As my own blog (and potentially other sites) grew, I needed more control and modularity, not a one-size-fits-all approach.
  • Maintainability: The cleaner separation of concerns makes the code easier to test, extend, and maintain.
  • Real-world Use Cases: Multi-host and multi-language support is no longer an afterthought — it's built in.

How to Upgrade to v2

If you’re already using v1, here’s a rough migration path:

  1. Update your NuGet references to the v2 packages (core, Optimizely, storage)
  2. Review your DI setup: switch to the new registration style, pass assemblies to discovery
  3. Refactor custom processors: align them with the new builder/processor interfaces
  4. Update feed models: you need to change them with the new marker interfaces
  5. Validate behavior: regenerate your feeds, make sure routing works correctly, deploy in a test or staging environment
  6. Monitor and tune: watch for any error logs during feed generation, especially for multilingual or multi-host feeds

Final Thoughts

Version 2 of DavidHome.RssFeed is a big leap: it’s not just an “improvement”, it’s a re-architecture. I believe this makes the library much more powerful for serious Optimizely use cases — but also more flexible than ever for hobby or solo projects like my blog.

If you’re using it today, now’s a good time to upgrade. If you’re just discovering it, hopefully v2 feels more robust and future-ready than the early days. You can find it on NuGet.org. If you're interested, you can also view my NuGet library

Thanks to everyone who has been using, testing, or contributing — I appreciate every bit of feedback. If you run into issues or want to help shape the future of this library, let me know or open an issue in the repo.

Happy coding!