Deploying Contribute 3.1: New Features and Options

Michael Hazard

University of Rochester Medical Center

This article explores how the medical school at the University of Rochester Medical Center is using the latest updates to Contribute 3 and Contribute Publishing Services (CPS). It is not a hands-on technical article, but rather an overview of how the medical center has deployed the 3.1 update to Contribute.

This article focuses on three new features: overlapping sites, publishing files directly to the server, and deploying files from a staging server to a live server. In an upcoming article, Zachary Roth, Lead Programmer for the medical center’s Web Technology Group, discusses customizing the publishing services in more detail.

Requirements

To complete this tutorial, install the following software and files:

Macromedia Web Publishing System

• Try
• Buy

Pricing Options for Macromedia Web Publishing System

• Learn more

Prerequisite knowledge:

This article assumes familiarity with Contribute 3 and Contribute Publishing Services.

Working with Overlapping Sites

Currently, the University of Rochester Medical Center is undergoing a large-scale redesign. They created the original site seven years ago and it’s more than showing its age. The original site was not architected to support more than a few hundred pages. As the years progressed, the site grew more and more cluttered. For example, the root of the site contains a single includes folder. This folder now holds 125 different includes, each with names such as "airinc.htm."

Higher education sites are a bit different than corporate sites. Typically, departments are completely responsible for their own content. There is nobody that oversees content, and therefore departments are free to do what they want. Looking at it this way, you can think of a department as its own site. Sure, they place standard navigation elements on their pages—links to the school's index page and so forth, but beyond that, a department site is on its own. Unfortunately for the medical center, the URMC site was not originally setup to support this reality. Since all departments share includes, images, documents, and other folders, they all must have access to the root of the site. Before Contribute, most of the web authors used Dreamweaver to maintain sites. The users defined their Dreamweaver sites as the root of the staging server. This gave all users access to the entire staging server.

To add to the confusion, the original site did not use templates, such as those commonly used in products like Dreamweaver. Therefore, users have access to all elements on a page. Needless to say, it was time to redesign the site.

When the Web Technology Group started working with various departments in the medical center, they decided that each department would have its own "sitelet" (In other words, each department’s folder on the site would have its own includes and templates folder). This made organization of the site much easier. At the same time, we decided to standardize on Dreamweaver and Contribute as the preferred site maintenance tools.

With the release of Contribute 3, we deployed Contribute Publishing Services to enable easier account maintenance and workflow. The rollout of Contribute 3 was not without problems though. Contribute Publishing Services did not support nested site definitions. Therefore, the root of the URMC site could not be defined as a site if folders within the root were defined as sites too. For example, the URL, staging.urmc.edu and staging.urmc.edu/smd/urology, could not exist as separate sites within CPS. Our only solution was to roll out Contribute and CPS to those departments that had newly redesigned sites. Users maintaining "old-style" URMC pages could not use CPS.

With the release of the 3.1 dot release of CPS, nested sites are now supported. Now the root of the URMC staging site and the folders within the root can be separate sites in CPS. It is important to understand how permissions work within nested sites such as those found at the URMC. Roles and privileges for a child site (a site located under another site) are not inherited from the parent site. Therefore, it is possible to define a role, for example, a writer role, for a parent site that does not have permission to publish pages and also define a writer role for a child site that can publish.

In the current incarnation of CPS, each site, whether it is nested within another site or not, has its own set of roles and permissions. However, if a user has a defined connection to two sites—one a child to the other—the child site’s administrative settings apply when editing pages within the child folder. As an example:

Staging.mysite.com/
	-/_mm

Staging.mysite.com/mylab/
	-/_mm

If a user is defined to both the root site and the mylab site, Contribute uses the mylab site definitions when editing pages within the mylab folder. Nested sites don’t just affect roles and permissions. You must also consider how they influence workflow when creating a nested site. Users can only send a page for review to other users defined within the current site. Therefore, if you’re working on a child site, the users that make up a parent site will not be listed in the Send For Review dialog box unless they are part of the child site too.

For the medical center, the choice to use nested sites was an easy one. Departments are free-standing entities. Because of this, workflow only happens within a department, and never between departments. However, you should carefully consider how you set up your sites and carefully consider whether you want to create nested sites. If you do decide to create nested sites, and if workflow between the sites is necessary, consider having users connect to both the child and parent sites. Doing so will ensure that they have access to workflow and objects such as templates and shared assets.

Publishing from Staging to Live Areas

One of the features that Contribute 3 lacked was a deployment tool for publishing from a staging area to a live site. Most medium size websites use some sort of a staging area where development and quality assurance occurs. Once a page is approved it is moved to the live site. While the Contribute Publishing System allowed developers to create web services that could move files from staging to live areas, there was no out of the box tool for doing so. Organizations needed to build their own tool. Of course, since the CPS used web services, an organization could create their tool in any language and platform they chose (.NET, Coldfusion, and so forth). To deploy the home-grown deployment service, Contribute administrators needed to edit configuration XML files. While not difficult, it certainly wasn't as user-friendly as it could have been.

The latest release of CPS not only contains a new interface for adding site services, it also ships with a sample Coldfusion application that helps you publish pages from staging to live servers. The new interface, in Figure 1, makes it very easy to add additional services to individual sites—you no longer have to modify XML files and so forth. In addition, it's a lot easier to review a site's setting from a single interface.

Figure 1. The Website Settings display in the Contribute Publishing Service point release.

(+) View larger

Note: You can add, edit, remove, and test services from within a single tab.

The File Deployer service that is included with the update to CPS is a Coldfusion-based application. You can use a compiled version of the service with CPS. The compiled version runs on the OEM version of JRun that's included with CPS. It's important to note that the File Deployer service does not automatically promote files from staging to live areas; instead, it stores information about published pages (and the additional files associated with the page such as new images and linked documents). To deploy a page to a live server you must open a management window, as shown in Figure 2.

Figure 2. The File Deployer Service web application.

Note: The service can display previews of the page content on the staging server and live server side-by-side.

You access the File Deployer application through a browser. The service lists all files that have been published through Contribute. You can even view previews of the updated page (on the staging server) and the current live version, as seen in the screen shot above. It's important to note that only sites managed by CPS and that have the Simple File Deployer installed have this feature. It is not a Contribute feature, but a CPS feature. It is also important to note that the management site seen above does not have any security applied to it. Anyone could therefore open the page and deploy files. If you plan on using the Simple File Deployer, you will probably want to customize the application.

To customize the application, you must modify a separate set of CFM files. Only the compiled File Deployer (the application seen above) will run on the OEM version of JRun that ships with CPS. Therefore, if you want to modify the system, you must host it on a separate installation of Coldfusion, or you can write your own service for another development platform. If you are using Coldfusion, you're in luck, as the source files that make up the File Deployer are available in uncompiled form. The University of Rochester Medical Center uses a modified version of the File Deployer for its site. In an upcoming article, Zach Roth describes how the URMC modified the File Deployer to meet our needs, but in general terms, we removed the management web interface and simply move all published files to the live server when the Publish button is pressed. This is perhaps a more common workflow. Since you can turn off the Publish button for those users who you don't want to give publishing rights to, the URMC has decided to use the Publish button as nothing more than a trigger to move files from staging to live areas. The Publish button is therefore only enabled for those users who have permission to approve content. In most cases, each department identifies individuals as content approvers; and gives this group rights to publish.

Publishing Local Files Directly to the Server

One final new feature found in the update that should be noted is the ability to upload files directly from a user's desktop to the server. Using the new Publish File From My Computer feature, users can easily publish a file from their computer to the server without having to use the Browse > Edit > Publish workflow. Instead, users simply choose the option from the File menu, select a file, and select the site use, and publish the file.

It's common for users to update certain documents on a regular basis. For example, someone in the Web Technology department may need to post an Excel file that contains site statistics each month. To do this, the user chooses File > Publish File From My Computer and browses to the file that they wish to publish. Contribute then prompts the user to select the website where the file will be published. If the file already exists on the server, users can overwrite the existing file, as seen in Figure 3.

Figure 3. Users select which website to publish the file to and then choose to overwrite the file if it already exists.

Where to Go from Here

This has been a broad overview of the improvements made to Contribute 3 and CPS. There are many more new features available, and it's recommended that you download the CPS demo if you're not currently using it. Be sure to explore the other sample service, the RSS feed generator for another interesting exploration of the extensibility of CPS.

If you're planning on rolling out Contribute 3 and CPS, plan on putting a lot of time into designing how to define sites (Contribute sites) within your site. While Contribute 3 and CPS now support nested sites, consider how nested sites may impact workflow and user/roles/permissions. For a complex site, I recommend that you sketch out the relationship between users and sites and develop a diagram of how you need users to interact with each other before rolling out Contribute. While you can certainly go back and fix a poorly planned implementation of Contribute/CPS, you'll be wasting a lot of time and effort, as you will likely need to retrain users anytime you modify your workflow.

About the author