A number of settings defined at the portal level are limited to SuperUser access. Some of these were pointed out in the previous section but there are a few additional ones. Because these settings are applicable on a per-portal basis, you need to be in the context of the portal in question to change them. You can reach the site settings for any portal through the Portals page (Host ð Portals). Just click the pencil icon next to one of the portal names (see Figure 5-8).
Figure 5-8
From the Portals page you can create and maintain portals as well as generate a portal template for import into another DotNetNuke installation.
At a glance, the list enables you to see which portals are configured as well as their portal aliases, number of registered users, disk space threshold, hosting fee, and expiration date (if set). Click the pencil icon next to any entry to access its Site Settings page. When you are logged on as the Host, you have access to additional configuration items (see Figure 5-9) that the Portal Administrator cannot see.
Figure 5-9
Table 5-7 explains how each of these advanced options affects the portal.
Setting | Description |
---|---|
Expiry Date | When the expiry date for a portal is exceeded, a friendly message is displayed in the place of regular content (see Figure 5-10). |
Hosting Fee | The default for this value is established in the Host Settings. This is primarily a display field that indicates the value appropriate for monthly renewal. |
Disk Space | The default for this value was set in the Host Settings. It limits the amount of disk space available to a Portal Administrator through the File Manager. |
Site Log History | The default for this value was set in the Host Settings. It keeps the site log for this portal truncated to the number of days indicated. |
Premium Modules | Modules can be installed for use by any portal or can be limited to use in specific portals by setting them as "premium." This set of controls identifies which premium modules have been applied to this portal. You learn more about host management of modules later in this chapter. |
Figure 5-10
There's also a new control at the bottom of the Site Settings page for maintaining the list of aliases (domain names) for the portal (see Figure 5-11).
Figure 5-11
Prior to version 3.0, all portal aliases were maintained in a comma-delimited string, which restricted the number of aliases that could be assigned. Additionally, it made processing based on individual aliases more complex and inefficient. Starting with version 3.0, portal aliases are maintained as a list of separate items. To add an additional portal alias, simply click Add New HTTP Alias and enter it in the text box provided. A portal can answer to an unlimited number of portal aliases.
To create a new portal, click Add New Portal on the bottom of the Portals page (or select it from the Action menu). The Signup page opens (see Figure 5-12).
Figure 5-12
The default root directory for the portal can be overridden. Aside from that, there should be only one field on this page that might be unfamiliar to you: Portal Type. You learn about Parent and Child portals in the next section.
In Chapter 3, you were introduced to the concept of Parent and Child portals. Portal Setup is where you put those concepts into practice by specifying either a Parent or Child portal. The only real distinction between a Parent and a Child portal is that a Parent portal alias has a simple URL attributed to it, whereas a Child portal consists of a URL and subdirectory name. An example of a valid Parent portal name is www.dotnetnuke.com. Alternatively, you can specify an IP address instead of a domain name (for example, 209.162.190.188). An example of a valid Child portal name is www.dotnetnuke.com/soccer, and an IP address can be substituted here as well (for example, 209.162.190.188/soccer). A Child portal can be turned into a Parent portal simply by adding a URL to its list of portal aliases.
When a new Child portal is created, a physical directory is also created in the root of the web site with the Child portal's name. A page called subhost.aspx is copied into the directory as default.aspx. That's how DotNetNuke can implement addressing of the Child portal by the alias name (for example, www.dotnetnuke.com/soccer) without making modifications to IIS. Without existence of a physical path and filename (for example, www.dotnetnuke.com/soccer/default.aspx), IIS would normally process the request without ever handing it to ASP.NET, rendering an HTTP 404 Error or "page not found." You might wonder why a simple change to IIS would not be a better solution. It might be, but DotNetNuke is built to provide the functionality in environments where this level of access control may not be available (that is, in a shared hosting environment).
So why would you create a Child portal instead of a Parent? With a single registered domain name, you can create an infinite number of cname portals (for example, soccer.dotnetnuke.com) as long as your ISP supports a DNS wildcard for your domain. The most popular reason for creating a Child portal is the capability to emulate a single sign-on solution where credentials appear to be shared between portals. This is a common implementation in intranets where departmental portals are involved. Because Child portals exist in the same domain as the Parent portal, they can share access to a domain cookie, which preserves their logged-in status across subportals as long as the username and password are synchronized.
In Chapter 4, you learned about portal templates in the context of importing one through the Site Wizard. As Host, you can create your own portal templates, which truly qualifies as a "superpower." Figure 5-13 illustrates the Export Template function, which is the second component of the Portals page on the Host menu.
Figure 5-13
This feature enables you to select an existing portal, supply a name and description, and then generate a template that contains all the information necessary to re-create the portal on another installation (see Listing 5-1). Two files are generated in the <name>.template process, and <name>.template .resources. .template is a plain-text file that contains a complete XML representation of the portal, its pages, modules, settings, and file structure. .resources is just a zip file of the portal root that is exported as content (if that option is selected).
Listing 5-1: Portal Template (Settings Node)
<settings> <logofile>logo.gif</logofile> <footertext>Copyright 2002–2005 DotNetNuke</footertext> <expirydate>0001-01-01T00:00:00.0000000+11:00</expirydate> <userregistration>2</userregistration> <banneradvertising>1</banneradvertising> <currency>USD</currency> <hostfee>0</hostfee> <hostspace>5</hostspace> <backgroundfile /> <paymentprocessor>PayPal</paymentprocessor> <siteloghistory>60</siteloghistory> <defaultlanguage>en-US</defaultlanguage> <timezoneoffset>-480</timezoneoffset> </settings>
Portal templates are a powerful capability in DotNetNuke — but this capability is still "raw." This means that we've yet to provide user interface controls to direct how a template file is exported. At this point, template files contain everything including the kitchen sink! If you are creating templates, it would be wise to actually read through the generated file and make sure that there are no options specified that would be inappropriate for where you intend to apply them. As a standard XML file, this is a pretty simple thing to do and removing nodes that you don't want should work fine.
For example, a generated template contains nodes with all the settings for the current portal. As you can see in Listing 5-1, there are a few nodes here that you might not want to override in a portal that imports the template; nodes such as <userregistration>, <hostspace>, and <paymentprocessor>. These settings might be appropriate for a new portal, but templates located in the Host Root (\Portals\_ default) are available to the Site Wizard and can be applied to existing portals as well.
Templates provide a lot of power and promise for automatic configuration and for sharing of portal information. However, they should be used with care until they're more fully "cooked."
The Portal Administrator and the Host each have their own version of the Skins page. As Host, both are visible and accessible to you, so it is essential that you understand which one you are working with.
When using the Admin ð Skins page, you (as Host) always have access to the Upload Skin and Upload Container buttons. These are visible to the Portal Administrator only when the Skin Upload Permission is set to Portal (as previously described in Table 5-6). This enables you to upload skins and containers that are private to the specific portal — those files are uploaded to the Portal Root directory (\Portals\ <PortalId>). When using the Host ð Skins page, the only difference is the target of the uploaded files. Skins and containers uploaded through the Host ð Skins page are installed in the Default Portal directory (\Portals\_default) and are available to every portal in the installation.
Note | To upload skins for a specific portal only, log in to that specific portal as a SuperUser and navigate to Admin ð Skins. A quick way to navigate to any given portal is to go to the Portals list on the Host menu and click the portal alias name. |
Chapter 4 provided some basic information about the Log Viewer from the Portal Administrator's perspective. As the Host, there are two specific differences in your view of the logs as well as a few additional features. First, your view includes exceptions (and any other events that are hidden from the Portal Administrator). Second, your view can contain log entries from all portals (if selected as an option). You also have access to some additional functions, including the capability to select and delete specific log entries, clear the entire log, and edit the log configuration.
System logging is accomplished by means of either a database provider or an XML file-based provider. For all versions since 3.1.0, the database provider has been specified by default and can be verified by checking the following line in the web.config file:
<logging defaultProvider="DBLoggingProvider">
In the database provider, the EventLog table holds the records for all event types. In the XML file-based provider, a single set of logs is implemented as a group of XML files that are located in the default portal root directory. There are no functional differences in the use of either provider.
If you are using the XML file-based provider, the full set of logs is located in the following files:
\Portals\_default\Logs\Application.xml.resources
\Portals\_default\Logs\Exception.xml.resources
\Portals\_default\Logs\Scheduler.xml.resources
\Portals\_default\Logs\Log.xml.resources
From the Log Viewer, select Edit Log Configurations at the bottom of the page or from the Action menu to open the Edit Log Settings page illustrated in Figure 5-14.
Figure 5-14
There are a number of preconfigured logging events — some enabled and some disabled. For example, because the Scheduler is disabled in the default installation of DotNetNuke, its logging events are also disabled. Click Add Log Configurations at the bottom of the page to add a new configuration, or click Edit next to an existing configuration to alter it. Figure 5-15 shows the Edit Log Settings page.
Figure 5-15
Table 5-8 explains each of the log configuration settings.
Setting | Description |
---|---|
Logging Enabled | Turns logging on for the item. Items can be defined in the log settings without being enabled (for example, the default Scheduler event logging settings). |
Log Type | Select one of the system-defined event types to log or the All category (as appropriate). It is acceptable to define more than one log setting for the same event or for overlapping events. |
Portal | Indicate a specific portal (or All portals) for which this event is to be logged. |
Keep Most Recent | Selecting All preserves all entries in the log. Any other value results in truncation of the log to the maximum number of items specified for the log type selected. |
FileName | Multiple log files can be created. This can be handy for monitoring performance and/or activity related to a given portal or event type. |
Email Notification Enabled | When enabled, the SendLogNotifications scheduled job assembles and sends e-mail according to the Edit Log Settings when it runs. |
Occurrence Threshold | Specifies how often an event must occur to trigger e-mail notification. |
Mail From Address | Sent-from address specified on outgoing e-mail. |
Mail To Address | Sent-to address specified on outgoing e-mail. |