Applying What You ve Learned

Applying What You've Learned

Now, the following sections walk through the development of the site and combine the techniques learned in the previous chapters.

Website Install and Preparation

All Multisites installations need multiple host entries to handle the different domains for each branch. This Case Study has eight different sites, and the Apache VirtualHost entries look like the following sample code:

 <VirtualHost *> DocumentRoot /www/bigabyte.intranet ServerName intranet.bigabyte.com </VirtualHost> <VirtualHost *> DocumentRoot /www/bigabyte.accounting ServerName accounting.bigabyte.com </VirtualHost> <VirtualHost *> DocumentRoot /www/bigabyte.admin ServerName admin.bigabyte.com </VirtualHost> 

Each of the branches of the intranet Multisites cluster needs a separate install of PostNuke. Copy the same PostNuke files into each of the different directories defined for the web server. They will share the same database, but each install must be set up to use a different table prefix. Try taking the names of the different site branches to derive the prefixes. Table 26.1 shows the prefixes used in this example.

Table 26.1. Database Table Prefixes

SITE NAME	TABLE PREFIX
Intranet	intra
Accounting	acc
Administration	admin
Development	dev
Human Resources	hr
Information Technology	it
Marketing	mark
Sales	sales

The config.php files for each site should be respectively configured to use these prefixes for their tables. These sites are also designed to be served internally on an intranet. Check the Site Is for Intranet or Other Local (Non-Internet) Use box at the 40% mark for each install of PostNuke to disable the unneeded extra security functions.

After the installs are complete, the /install/ directories and install.php files need to be removed from every site. Even in a secure internal environment, accidents can happen, and there's no reason to keep those files on a site after it becomes live.

From the Modules Administration table, the AutoLinks, Banners, Ephemerids, Quotes, Reviews, and Xanthia modules should be deactivated for every site. This helps simplify the Administration Menu for the different sites. AutoTheme will be used by all of the sites, so install this module throughout the cluster.

Note

AutoTheme is available in 5 and 10 license packs with discounted pricing. Visit spidean.mckenzies.net for current pricing and options.

The database changes required to make a Multisites cluster work should be completed before too much effort goes into customizing each branch. This not only makes the site development easier, with single changes from shared user accounts for example, but it also allows you to begin testing your Multisites settings immediately to determine if any other tweaks are needed.

Combine the user accounts between all the sites by sharing these tables: group_membership, groups, priv_msgs, user_data, user_property, userblocks, and users. Don't share the group_perms or user_perms tables to make each site's access different. For example, one department might have content managers who can administrate its site, but on other department branches those employees are simply users. The group_membership and groups tables can also be kept unique to require fewer groups, but it is much easier to manage a site cluster in which a new user on one site is automatically a user on all other sites.

News is shared through the autonews, stories, stories_cat, topics, and queue tables. To combine the Admin Messages module, change the message table. In addition, given that this site also has a known set of users, there's no reason not to combine the language tables languages_constant, languages_file, and languages_translation. Then, any additional languages installed for one department branch are automatically available to the entire intranet site.

The site statistics should be combined to ensure realistic data. For example, an employee who visits two branches of the intranet site generates double sessions and hits unless the data is combined to allow one session to move between all branches. Share these tables to make it happen: counter, referer, session_info, stats_date, stats_hour, stats_month, and stats_week. Finally, the comments and hooks tables should also be combined for the sites to maintain consistency of content and features for different modules between the site branches.

The shared tables need to be renamed to use the prefix "share," and although any of the installs can be used as a source, it is often conceptually easiest to use the main hub install for your cluster, in this case the intra tables. After the tables have been renamed, also edit the various pntables.php files in each PostNuke install to reflect the table changes.

Tip

If you are careful while choosing search wording, you can open up several pntables.php files in your editor at once and perform global search and replace changes to the key tables listed previously. It can save a great deal of time, especially when altering multiple identical files.

With the last of the pntables.php changes saved, the Multisites cluster is complete and the frontend development can begin.

Module Setup and Hacks

The News module tables are shared across all of the sites, but the built-in categories will be used to separate postings for different department sites. From the Add Story form, add additional categories for each department. Use the "Default Articles" edit described in Chapter 22, "News and Article Hacks," to change Articles to All Departments. Articles can now fall under the customized department categories shown in Figure 26.1.

Figure 26.1. Posting globally or privately with specialized categories.

The Article Title and Links hacks should also be used to remove the Section name from being displayed with different articles. The permissions will be set to disallow the access to categories that are not relevant to a particular department. For example, HR employees submitting articles will only see the All Departments and Human Resources categories. The hack changes need to be made to each installation of PostNuke, but after you change a file, it can easily be copied over the source in the other installs.

The User Registration Configuration under User Administration should be set to simplify the account creation process by not validating email addresses and removing the age check. These fields on the Dynamic User Data page can all be disabled: Fake Email, Homepage, ICQ, AIM, YIM, MSNM, and Interests. Smaller businesses might also not need the Time Zone Offset, Location, or Occupation fields. Additional fields can now be added, though the specific field needs will vary for different businesses or organizations. Some suggested fields are listed in Table 26.2.

Table 26.2. Optional User Data Fields

FIELD	FIELD LABEL	DATA TYPE
Department	_DEPARTMENT	String
Job Title	_JOBTITLE	String
Work Phone	_WORKPHONE	String
Cell Phone	_CELLPHONE	String
Fax	_FAX	String
Work Address	_WORKADDRESS	Text
Home Phone	_HOMEPHONE	String
Home Address	_HOMEADDRESS	Text

The wording of various messages should be adjusted at this point by editing the different modules' global.php files, and the user system can be polished further with other changes, such as the login timer bar, as discussed in Chapter 24, "Login System Hacks and Modules."

The separate installs of PostNuke for each site allow the different departments to customize their sites with different modules. For example, the Human Resources department can use the Web Links module to list job openings. The links can be made directly to internal documents or a wrapper can be employed to integrate the site with a separate job application system. Accounting can similarly link to current budget reports or analyses.

Pagesetter is a good choice for the Marketing department to create a custom content system for company information and press releases. Development, Marketing, and Sales can collaborate using Pagesetter to document product materials for customers.

Administration and Information Technology can use the Advanced Polls module to get instant feedback on different issues announced in the Admin Messages posting. Information Technology might also find the FAQ module a great tool for creating a self-help system for common computer problems. Human Resources and Marketing both can use the pnESP module to survey employees for needs and feedback. And any department can benefit from the PostCalendar module to schedule and announce events.

Because the user system is combined, any employee of the company simply needs to visit the respective department site to access the information the department provides to the rest of the company.

Groups and Permissions

The new groups must first be developed so that permissions can be assigned. The same groups are used for the entire cluster, so it does not matter from which site the group changes are made. The Admins group is kept but renamed to Global Admins. This group will have administrative access to all sites. Because the default Admins group already has those privileges, it's easy to use that group for the global Multisites administrators.

The default users group is also kept with the same access rights installed by default. For this example, the users of a given department can submit content and make comments to any site in the cluster. An unlimited number of site and permissions settings combinations are available, which could be used with Multisites, and certainly there could be more groups to define more types of users, such as content approvers or members of single departments.

Two new groups need to be created for each site in the cluster: Site Admins and Managers. The first group will have identical access to the Global Admins, but only for one department site. The Managers group allows selected users to oversee and approve content within a specific department site. The prefixes used for the database tables can be used here to shorten the group names. Figure 26.2 illustrates the group setup.

Figure 26.2. Groups for a Multisites cluster.

With the groups table shared, creating the different names from any site makes them available from all others in the Multisites cluster. Sharing the group_membership table means when you add a user to one of these groups, the membership also carries automatically to all of the other sites.

Permissions for each branch site build upon the default settings. The Users group permission granting Comment access should be edited to apply to All Groups. This edit drastically simplifies the amount of changes you need to make to support the longer group listing. Now, any group not listed in a particular branch's Permissions table is treated no differently than the Users group.

Above line two where All Groups are restricted from the Main Menu's Administration link, add two new entries for the Site Admins and Managers groups needed for each respective site. For the Sales department site, the first entry is:

 Site Admins - Sales    |    .*    |    .*    |    Admin 

And the second should look like this:

 Managers - Sales   |    (Stories::|Admin_Messages::|Sections::| Topics::|Web_Links:: |Menublock::)   |   .*   |   Delete 

The Site Admin entry gives group members complete access to the Sales site, but because these permissions do not carry to other sites in the cluster, they are only users elsewhere in the Multisites cluster. The second entry grants full content management access for Managers to main content modules. If additional content modules like Pagesetter or pnESP are installed, they should be added to this line. The final entry for MenuBlock ensures Managers will see the Administration link in the Main Menu. The basic hierarchy for the site permissions is now set up.

Next, segregate the news by department category using two entries above the Site Admins row and below the top Global Admins row. The following examples are written for the Marketing department. The first line has this data:

 All groups   | Stories::Category       | (Accounting|Administration|Development|Human Resources|Information Technology | Sales):: |   None 

And the second should contain this:

 All groups   | Stories::Story       |     :(Accounting|Administration|Development|Human Resources|Information Technology | Sales):     |   None 

The first prevents access to the non-Marketing categories, for example from the Add Story form. The second prevents view of the stories themselves as they are listed on a site's News page. Because these entries are below the Global Admins top access, accounts in the Global Admins group will always see all news together no matter what site they are on.

That completes the global changes needed for all departments, but each department has other unique settings that should be added. The Admin Messages module can be restricted to allow posts from specific departments, such as Administration and Information Technology. The line should be above the Site Admins entry and look like this:

 All Groups    |    Admin_Messages::    |    .*    |    Read 

Any other module can be rendered read-only to a department with an addition to that line. Figure 26.3 shows how these settings can be combined for the Human Resources department permissions.

Figure 26.3. Permissions for the Human Resources department.

Note

For sites in which content modules are restricted, the Managers entry can also be simplified, removing the modules from which they are restricted. But because the restriction overrides the standard Manager permission line, it does not cause a problem to leave it, as shown in Figure 26.3. Should the department module restrictions change later, the Managers entry is already prepared.

Interface

Intranets are focused on functionality over form and generally possess more spartan designs than their public counterparts. There is no need to aggressively market toward existing employees, and large intranet portals can always use the space for more content. For this Multisites cluster, a simple tabbed navigation system at the very top of every page provides direct access to other departments. The navigation system can be generated using a short PHP script as in the following sample code:

 $currentsite = "Administration"; $departments = array("Accounting", "Administration", "Development", "Human Resources", "Information Technology", "Marketing", "Sales"); echo "<div style=\"width:100%; height:33px; background-image:url('". $imagepath ."images/nav-bg.gif');\"><table cellpadding=\"0\" cellspacing=\"0\" style=\"width:100%; border:0px;\"><tr>"; for ($i = 0; $i < count($departments); $i++) {     $class = "navoff";     if ($departments[$i] == $currentsite) { $class = "navon"; }     $imgname = "offoff";     if (($i == 0) and ($class == "navon")) { $imgname = "lefton"; }     elseif (($i == 0) and ($class != "navon")) { $imgname = "leftoff"; }     elseif (($i != 0) and ($class == "navon")) { $imgname = "offon"; }     elseif (($i != 0) and ($departments[$i-1] == $currentsite)) { $imgname = "onoff"; }     echo "<td><img src=\"". $imagepath ."nav-". $imgname .".gif\" /></td><td class=\"$class\">$departments[$i]</td>";     if (($i+1) == $count($departments) {          $imgname = "rightoff";          if ($class == "navon") { $imgname = "righton"; }          echo "<td><img src=\"". $imagepath ."nav-". $imgname .".gif\" /></td>          }     } echo "</tr></table></div>"; 

Take this code and apply it to all the department sites through the creation of a new AutoTheme command, and for each site's theme, change the $currentsite variable to reflect the local content (see Figure 26.4). A reusable navigation system can also help maintain consistency when a department theoretically has the ability to change nearly everything about its site.

Figure 26.4. Simple navigation for Multisites.

The different departments can use the AutoTheme templates and AutoBlocks to customize their employee interface greatly. Contrast the Human Resources and Information Technology branches. The HR uses older transitional-level XHTML blocks in a traditional PostNuke layout. The following is an example of the left-side block code:

 <div style="width:160px; height:33px; background-image:url('{image-path} leftblock- back.gif');"> <table border="0" cellpadding="0" cellspacing="0" width="100%"><tr> <td style="width:100%; text-align:center; font-weight:bold;">» <!-- [block-title] --></td> <td style="width:13px;"><img src="/books/1/160/1/html/2/{image-path}leftblock-head.gif" /></td> </tr></table></div> <div style="background-color:<!-- [color2] -->; padding:5px; border-right:5px solid <!-- [color2] -->;"><!-- [block-content] --></div> <div style="background-color:<!-- [color2] -->; height:5px;"><img src="/books/1/160/1/html/2/{ image- path}space.gif" style="width:5px; height:5px;" /></div> <div style="background-color:<!-- [color4] -->; height:1px;"><img src="/books/1/160/1/html/2/{ image- path}space.gif" style="width:5px; height:1px;" /></div> <br /> 

The IT branch site breaks from the left/right format by structuring all content in AutoBlocks. It uses more current XHTML with an emphasis on styles. The cascading style sheets (CSS) for the blocks is written as this:

 .itblock-title      { background-position:top right; background-repeat:no-repeat; padding:8 8 0 8; color:#000; font-size:13px; font-weight:bold; text-transform:uppercase; } .itblock-body       { background-position:bottom left; background-repeat:no-repeat; padding:0 8 8 8; font-size:11px; font-weight:normal; } 

The use of styles and a tableless structure greatly simplifies the individual block code to the following:

 <div style="width:170px; background-color:#FFF;"> <div  style="background-image:url('{image-path}itblock-top.gif');"><!- - [block-title] --></div> <div  style="background-image:url('{image-path}itblock- bottom.gif');"><!-- [block-content] --></div> </div><br /> 

The separate AutoTheme installs truly mean each site could be completely different from the others, while still sharing the underlying database structure and content. The freedom to develop with different designs, coding styles, and standards levels within the same Multisites system makes it possible for more developers at different skill levels to collaborate on the project.