Archive
Monthly
Go
|
|
DNN Blog
Apr
28
Posted by:
Scott Willhite
4/28/2010 5:31 PM
 Producing DotNetNuke 5.4.1 has been inspiring! The ASP.Net 4.0 motivated release of DotNetNuke 5.4.0 was not without a few “showers” in April, but we’re looking for “flowers” in May with 5.4.1! I have to say that I am very pleased with the responses of our Management and Engineering teams as well as the Core team and the Community. It’s really a testament to the importance of community in open source and the strength of the DotNetNuke Community in particular. Constructive dialog, quick response, highly inclusive… well done by all!
Today Shaun is in Ecuador speaking at a Microsoft Interoperability Conference. Earlier this month Navin spoke at SugarCon on the open source delivery model. This month we’ve produced two open core releases; sorted through and selected speakers for DotNetNuke Connections; seen the final release of Blog 4.0.0; defined improvements to the installer user experience; made numerous improvements to localization; backported some PE features to CE; seen Form and List through 2 upgrades and XML through one also (thanks Stefan!); published (internally) a draft of a DNN User Experience Style Guide; moved the BC office from Abbotsford to Langley; hired a few new folks (I don’t even know them all); were honored in the OnDemand 100; initiated a module developer stakeholder group; and that barely scratches the surface!
April has seen a lot of activity and progress. There has also been a lot that has not been seen, but that I expect to have the privilege of sharing in May… with the flowers!
Cheers,
Scott
6 comment(s) so far...
Re: April Showers & May Flowers
Good news to see some PE features going into the CE version, I believe this should have been done in the first place. You might also check stuff like this oliverhine.com/DotNetNuke/Providers/CustomPermissionsProvider.aspx
By M Bouwman on
4/29/2010 8:37 AM
|
Re: April Showers & May Flowers
Scott
I confirm that 5.4.0 was shaping up to be a bad season, howvever after final testing of 5.4.1 today we have rolled this out to our production site. For our requirement 5.4.1 new install and upgrade flew through our testing with flying colours.
Fresh flowers to the teams and management involved in moving us from 5.4.0 to 5.4.1 in such a short time. I am very pleased with the results.
By Craig Hubbard on
4/29/2010 8:37 AM
|
Re: April Showers & May Flowers
@Craig ~ Your thanks are sincerely appreciated. And we intend to continue to earn them with EVERY future release ;-)
By Scott Willhite on
4/29/2010 8:39 AM
|
Re: April Showers & May Flowers
@M Bouman ~ There are a LOT of great extensions out there for DotNetNuke. Our ecosystem and the folks that participate in it is one of our greatest strengths! There's no way we can responsible for all the improvements in extensions that can or should be done, which is why we make it possible for others to create them as well. One thing we ARE doing (that it is still to early to discuss in detail) is working on ways to increase visibility of available extensions to users of the platform. Nobody should have to depend on us to package specific extensions for them to be discoverable, installable and gain traction in the marketplace.
By Scott Willhite on
4/29/2010 8:44 AM
|
Re: April Showers & May Flowers
Scott
One comment I would make which is difficult to understand the decision point, is in relation to the roll-out of the DNN provider version of RadEditor.
The out of the box experience is not a very good one, in that in comparison to the FCK provider which has a rich set of custom configurations the RadEditor provider does not compare and breaks a lot of our requirements that worked well in FCK.
It is also glaringly obvious that when using RadEditor in modules with multiple edit boxes (like FAQ) that it is next to impossible to edit due to the RadEditor overlapping other fields. previously with FCK we could apply custom configs to portal,module or instance. We also note that RadEditor does not allow relative paths, another important feature. While I could go on, my main issue is with the decision points that make these decisions in replacement components.
I have seen comments that promote the benefits of DNN deploying a smaller footprint installation because you will not need to deploy the huge FCK editor, however until such time as the RadEditor can provide the required features and is fully suited to DNN, I really think that this replacement can not be realised.
We have attempted to use the DNNRadEditor in an existing test environment which was based on an upgrade, however the content creation experience is poor. Rolling back to the FCK provider provides the best solution at this time.
In summary, early release decisions like this into main stream deployments is one area that I do not support from DNN.
Kind Regards
Craig
By Craig Hubbard on
5/30/2010 1:46 PM
|
Re: April Showers & May Flowers
@Craig ~ We appreciate your feedback. We continue to hear positive and constructive responses to the change and I am certain that the products team has improvements underway for the radEditor implementation. Thankfully, the provider model makes it quite easy to use the FCKEditor or any of the other 3rd party editor options including the new CKEditor as well.
By Scott Willhite on
5/30/2010 1:50 PM
|
|