Criteria This choice specifies how the Impressions and Date constraints should be enforced. If enforced independently of one another (OR), a banner will cease to display outside of its date constraint or even within its date con- straint if the number of impressions has been reached. If 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 chewed up very quickly and so displayed over only a brief time period. By jointly evaluating the criteria, a more equitable rotation is achieved by pro- viding for additional banner impressions during the time period. Figure 4-45 You can advise vendors of the status a banner by clicking the Email Status to Vendor button at the bot- tom 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). Vendors as Affiliates 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, you can click Add New Affiliate. Define a tracking period and associated cost per click (CPC) and cost per acquisition (CPA) and e-mail the vendor their link information by clicking Send Notification (see Figure 4-46). Figure 4-46 105 Portal Administration 08_595636 ch04.qxd 5/10/05 10:00 PM Page 105 The CPC information for affiliate referrals will be 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 will produce double counts of vendor performance during the period of overlap. So be sure to end one affiliate period before starting another. Newsletters Periodically, you’ll want to communicate with your users. The Newsletter page provides a very conve- nient way for you to do this by allowing 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. Figure 4-47 Just select the role(s) that you want to be included in the distribution. If a user belongs to more than one role, they’ll still only get 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 displays the advanced e-mail options, which include sending a file attachment and choosing the priority setting. The Send Method option allows you to specify whether or not your e-mail is person- alized. Choosing the BCC method sends just one e-mail, which will be 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 significant (with large user volume). Second, it signifi- cantly increases your bandwidth utilization. The bandwidth associated with the BCC method is mini- mal — 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 actu- ally 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’ll never actually be trying to send an e-mail with thousands of BCC recipients. 106 Chapter 4 08_595636 ch04.qxd 5/10/05 10:00 PM Page 106 Figure 4-48 Site Log The Site Log displays text-based reports only, as shown in Figure 4-49. Figure 4-49 Table 4-15 identifies the available report types. Table 4-15: Site Log Report Types Affiliate Referrals Track referrals from vendors who are defined as affiliates. By using their affiliate ID numbers in links to your site, you’ll be able to capture how pro- ductive those affiliate links are. Detailed Site Log This detailed log of site activity includes all users and displays date and time, user name, referrer, user agent, user host address, and page name. Table continued on following page 107 Portal Administration 08_595636 ch04.qxd 5/10/05 10:00 PM Page 107 Page Popularity Display the total number of visits to the pages on your site in the period specified. Date and time of the last page visit is included. 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). Site Referrals Summary list of web pages (including search engines) that users have clicked on to lead them to your site. User Details This series of reports provides a summary of the number of page visits recorded according to the characteristic specified (Agents, Frequency, Regis- trations 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 will become obsolete because they work only with database logging information (at this time). See Chapter 5 for more information on Host settings that control logging. Recycle Bin Have you ever deleted a file on your computer only to experience a panic moment? Portal Administrators might feel that too once in a while, which is why DotNetNuke has a Recycle Bin feature (see Figure 4-50). 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 so ignores it in the general interface. Items that have this flag set can be found (and restored from) the Recycle Bin. Developers can see this implementation by looking at the database fields Tab.IsDeleted and Modules.IsDeleted. 108 Chapter 4 08_595636 ch04.qxd 5/10/05 10:00 PM Page 108 Recycling Pages You can select single or multiple pages to restore or delete. However, when doing either you must follow the hierarchy of the pages in order for it to work. If you think about this, it makes perfect sense, but it is not obvious. In the example 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 that shown in Figure 4-51. 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. Figure 4-52 You’ll note that when a page is deleted its modules do not appear 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). Recycling Modules 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 will have 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, since 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. Cleaning Up 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/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. Log Viewer 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. 109 Portal Administration 08_595636 ch04.qxd 5/10/05 10:00 PM Page 109 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 e-mail list contents to a specified recipient if assistance is needed (as shown in Figure 4-53). When sending log entries, the body of the e-mail message is populated with the XML text exactly as it appears in the log files. Figure 4-53 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. 110 Chapter 4 08_595636 ch04.qxd 5/10/05 10:00 PM Page 110 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, however some contain many more. The event detail for a module load exception is illustrated in Figure 4-54. Figure 4-54 Summary In this chapter you learned just about everything there is to know about the Portal Administrator and the features and functions available to you in that role. Key features that you should understand include the following: ❑ Control Panel ❑ Site Wizard, Preview Mode, and Help ❑ Preview Mode You should be familiar with the tools available to configure your portal, such as the following: ❑ Site Settings ❑ Security Roles ❑ Pages ❑ Skins ❑ File Manager ❑ Languages 111 Portal Administration 08_595636 ch04.qxd 5/10/05 10:00 PM Page 111 And the tools available to maintain your portal over time: ❑ User Accounts ❑ Vendors ❑ Newsletters ❑ Site Log ❑ Recycle Bin You should have some understanding of how to do things, and when and why to do them as well. 112 Chapter 4 08_595636 ch04.qxd 5/10/05 10:00 PM Page 112 Host Administration In Chapter 4 you learned just about everything there is to know about administering a DotNetNuke portal. In this chapter you learn everything there is to know about administering a collection of por- tals, their environment, and runtime features. As the Host you function essentially as the “creator” of the DotNetNuke universe in which the portals exist. While a lofty sounding role, it is an accurate description because the Host has abso- lute sway over what portals within their installation can and cannot do. Where each Portal Administrator is subject to the “laws of nature” established by the Host, the Host has complete authority to change those laws at will. Some of those laws apply to all portals in the installation universally, but others will apply discretely to individual portals. Understanding the Host role is very important. While the Portal Administrators consider their portal to be alone in its own corner of the cyber-universe, the Host knows otherwise. Host options provide for differentiation between one installation of DotNetNuke and another. Configuration choices made by the Host can affect function and performance of all portals and must therefore be made wisely and with deliberate intent. Upon completion of this chapter, you’ll know everything you need to know as a Host to effectively configure and manage an installation of DotNetNuke. Who Is the Host? Continuing with the Host as “creator” analogy could get you in trouble in some circles (not to mention with your editor!). Since DotNetNuke is an “equal opportunity application,” we’ll find another way to describe the Host that is less prone to cause this particular brand of excitement. DotNetNuke generates plenty of excitement in business and technology circles and we’re quite content with that. 09_595636 ch05.qxd 5/10/05 9:57 PM Page 113 To clearly identify the Host requires us to first review a defining characteristic of DotNetNuke. You’ll recall from Chapter 3 that DotNetNuke is defined as supporting “multiple web sites from the same codebase.” With one installation of DotNetNuke you can create as many unique portals as you like, each with its own URL(s), identity, features, users, data, and so on. You learned in Chapter 4 that each portal has its own administrator, but this begs the question, “Who administers the creation of portals?” So this is how the scope of the role first comes into focus. The Host is the user who creates portals. But the Host does a lot more too. So much more that we’ve devoted an entire chapter to the role. Prior to version 3.0, the Host was alone in his sovereignty, carrying all the responsibility that went along with being the only user in that role; big title, big job. There was only one Host account and that was it. Version 3.0 introduces the role of “SuperUser,” so now instead of being forced to play deity a Host can open ranks to allow for a more “Justice League” approach to configuration and maintenance. All SuperUsers have “super powers” in the DotNetNuke universe. So the first thing you’ve learned is that “Host” is already a legacy term in version 3.0, carried forward from previous generations of DotNetNuke. Understanding this, you can now feel free to interchange the terms Host and SuperUser anywhere that you see them — in all but one case. The default installation of DotNetNuke has one SuperUser account preinstalled whose username actually is “host.” Where Do I Begin? If you’re going to master a universe, you’ll have to manifest your superpowers and take some cues from the most famous “in the beginning” of all! Breathe some life into a new user, or, in keeping with the “Justice League” theme, be a hero and get a “sidekick.” The very first thing you’ll want to do is to create another SuperUser account. Once that is done, you’ll retire the default host account. It’s a prudent security measure in any software installation to retire default administrative accounts to thwart dubious hacking efforts. At a minimum, you’ll want to change the password for the default host account, although you can also delete it entirely. In version 3.0, DotNetNuke utilizes a version of Microsoft’s ASP.NET 2.0 MemberRole component in the default Membership Provider. One of the many distinct features of this component is the implemen- tation of user lockout. After a specified number of invalid password attempts a user account will be unable to log in. Although DotNetNuke resets the password lockout after 10 minutes, the nuisance can be avoided entirely by using a different account and username. Log in by using your new SuperUser account username and password. You’ll notice that you have the same view as the Portal Administrator (see Figure 4-2 in Chapter 4) with one small exception: you also have an additional top-level menu “Host” as shown in Figure 5-1. You’ll be getting into all the details of all these options in this chapter, but right now just concern yourself with the SuperUsers Accounts menu item. 114 Chapter 5 09_595636 ch05.qxd 5/10/05 9:57 PM Page 114 [...]... the Portals page on the Host menu Just click the pencil icon next to one of the portal names (see Figure 5-8) Portals Navigate to the Portals page on the Host menu as illustrated in Figure 5-8 From this page you’ll be able to create and maintain portals as well as generate a portal template for import into another DotNetNuke installation Figure 5-8 At a glance the list enables you to see what portals. .. default.aspx This is how DotNetNuke is able to 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 40 4 Error or “page not found.”... Add New Portal on the Portals page It should have a form like the following: http://soccer .dotnetnuke. com/Default.aspx?ctl=Signup&m id=321 This page is not illustrated specifically, but it uses the same control as regular portal signup, which is illustrated in Figure 5-12 This legacy feature of DotNetNuke was originally provided to showcase the ability of DotNetNuke to host private portals for potential... “appear” to be shared between portals This is a popular implementation in intranets where departmental portals are involved Because Child portals exist in the same domain as the Parent portal, they share access to a domain cookie, which will preserve their “logged in” status across sub -portals as long as their username and password are synchronized Portal Templates In Chapter 4 you learned about portal... permissions (see Figure 4- 33) That’s because the Host Root permissions are not configurable; only SuperUsers can add, change, modify, or delete files in the Host Root Vendors Like the File Manager, the Host Vendor page works in exactly the same way for SuperUsers as it does for Portal Administrators If you need a refresher on basic operation, consult Chapter 4 (see Figure 4- 44) The only difference between... the features that these settings control Table 5-6: Advanced Settings, Other Settings Control Panel Select the Control Panel that Portal Administrators will use Chapter 4 contains a full description of the choices (see Figures 4- 3 and 4- 4) The ability to select the Control Panel exists largely to promote the concept of creating customized Control Panels for the host If you created your own Control Panel,... configuration options that will affect the appearance of portals in this installation Table 5-3 summarizes the effects of each choice Table 5-3: Basic Settings, Appearance Show Copyright Credits Use Custom Error Messages This setting specifies whether DotNetNuke will intercept module errors or whether ASP.NET will intercept them If this option is selected, DotNetNuke will display only basic friendly messages... default folder, which will make it available to all portals This is in contrast to uploading from Site Settings, where it will load into the Portal Root folder Skins uploaded from here are located in \Portals\ _default\Skins Upload Container 118 If checked, this setting inserts the DotNetNuke version number into the browser’s title bar and populates the [DOTNETNUKE] skin object In the default skin this... Chapter 4 that many of these Payment Settings have been preserved from earlier versions of DotNetNuke for legacy support purposes For the Host, these settings only come into play as defaults for new portal creation or for portal subscription renewal These Payment Settings will ultimately be deprecated in a future version in favor of more robust eCommerce APIs (see Table 5 -4) 119 Chapter 5 Table 5 -4: Basic... entries from all portals (if selected as an option) You also have access to some additional functions including the ability to select and delete specific log entries, clear the entire log, and edit the log configuration To view the full set of 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 . PM Page 106 Figure 4- 48 Site Log The Site Log displays text-based reports only, as shown in Figure 4- 49. Figure 4- 49 Table 4- 15 identifies the available report types. Table 4- 15: Site Log Report. which is why DotNetNuke has a Recycle Bin feature (see Figure 4- 50). Figure 4- 50 The act of deleting a page or module doesn’t really delete anything; it merely sets a flag that DotNetNuke understands. characteristic of DotNetNuke. You’ll recall from Chapter 3 that DotNetNuke is defined as supporting “multiple web sites from the same codebase.” With one installation of DotNetNuke you can create