In the 4.5.3 release, a new Search enhancement was introduced which caused a great deal of debate; both in the community and on the development team. Since there are so many factors related to this issue which are not immediately apparent, we decided it would be best to share some additional insight into the dilemma we face.
The enhancement added some extra functionality to the Search skin object which is used in the majority of skins available for DotNetNuke. Specifically, "Web" and "Site" options were added to the Search skin object, providing the search functionality which has become very popular in web sites in recent years. The functionality was added in an extensible manner which allows the "Web" search to leverage any search engine which exposes a public search URL. The default "Web" search is configured to use the Google search engine but an MSN example is also included in the resource file as well.
The ability to control the visual display of the new options is controlled by the standard DotNetNuke skin object attribute mechanism ( essentially you can modify the control declaration in the skin file to include custom values for its public properties - ie. <dnn:search id="dnnSearch" runat="server" showsite="False" showweb="False"></dnn:search> ).
So this all sounds useful, right?
Well the problem is that we enabled the new "Web" and "Site" options by default. As a result, this enhancement had the potential to affect the behavior of existing sites on upgrade ( which we always try to avoid ). Enabling the options by default was in fact an accident in the original 4.5.2 release, but it soon became apparent that simply disabling the options was not a complete solution to the problem. Now some people have already tried to create a big conspiracy theory out of this issue, but the fact is this Search scenario revealed a long-time architectural issue in the DotNetNuke skinning model. Let me explain...
In DotNetNuke, there are a set of skin objects which designers can use to provide an interface between their client-side skin files and the server-side portal engine. For example, we have Login, Register, Menu, and BreadCrumb skin objects which provide dynamic server-side functionality. Now, it is important that designers are able to control the visual display characteristics of these skin objects; therefore, we have robust model where attributes can be customized. The attributes are persisted in the skin file for a simple development and portability model. This all works great for display characteristics where the designer is the real authority on what works best in the skin.
However, skin objects also have customizable properties which control "functionality". In this case it is not necesarily the designer who should be making the decision on what portal functionality should be available. In fact, it is the portal administrator who should be able to specify the functionality they want in their site. So herein lies the problem. There is currently no way for an administrator to control this behavior unless they open the skin file and make their changes manually. Obviously this is far too technical for many administrators and somewhat defeats the purpose of using a content management system in the first place.
In the case of the Search skin object, it really should be up to the Administrator to specify if they want "Web" and "Site" search options. However, if we disable these options by default, there is no easy way for the Administrator to enable them ( as I just described in the previous paragraph ). The reality is that if these options are disabled, it renders the enhancement useless to 95% of the community - as A) existing skins are not aware of the new options and B) many of our users are not technical enough to enable them manually. However for those users who are upgrading and do not want the new functionality, the reciprocal problem exists as well. Dilemma. So given the current limitations, we need to decide which use case would be more common. Would more Administrators like to use the "Web" and "Site" options in their site, or would they prefer for these options to be disabled. In the past we have found that most people want to have "all" the application functionality available - without restrictions. So t this point we are leaning towards keeping them enabled.
So that explains the default settings, but does not solve another problem. Unfortunately, the addition of the new options in the Search skin object can sometimes affect the visual display of some skins. This is especially true where designers have been rigid in specifying the exact size of various objects in their skin. In the vast majority of cases where elastic designs are used, I have witnessed no impact on display. Regardless, we really do not want to impact anyone. As a result, Nik Kalyani has been experimenting with some client-side techniques which would preserve the real estate footprint of the object, while still enabling the new options.
So this has the potential to handle the visual display issue - but not ability for an Administrator to manage skin object functionality. As a result, the other day I decided to write an admin utility which provides this type of functionality. The idea is that the Administrator can choose a skin/container, a specific file, a skin object token, a setting for the skin object, specify a value, and hit Update to activate the new setting. I have a working prototype and we are considering including this as a new module in the Admin/Skins area of the application.
The cool part about this utility is that actually provides documentation for all skin object properties. Help text is displayed in the utility to help Administrators ( and Designers ) understand the purpose of the various settings. The utility also has the ability to generate the XML skin manifest file related to HTML skins - a task which has long been challenging for designers making the transition to DotNetNuke from static web sites.
The lesson in all this is that changes which appear simple on the surface, often reveal much deeper complications you had never considered. And when the changes affect many users, you need to be prepared to act swiftly to fix the problem, but not so quickly that you ignore the big picture.