Multisites Basics

The first thing to know about Multisites is it's a hack. The source files are there for you to use to create your cluster, but you still have to edit the files and know what you are doing. There really are not many changes, and some of the hacks detailed earlier in this book would be considered more difficult, but the process is still somewhat involved and not really for the faint of heart.

The second thing to consider is what you want out of a Multisites cluster. What needs to be shared between the sites? What must always be separate? Is it more of a single site that branches off, or do you want to link up pre-existing, standalone sites? You can approach the clustering in different ways, and you should have a very good idea of what you want to accomplish before you begin.

Documenting Domains

PostNuke does not care how many domains you want to use or whether they are full or subdomains. The important thing is that each site or site piece has its own fully qualified URL. Suppose, for example, that there are a series of sites all dealing with pets. Some examples of domain variations that might be used for the sites include

• www.familypets.com

• dogs.familypets.com

• cats.familypets.com

• forums.familypets.com

• www.familycats.com

• www.familypets.org

• www.familypets.co.uk

You can, of course, add sites to a Multisites cluster after its creation, but it's easier to plan for your site's needs as fully as possible the first time.

Now document what each domain will be used for. Will the sites share news? User accounts? Does a domain stand alone as a full site, or is it just a portion of the whole? Write out what you intend so you can refer back to your notes as you complete your changes.

As an example of the documentation, you'll create that pet site using the domains www.familypets.com, dogs.familypets.com, and forums.familypets.com. The main "www" is the primary site created first and serving as a foundation on which to build the others. The "dogs" variant pulls content from the main site but is a subset, where only dog-related information is shown. The "forums" site is also a branch from the main, but it has its own content and forums module and mainly shares user accounts.

Documenting Tables

Now, you need to document exactly what table information will be shared by each domain. Look through the modules installed with PostNuke. Consider what features each module has, and what you plan to share or specifically not share. Set up a simple table that documents these specific needs, by domain. Table 25.1 lists an example of the information you will be collecting.

Table 25.1. Documenting Multisites

RESOURCE	WWW	DOGS	FORUMS
Comments	Shared	Shared	Shared
FAQ	Shared	Not Shared	Shared
Groups	Shared	Shared	Shared
News	Some Shared	Some Shared	Unused
Permissions	Not Shared	Not Shared	Not Shared
Settings	Not Shared	Not Shared	Not Shared
Stats	Shared	Shared	Shared
Themes	Not Shared	Not Shared	Not Shared
User Accounts	Shared	Shared	Shared

Tip

If your sites will not allow users to change the default theme, but you want each site to have a different look, you don't need to duplicate all the themes folders. Just copy the Website Settings table so the default theme is different for each site.

What you are trying to document is the content you care about. There are almost surely modules you do not plan to use on any of the sites, so don't worry about those. The table should contain the structures with which your users will interact.

Note

In the previous example, the News is listed as "Some Shared." It is planned that the News module will be shared between www and dogs, but although all dogs news appears as part of www, only the dogs news appears in dogs. This is written here for documentation, but you learn how it is done later in the chapter.

Now review the tables in your PostNuke install. Go to your database administration tool, such as cPanel or phpMyAdmin, or list them manually from a shell prompt. The pntables.php file in your site's root directory also contains the names of most of the files. The following is a list of the 77 tables contained in the default PostNuke install. The ones missing from pntables.php are shown in italic.

 nuke_autolinks  nuke_languages_translation  nuke_seccont nuke_autonews  nuke_links_categories  nuke_sections nuke_banner  nuke_links_editorials  nuke_session_info nuke_bannerclient  nuke_links_links  nuke_stats_date nuke_bannerfinish  nuke_links_modrequest  nuke_stats_hour nuke_blocks  nuke_links_newlink  nuke_stats_month nuke_blocks_buttons  nuke_links_votedata  nuke_stats_week nuke_comments  nuke_message  nuke_stories nuke_counter  nuke_module_vars  nuke_stories_cat nuke_downloads_categories  nuke_modules  nuke_theme_addons nuke_downloads_downloads  nuke_poll_check  nuke_theme_blcontrol nuke_downloads_editorials  nuke_poll_data  nuke_theme_cache nuke_downloads_modrequest  nuke_poll_desc  nuke_theme_config nuke_downloads_newdownload  nuke_pollcomments  nuke_theme_layout nuke_downloads_subcategories  nuke_priv_msgs  nuke_theme_palette nuke_downloads_votedata  nuke_queue  nuke_theme_skins nuke_ephem  nuke_quotes  nuke_theme_tplfile nuke_faqanswer  nuke_ratings  nuke_theme_tplsource nuke_faqcategories  nuke_ratingslog  nuke_theme_zones nuke_group_membership  nuke_realms  nuke_topics nuke_group_perms  nuke_referer  nuke_user_data nuke_groups  nuke_related  nuke_user_perms nuke_headlines  nuke_reviews  nuke_user_property nuke_hooks  nuke_reviews_add  nuke_userblocks nuke_languages_constant  nuke_reviews_comments  nuke_users nuke_languages_file  nuke_reviews_main 

The listing uses the default nuke_ prefix, which might be different for your install. The respective modules should be clear from the table names. The tables not defined in the main pntables.php file are contained in their respective modules directory in a file of the same name. For example, the theme tables are defined in /modules/Xanthia/pntables.php.

Note

This separation of the table information is part of the pnAPI. As more modules are converted to be fully pnAPI compliant, they will all have separate pntables.php files.

At this point, you need to decide what kind of site cluster you intend to make. The standard way to create a PostNuke Multisites installation is to take a single install and duplicate tables and files that are not shared. This method has the benefit of having the smallest footprint on your server. Little-used or ignored PostNuke tables are only created once. There is only one copy of PostNuke, which not only takes up less drive space but single updates and changes to the one install apply to all sites automatically. The primary drawback to this method is it requires many steps to complete.

An alternative way to create a cluster is accomplished by joining installs. In this option, separate installs of PostNuke are created and specific changes are made in the code to share the correct tables. This method has the benefit of being very easy with few steps. You can make edits and install modules on one install without affecting the other. Drawbacks, however, include duplicates of unneeded tables and files, and it is harder to update the installs. The joining method can, of course, be improved by doing some simple file and database cleanup afterward.

The decision of which method to use might also depend heavily upon what site(s) you already have installed. If you have two living sites you want to combine, for example, the joining method might seem easier, but you also need to combine the existing user data into one set of tables. The potential for duplicate accounts coupled with very large user lists might make the prospect seem not as attractive as creating a split off of one site and moving pieces over as you go.