March 10, 2017 by Alistair Deneys
After much more development effort than we originally anticipated, I’m very happy to announce WeBlog 3.1 has been released!
“But what happened to WeBlog 3.0” I hear you ask? Yeah, we didn’t make a big deal out of it as it didn’t support Sitecore 7.x. The team had a large desire to get WeBlog 3.0 out before the end of 2016, and we did, on December 22 2016. To meet that deadline (which we gave ourselves), we decided to get the module version out which worked with Sitecore 8.x, as many people had been asking for it. WeBlog 3.1 simply adds support for Sitecore 7.2 and 7.5.
So, that leads into the first major topic about WeBlog 3.1;
No more support for Sitecore < 7.2
WeBlog 3.1 drops support for Sitecore versions 7.0 and 7.1. We chose to drop support for these versions simply as a scope reduction mechanism, combined with the fact these versions are getting a bit old now, and it’s quite unlikely anyone is still actively developing any sites based on these older Sitecore versions.
Supporting Sitecore > 8.0
WeBlog 3.1 supports all Sitecore 8.x versions (8.0, 8.1 and 8.2). It kinda makes sense that as we add support for a new version we remove some support for an older version.
WeBlog 3.1 now supports MVC! We have MVC versions of all the presentation components included with WeBlog. We also have a complete set of templates (where we have presentation) and branches, to help you use the correct templates depending on which rendering engine you prefer to use.
New theme system and new themes
I was never really sure if anyone used the theme system in WeBlog…to be honest, I wanted to remove it a while back. But some of the other contributors do use it, so that’s proof enough for me to keep it. Even so, the old themes did look a bit tired and in need of replacement. Don’t be too harsh on them though…they were there almost from the start.
And the new OOTB themes are responsive! So that should make demos look a bit nicer.
Updated WordPress Import
The WordPress import tool had a few issues, which have been fixed. But we also created a brand spankin’ new WordPress import tool in SPEAK. The import tools are also aware that we now have 2 options for presentation engine and allow you to select to import your content into a new WebForms blog or MVC blog.
No more Custom Item Generator (CIG)
WeBlog has used the Custom Item Generator for a while. The concern with it’s usage was that WeBlog would be forcing a specific version of that module on users, and if you wanted to use CIG in your site implementation you could only use the same version WeBlog was using. If CIG was updated, then users would have to wait for WeBlog to update to the new version before you could use it on your site.
In addition, I don’t think WeBlog really needed CIG. CIG is good when you have a large number of templates to create custom items for, or if you go through a lot of change in your templates and need to regenerate your custom items often. These are both instances that may pop up on a site build, but neither of which we had in WeBlog. We have a low number of templates and that are pretty stable, not changing often. In the end, it felt like an additional dependency that we didn’t really need.
Unit Test or Bust!
(I think I hear Dan Solovay cheering)
Much of the development work for WeBlog 3.1 was complete before the first quarter of 2016 was done. The new themes where in and we had MVC componentry too. But the test suite was a little fragile, and it was difficult to get the tests all passing consistently across all Sitecore versions we support. The test suite at the time was all integration tests, using the Codeflood ASP.NET NUnit Test Runner to run them inside a live Sitecore instance. One symptom of supporting so many Sitecore versions is that there are small changes between the versions that where impacting the tests. Things like the date format changing ever so slightly so that test items didn’t always deserialize properly or the same way from version to version.
In the end we bit the bullet and converted whatever we could to a unit test. We now have a separate project for unit tests (which are actually unit tests) and one for integration tests. Remember, even with proper unit tests, you still need to make sure the “units” play nicely together, which you do with integration tests.
Thanks to the contributors
As always, I’d like to say a big thank you to the WeTeam contributors that worked on this release.