Blog » TechBubble

Skinning Portal Images in DNN with ImageSwap

Jul 042009

DotNetNuke has powerful skinning support, but skin designers are often frustrated by their inability to customize various images with static links in the portal. In this post, I’ll suggest a technique and some code to enable skinning of such images.

Let’s first understand the problem. Say you have a DNN site and you have created a custom skin. You have tweaked the CSS to perfection and everything looks great. That is, until the user switches to Edit mode. At that point, various icons used by the framework are displayed on the page. These include icons for help, action icons such as Save, Cancel and Delete. If you want to change these images, your only option is to replace them at their default location. Unfortunately, this is not a long-term solution. Firstly, the change will affect all portals on that instance of DNN. Secondly, the next time you upgrade, the images will be over-written.

An ideal solution would be for you to include the desired images with your skin and have the framework use your images instead of the default. In order to do this on the server-side, there would be several changes needed to the DNN Core. And even if these changes were made, chances are the result would not be very performant.

My solution, called ImageSwap, is to leverage jQuery to create a simple, but effective client-side solution to the problem. The solution is something like this:

Step 1: Select all IMG elements in the page whose “src” attribute has a value containing a known path (example: images/)

Step 2: Iterate through the selected elements, and for each element:

a) Check if a similar named image exists in a sub-folder of the current skin

b) If No, then do nothing

c) If Yes, then change the “src” attribute to the URL of the image in the skin folder

That’s it….in two simple steps we have a solution to skin portal images.

To implement this solution, you will need to add some code to your skin. I have provided the requisite code for DNN4/DNN5. I’ll embed this code into a DNN5 Widget and post it here soon to make it even easier to use.

Implementation of ImageSwap

Step 1: Decide which portal images you want to replace, then create a sub-folder in your skin folder with the replacement images. For example, you might create a sub-folder named “portal/images.” Take care to name the files exactly the same as the originals.

Step 2: Add the following HTML to each layout file in your skin:

&lt;script type=&quot;text/javascript&quot; src=&quot;http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js&quot;&gt;&lt;/script&gt;

Step 3: Embed the following script in your skin:


var searchPath = &quot;/images/&quot;;
var replacePath = &quot;&lt;%= SkinPath %&gt;portal/images/&quot;;
(function($)
{
 $(&quot;img[src*='&quot; + searchPath + &quot;']&quot;).each(

 function()
 {
 var frags = $(this).attr(&quot;src&quot;).split(&quot;/&quot;);
 var oldsrc = $(this).attr(&quot;src&quot;);
 $(this).error(
 function()
 {
 $(this).attr(&quot;src&quot;, oldsrc);
 });
 $(this).attr(&quot;src&quot;, replacePath + frags[frags.length-1]);
 }
 );

})(jQuery);

You will want to change the values for “replacePath” so it corresponds to the actual folder name you use in your skin for the replacement images. If you are using DNN5, you can delete the script reference for jQuery as it is automatically referenced by DNN as long as widgets are enabled (the default).

I have attached a ZIP file that contains an HTML file that demonstrates this approach. In the file, there are several color icons rendered using the IMG element. In another folder, I have grayscale images of all but two of the icons. When you display the page in your browser, you will see that all but two of the color icons are replaced with their grayscale versions, demonstrating how the ImageSwap script functions.

If you use the script, please leave a comment about your experience so I can improve the script and the ImageSwap widget that I will be creating for DNN5.

ImageSwap.zip (10.5 KiB)

DotNetNuke Professional Edition 5.1 – Content Approval

Blog, DotNetNuke No Responses »

Jun 302009

DotNetNuke Business Model and Product Roadmap (Part 2 of 2)

Blog, DotNetNuke 3 Responses »

Apr 202009

In my last post – DotNetNuke Business Model and Product Roadmap (Part 1 of 2) – I provided some insights into the DotNetNuke Corp. business model, specifically as it pertains to the similarities and differences between DotNetNuke Community and Professional Editions.

In this post I provide some background and insights into how we develop the DotNetNuke product roadmap and also share the roadmap for DotNetNuke 5.1 Community and Professional Editions.

There is no shortage of features that existing DotNetNuke users would like to see added to the product. No matter what feature we add, there will be some users who question the addition of that feature over another that may have more importance to them. The best thing we can do is to gather input from as many constituencies as possible, and then prioritize based on strategic objectives and time/resource constraints.

In order to determine the roadmap for DotNetNuke, we use the following sources:

Site forums
Site roadmap
Enhancement requests logged in Gemini
Feedback from site forms and surveys
Feedback from DotNetNuke team volunteers
Feedback from customers (of both editions)
Feedback from customer prospects
Feedback from ISV’s, consultants and designers in our ecosystem
Feedback from ISV’s and consultants not in our ecosystem
Feedback from conference and user group attendees
Analysis of competitive landscape
Industry, market and technology trends
Feedback from experts in Open Source, WCM and enterprise software
Feedback from investors
Experience and intuition

After aggregating the resulting feature requests, we divide them into Community and Professional features.

Community features are those that broad segments of DotNetNuke users would find beneficial and would use on a regular basis. We review how the feature will impact the product’s usability, accessibility, security, performance, scalability, etc. We also evaluate the time and cost of implementing the feature and its strategic importance. All these factors determine if the feature is added to the product roadmap for the Community Edition.

Professional features are those that advanced business users of DotNetNuke would find beneficial and would be willing to pay for. These features are often easy to spot as their use is typically associated with the existence of advanced infrastructure, large site membership, high-traffic or mission critical applications, advanced security requirements or complex business processes. Also, features that would result in significant time savings and improved productivity when managing large sites are candidates. We evaluate the time, cost and return on investment of implementing the feature and its strategic and competitive importance before adding it to the product roadmap for Professional Edition.

Since Professional Edition was first announced, we have often heard comments or concerns about neglecting or withholding features from Community Edition to “force people to buy Professional Edition.” Let me share some insights to help mitigate these concerns:

Continued growth in the adoption of Community Edition is essential to the survival of DotNetNuke Corp. Open Source companies cease to exist if they don’t have a thriving community. Communities don’t thrive around products that are stagnant and not evolving or innovating. We want DotNetNuke Corp. to be successful, and therefore, ensuring the continued success of Community Edition is a strategic imperative for us.
We can’t put every feature with value only into Community Edition, nor can we put every feature with value only into Professional Edition. There is a middle ground and finding it is not an exact science. We have to balance our desire to have Community Edition adoption grow, with our need to build a sustainable, profitable business so we can pay our bills and continue to fund the project. The feature selection process outlined above, while subjective, is rational and driven by our prior experience nurturing the growth of this ecosystem.
If you happen to be one of those people with the concerns outlined above, do consider the roadmap for DotNetNuke 5.1 Community and Professional Edition below objectively. I trust that after reviewing the roadmap you will not be as concerned.

DotNetNuke 5.1 Roadmap

Now that you have some background and perspective, let’s review the roadmap for DotNetNuke 5.1.

Starting with 5.1 we are embarking on a multi-release, phased improvement of the DotNetNuke User Experience from the ground-up. Our vision is to implement a high degree of consistency, usability and fluidity to the DotNetNuke user experience by employing a pattern-based UI approach. We have created mock-ups of many such patterns, and as you can imagine, the task of implementing them is large with significant enhancements to the Core Framework Libraries and Core Extensions.

Given the nature of user interfaces, they have high complexity or interdependency and therefore are at a high risk of taking longer than planned. (In the roadmap grid below, some UX features have a gray background to indicate their risk of being excluded from the release or adversely impacting the release schedule.)

Another feature we will deliver in 5.1 is the often-requested Content Approval feature. We view this feature as separate and different from Workflow, which may involve complex business rules and processes. Since most “content” in DotNetNuke is managed using the Text/HTML module, we will implement the approval features in this module. Professional Edition users who have more involved Content Approval requirements can continue to use the Text/HTML module or derive additional benefit from the HTML Pro module, a more advanced version of the Text/HTML module that will be included in the Professional Edition package.

Here’s the roadmap feature grid for DotNetNuke 5.1:

Feature	Comment	Community	Professional
Content Management	Content Approval - Single-stage content approval - Select content approver roles at the site level - Text/HTML module enhancement to support Content Approval	•	•
	Content Approval and Versioning - Multi-stage content approval - Define stages and select content approver roles at the site level - HTML Pro module to support multi-stage Content Approval		•
User Experience	Control Panel Improvements in usability and appearance through tabbed, ribbon user interface	•	•
	Advanced Control Panel Add a page or edit common page settings directly from the Control Panel		•
	Skin Objects Skin objects code will be XHTML compliant	•	•
	Action Panel Skin Object An Action Panel Skin Object to provide a consistent way for exposing available actions to users	•	•
	Management Console Improve access and discoverability of administrative features by aggregating features into a Windows-style control panel	•	•
Analytics & SEO	Google Analytics Support Support for injection of analytics tracking code on every page	•	•
	Google Analytics for Marketing Support Support for advanced Google Analytics segmentation based on role membership		•
	Per-page Custom Sitemap Rank Define the rank for each page for use in the Sitemap published to search engines.	•	•
Security	Change Audit Last modified and full history audit trails	•	•
	Extended Edit Permissions Page, module and folder level permissions that extend existing Edit permissions		•
Scalability	Distributed Caching Provider More efficient resource usage in large web farms		•
Stability	Application Integrity Checking Checks files in the installation and reports any inconsistencies which may impact website reliability		•
Network Services	Health Monitoring Pings the website periodically to identify failures and will notify the site owner. Also ensures the site stays in web server memory for faster user accessibility		•
	Vulnerability Database (Basic) Maintains a vulnerability database with basic information for each product version to easily identify potential issues	•	•
	Vulnerability Database (Detailed) Maintains a vulnerability database with detailed information for each product version to easily identify potential issues		•

Hopefully the information in this two-post series was helpful to you and answered more questions than it raised.

DotNetNuke Business Model and Product Roadmap (Part 1 of 2)

Blog, DotNetNuke No Responses »

Apr 202009

Development of DotNetNuke 5.1 Community and Professional Editions is progressing at full speed. It took us quite a bit of time to analyze dependencies, evaluate resource availability, determine viability and clearly define scope. As a result, until now, we did not publish a roadmap for DNN 5.1. The lack of published and authoritative roadmap details and a general misunderstanding about our business model has caused some confusion in the community.

In this, the first of a two-part series, I will make an attempt to clear this confusion and bring clarity on two topics:

1) Our business model: I’ll explain our business model and how it underscores our commitment to Community Edition and the overall DotNetNuke ecosystem. This is the subject of my first post.

2) Product roadmap: I’ll review the research, planning and decision-making process on how the roadmap for both Community and Professional Editions is determined. Then I’ll outline the release 5.1 roadmap for both Community and Professional Editions. This is the subject of my second post.

Our business model

DotNetNuke Corp. has an “Open Core” business model. In plain English this means that our free, community product and our paid, commercial product have a common, free, Open Source Core. This begs the question, what exactly is the DotNetNuke Core?

The DotNetNuke Core refers to the base combination of DotNetNuke framework libraries and extensions required to have an operational DotNetNuke website. Any additional extensions included in the distribution, even if they are not enabled by default, are also considered Core extensions.

The Core thus consists of the DotNetNuke framework libraries; all providers; all administrative modules; all control panels; the Text/HTML module; the default skin/containers; all skin objects; and all widgets included in the DotNetNuke distribution.

Both Community and Professional Editions share this identical DotNetNuke Core, which is why our business model is called “Open Core.” Given this context, it is worth emphasizing the implications of this business model:

The Core is and will remain free and Open Source. This is essential for the continued success of DotNetNuke.
Any enhancements made to the Core framework libraries are ALWAYS available to both Community and Professional Editions.
Any enhancements made to any Core extensions are ALWAYS available to both Community and Professional Editions

On the topic of Core enhancements, there have been some questions about whether any will be made in the future. The answer is an emphatic “Yes!” This is clearly evident by reviewing the DNN 5.1 roadmap. Also consider that since 2006, over 95% of the Core development has been done by employees or consultants paid for by DotNetNuke Corp. Given the investment we have already made and the fact that the Core forms the foundation for both our products, continuing to invest in improving and enhancing it is the best decision for the company and the community.

Now, let’s examine each of the editions to understand how they are similar and different purely from a software standpoint.

The DotNetNuke Community Edition package includes the DotNetNuke Core and DotNetNuke Community Extensions developed and maintained by one of the many volunteer-based DotNetNuke Project teams. The result is a complete solution that is suitable for many different scenarios.

The DotNetNuke Professional Edition package includes the DotNetNuke Core, DotNetNuke Community Extensions and DotNetNuke Professional Extensions. The result is a complete solution that is suitable for mission-critical business scenarios where the desired level of performance or functionality is not achievable using only the Core or Community Extensions. In such situations, the user can purchase the desired extensions from a third-party, develop them in-house or opt for the convenience of getting a single package – DotNetNuke Professional Edition.

Let’s address the questions this raises:

Q: Why is it necessary for DotNetNuke Corp. to bundle its extensions into a separate package instead of making them available separately for purchase like other extensions made by third-party vendors?

A: Our target customer is a business that is looking for a fully-integrated, supported solution and not a build-your-own package. By offering a packaged solution, we address this need. A good analogy is the automotive industry. Consumers do not have the time, skills or resources to assemble a safe and reliable car even though parts are available. They prefer to buy a fully assembled, tested vehicle that has a warranty and which they can start driving immediately.

Q: Does this mean that DotNetNuke Corp. will no longer enhance any of the Core Extensions?

A: That is certainly not the case. Since we have an Open Core business model, we absolutely must continue to enhance the Core Extensions as they are vital to the continued success of both DotNetNuke Community Edition and DotNetNuke Professional Edition. For example, our roadmap for this year includes significant enhancements to the user experience of Core Extensions the scope of which is greater than any prior effort to improve DotNetNuke’s usability.

Q: What types of extensions will DotNetNuke Corp. include with Professional Edition?

A: In general, we will include extensions that are clearly of interest to larger, more mission-critical business. The feature areas will include advanced security, performance, commerce and scalability.

Q: Can third-parties build extensions for Community Edition that provide similar functionality to DotNetNuke Professional Extensions?

A: Of course. Since the DotNetNuke Professional Extensions leverage the extensibility built-into the DotNetNuke Core that is common to both editions, third-parties have an equal opportunity to build similar (or better) extensions. This is no different than what many third-parties are doing today given the vast number of extensions — free and commercial — already available to DNN users.

Q: Will source code for DotNetNuke Professional Extensions be included with Professional Edition?

A: No. Source code will not be distributed; however, it will be held in escrow for Professional Edition customers.

Q: Will DotNetNuke Professional Extensions ever be available in Community Edition?

A: Yes. In some cases we may choose to migrate specific extensions from Professional Edition to
Community Edition.

Q: Will third parties be able to build functionality on top of DotNetNuke Professional Extensions?

A: Yes. However, at this time there is no extensibility provided in DotNetNuke Professional Extensions. This does not stop ISVs from building product versions which are targeted at Professional Edition customers.

To summarize:

DotNetNuke Corp. has an Open Core business model
The DotNetNuke Core will continue to be enhanced, benefitting both Community Edition and Professional Edition users
DotNetNuke Community Edition is applicable to most usage scenarios
DotNetNuke Professional Edition is applicable to larger, more mission critical business environments

Hopefully this post answered many of the community’s questions about the DotNetNuke Corp. business model, specifically as it pertains to the similarities and differences between DotNetNuke Community and Professional Editions.

In my next post – DotNetNuke Business Model and Product Roadmap (Part 2 of 2) – I will provide some background and insights into how we develop the DotNetNuke product roadmap and also share the roadmap for DotNetNuke 5.1 Community and Professional Editions.

Blog Platform Switch and Makeover

Blog, DotNetNuke No Responses »

Feb 022009

When I first started blogging in 2004, I had to decide which platform to use. There were some hosted blog sites available, but my rule of thumb #1 is that if it’s important to me, then I need to have full control over it and not be at the mercy of some other provider. I need to have unfettered access to make changes, enhancements and backups. At the time, the best .NET-based Open Source blogging platform I could find was DasBlog. I have used it since and it has served me very well. However, the more entrenched I got with the DotNetNuke project, the guiltier I felt due to rule of thumb #2 — eat your own dog food. I desperately wanted to switch my blog to DotNetNuke but faced three obstacles:

1) Migration: As far as I know, there was no simple way to import everything from DasBlog to the DNN Blog and maintain fidelity.

2) DNN Blog: While the DNN Blog software is good, it lacked a few key attributes that I personally felt very strongly about — excessive use of tables, inability to completely control the appearance using CSS and inability to control syndication URL’s. There were a few other minor issues, but these were the primary ones.

3) Time: Just did not have enough of it to make the switch.

Last year, I had been collaborating with Antonio Chagoury, the DNN Blog Project lead, and had started to make enhancements to the DNN Blog module. However, my work got really busy and I was unable to get these changes done. Meanwhile, the Blog project team continued to make progress and I found my code to be out of sync with the project code. So here I was with some working enhancements to the Blog module, but not able to easily integrate my changes back into the project.

Over the Christmas/New Year break, I made a decision that I would switch my blog to DNN within the month of January. Once I made this decision, things got easier as I work best under deadline pressure. Spending a few hours each week during the past month, I did the following:

Setup a DNN5 site for my blog
Locally reconciled my changes of the Blog module with the code that was in the repository
Wrote a small script to import from DasBlog to the DNN Blog
Implemented many enhancements to the DNN Blog
Created a custom skin for my blog which uses some of the new widgets I created for DNN
Fully ported my blog to the DNN platform

The first three were simple and did not take much time at all. I spent quite a bit of time on the remaining three. Here are the details:

Blog Enhancements: I made the following enhancements:

Templating – Used the DNN token replacement engine to create template support for Header, Item List, Item Detail and Item Print. All templates support the standard DNN tokens and some custom ones. For the Header template, the permissible tokens are (using { } in place of [ ] to prevent replacement in this post):

{BLOG:TITLE}
{BLOG:OWNER}
{BLOG:DATE-CREATED}
{BLOG:DESCRIPTION}
{BLOG:RSS-URL}
{BLOG:RSS-IMAGE-URL}

For all other templates, the tokens permissible tokens are (using { } in place of [ ] to prevent replacement in this post):

{BLOGITEM:TITLE}
{BLOGITEM:AUTHOR}
{BLOGITEM:BYLINE}
{BLOGITEM:BYLINE-DATE}
{BLOGITEM:DATE-PUBLISHED}
{BLOGITEM:MONTH-PUBLISHED}
{BLOGITEM:DAY-PUBLISHED}
{BLOGITEM:URL}
{BLOGITEM:PRINT-URL}
{BLOGITEM:BLOG-TITLE}
{BLOGITEM:BLOG-URL}
{BLOGITEM:BLOG-CATEGORY-TITLE}
{BLOGITEM:BLOG-CATEGORY-URL}
{BLOGITEM:BLOG-RSS-URL}
{BLOGITEM:BREADCRUMB-HYPERLINK}
{BLOGITEM:TRACKBACK-URL}
{BLOGITEM:RSS-IMAGE-URL}
{BLOGITEM:SEARCH-RANK}
{BLOGITEM:EDIT-URL}
{BLOGITEM:EDIT-HYPERLINK}
{BLOGITEM:COMMENTS-HYPERLINK}
{BLOGITEM:COMMENTS-URL}
{BLOGITEM:COMMENTS-COUNT}
{BLOGITEM:MORE-HYPERLINK}
{BLOGITEM:TAGS}
{BLOGITEM:SUMMARY}
{BLOGITEM:CONTENT}

These tokens make it possible to format the blog list and detail views to be customized precisely with nothing extraneous. I thought about adding a template for RSS, but decided against it to keep things simple. I did however modify the RSS template to always show full content as RSS feeds that show only summaries are a pet peeve of mine (I will not subscribe to any blog that does not post full content in the feed).

CSS-enablement — Everyplace that I found an HTML table, I removed it and replaced it with the equivalent DIV+CSS code and enabled simple URL actions instead of Javascript-driven postbacks. This reduced the HTML footprint considerably.

Archive – I added entry counts to each month in the Archive list. I also added the ability to turn off the calendar mostly because from a user experience standpoint, it is not much use. Between the Archive list and search, the bases are covered.

Tagging — We are currently working on core-provided tagging support, but I wanted to have some quick tagging support and display a tag cloud. My solution — I created a setting whereby you can specify an HTML element that indicates a word or phrase that should be a tag. The default element I picked is “cite”. Using the standard HTML editor, I can simply highlight words and apply “cite” to them. The tags are not stored anywhere separately. When a post is rendered, the tags are extracted with a regular expression and Technorati microformat tag links are automatically created. The same code is used to create a composite tag cloud using jQuery. Since tags don’t change too often, with caching this is a simple solution that can be upgraded to the core tagging engine when it is available with minimal effort since there is no data to worry about.

Tab Targeting — I wanted to display my blog listing on one or more pages, but always wanted to direct the user to a single blog page for details. The solution I implemented for this is a setting called LinkTargetTab. In the blog’s settings, you can choose the page where all links should go. I can thus have a listing on the Home page of my blog site, but have the detail and editing occur on the Blog page.

Syndication — I implemented a setting that allows you to specify the Base Syndication Url such as http://feeds2.feedburner.com. All syndication links are then automatically created by appending the name of the blog/child blog to the base URL as appropriate.

Comments — I wanted to use Disqus for comments on my blog. Since the module’s comments can easily be turned off, adding Disqus was a simple matter of adding the embed code to the Item Detail template. (The same applies for Sharing…I just added the code for ShareThis to the template.)

I implemented a few other minor enhancements, but the above list constitutes a bulk of them. At the time of this writing, the blog I am using has these enhancements. There are probably a few rough edges, but overall, things seem to work. Now that I am here, I’ll get this code over to Antonio and the Blog team so they can decide if any of it is desirable for the Blog Project. (I will not post these enhancements for general download as I think the Blog Project team is best equipped to review the code and determine if the changes should be merged. Also, I do not want to be in a position of supporting the code.)

Custom Skin: I modified the appearance of the standard DNN skin slightly to meet my branding choices. I did make a bunch of changes under the hood that make it very different structurally from the default DNN skin. These changes are –

CSS Layout — I used the built-in DNN super-stylesheets to create a table-less CSS layout.

Mobile-optimized — I used the new DNN5 RelocationWidget to optimize the skin for search-engines and mobile devices. The entire header and menu block actually appears at the end of the page, but is visually made to appear at the top using the RelocationWidget. Mobile devices should also see a simpler menu system.

TechBubble Blog: Now that my blog is fully ported to DNN, I am very excited to be able to create and share sample code with working examples right here on the site. For instance, I am using the DNN EmbedWidget on the Photo page to display my Flickr photo stream (not much to look at yet).

Overall, the time and effort it took to get here was well worth it. I am VERY happy to be using DotNetNuke for my blog.

Older Entries Newer Entries

TechBubble

Skinning Portal Images in DNN with ImageSwap

DotNetNuke Professional Edition 5.1 – Content Approval

DotNetNuke Business Model and Product Roadmap (Part 2 of 2)

DotNetNuke Business Model and Product Roadmap (Part 1 of 2)

Blog Platform Switch and Makeover

Categories

Archives