Step 1 Log in with an Admin or Host account. If you are installing a skin for the current portal, go to the Admin/Site Settings menu (see Figure 14-9). Skin files will be stored in the individual portal directory. If multiple portals upload the same skin, then duplicate files will exist in the portal directories. Figure 14-9 If you want all of the portals in a multi-portal installation to have access to the skin, make sure to log in with the Host account and select the Host/Host Settings menu (see Figure 14-10). Figure 14-10 375 Distribution 18_595636 ch14.qxd 5/10/05 9:55 PM Page 375 Step 2 Figures 14-11 and 14-12 show the key portions of the Portal Settings and Host Settings screens. Select the Upload Skin link to go the File Upload screen. Figure 14-11 Figure 14-12 Step 3 The File Upload screen provides a simple interface for uploading one or more skins (see Figure 14-13). Browse to the desired skin package, click OK on the Browse dialog, and click the Add link on the File Upload page. Use the Upload New File link button to finish installing the module. Step 4 After installing a new skin package, you should review the upload logs (see Figure 14-14). Errors will be highlighted in red. If no errors are shown, then the skin is ready for use in your portal. The location of the installation directory will be displayed at the top of the logs. Note that the directory matches the name of the skin package and will only vary based on whether the skin is installed from the Admin menu or the Host menu. 376 Chapter 14 18_595636 ch14.qxd 5/10/05 9:55 PM Page 376 Figure 14-13 Figure 14-14 FTP-Based Installation To install a new skin using FTP or any file manager, copy the module into the Install/Skin directory of your DotNetNuke installation. When the ResourceInstaller task runs, it will install this skin using the standard skin installation code. If an error occurs it will be noted in the task history, which is available by selecting the History link for the ResourceInstaller task on the Schedule page (shown in Figure 14-7 previously). 377 Distribution 18_595636 ch14.qxd 5/10/05 9:55 PM Page 377 Containers Containers, like skins, provide the ability to control the appearance of portal. While skins work at the “page” level, containers are designed for wrapping individual modules that appear on the page. Each module on a given page may use any one of the installed containers. Containers follow many of the same packaging and installation processes as skins and differ primarily in the allowable content inside the html or ascx definition files. Let’s take a look at these differences. Packaging Containers Containers follow all of the same packaging rules as skins. Container packages may contain files that are applied to all container definition files in the package or that are specific to an individual container defi- nition as outlined in Table 14-10. The behavior and purpose of these files is the same as for skins, and only the names of the files are different. Table 14-10: Container Filenames File Type Global Name Individual Container Name Configuration File Container.xml [container filename].xml Style Sheet Container.css [container filename].css Installing Containers Containers follow the same procedures for web- and FTP-based installations. For web-based installa- tions, in Step 2, select the Upload Container link instead of the skin link (shown in Figures 14-11 and 14-12 previously). Containers will be installed in the Portal or Host containers directory. To install con- tainers using FTP, place the container package in the Install/Container directory. Language Add-Ons DotNetNuke 3.0 added support for multiple languages. The DotNetNuke implementation loosely fol- lows the localization architecture and naming conventions of the upcoming ASP.NET 2.0 framework. DotNetNuke 3.0 only recognizes a single type of language add-on: a Language Pack. This will likely change in future DotNetNuke versions as the Language Pack is split into Core Language Packs and Module Language packs. Language Packs The multi-language architecture poses a unique challenge for creating and installing Language Packs due to the number of directories and files involved. Like code add-ons, Language Packs utilize a mani- fest file to manage the meta-data necessary to get all of the files installed to the correct directory. 378 Chapter 14 18_595636 ch14.qxd 5/10/05 9:55 PM Page 378 Language Pack Manifest File The Language Pack manifest file follows a very simple format, as shown in Listing 14-7. Listing 14-7: Language Pack Manifest File Format <?xml version=”1.0”?> <LanguagePack xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” Version=”3.0”> <Culture Code=”” DisplayName=”” /> <Files> <File FileName=”” FileType=”” ModuleName=”” FilePath=””/> </Files> </LanguagePack> The Language Pack manifest file relies more on the use of attributes, which is a more compact format than using simple elements. Table 14-11 lists the key elements of the manifest file. Table 14-11: Manifest File Elements Element Name Description LanguagePack The LanguagePack element is the root element for the manifest file. This ele- ment must be created exactly as shown in Listing 14-7. The installation code will validate the file against the listed schemas. Culture The Culture element defines the culture information associated with the cur- rent Language Pack. The Culture contains two attributes: Code and Display- Name. The Code attribute takes a value corresponding to a valid culture name as defined by the .NET Framework System.Globalization.CultureInfo class. The DisplayName defines the name to display when selecting lan- guages in the portal framework. Files The Files element contains one or more File nodes that provide the informa- tion necessary to properly install the individual resource file identified by the File node. See Table 14-10 for more information about the individual attributes of the File element. Each language resource included in the Language Pack must be identified by a corresponding file ele- ment in the manifest (see Table 14-12). The files will be saved based on predefined rules depending on the file type. Table 14-12: Manifest File Elements Attribute Name Description Required FileName The FileName attribute defines the name of the physical file. Yes The filename should not include any path information. Table continued on following page 379 Distribution 18_595636 ch14.qxd 5/10/05 9:55 PM Page 379 Attribute Name Description Required FileType The FileType attribute defines the type of file identified by Yes this node and is used by the portal to determine the root directory where the file will be installed. The FileType must be one of four values: GlobalResource, AdminResource, ControlResource, or LocalResource. See Table 14-11 for more information on these file types. ModuleName The ModuleName attribute is required for files marked as No AdminResource or LocalResource. This value identifies the name of the Admin or DesktopModule that is associated with this file. The ModuleName is the same as the directory name where the module is installed. FilePath The FilePath attribute defines a path relative to the default No resource path. The file path where the file will be saved is: [RootPath]\[ModuleName]\[FilePath]\[ResourceDirectory]. The RootPath and ResourceDirectory values are determined by the file type and are defined in Table 14-11. The FileType attribute will be used to determine the appropriate RootPath and Resource directory (see Table 14-13). The RootPath value corresponds to specific directories defined by DotNetNuke. Admin modules, Controls, and DesktopModules are the only DotNetNuke elements that are permitted to have local language resources. All other elements should use the Global resources. The Resource directory is defined to correspond to ASP.NET 2.0 values and are subject to change before the final ASP.NET 2.0 release. Table 14-13: FileType Values FileType Description RootPath Resource Directory GlobalResource Shared resources \ App_GlobalResources AdminResource Admin module resources \admin App_LocalResources ControlResource Control resources \controls App_LocalResources LocalResource DesktopModule resources \Desktopmodules App_LocalResources To simplify the creation of the manifest file, DotNetNuke includes the ability to generate the Language Pack including the manifest file. Although the manifest file may be hard to maintain by hand, it is a for- mat that lends itself well to automatic generation and is easily read during the installation process. Listing 14-8 shows a partial listing of the generated Deutsch (German) manifest file. Listing 14-8: German Language Pack Manifest <?xml version=”1.0”?> <LanguagePack xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” Version=”3.0”> 380 Chapter 14 18_595636 ch14.qxd 5/10/05 9:55 PM Page 380 <Culture Code=”de-DE” DisplayName=”Deutsch” /> <Files> <File FileName=”GlobalResources.de-DE.resx” FileType=”GlobalResource” /> <File FileName=”SharedResources.de-DE.resx” FileType=”GlobalResource” /> <File FileName=”TimeZones.de-DE.xml” FileType=”GlobalResource” /> <File FileName=”Announcements.ascx.de-DE.resx” FileType=”LocalResource” ModuleName=”Announcements” /> <File FileName=”EditAnnouncements.ascx.de-DE.resx” FileType=”LocalResource” ModuleName=”Announcements” /> <File FileName=”Address.ascx.de-DE.resx” FileType=”ControlResource” /> <File FileName=”DualListControl.ascx.de-DE.resx” FileType=”ControlResource” /> <File FileName=”Classic.ascx.de-DE.resx” FileType=”AdminResource” ModuleName=”ControlPanel” /> <File FileName=”IconBar.ascx.de-DE.resx” FileType=”AdminResource” ModuleName=”ControlPanel” /> </Files> </LanguagePack> Packaging Language Packs A Language Pack includes three different types of files: ❑ Language Resource File: A language resource file is a standard .NET resource file that includes a key name and the localized value. A call to the DotNetNuke method GetString(key) returns the value that corresponds to the key. ❑ Time Zones File: The TimeZones file includes a list of time zones that are recognized by the DotNetNuke portal. ❑ Manifest File: The manifest file identifies the resource files included in the Language Pack. DotNetNuke includes the ability to generate Language Packs for any of the languages/cultures that are currently installed on your portal. Given the number of files and directories involved in creating a com- plete Language Pack, the generator is the recommended method for creating Language Packs. Not only does it simplify the creation process, but it also ensures that all necessary files are included and that the manifest file is properly formatted. Follow these simple steps to create a Language Pack. Step 1 Log in with the Host account and go to the Languages page on the Host menu (see Figure 14-15). Although the Admin account has some ability to edit language resources, they do not have the necessary permissions to Generate or Import Language Packs. 381 Distribution 18_595636 ch14.qxd 5/10/05 9:55 PM Page 381 Figure 14-15 Step 2 The Languages screen provides a number of options for adding new Locales/Languages to your portal. If you want to generate a Language Pack for a language that does not show up in the Supported Locales list, you must first add the language to your portal. (See Chapter 4 for more information about adding additional languages.) Select Create Language Pack from the Action menu or from the links at the bot- tom of the screen as shown in Figure 14-16. Figure 14-16 Step 3 Select the Locale for which you want to create a Language Pack and then click the Create link (see Figure 14-17). 382 Chapter 14 18_595636 ch14.qxd 5/10/05 9:55 PM Page 382 Figure 14-17 Step 4 After the Language Pack has been created, you will be presented with a complete log showing all of the files added to the Language Pack (see Figure 14-18). You should review the logs for errors, which will be highlighted in red. Additionally, the log shows you important information about the directory where the generated Language Pack is stored. The log also provides a link to the File Manager so that you can download the Language Pack from the portal server. Figure 14-18 Installing Language Packs Just like code and skinning add-ons, Language Packs also support two installation methods: web-based and FTP-based. Language Packs can include hundreds of files, which must be properly referenced in the manifest file. Any mismatch between the files identified in the manifest and files included in the Language Pack will result in an error. Additionally, the manifest file controls where each resource will be installed. An error in the manifest could result in a resource file being installed into the wrong directory. If the DotNetNuke Language Pack Generator was used to create the Language Pack, the likelihood of errors during installation is significantly reduced. 383 Distribution 18_595636 ch14.qxd 5/10/05 9:55 PM Page 383 Web-Based File Upload Follow these four steps to install a new language into your portal using the web-based installer. Step 1 Log in with the Host account and go to the Languages page on the Host menu (shown previously in Figure 14-15). Although the Admin account has some ability to edit language resources, it does not have the necessary permissions to Generate or Import Language Packs. Step 2 The Languages screen provides a number of options for new Locales/Languages. If you want to gener- ate a Language Pack for a language that does not show up in the Supported Locales list, then you must first add the language to your portal. (See Chapter 4 for more information about adding additional lan- guages.) Select Upload Language Pack from the Action menu or from the links at the bottom of the screen (see Figure 14-19). Figure 14-19 Step 3 The File Upload screen appears (see Figure 14-20). Select the file you want to upload and then click the Upload New File link. Step 4 After the Language Pack has been uploaded, you will be presented with another File Upload screen. This screen displays the complete Resource Upload Logs showing all of the files that have been uploaded (see Figure 14-21). You should review the logs for errors, which will be highlighted in red. Additionally, the log shows you important information about the directory where the generated Language Pack is stored, and the log provides a link to the File Manager so that you can download the Language Pack from the portal server. 384 Chapter 14 18_595636 ch14.qxd 5/10/05 9:55 PM Page 384 [...]... of, 16–17 405 Index DotNetNuke (DNN) [DOTNETNUKE] object [DOTNETNUKE] object, 338, 345, 366 DotNetNuke. Common namespace, 205 DotNetNuke. Data namespace, 205 DotNetNuke. Data.SqlDataProvider script, 199 DotNetNuke. Entities namespace, 206 DotNetNuke. Framework namespace, 206 DotNetNuke. Modules namespace, 206 DotNetNuke. Schema.SqlDataProvider script, 199 DotNetNuke. Security namespace, 206 DotNetNuke. Services... AdministratorId property, PortalSettings, 397 AdministratorRoleId property, PortalSettings, 397 AdministratorRoleName property, PortalSettings, 397 AdminTabId property, PortalSettings, 397 advertising banners adding to page, 161–163 creating for vendors, 103 105 AffiliateID property, UserInfo AffiliateID property, UserInfo, 398 affiliates adding vendors as, 105 106 tracking, 107 aliases for portals, 127, 392... questions about DotNetNuke are asked again and again Each released version of DotNetNuke tends to create a new set of frequently asked questions The following includes many of the questions that are often asked in the support forums Q: What folder permissions are necessary to run DotNetNuke? A: You need to grant the account that ASP.NET runs as FULL CONTROL over the root folder of DotNetNuke For further... to the path “C:\WebSites \DotNetNuke\ Portals\ 0\ portal.css” is denied” mean? A: This is usually caused by one of two problems The permissions may not be set correctly on the Portals directory See Chapter 2 for details This can also happen when a source control application is open while trying to install DotNetNuke Try closing the source control application before installing DotNetNuke Q: How do I set... DotNetNuke. Schema.SqlDataProvider script, 199 DotNetNuke. Security namespace, 206 DotNetNuke. Services namespace, 206 DotNetNuke. Services.Exceptions namespace, 216 DotNetNuke. Services.Log.EventLog namespace, 208 DotNetNuke. SetUp.SqlDataProvider script, 199 DotNetNuke. UI namespace, 206 downarrow attribute, [SOLPARTMENU], 342 downloading DotNetNuke, 32 Draco.NET (Chive Software Limited), 388 drag and drop, for modules, 178, 179... containers, 154 of DotNetNuke Business Logic layer, 195, 197–198 Data Access layer, 195, 198–199 Data layer, 195, 199–201 description of, 195 Presentation layer, 195, 196–197 of modules, 151–154 of pages, 153 of portals, 152 ascx filename extension for private assembly archives (module add-ons), 361 for skin and container packages, 335, 371 for skins, 331 402 ASP.NET account name being used to run DotNetNuke, ... control application before installing DotNetNuke Q: How do I set the default language for all portals? A: The best way to set the default language for all portals is to make a Site Template and specify the culture in the template The easiest way is to modify the default template (located at /Portals/ _default/ DotNetNuke. Template), or at least create a copy of it and modify the default language tag as... completes our discussion of DotNetNuke development We have progressed from administering standard DotNetNuke installations to creating DotNetNuke modules and skins, and finished by documenting the steps needed to package, distribute, and install these add-ons You are now ready to begin work on using DotNetNuke to build professional web sites that fully take advantage of the power, flexibility, and extensibility... EditEvents control, 316–321 EditText filename extension, 223 EditURL function, 328–329 e-mail of Host, setting address for, 117 newsletters, 106 107 notification of log events, 132–133 Email property PortalSettings, 397 UserMembership, 398 e-mail templates, 98 100 end date, for modules, 157 EndRequest event, HTTP modules, 235 406 Enhanced Feedback (Slalom Services), 389 Error event, HTTP modules, 235... 223 Event Handlers region Edit control, 323–327 View control, 310 313 event log classification, 208 event logging API classes for, 208–209 buffering, 125 in Business Logic layer, 197 definition of, 208 history of development of, 25 log classifications for, 208 log types for, 208, 209– 210 logging events, 210 214 monitoring with Log Viewer, 109 –111 EventInfo class, 290–293 EventLogController class, 209–214 . necessary to run DotNetNuke? A: You need to grant the account that ASP. NET runs as FULL CONTROL over the root folder of DotNetNuke. For further information, see Chapter 2, “Installing DotNetNuke. ” Q:. ch14.qxd 5 /10/ 05 9:55 PM Page 385 Summary This chapter completes our discussion of DotNetNuke development. We have progressed from adminis- tering standard DotNetNuke installations to creating DotNetNuke. Add-Ons DotNetNuke 3.0 added support for multiple languages. The DotNetNuke implementation loosely fol- lows the localization architecture and naming conventions of the upcoming ASP. NET 2.0 framework. DotNetNuke