In a previous blog entry, I outlined some of the changes that this website has been going through. I have been upgrading this site from version 4.05.03 to version 4.09.00, and this included a final round where I upgraded all of the modules as well. All of this has been put into motion to make my blog more accessible, faster, better organized, easier to syndicate, and more SEO friendly.
The upgrades all went fine, but one of my goals is to submit my blog to the DNNBlogs.com website. However, the current iteration of my blog didn't meet their requirements, as I had personal blog entries intermingled with the DNN ones. What I needed to do was find a way to separate all of the blog entries, leaving the DNN and .Net ones by themselves. Luckily, this functionality already exists in the DNN Blog Module! In fact, it has existed for quite a long time...
One of the things about the Blog Module that has had a love/hate relationship with the community, is the fact that the blogs are directly tied to user accounts - more so than most features typically are. This would be okay though, if the admins and hosts had some control over this. Anyhow, a benefit of this format is that it makes it easy for us to categorize our blogs using the Child Blog feature. This feature is found at the bottom of your Blog Settings.
In my situation, I already had two categories of blogs in mind: Personal, and Professional. The Professional ones would be about .Net and DotNetNuke, and Personal would be for everything else. We will continue with this example.
When you click the "Add" child blog button, you are faced with pretty much the same interface you saw before when creating a new blog. Only this one will have a direct relationship with the blog you originally created. If the first blog you created is the Parent, then this would be it's Child. You can also equate this to folders. In the folder analogy though, the original blog would be the filing cabinet.
Fill out the child blog form just like you would for any other new blog. Then, click the "Update" button at the bottom of the page. Assuming there were no errors, you would be returned to the Blog Settings page. In my case, I did this twice, once for each category.
Now that I created the two categories I needed, it was time to find out what the BlogID's were. I would need this values in a moment in order to move blog entries from the original blog to the new ones. I used the following query:
(Your queries might vary, depending on how you have your database and tables set-up.)
Once the query executed, I was able to see 3 records in the table, one for each blog - the parent and the two children. I noted the ID numbers for each.
Now, I needed to perform a quick T-SQL surgery to move the blog entries. First, I moved the personal ones. This step was the most important, as I needed to browse through the database table real quick to grab the ID's for each personal entry. This would only need to be done this one time. You'd want to choose whichever category has the least number of entries to save time. I used the following query to look through the blog entries.
The enabled me to come up with a list of blog entries to use in the first data transfer query. In the example below, pretend that the numbers 1 though 6 is actually a meaningful list of numbers.
SET [BlogID] = 2
WHERE [EntryID] IN (1,2,3,4,5,6)
Since we only needed 2 categories here, the entries that remain after running the previous T-SQL snippet are all part of the same category. Now, we can run the following T-SQL to move the remaining entries reliably into the appropriate child blog.
SET [BlogID] = 3
WHERE [BlogID] = 1
This leaves no entries in the original blog, but instead has all of the blog entries in their respective child blogs. This facilitates you being able to separate the RSS feeds for each blog, as well as being able to link to specific blog types, and more. You can already see this process in action on this very blog.