WeBlog 4.2 Released
WeBlog 4.2 has been released. You’ll find the Sitecore packages for various Sitecore versions on the release page at https://github.com/WeTeam/WeBlog/releases/tag/release%2F4.2.
This was a fairly small release with not a large number of features added. But there was one pretty significant change, so let’s start there…
If you were running WeBlog 4.1 or earlier in a multi-server environment and using the out-of-the-box comments, then you would have been using a WCF service to send the comments from the CD server to the CM server when a user submitted the comment. WCF can be quite complex to get working properly in a production deployment. Additionally, several production deployments don’t allow communication from a server in a lower trust network segment (the CD server in the DMZ) to a server in a higher trust network segment (CM server in the internal network). These deployments would be forced to use an external comment service instead of the out-of-the-box comment components.
WeBlog 4.2 now uses the Sitecore Event Queue to transfer comments created by a user on the CD server back to the CM server. This idea was first suggested by our good friend Alen Pelin back in 2015. Better late than never right? :) .
One of the big benefits of using the Event Queue is that it works without any additional infrastructure or configuration. We also considered using the Sitecore message bus, but this requires additional databases and configuration to make it work, so we opted for the simpler approach.
Support for Sitecore 10.1 has been added. Just grab the correct package from the release page or make sure you select the correct build configuration if building from source.
WebForms support was deprecated in WeBlog 4.1. That was announced on the release page for WeBlog 4.1 and also in my post for the release Post not found: weblog-4-1-released. WeBlog 4.2 has removed all WebForms components from the module.
As always, there’s been more internal refactoring of the codebase to remove deprecated members and improve the internal structure of the code. Much of this is efforts to reduce our usage of FakeDB, with the ultimate goal of removing FakeDB from the tests. FakeDB is not being updated for all new Sitecore releases, so it’s only a matter of time before we hit a wall and won’t be able to use FakeDB for some future Sitecore version. The current abstractions in Sitecore make FakeDB obsolete, so why not remove a dependency from the build?