After your portal is set up and working just the way you want, you'll start finding good reasons to enhance or change things. You'll delegate maintenance work to others; you'll pick up some site advertising or want to track affiliate referrals; you'll want to communicate with your registered users; you'll want to recover work that you've previously discarded; and you'll want to know what kind of traffic your site is getting.
You've already experienced a feature-rich environment for configuration of your portal's look, feel, and function. DotNetNuke provides an equally rich suite of tools for maintenance tasks as well.
The User Details page (previously shown in Figure 4-16) provides for user self-management. The Portal Administrator is able to manage users from the User Accounts page (see Figure 4-41). Access it by selecting Admin ð User Accounts.
The page supports several methods of finding a user, which is helpful when your number of registered users becomes large. Clicking a letter filters the list by username, displaying a maximum of the number of records specified in the drop-down list box in the upper-right corner of the page. A standard paging control with buttons for First, Previous, Next, and Last appears if there are enough users in the list to require paging. If you need to find a specific user, the search box can accept either a username or an e-mail address.
Depending on the type of Portal Registration Options you selected (previously described in Table 4-4), you may have particular interest in finding unauthorized users. Private registration requires the Portal Administrator to manually approve users so the button to list them, the check box to indicate them, and the button to delete them are handy features. List the unauthorized users, approve the ones you'd like to permit access, and then click Delete Unauthorized Users to remove the remaining registrations you've deemed inappropriate for your site.
Clicking the pencil icon next to a user's name takes you to the Edit User Accounts page (see Figure 4-42). This page is similar to the User Account page previously shown in Figure 4-16, but it differs in a couple of key ways. There is an Authorized check box to flag the user, and the Membership Services control is missing in favor of a link button to Manage Roles For This User.
In early versions of DotNetNuke, it was possible to change the name of a user, but this feature is not present after version 3.0. The default Membership Provider used by DotNetNuke incorporates an ASP.NET 2.0 component (MemberRole) with lots of sophisticated security features. One of the security tenets of this component prohibits the changing of a user's identity after it is set.
In support of the Private Registration option, checking Authorized causes an e-mail to be sent to users that provides them with their login credentials and a welcome message.
The Preferred Language and Time Zone settings work exactly as they do for the Site Settings (previously described in Table 4-6). These settings will override the default site settings when the user is logged in.
Earlier in this chapter, you were introduced to managing security roles within the context of the list of roles (as previously shown in Figure 4-26). When you're approaching this task from the list of users, the Manage Roles For This User button takes you to a similar page (see Figure 4-43).
You can assign a role to your user along with an expiration date (if desired), or remove existing roles. You can also choose whether you'd like the user to receive e-mail notification of the change.
At some point, you may want to develop partnerships with others in promoting your web site and/or complimentary products and services. DotNetNuke provides a number of built-in features to get you started in developing these relationships.
The vendor-management features provide a lot of basic functionality, but for enterprising developers there is also a lot of room to build on this foundation to provide additional services.
To create a new vendor, open the Vendors page (see Figure 4-44) by selecting Admin ð Vendors. Then, select Add New Vendor from the bottom of the page or from the action menu.
On the Edit Vendors page (not pictured), you add basic contact information for the vendor as you would for any user. You also have the option to specify a vendor's web site, logo, key search words, and classification.
At the time of this writing, most of these optional fields are unused. However, they are reserved for future use as DotNetNuke architecture/services continue to develop in this area.
After you add a vendor, you can create banners for it that can be displayed on your site. Navigate to the Edit Vendor page for your vendor, expand the Banner Advertising section, and click Add New Banner. Table 4-16 explains the settings.
Identifies the banner in lists, and is used as the ALT text for graphic banners and as hyperlinked text on text banners.
Of the available banner types, only two really impact how the banner fields are used. When you place banners on your site with the Banner module, you select the type of banner it should display. Choosing Banner, MicroButton, Button, Block, and Skyscraper provides logical groupings of banners that fall into common width and height formats. There are no actual rules, but these groupings help to organize banners so that you don't wind up displaying wide banners in button-sized locations in your skin.
Text and Script types are special cases. If you choose a Text banner, you can mimic the look of Google AdSense (see Figure 4-45). Choosing a Script banner allows free-form HTML in the text box, which is helpful for a number of generated links for things like Amazon products.
Further aids in the ad-hoc grouping of banners. For example, DotNetNuke.com displays rotating button banners for its sponsors. To keep sponsor buttons separate from other banners, each has Sponsor in its Banner Group field. Likewise, the Banner Options for the module specifies Sponsor in its Banner Group.
Because this field is ad-hoc, there is no real way to track how or where it is used. You have to keep up with that on your own. But it does provide for all the logical separation you should ever need.
Specifies whether your image (if applicable) is to be rendered from a file on your site or from a remote URL.
The text in this field is handled differently depending on the Banner Type previously selected. For most banner types, just leave this field blank. For type Text, the value appears as simple text (unlinked) below the hyperlinked Banner Name field (see Figure 4-45). For the Script type, this field can contain raw HTML, supporting a variety of link types and formats.
The field length is limited to 1000 characters.
If this value is populated, it is used instead of the URL associated with the vendor. You can use this URL to point to specific pages in a vendor's site or to configure extra query string parameters. This field also displays as hyper-linked text on banners of the Text type (see Figure 4-45).
At the time of this writing, the CPM value is not used for any calculation. However, it does provide a convenient place to record this information in the context of the banner.
If specified, this value is one of the criteria used to determine whether a banner should be shown. To limit a banner's display based on the number of impressions, this field removes it from rotation after the value has been reached.
Use this field to set up banners in advance to begin displaying at a future date.
Together with Start Date, you can create banners to run for specific date durations for events, special deals, holidays, and so on.
Specifies how the Impressions and Date constraints should be enforced. If they are enforced independently of one another (OR), a banner ceases to display outside of its date constraint or even within its date constraint if the number of impressions has been reached. If they are enforced jointly (AND), all criteria must be true for the banner to cease display.
The AND option helps to address a lack of throttling control. On a busy site with few banners in rotation, a given number of impressions can be used up quickly and so displayed over only a brief time period. By jointly evaluating the criteria, a more equitable rotation is achieved by providing for additional banner impressions during the time period.
You can advise vendors of the status of a banner by clicking the Email Status To Vendor button at the bottom of the Edit Banner page. This sends an e-mail to the address specified in the Vendor details, which relays the banner field information (text, costs, and constraints) and performance (view and click-through counts).
Just as your site links to vendors through the use of banners, your vendors may also link to you. If you would like to be able to track your vendors' click-through performance to your site, click Add New Affiliate. Define a tracking period and associated Cost Per Click (CPC) and Cost Per Acquisition (CPA), and e-mail the vendor the link information by clicking Send Notification (see Figure 4-46).
The CPC information for affiliate referrals is summarized in the Edit Vendor list, just as click-through is for banners. However, the CPA information is currently unused. You can specify multiple affiliate relationships under a single vendor to provide for tracking during discrete time periods.
At the time of this writing, it is possible to create affiliate referrals with overlapping date ranges. This produces double counts of vendor performance during the period of overlap, so be sure to end one affiliate period before starting another.
Periodically, you'll want to communicate with your users. The Newsletter page provides a convenient way for you to do this by enabling you to send e-mail to users in specified roles (see Figure 4-47). Remember when you set up the Newsletter Subscribers role? Here's where you put that to use.
Just select the roles that you want to be included in the distribution. If users belong to more than one role, they'll still get only one e-mail. You can also specify additional recipients separated by semicolons in the Email List field. And you can format your e-mail as either text or HTML.
Figure 4-48 shows the advanced e-mail options, which include sending a file attachment and choosing the priority setting. The Send Method option enables you to specify whether your e-mail is personalized. Choosing the BCC method sends just one e-mail, which is delivered to all users. Choosing the TO method causes your e-mail to be personalized (for example, "Dear John Doe").
Using the TO method seems much more personal, but it comes at a cost. First, the processing required to create a separate e-mail for each user could be substantial (with large user volume). Second, it significantly increases your bandwidth utilization. The bandwidth associated with the BCC method is minimal — just one e-mail. However, the bandwidth associated with the TO version is the product of the size of the e-mail and the number of users.
You can also choose whether the sending of e-mail is processed synchronously or asynchronously. If you have a large list of users, asynchronously probably makes the most sense. In either case, a summary e-mail is sent to the Portal Administrator reporting on the number of recipients, number of pieces of e-mail actually sent (1 or n), and the start/stop times for processing the job. DotNetNuke batches e-mail addresses into groups in the background so you never actually try to send an e-mail with thousands of BCC recipients.
The Site Log displays text-based reports only, as shown in Figure 4-49.
Table 4-17 identifies the available report types.
Tracks referrals from vendors who are defined as affiliates. By using their affiliate ID numbers in links to your site, you can capture how productive those affiliate links are.
Detailed Site Log
Includes all users and displays date and time, username, referrer, user agent, user host address, and page name.
Displays the total number of visits to the pages on your site in the period specified. It includes the date and time of the last page visit.
Page Views By
This series of reports provides a summary of the number of visitors (anonymous) and users (logged in) that accessed your site in the intervals specified (Day, Day of Week, Hour, Month).
Summary list of web pages (including search engines) that users have clicked to lead them to your site.
This series of reports provides a summary of the number of page visits recorded according to the characteristic specified (Agents, Frequency, Registrations by Country, and Registrations by Date). The Report by Frequency can be interesting — it identifies your most frequent visitors in any given period.
Logging occurs at the discretion of the Host, who has a number of options for how it is configured. If the Host chooses to generate text-based log files (like IIS logs), these reports become obsolete because they work only with database logging information (at this time). Chapter 5 provides more information on Host settings that control logging.
Have you ever deleted a file on your computer only to experience a panic moment? Portal Administrators might do that, too, once in a while, which is why DotNetNuke has a Recycle Bin feature (see Figure 4-50).
The act of deleting a page or module doesn't really delete anything — it merely sets a flag that DotNetNuke understands internally as deleted and ignores it in the general interface. Items that have this flag set can be found in (and restored from) the Recycle Bin.
Developers can see this implementation by looking at the database fields Tab.IsDeleted and Modules.IsDeleted.
You can select single or multiple pages to restore or delete. However, when doing either you must follow the hierarchy of the pages for it to work. If you think about it, that makes perfect sense, but it is not obvious. In the example previously shown in Figure 4-50, the Team Info page was the parent to the others (in the menu structure). If you attempt to restore the Game Schedule page first it would have nowhere to go, so you would receive a warning like the one shown in Figure 4-51.
Likewise, if you try to permanently delete the top-level page (Team Info) before deleting the child pages, you would receive a warning like the one in Figure 4-52.
When a page is deleted, its modules are not listed individually in the Recycle Bin. That's because a page is considered to include all of its content (which is restored along with it).
When modules are deleted, they lose their association to a specific page. So when they are restored, you must select a target page for them to appear on.
Currently, a restored module has the same view and edit permissions that it did originally. However, this may not be what you have in mind if you are restoring a module that has been in the Recycle Bin for a while. In fact, because there is no convenient way to look at a module that is in the bin, you might be just restoring one to see what it was. The best way to do this is to restore modules to a page that is not visible to your users (a staging page). Then you can check it out for yourself and change whatever settings are necessary before moving it to its final (visible) home.
Modules are always restored to the ContentPane on the target page (shown previously in Figure 4-12). Because a skin designer can create virtually any number of panes in a skin, DotNetNuke can only rely on the existence of this one required pane. This is one more reason why it's a good practice to restore modules to a staging page before relocating them.
As you might have gathered, it's possible to accumulate quite a bit of junk in the Recycle Bin if you do a lot of creating and deleting of pages and/or modules. It's a good idea to do a little housecleaning here every once in a while so that when you really need it, the Recycle Bin is easier to navigate.
The Log Viewer gives a Portal Administrator the ability to monitor a variety of events and associated details including (but not limited to) exceptions. Out of the box, DotNetNuke is configured to log exceptions only; however, any of the (approximately) 48 defined events can be logged at the discretion of the Host.
System logging is accomplished by means of either a database or an XML file-based provider (as configured by a Host). 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:
In the database provider, the EventLog table holds the records for all event types. However, 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. Records from these files are filtered to display only those generated by your portal. The Portal Administrator can filter the list by event type, limit the size of the list displayed, and even send an e-mail that lists the contents to a specified recipient if assistance is needed (as shown in Figure 4-53). There are no functional differences in use of either provider.
When you're sending log entries, the body of the e-mail message is populated with the XML text exactly as it appears in the log files.
Clicking an entry in the Log Viewer expands it to show the full details of the event. Some events contain as little as one or two items of detail, and others contain many more. The event detail for a module load exception is illustrated in Figure 4-54.
To view the full set of default logs, take a look at 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
For an in-depth review of logging, see Chapter 8.