By yoooee on
5/7/2012 7:15 AM
I've been using DotNetNuke for about five years now and am very impressed with the overall quality of the product. There have been a number of changes made to the software during that time and some of these changes have introduced major improvements to the usability and functionality of DotNetNuke. However, there is one particular area that I feel could use a little extra attention and that is the DotNetNuke Recycle Bin.
If you've administered your own DotNetNuke site or a DotNetNuke site for a client, you've probably found yourself face to face with the Recycle Bin. At first glance, it appears to be quite innocent and straight forward.
- Find the page or module that you need to restore.
- Select that page or module.
- Click the Restore button.
The above steps will result in the selected item being restored to your site. However, what if the recycle bin contains 200 - 300 modules? What if 60 of these modules were not given titles? You would find that you have a needle in a haystack scenario on your hands. If there were a way to sort these items your task would become much easier. Perhaps you could sort by the date deleted or by the user who deleted the page or module. Being able to preview the page or module before choosing to restore it back to the website would also be a helpful feature. These enhancements are just a few of the ideas I've had for improving the DotNetNuke recycle bin.
I propose adding sortable columns of additional data to the Page/Module list in the Recycle Bin to greatly reduce the time necessary to find and restore the correct item(s). The administrator would be able to sort the list by Page Name, Module Type, Module Title/Name, Date Created, Date Deleted, or even by the DotNetNuke user who deleted the item. The administrator could also preview the page or module before restoring it to the website to ensure the correct item is selected.
Old Recycle Bin vs. New Recycle Bin
click to view larger
New Recycle Bin Module Preview Feature
click to view larger
If you think these changes would improve DotNetNuke and you would like to see them included in a new release, head over to support.dotnetnuke.com and vote for this enhancement request. If you have additional ideas, I would enjoy hearing from you in the comments.
By yoooee on
9/28/2011 7:19 AM
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.
- The primary navigation Mega Menu uses the AZ.DNNMenu.
- 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 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.
- 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.
- 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.
By yoooee on
3/19/2011 12:14 PM
For the past two or three months, I have had the distinct privilege of working in depth with the DotNetNuke Professional edition. Most notably with the extended permissions and advanced work flow options. The combination of these two very powerful pieces of functionality gives the end user almost limitless options in how he or she wishes to configure his or her website.
The site that I have been working on for the past few months is utilizing DotNetNuke to its full capacity. The complex and intricate permission grid and work flow system they have in place is amazing, but there have certainly been a few bumps and surprises getting it all in set up.
Most notably, we have created for ourselves an issue in regards to the ability to edit of module titles. The particular needs of this client dictate that “website editors” have access to update module content and module titles, but only through a specific work flow. Obviously, we did not want to give these users the ability to manage module settings as that would allow them to change/bypass the work flow in place. We quickly discovered that when we revoked rights to module settings that we also revoked the ability to change the modules title. We thought that enabling the inline editors available in (Admin > Site Settings | Advanced Settings | Usability Settings | ) would allow for module title updates, but it would appear that even the inline editors are bound by the module settings permissions. The inline editors for content work as expected, but module titles are not editable. Thus we now have a scenario where our website editors can add modules, delete modules, and edit the content of said modules, but not edit the modules title.
I'm not sure if this is by design or just an issue that found its way into the permissions/work flow schema unintentionally, but it seems to be an issue.
If anyone else has experienced this type of issue or knows something I'm missing, I would really like to hear from you.
By yoooee on
10/7/2010 3:57 PM
If you're an HTML purist and would like the DotNetNuke Rad Editor to use paragraph tags
instead of the default break tag every time you hit the Enter key on your keyboard then following these simple steps:
- Download the ConfigDefault.xml file from the following location: /Providers/HtmlEditorProviders/Telerik/Config
- Find the following line of code
and change it to read
- Congratulations! That's it! Any module that uses the Telerik Rad Editor will now use paragraph tags instead of break tags.
By yoooee on
10/4/2010 2:25 PM
If you've used DotNetNuke for any length of time, I'm sure you've discovered the quick edit pencil icon and the Modules Action drop down menu as ways to edit your content. I'm also sure that you've noticed these two features "fight" for the same space on the page, which can become somewhat annoying.
There are two different paths you can take to adjust this overlap issue.
Method 1: Remove the ability to use the quick edit pencil icons.
Navigate to Admin - Site Settings - Advanced Settings - Usability Settings
- Uncheck the box labeled "Inline Editor Enabled?"
- Click Update.
- Congratulations, the pencil icons will no longer be displayed on your site.
Method 2: Adjust the CSS for the quick edit pencil icon.
- Using your favorite FTP program, download the portal.css file located in the following folder:
- Add the following CSS code to your portal.css file.
- Save and upload the file back to its original location.
- Congratulations, the pencil icons will now display 15 pixels to the right of Modules Action drop down arrow.
Hopefully this helps you and/or your clients as you work with your various instances of DotNetNuke on a daily basis.