If you keep up on the dotnetnuke.com blogs, you have probably seen over the past month or so I have been releasing forum betas. So far these have been under the 4.6 and 4.7 versions (I didn’t blog about 4.7). I have created a new one, which is technically 4.8, but after many changes I have decided that the final release version will be 5.0. This is because I have changed so much that a major version was due (there was also a lot of cleanup in the module code besides bug fixes and enhancements). As for plans for a release, over the course of the next two weeks or so I am going to continue to solicit feedback on the beta code and continue to test it myself. After this period is done, I will then submit the module to the core release process.
FYI: Currently, the 4.6 Beta 2 is what is installed here on dnn.com and is what I would recommend for anyone wanting to use a newer version of the forum module in production (this will remain a release at CodePlex). However, anything after that version should not be placed into production until you hear otherwise and should be used for testing purposes only.
One of the reasons I authored a blog series on taxonomy was so I knew enough to integrate it into the forum module. Now that the blog series is done and I had time to implement it in the module, it is now included in any future releases. Before we dive into the details of where/how, one important thing to understand is that tagging is only going to be available in public forums. The reason for this is because the forum has another granular level of security which other DotNetNuke modules do not and this is done @ the forum level (group –> forum, not to be confused with the forum module itself). If we exposed private forum to tagging, what would happen is clicking a tag anywhere in the site that is associated with a private forum’s thread would result in users potentially being able to see content from a tagged thread which they shouldn’t see (this is a similar situation to ISearchable and what is exposed by the forum module). While they wouldn’t be able to click the results link to view the thread itself, they would see the subject which may contain sensitive information. Hopefully, you understand why this is why only public forums are available for tagging. That said, lets take a look at what is available now.
Thread authors can apply existing terms when creating a new thread (replies/quotes do not get this option). As you can see in the screenshot below, the same control which is used while editing a DotNetNuke page is used here. This does not allow entry of new tags via the control, but I wanted to re-use the core controls (for now) to get this going.
After a thread is submitted (and approved, if moderated), it can then be ‘tagged’ by end users as long as they are logged in. Tags are applied using the core control which was used for the skin object. This tag control, which also displays current tags, is available at the bottom of the thread page. A sample of adding a tag is shown in the figure below. Keep in mind, if a tag wasn’t available to the thread author when creating the thread, they could easily added it from here after the post was submitted (and approved if applicable).
In the next screenshot, you can see where tags are displayed to site visitors (note: users not logged in will not see the “Add” button).
Since the module is utilizing the core tagging, as well as its controls, clicking on a tag will result in the user being navigated to a search results page. A sample of this can be seen in the next image.
There really isn’t much more I can say about tagging here that hasn’t already been mentioned before. I’ll ship the next release with it how it is and go from there to see if any changes are necessary in future versions. I also expect to see it here on DotNetNuke.com over the course of the next couple weeks.
A few things were added to help SEO, with regards to the forum module (I am no SEO guru, but I knew a few things could be done here). First, forum administrators can override the keywords applied when viewing a thread page. When enabled, up to 15 meta keywords are applied to posts view. The first keyword applied is the forum name (if a child forum, both forum names are applied as separate keywords), then any applied tags are added to the list, up to the limit. Before this addition, every single thread was using the keyword assigned to the DotNetNuke page. The next option added was the ability to override the meta description in posts view. When enabled, the subject of the thread will be applied here (up to a 150 character limit). I am considering some minor updates to this, so if you have any input please let me know. While here, I also updated the existing option for overriding a page title, I now make sure that the forum name + subject that were used to build the title are no longer than 64 characters. There is another option added, sitemap priority, which we will get to in a moment. You can see the options added in the screenshot below which is from the forum admin control panel’s SEO section.
The sitemap priority setting that I touched on is really a ‘default’ setting here. To understand more, you will need to look at the edit forum screen, also accessible from the admin control panel. Here you should see two new options, one is enable sitemap and the other is the sitemap priority. The enable sitemap setting here determines if the forum will be exposed to the SEO sitemap provider (ie. threads output as pages in the xml sitemap). By default, in a new install or upgrade, this will be set to true with the priority of .5. One important thing to note about this is that only public forums (those forums that can be viewed by any users who can view the page) are available for listing in the SEO sitemap. This is because we don’t want the index bots attempting to index private site content (which it wouldn’t have access to anyway). A screenshot of the edit forum screen is shown below.
The final portion of the SEO updates, and you might have guessed this already, was to include a Sitemap Provider for the forum module. This will display all threads that are exposed to the sitemap as separate pages in the xml sitemap (available from domain.com/sitemap.aspx). For those who are upgrading, one important thing to note is that only threads that have been visited will be available here (besides being a public forum with this enabled). What happens, and this is to support tagging as well, is when a thread is created (or first viewed in an upgrade scenario) a core Content Item is created. I did it this way for a number of reasons, one being that I base the tabid on the one associated with the content item. One thing to also make note of is that the data structure has the ability to enable/disable sitemap exposure per thread too. Currently, there is nothing in the user interface to support this but I wanted to include it in the data structure from the start. You can see a sample of the forum specific sitemap output in the screenshot below.
I do want to add that I know the output page links are not very friendly but fixing that goes far beyond the scope of the forum module itself. Hopefully, in the next two week period we can get some more feedback based on what is available now. If you are interested in participating, the forum module releases (and betas), can be downloaded from CodePlex. If you wish to submit any bugs, please do so over @ www.dnnforums.com.