Christopher Paterra

Updating Your Forge Extensions for the Extension Gallery

thecrispy1@gmail.com — Tue, 12 Jul 2011 05:00:00 GMT

One of the new major additions in DotNetNuke 6.0 is the Extension Gallery. If you read this blog post from Joe, you may already be familiar with this feature. If not, the DotNetNuke Extension Gallery is an integrated section in the Extensions module (under Host –> Extensions in the navigation menu). This interface permits the searching, as well as the downloading and deployment of third party extensions made available from Snowcovered as well as the DotNetNuke Extension Forge (FYI: This has not been a working piece in any of the CTP’s or Betas to date but will be available in the final release).

If you are a Snowcovered vendor, you should have already received some instructions (via email) for updating your products. If you are a Forge extension developer, the remainder of this blog will show you how to update your project to make it eligible for the Extension Feed. Please note here that only modules and skins will be eligible in the initial 6.0 release.

Editing Your Forge Project

If you navigate to the Extension Forge page, and you are logged in, you will be able to reach any of your projects by selecting the “My Projects” link in the upper right hand corner of the module. When clicked, this will take you to a list that displays all projects you are associated with in the Extension Forge. Once on this view, find a project you would like to make available and click on it to navigate to the project’s home page (in the Forge).

Once you are on the project’s home page, click the “Edit Project” link as shown in the first screenshot below, clicking it will navigate you to the “Edit Project” page as shown in the second screenshot below (where you should select the “DotNetNuke” tab).

Forge Project Home

Forge Edit Project

Now, before you edit anything it is important to understand what these fields are. As a DotNetNuke extension developer, you should be familiar with the .dnn manifest file. If not, I have provided a sample from my Tag Cloud module (the same project I am using throughout this blog for demo purposes) shown in the screenshot below. For now, focus on line 3 in the screenshot and notice how it sets the package name, type and version. The package name here is what you want to set for Package name in the “Forge Edit Project” screenshot. You also want to set the type in the drop down to what is set here. As for version, we’ll get to that in a minute. Once you have made the updates (to the project and saved them), you are now ready to edit the individual releases.

Sample Manifest (Beginning)

Edit A Forge Release

To edit a Forge release, you simply need to select the “Version Details” tab and click “Edit Release” (as shown in the first screenshot below), which will navigate you to the “Edit Release” screen which is shown in the second screenshot below (the “DotNetNuke” tab will be selected for you). FYI: If you want to change the release you are editing, simply select a different one from the drop down list.

Editing a Forge Release

Edit Forge Release Screen

Once on this screen, you only have 3 possible fields to edit (and the last one, .NET version is basically ignored). The first one, extension version, is the version taken from your .dnn manifest file (in this case, it is 01.00.01). Please note, this must always be in a ##.##.## format (It’s also worth noting that many release the version as the name, too, but that is managed at CodePlex thus we require it as a separate entry here). The next part, minimum core version, is a very important field for compatibility reasons (of course). As you can see, this is a drop down list. It will list all stable core versions available for you to choose from (this is also available in the .dnn manifest, line 15 from my screenshot above).

You must repeat the above step for all stable releases, if you wish for them to be eligible for inclusion in the Extension Gallery. Also note that ‘stable’ is a requirement (which is set @ CodePlex per release) in order for it to be considered. If you have any questions, please use the Forge Forum.

More ...

Category: Development

Category: Extension Forge

Telerik Controls in DotNetNuke 6.0

thecrispy1@gmail.com — Mon, 11 Jul 2011 05:00:00 GMT

Last week Beta 2 of 6.0 was released, as many of you already know, and my colleague Joe Brinkman took the time to highlight a few of the lesser known features/enhancements introduced in 6.0 as well of some of the updates we made based on feedback from previous CTP’s and Betas. Since reading his blog, I have been reminded of another feature/enhancement that has been overlooked thus far: Telerik wrappers. Before diving into what exactly was added for developers to take advantage of, it might be good to provide some history related to the controls as well as our usage in the updated user interface for 6.0.

Category: Development

Category: Extension Forge

Modal Popups in DotNetNuke 6.0 Extensions

thecrispy1@gmail.com — Mon, 04 Jul 2011 22:39:02 GMT

If you played with any of the DotNetNuke CTP’s or the Beta, you are sure to have seen this new feature. When you first attempted to login (on a new install), you saw the popup with the username and password area loaded inside. Once you were logged in and navigated around, you also saw various screens throughout the user interface also using this modal popup. In this blog, I am going to explain how module developers can incorporate it in their custom extensions as well as touch on some of the basics related to the modal popups.

In a previous blog, I discussed Updating the Contest Module for 6.0, where I highlighted a couple bits related to the user interface for module developers. If you have not read that yet, you may wish to do so before continuing on since I will be using the same Contest module (post those changes) in this example too. You may also want to review this blog post where Vince introduces the module branding feature. The reason I suggest that is because I implemented it in the Contest module (if you are following along) and it is the only other change related to the DotNetNuke manifest in 6.0. Do keep in mind that developers who want to take advantage of both features but still support DotNetNuke 5 using a single install package can do so by using the new .dnn6 manifest file.

Before diving into the manifest change (which is really quite simple), there are a few things that should probably be discussed about how the modal popups are implemented in DotNetNuke.

Styling

The modal popups are implemented using the jQuery UI dialog. By default, there is a section in default.css that contains all classes to style this (and other jQuery UI widgets we use) where we basically apply a default theme via CSS. Placement in the default.css allows skin designers to override this in their own skins via skin.css, yet older skins that were not designed for 6.0 will also have the dialog styled so it doesn’t look broken (it may not fit 100% with the site design, though).

One other note related to the style of the modal is: based on testing and provided feedback from the Beta, module developers can also apply their own (or published) jQuery UI themes in their modules. What this means is there will be the default styling (which a designer can override via skin.css), but jQuery UI widgets exposed in custom modules can be themed as they were before 6.0 (and our style in default.css will not interfere with them).

Enabling & Disabling

Modal Popups are enabled/disabled in two different places. One is the module control itself (which is controlled by module developers, but super users could alter if so desired) and the other is per portal (controlled by site administrators). When a site administrator disables popups from the Admin –> Site Settings menu (in the screenshot below) no modal popups will be invoked throughout the entire portal regardless of what is set at the module control level.

By default, new installs will have this setting enabled (thus, enabled per portal). As for the module control level, that depends. Admin and host modules that ship with DotNetNuke as well as PE and EE edition modules will have this enabled (if applicable). Third party modules (modules from the Forge, Snowcovered vendors, modules that haven’t been updated from 5.x, etc.) will have all of their module controls disabled by default (I believe this happened post the public Beta, based on submitted feedback).

Manifest Update: supportsPopUps

Finally, we are at the point where you can see how easy it is to enable this in your own extensions. To do so, simply edit your module’s .dnn manifest (the .dnn6 manifest in some cases) and add the supportsPopUps node for each module control and set its value to “True” (of course, you can set it to False too if you need to). You can view the differences based on the Contest module here. Please note, I updated the module version number, the core version dependency, as well adding the supportsPopUps node multiple times.

Thus far, we have only covered the basics related to modal popups in DotNetNuke but we had to start somewhere. Topics related to the ways to customize this experience, invoking without module actions, and more are things that will need to be covered another day.

More ...

The .dnn6 Extension Manifest File

thecrispy1@gmail.com — Thu, 30 Jun 2011 07:04:41 GMT

When CTP 2 was released for 6, Joe dedicated a brief section to Module Branding in his blog post. This enhancement allows module developers to associate an image with their extension product. However, to take advantage of this addition, extension developers would normally have to create two separate releases: one to use for DotNetNuke 5.x, and another for DotNetNuke 6.x (even if there were no other changes) This was the only option outside of the developer moving their development to DotNetNuke 6 or greater only. Luckily, we added a last minute addition to avoid this potential hurdle.

If you are a DotNetNuke extension developer, you are probably familiar with the .dnn manifest file. If your not familiar w/ the .dnn manifest file, it basically tells DotNetNuke how to install an extension as part of the (module, skin, menu, etc.) installation process (You can review technical details about manifests via our Wiki).

As of DotNetNuke 6, we will support both a .dnn manifest file (what is normally used) as well as a .dnn6 manifest file. In installs prior to DotNetNuke 6 (RC or public release), this .dnn6 file will simply be ignored. In DotNetNuke 6 (RC or public release), this manifest file will be read instead of the standard .dnn manifest file (thus allowing you to include both in a single installation package). Please keep in mind, outside of the new additions the same rules apply to the .dnn6 manifest as they do for the .dnn manifest file (they really are the same thing).

A couple reasons that may make it worth your time to create a .dnn6 manifest:

Module Branding Support
More Control Over Popups in a Module (when enabled)
And More…

One last thing that I think is important to note is that if your module is only going to support DotNetNuke 6 or greater (for whatever reason), there really is no reason to create a .dnn6 specific extension manifest, simply use the .dnn manifest as you would have in the past.

More ...

Category: Development

Category: Extension Forge

Updating the Contest Module for 6.0

thecrispy1@gmail.com — Tue, 07 Jun 2011 05:00:00 GMT

The past couple of months I have spent a decent amount of time working on DotNetNuke 6.0. To be a little more specific, I (and several others) have been focusing on updating the user interface. If you have seen CTP 3, or read Joe’s blog post, you have already been introduced to some of the user interface changes we have going on. Although it may not seem like it, there was a lot of work and planning that went into overhauling the user interface in 6.0.

Category: Reference

Category: User Experience

The Forge Tour: Searching for Extensions

thecrispy1@gmail.com — Sat, 16 Apr 2011 21:14:00 GMT

In case you missed the announcement made earlier this week and you have yet to see it on the site, the DotNetNuke Extension Forge was recently rewritten and made available to the community on the www.dotnetnuke.com website. In order to help acquaint users with the recent updates to the Extension Forge, I decided to start “The Forge Tour” blog series. This post is part 1 in a multi-part series and will focus on the process of searching the Extension Forge to find the extensions you are looking for.

Getting to the Results Page

When you first land on the Forge page multiple search options (browse by type, browse by tag, and ‘search projects’) are displayed as well as information related to Forge statistics, a featured extension project and you are also presented with a list of the five latest projects to have a release. From this page, you can reach the search page in one of the follow ways:

Clicking the “View More Releases” link at the bottom of the module – sample
Clicking a “Type” such as '”Module” – sample
Typing a word (or phrase) into the search text box and clicking “Go” – sample
Clicking on a “Tag” such as “Razor” – sample

In addition to what was just listed, you can generally reach the search page in other areas of the Forge module by clicking the “Search” navigation link in the upper right hand corner of the module. Depending on how you reach the search page (as well as what you are actually searching on) you are going to see one of two possible views. Both views work (and almost look) exactly the same, the primary difference is what ‘filters’ are applied and what, if any, results are displayed to you.

For example, clicking the ‘Search’ navigation link at the top of the module will show you the screen below (note: link not available on initial forge home page). You should note that the “Browse by Type” and “Browse by Tag” look identical to the home page of the module. You should also notice that the search box shifted to the upper right and that this link will always take you to the search page with no filters applied and you should never see any results when first hitting the page (from this link).

If you reached the search page by clicking the “View More Releases” link, it will look very similar to the last screen shot except you will now see a list of search results (which are every project in the forge that is authorized and they are ordered by the most recent release date with the project with the newest release at the top).

Searching with Filters

As previously stated, you can reach the search page in a number of ways. Clicking any ‘tag’ or ‘type’ in addition to searching for a word or phrase will take you to the search results page. In this scenario, unlike the others discussed before, you will now see an “Applied Filters” section. A screenshot with two applied filters is shown below (a tag and a content filter are applied).

Currently, the Forge supports up to three filters (tag, type, content) and only one search parameter can be applied per filter at this time (in other words, you can apply 1 tag but not 2). While I think tags and types are pretty self explanatory, I feel I should clarify that the ‘content’ filter is whatever a user typed into the search textbox. On the backend, the ‘content’ filter searches against a project’s name as well as the content in its description.

As you apply filters, you should notice that the tags displayed are changed along with the project results that are displayed. Basically, a search is done against all tags used throughout the module and its results are displayed (via the tag cloud) in addition to a search being done against all forge releases which has its own result set displayed (via the grid). Technically, the same search is going on in the background we are just getting two different result types (tags vs. projects).

As you mix and match different filter combinations, you will likely find a combination that returns no results. To make the process of getting back to your previous search easier, the applied filters section allows you to remove each filter one by one. Removing a filter will re-run the search with all other filters applied besides the one you just removed. It will also reset any sorting and paging applied previously.

As long as results are returned in a search, the user can sort those results by “Name”, “Downloads” count, or “Date Released” (for now). An important thing to understand here is that any project that does not have a downloadable (and therefore installable release) has “No Release” displayed and it will have the minimum date applied (for sorting purposes). You may also want to make note that sorting or paging will never change the URL nor will they change the filters applied.

In the future, we plan to enhance the search process as more data becomes available to us and we add features but in the meantime I feel its pretty easy to use. I hope all of you find it easy to use as well but if you have any questions related to the module please post them in the Using the Forge forum which I monitor.

More ...

Category: Community

Category: Development

Retirement of the Core Forum Module: My Take

thecrispy1@gmail.com — Thu, 24 Feb 2011 20:11:00 GMT

If you haven’t heard (or read the details), Active Modules Inc. has been acquired by DotNetNuke Corporation. Since the announcement, there has been a great deal of discussion going on throughout the community. While these discussions cover many different topics and view points, I noticed several people asking about the core forum module team and how they feel. Because of this I figured it was best, as the primary developer of the module since 2004, to respond here.

First, I want to state (in case some of you are unaware) that I am a DotNetNuke employee. However, the response here is my own personal opinion as a long time community member and core forum module developer (not as an employee). Now, on to the fun!

As per the announcement, Active Forums will become open source and it will replace the core forum module in the DotNetNuke product and on the website. In my opinion, this was a no brainer. To help others understand why I came to this conclusion, I think it might be worthwhile to revisit some of the module’s history.

The core forum module was the first module released as a separate module project for DotNetNuke as an ‘official’ core module. I remember this sparked much debate at the time about how it would impact the commercial option, Active Forums. Well, despite all the concerns, Active Forums was still a Snowcovered top seller for a long time and was accepted as the premier forum module by the DotNetNuke community. The reason why? It was the better product.

I have always stated that Active Forums is a better product. It offered support, had a dedicated team and ultimately had funded development (through the sale of the product). As a volunteer who had a day job (which wasn’t DNN Corporation for the majority of this time), I could not put the time in required to change that. Sure, I feel the core forum module is a much better module today compared to the initial 2005 release and I think the gap between the two modules has decreased significantly. However, while we were bridging the stability/feature gap, Active Modules went another direction and introduced Active Social and integrated it with Active Forums.

So here we are again, another significant feature gap the core forum module has to overcome. At this point (around the time active social and active forums were integrated & released), I felt like I was living the infamous scene from Godfather III. It was also about this same time period that I was having less and less free time to dedicate to the core forum module project. This basically meant that the core forum module would not be adding features to compete with the Active Social integration, due to my lack of availability. It is also worth mentioning, at the time, we had no requirements for doing the ‘social’ thing in our forums on dnn.com which meant I had little reason to match the Active additions.

Fast forward to modern day. Internally (@ DNN Corp) a few of us start discussing the acquisition possibility and the impact this would have on the core forum module. Besides what I have already covered, a few other key questions/concerns I (and I am sure many others) had were:

Will there be a free & open source forum available?
Will there be a migration path?
Will features of one (the core) be added to the other (Active)?

Once those questions were addressed (and the answer was yes), the only other questions I had left were regarding what was best for the product and the community overall (in reference to the forum module ONLY). Based on the history and the answer to the 3 question I had, I felt that going with Active was the best choice. Why, you ask?

Continuing both products is a waste of resources, we had to choose one.
Active has historically been viewed by myself, and most others, as the better of the two modules.
Active has a better User Interface and theme customization options.
Active already has the social integration with Active Social.

It is much easier to add a few missing features to Active Forums than to add all the other things to the core module.
Active had a better handle on community forum requirements (meaning, they had customers driving requirements. I had dnn.com as my only ‘client’, with a few suggestions here and there from community members).

I could keep adding to this list, but I think you get the point. So, to try and wrap this lengthy post up, I think the best way to summarize my feelings about the retirement of the core forum module is one word; excited. Not only will the community get access to the better of the two modules (free and open source), but the actual Active Forum product itself will be enhanced thus making it even better.

More ...

Category: Extension Forge

Category: Community

Introducing the DotNetNuke Rad Tag Cloud

thecrispy1@gmail.com — Fri, 17 Dec 2010 21:42:17 GMT

A few weeks ago I came across a project in the DotNetNuke Forge which caught my attention, the Page Management module. After playing around with it locally I found that I really liked several things about it: Easy to use, looks good, little usage (if any) of post backs (it’s a great little module overall, I am just focusing on the items that caught my attention at the time). These few points I noted are an area I feel many modules (including my own) really need to focus on. About the same time I came across this module I also realized I have a need for a way to display tags on a DotNetNuke site. Back in 5.4 we added tagging to the DotNetNuke core and with the recent forum 5.0 release, I implemented it in the module. This is all fine and great, however, there was no way to display tags applied except at the content item level (ie. a forum thread). What if you want to display all tags used on a page or all tags used across a site? In this case, you have to use a third party module. At this point, I searched through our Forge and found one module that would meet most of my needs but not quite everything. Because of this need (for a tag cloud) and for my desire to show that module administration can be an easy process, I decided to create the DotNetNuke Rad Tag Cloud module.

Recently, Telerik added a new control to their collection: Rad Tag Cloud. As of DotNetNuke 5.6, DotNetNuke core shipped with a version of Telerik that included this control. Therefore, this module requires DotNetNuke 5.6. By utilizing this control, I pretty much had the primary view of my module complete and I simply had to focus on settings and populating the cloud with data. FYI, clicking any tag will take you to a search results page available in DotNetNuke installs that will show all items that have that tag applied and the module is completely localized. Before diving into setup, lets take a look at how the module looks when populated with data for most users:

Setup

Once you have the module installed, place it on a page in your portal. After placement on the page, if the module shows no results then you have no tags in your portal yet (check out the core forum module for something that exposes tagging). Otherwise, you should be getting results. Once you have some tag results displayed (you can go over to Admin –> Taxonomy as host and add terms to the Tags vocabulary), you can now tweak the module settings. Technically, you can tweak it without having tags but what is the point?

After navigating to the module settings screen, and scrolling to the bottom, you can see the module contains 3 tabs of settings. The first section is for general settings. From here, you can control the content filter (which allows you to display all site tags, all page tags or tags used in a specific module type). You can also control the way the results are sorted from this tab too. If at any point you are unsure of what a specific field does, simply scroll over the blue information button and a friendly help tooltip will be displayed with full details. Each tab has its own help tooltip specific to the view but all views access this tooltip the same way (as shown below).

Under the Appearance tab, you have settings that control the look and feel of the tag cloud. As you change the settings, the sample tag cloud will be updated in real-time (except for the applied skin, which requires an update. You can also see a demo of the 14 predefined skins). Besides the applied skin, you can also set the width of the tag cloud, toggling of match count display (on/off), Minimum number of match count results to display (ie. tag applied 3 times or greater to be displayed if set to 3) and the maximum results to display in the cloud. A sample of this tab can be seen below.

The final tab is the Advanced tab. Most items here do not need to be changed unless you want to tweak various CSS related elements of the tag cloud. I will spare you the details of what each one does but if you need help full details are available in the module. A screenshot of this tab can be seen below.

Well, that is all there is to the module. It’s not much but I think the two goals I set out to achieve have been met: A way to display tags used on a DotNetNuke page and show that module administration doesn’t have to be so boring!

If you are interested in using the module, you can download it from CodePlex. If you would like to demo the module, you can do so here. Please note that people who intend to develop the module either need a valid Telerik developers license or a DotNetNuke Professional license (which includes the Telerik license).

More ...

Category: Extension Forge

Category: Development

Hackathon Voting Open & My Seattle Trip

thecrispy1@gmail.com — Wed, 15 Dec 2010 17:46:05 GMT

As many of you may know already, we had a Hackathon in Seattle last week focused on Microsoft Razor (check the link for full details) which was held in Seattle. After one week of time (and lots of effort from the participants) we now have all entries posted and voting is underway until December 17th at 12:00 AM EST. Like all Hackathons, all submissions are available in our Forge for download. After spending time reviewing all the entries and working on my own (more on that in a minute), I think we had some pretty cool entries submitted. So, because there is only a brief period of time for voting, I encourage you to vote now (FYI: You also get community recognition points if you vote!).

As for my entry, I didn’t find this as visually appealing as many of the others (way to talk everyone out of voting for me!). I did, however, find it a useful exercise to see a great way to utilize the DotNetNuke Razor Host module. For my entry I worked on displaying core Forum information on a user’s core profile page. Having attended the live event, I was able to get a solid understand from Andrew and Charles Nurse (who both presented at the event) on how to utilize Razor in DotNetNuke. If you didn’t attend the event, however, you can watch a video of Charles’ presentation here. Loaded with that knowledge and being rather familiar with the DotNetNuke API (and core forum module), I was able to create my entry in roughly 2-3 hours. For those who may not be familiar with DotNetNuke module development, I think that is pretty quick. This quickness (and the fact that you don’t always need a full blown module) is one of the reasons Razor can really have an impact on our community and seems like a no brainer for some simple module needs. Below, I have included a screenshot of my entry which can also be viewed here.

Besides the Hackathon event last week in Seattle, I also spent the remainder of the week with Scott Willhite discussing all things community for DotNetNuke (before we traveled to San Francisco on Friday). One thing we really got to focus on during our time together was our integration with CodePlex via the Extension Forge. During the week we had a meeting with Jonathan Wanagel and a couple others from the CodePlex team where we discussed multiple things that can really help our Extension Forge grow in 2011, so look out for changes in that area early 2011. While we discussed many other things, like additions to the community recognition system, I think this will have the biggest impact next year so I am excited to see that coming soon.

One final note before I finish up this blog, I have been working on a couple different small modules in my spare time so stay tuned for a couple end of the year releases. If you follow me on Twitter, you may have already seen a preview (and my traveling rants!) but if not I will post a blog with each release.

More ...

Category: Events

Category: Community

Forum 5.0 on DotNetNuke.com

thecrispy1@gmail.com — Tue, 12 Oct 2010 05:00:00 GMT

Since the previous build used on this site (what I labeled 4.6 Beta 2 on CodePlex), not too much has changed for end users. The majority of the changes I made were in the backend of the module (caching, bug fixes, removing legacy table columns and tables, etc.). Having this installed on here, in combination with the 5.0 version of the module being in the release tracker, means the module could be a part of the next core release. A few key changes since 4.6 Beta 2:

New Feature: Auto Trust Users based on approved Post Count.
Telerik control integration in some areas (not all yet).
Private Messaging Removed (we didn’t use it on dotnetnuke.com)
Removal of Member List (we didn’t use it on dotnetnuke.com)
Better SEO options, now using meta keywords (includes tagging support) and meta description.

As I mentioned before, not too many things changed on this site with the latest upgrade. However, I wanted to take a few moments to point out a few of them which did.

Notifications

Notification management for users has been simplified. First, simple grids are used instead of duplication of the forum UI. This reduced the size of the page and I feel it also made it more ‘useable’ (considering people don’t really ‘read’ threads from here, this section is just meant for notification management). Next, the ‘unsubscribe’ process was changed so that users simply click a red x icon (delete button) and they are removed from the forum/thread subscription and they will not receive further notifications (for the thread of forum they removed). Plus, this immediately removes the row from the grid providing instant notification that they are ‘unsubscribed’. In previous versions, users had to select a checkbox and then click delete (this old way meant at least 2 clicks, vs. 1 for new way).

The second big change: in older versions users could subscribe to a forum, thread or a post within a thread (max one post per thread). In reality, when subscribing to a post within a thread you were subscribing to the thread itself but you could only manage this on a post per post basis (ie. edit the posts you previously selected ‘notify’ for). Now, users can manage all their notifications from a single view within “My Settings”. This change means users do not need to ever edit a post to ‘unsubscribe’ from a thread. It also means that on the backend there is one less place to check when sending out notifications (thus reducing the chances of missing someone, 1 less table to check).

Tagging

When browsing posts in a thread, users can now apply tags to a thread as well as view previously associated tags. This is located in the bottom left hand section of the module, below the bottom breadcrumb of the forum. One thing worth noting up front, this is only available in forums which can be viewed by all user who can view the page (which in this case is anyone, logged in or not). There are several technical reasons why this is not available in private forums but I will spare you those boring details.

Applying a tag can be done in one of two ways. If you are creating a new thread, you can use the core “Terms Selector” control which lets you select from a list of previous used tags on the site as your post your new thread (shown in the first screenshot below). Those who have edited a page in DotNetNuke core 5.4 or greater, this control should look familiar. The other way to apply a tag is to click the “Add” button in the tag section and type in a new tag (and click save). This uses another core control which you may also be familiar with, as it is the same one used in the skin object for taxonomy. This ‘tag control’ is shown in the second screenshot below.

Clicking on a tag will take users to a view where all items across the site associated with the click tag are displayed (shown below). Other areas on this site will behave similar in the future (when a tag is clicked), it’s just a matter of tagging being exposed in other modules in the future.

Search

It seems like it has taken forever, but I think search is finally headed in the right direction for the module. I expect it will need tweaks in future revisions and can use some more options for an advanced search but it is much more useable now than it has been in the past. Previously, it seemed no matter what I searched for in this module I got an error on this site. This was due to an SQL timeout in the background. After this recent update, I haven’t been able to reproduce this problem after several attempts. I also removed the user lookup control for a number of reasons (the main one being usability of it was horrible).

While the list of changes/enhancements was not huge, the primary focus since 4.6 beta 2 has been on bug fixing as well as utilizing core features/controls available as of DNN 5.4.1 (the minimum core version required for the module).

More ...

Category: Development

Category: Community