Have you ever wanted to have a module display on most of the pages of your site? Not every page, but more pages than you really want to manage by hand. Until now, you really had two options. 1) Set the module to dispay on every page. This centralizes module content management and a change to one module affects every other page no matter which page it was editing on. The downside is that it will be on every page. There is no way to limit it to just part of your site. 2) Use the copy module feature to make a duplicate of the original module. This allows you to selectively put the module on multiple pages without needing to show it on every page on the site. The downside is that if you need to make a change to the content, you must visit every page to make the change. If you have 100 pages with this module on it then you have to make the change 100 times. [see comments below] The only problem with this approach is that if you have a large number of pages, this can be very time consuming.
I have discovered a third way that combines the best of both worlds described above. It allows you to have a module appear on as few or as many pages as you like and still centrally manage the content. You can edit the module on any page and have the change ripple throughout the site automatically. To make this method work you must be familiar with how DotNetNuke stores module information and you must be willing to run custom SQL queries on your site.
NOTE: BE VERY CAREFUL! You can really mess up your site if you don't know what you are doing. So make a backup of your database before you begin.
There are really 3 tables that will store the information that we are interested in: Tabs, Modules and TabModules. The modules table defines the basic module type, whether the module is to be displayed on all tabs, and what the ID is for this specific module instance. The ID is key because this is how we know that we will be sharing a single module instance rather than just duplicating content. If you are working with a single ID then you have only one set of content.
The Tabs table will contain the information about a specific page of the website. We will use this table to determine the IDs for the tabs that we want our module displayed on (or not displayed on).
The primary table we will work with is the TabModules table. It contains the associations between the pages of your site and the module instances which are displayed on those pages. This is where we can use the same ModuleID over and over again and just by having different TabIDs we will end up with the same module on multiple pages.
In this article I am going to assume you want the module on almost all pages of your site. There is another method we can use if we just need the module on a small number of pages. The first step is to go into Module Settings and check the box to display the module on all pages.
Now that the module is appearing on all pages, you are ready to customize the settings to remove pages where you do not want the module displayed. To remove the module from a page just delete the appropriate entry from the TabModules table. For example, if our ModuleID was 521 and the TabID of the page was 23 then we could execute the following SQL to remove the module from this page:
DELETE FROM TabModules
WHERE TabID = 23
AND ModuleID = 521
But this approach could get very tedious if you had several pages where you didn’t want the module to appear. The approach I ultimately used was to use a different skin on the pages where I didn’t want the module. This was a natural function of my site design. You might want to use a different criteria. In my case I used the following query to remove the module from all pages that used the AlternateSkin.
DELETE FROM TabModules
WHERE TabModuleID in (
SELECT TabModuleID
FROM TabModules
WHERE (ModuleID = 521)
AND (TabID IN
(SELECT TabID
FROM Tabs
WHERE (SkinSrc = '[G]Skins/MyCustomSkin/AlternateSkin.ascx'))))
You could alternately choose to use the TabPath, the Keywords or event the ParentID (the ID of the parent page). The principle still applies. Query the db for a list of TabIDs, and use those IDs to delete the appropriate entries in the TabModules table. Once you have your query save it for future use. Every time you add a page to the site, DotNetNuke will automatically add the module to the new page. Just re-run the query and it will remove the module from the new page as defined by your query.
One of the principles that I hope you take away from this discussion is that much of DotNetNuke’s behavior is controlled by entries in the database. A little looking under the covers and the judicious use of a few SQL queries can provide functionality that is not available from the User Interface alone. Don’t be afraid to explore, just make sure you do it on a development database, and when performing the change on a production site ensure you have a good backup of the site.