Sep 28 2011

DotNetNuke Case Study at the St Louis DotNetNuke User Group meeting

Thank you to all who participated in the DotNetNuke case study presented this past Monday at the St. Louis DotNetNuke User Group meeting.

I wanted to include my slide deck for any of you who are interested as it contains a couple of items that were not mentioned in the meeting.  

I also wanted to answer a couple of questions that were not answered Monday.  Mainly in terms of the navigation.

  1. The primary navigation Mega Menu uses the AZ.DNNMenu.

  2. The primary navigation side menu for the sites within a site uses the RadMenu.

If you have any further questions, please leave a comment.

****** UPDATE (9/30/2011) ******

Due to time constraints, we were unable to cover all the challenges faced in building out the client’s new DotNetNuke site during Monday's User Group meeting.

I am happy to elaborate on the items that were not touched on, but would like to say that some of the challenges are more in line with feature requests. However, they are worth mentioning as they come from individuals who are utilizing DotNetNuke Pro in a real world environment on a daily basis.

Challenges & Solutions Continued...

Work flow

  • Work flow override for Administrators

    • Once work flow was implemented, we quickly realized that there was no way to override work flow, other than removing it completely. Essentially, when a site administrator wants to post content to the site, he or she is still bound by the constraints of work flow. This behavior is understandable, but a request was made for Administrators to be given the ability to override work flow in the case of a “content emergency.” Possibly a check box that only shows up for administrators that reads “override work flow.”

  • Work flow e-mail notification additional details

    • Work flow e-mail notifications lacked specific details in regards to what user was making updates to the site. Including the user name, date, and time of the update would make nice additions to the notification e-mail.

Page Caching

  • Turning on caching at the page level caused DotNetNuke to use Windows-1252 character encoding vs. utf-8 character encoding. This change in encoding created odd symbols/characters to appear within the content.

    SOLUTION: This issue was a known bug in previous versions of DotNetNuke and was addressed in version 5.6.3. 

.Net URL Character Limit

  • Due to the size of the site, we reached the maximum allowed characters for a URL string. The complete URL would not display in the browser URL bar.

    SOLUTION: Upgrading the .Net framework to .Net 4.0 allowed us to increase the maximum allowable characters.

External Links

  • The client required the ability to link to an external website via the Link Url page settings and have that link open in a new window. The user interface does not offer the functionality to have external links open in a new window at the page settings level.

I hope this helps clarify the last couple of items we missed.  Again, if you have any questions, please leave a comment.



Who is this?

Ian Robinson
Hey Joe,

I really enjoyed hearing about the challenges you faced during the presentation. Would you be able to elaborate on the ones we didn't get to cover in the presentation? I remember talking through anchor tags and permissions, but the details of your workflow challenges escape me, and I don't think we got to cover page caching, URL character limit, or external links at all.


Posted: · reply · 1 0 0
Hi Ian,

Thanks for the opportunity to present. I will be happy to speak more about the items that were not covered in Mondays meeting.

I will update this post with additional details.

Posted: · reply · 0 0 0
David O'Leary
Thanks for answering my Navigation question.
Posted: · reply · 0 0 0
My pleasure.
Posted: · reply · 0 0 0
ArchiveS ArchiveS