Important Concepts of DotNetNuke

1. Parent/Child Portals

1. A child portal has its own discreet membership, modules, and so on — essentially its own portal entirely — within the same domain as a parent. DotNetNuke creates a physical directory and file that enable IIS to recognize the portal's existence. Child portals make sense within a single domain, leveraged to intranets, SSO, and so forth.

   A parent portal has no subdirectory, although it can remain within a domain by using cnames (sales.Domain.com, for example).

2. Pages
1. Pages are a relatively new term in DotNetNuke. Prior to version 3.x, these were called tabs. This change was made to allow for a more user-friendly experience for the novice who may not be a programmer by trade. You can think of a page in the same way you think of a static HTML page. The difference is that the application loads the content based on the parameters passed to it at runtime.
3. Panes
1. Panes are the areas of your skin that hold the various content modules you drop on each page. These enable you to organize your content in a manner that makes the best use of your site's real estate. The number and placement of panes is a function of your skin design.
2. If DNN cannot find a pane — that is, a pane name that matches — it puts the modules in the ContentPane. If a skin is significantly different, the layout changes, but all the functionality is preserved (nothing breaks).
4. Containers
1. Containers enable you to enhance the look of your portal without any design changes to your skin. A container's purpose is to surround the content of a module with some design element, which allows you to bring more attention to the content of the module. You have two options for applying containers to your portal: You can apply a default container to your entire portal and, if desired, set a container for each module. Go ahead and add a module to a page and set up a container for a visual reference.
5. Modules
1. Modules are the meat and potatoes of a DotNetNuke site. They are the components that display relative, easy-to-update content to your visitors.
6. User Roles
1. DotNetNuke offers a fairly robust method for dealing with permissions and controlling the tasks a particular user is allowed to perform. It does this with a roles-based security module, where every page and module in the application is assigned roles that determine what the user is allowed to do within the context of the application. You have the option of setting permissions at several levels within the portal. A user may be allowed access to edit certain modules or be given access to edit the entire page, as you deem necessary. These functions also apply to viewing a module's content or a specific page. Basically, all you need to do is create the necessary security roles and assign the permissions you want that role to perform to the module or page. After you have the roles and permissions defined, you can then place your users in the appropriate role, which will allow or restrict their access based on those permissions. This allows very granular control over the actions of users in your portal.
7.