WeBlog 4.1 Released

WeBlog 4.1 has been released. The main feature of WeBlog 4.1 is support for Sitecore 10.0. You'll find the Sitecore packages for various Sitecore versions on the release page at https://github.com/WeTeam/WeBlog/releases/tag/release%2F4.1.

No more support for Sitecore 8.x

As mentioned in my post announcing the release of WeBlog 4.0.1, that was the last release to support the Sitecore 8.x series. So release 4.1 drops support for Sitecore 8.x.

Added support for Sitecore 10.0

WeBlog 4.1 adds support for Sitecore 10.0. Just grab the Sitecore package from the releases link above. There is a Sitecore package for each of the minor Sitecore versions supported.

Use Sitecore Robot Detection instead of CAPTCHA

No one likes a CAPTCHA, but it feels like this hassle has become a necessary evil when using forms to submit data on the internet. WeBlog has included a CAPTCHA component on the comment form for a very long time. However, there is a better way for dealing with bots. Sitecore includes a robot detection feature which is much less of an impediment than a CAPTCHA. In fact, Sitecore Forms added a feature in Sitecore 9.3 (https://doc.sitecore.com/users/93/sitecore-experience-platform/en/work-with-robot-detection-for-forms.html), allowing users to enable robot detection on forms to stop robots submitting them.

We've done the same in WeBlog 4.1. All the CAPTCHA components have been deprecated and will be removed in the next minor release. In addition to the normal form data validation, a new pipeline named weblogValidateComment has been added with a ContactNotRobot processor which uses Sitecore robot detection to ensure the contact is not a robot. Much nicer than a dirty old CAPTCHA on your form.

No more support for WebForms

We've been debating whether to continue supporting WebForms for quite a while. A few months ago I did a bit of research to see what people were recommending to use. Being MVC is newer than WebForms I imagined most people would be heading that way. But to my surprise, most people recommending using whatever you're comfortable with.

I personally prefer MVC over WebForms. I've just found it to be a more natural fit when I've been designing Sitecore implementations in the past. And the writing's on the wall for WebForms with .net core not planning any support for it. To solidify my preference I reached out on Twitter recently to ask which technology others are using (https://twitter.com/adeneys/status/1291142762792751104). 90% of the respondants chose MVC.

If that isn't enough evidence, I also found a bug in the WeBlog 4.0 WebForms code while preparing the WeBlog 4.1 release. Given the fact no one has yet reported the bug indicates no one is actively using WebForms with WeBlog.

Refactoring

The majority of changes in this release have been internal refactorings.

Firstly, all projects were upgraded to the SDK project format which has helped simplify the project XML. It was also necessary to do this to allow changing NuGet references for different target Sitecore versions. We've also been able to switch over all Sitecore references to NuGet package references.

In doing this, there have been some changes to project configuration files. If you've been building the project locally yourself, the biggest change will be the deploy.targets file which has been renamed to deploy.props (because the file only contains MSBuild properties and no targets). Details on how to build the project are included in the README.md file at the root of the repo.

There were also many changes to clean up the custom item classes and remove their dependencies. One of the key points of the Custom Item Pattern is that a custom item class should be implicitly convertible to Sitecore.Data.Items.Item. Previously dependencies had started to creep into these classes, requiring those to be passed in the constructor. These have all now been cleaned up with the old constructors being deprecated. There were also a lot of hidden dependencies in the custom item classes, accessing static Sitecore members (link LinkManager). Those dependencies have also been removed by encapsulating the additional behaviour and injecting the extracted class to the locations that required it, rather than shackling the custom item class with all that extra responsibility.

There were also a large number of refactorings to help make the code more testable, adding unit tests along the way.

Conclusion

Although there isn't a heap of new functionality in WeBlog 4.1, the refactorings have helped make the code structure better, and helped increase the code coverage of the unit tests, to help increase the quality of this and future releases.