You must obtain and install an additional download to enable Alfresco WCM functionality. The download includes a new Spring bean configuration file, a standalone Tomcat instance pre-configured with JARs, and server settings that allow a separate Tomcat instance (which is called the virtualization server) to run web applications stored in Alfresco WCM web folders. This capability is used when content managers “preview” an asset or a website. Just as in the core Alfresco server, you can either build the WCM distribution from source or obtain a binary distribution.

Step-by-Step: Installing Alfresco WCM

If you are building from source, the source code for Alfresco WCM is included with the source code for the rest of the product. Once the source code is checked out, all you have to do is run the distribute Ant task as follows:

 ant -f continuous.xml distribute

After several minutes, the WCM distribution will be placed in the build|dist directory of your source code’s root directory. Alternatively, if you are using binaries, download the binary distribution of the Alfresco WCM extension. Where you get it depends on whether you are running Labs or Enterprise. The Labs version is available for download from http://www.alfresco.com. The Enterprise version can be downloaded from the customer or partner site using the credentials provided by your Alfresco representative. Regardless of whether you chose source or binary, you should now have an Alfresco WCM archive. For example, the Labs edition for Linux is named alfresco-labs-wcm-3b.tar.gz.

To complete the installation, follow these steps:

1. Expand the archive into any directory that makes sense to you. For example, on my machine I use |usr|local|bin|alfresco-labs-3.0-wcm.
2. Copy the wcm-bootstrap-context.xml file to the Alfresco server’s extension directory ($TOMCAT_HOME|shared|classes|alfresco|extension).
3. Edit the startup script (virtual_alf.sh) to ensure that the APPSERVER variable is pointing to the virtual-tomcat directory in the location to which you expanded the archive. Using the example from the previous step, the APPSERVER variable would be:

   APPSERVER=|usr|local|bin|alfresco-labs-3.0-wcm|virtual-tomcat
   

4. Start the virtual server by running:

   |virtual_alf.sh start</i>
   

5. Start the Alfresco server (or restart it if it was already running). You now have Alfresco with Alfresco WCM up and running. You’ll test it out in the next section, but you can do a smoke test by logging in to the web client and confirming that you see the Web Projects folder under Company Home.

Creating Web Projects

A web project is a collection of assets, settings, and deployment targets that make up a website or a part of a website. Web projects are stored in web project folders, which are regular folders with a bunch of web project metadata. The number of web project folders you use to represent a site, or whether multiple sites are contained within a single web project folder is completely up to you. There is no “right way” that works for everybody. Permissions are one factor. The ability to set permissions stops at the website. Therefore, if you have multiple groups that maintain a site that are concerned with the ability of one to change the other’s files, your only remedy is to split the site across web project folders. Web form and workflow sharing is another thing to think about. As you’ll soon learn, workflows and web forms are defined globally, and then selectively chosen and configured by each site. Once made available to a web project, they are available to the entire web project. For example, you can’t restrict the use of a web form to only a subset of the users of a particular site. SomeCo has chosen the approach of using one web project folder to manage the entire SomeCo.com website.

Step-by-Step: Creating the SomeCo Web Project

The first thing you need to do is create a new web project folder for the SomeCo website. Initially, you don’t need to worry about web forms, deployment targets, or workflows. The goal is simply to create the web project and import the contents of the website.

To create the initial SomeCo web project, follow these steps:

1. Log in as admin. Go to Web Projects under Company Home.
2. Click Create, and then Create Web Project.
3. Specify the name of the web project as SomeCo Corporate Site.
4. Specify the DNS name as someco-site.
5. Click Next for the remaining steps, taking all defaults. You’ll come back later and configure some of these settings.
6. On the summary page, click Finish.
7. You now have a web project folder for the SomeCo corporate site. Click SomeCo Corporate Site. You should see one Staging Sandbox and one User Sandbox. Click the Browse Website button for the User Sandbox.



8. Now you can import SomeCo’s existing website into the web project folder. Click Create, and then Bulk Import. Navigate to the “web-site” project in your Eclipse workspace. Assuming you’ve already run Ant for this project, there should be a ZIP file in the build folder called someco-web-site.zip. Select the file. Alfresco will import the ZIP into your User Sandbox.

What Just Happened

You just created a new web project folder for SomeCo’s corporate website. But upon creation of a web project folder, there is no website to manage. This is a big disappointment for some people. The most crestfallen are those who didn’t realize that Alfresco is a “decoupled” content management system—it has no frontend framework and no “default” website like “coupled” content management systems such as Drupal. This will change in the 3.0 releases as Alfresco introduces its new set of clients. But for now, it’s up to you to give Alfresco a website to manage.

You just happened to have a start on the SomeCo website sitting in your Eclipse workspace. Alfresco knows how to import WAR and ZIP files, which is a convenient way to migrate the website into Alfresco for the first time. Because web project sandboxes are mountable via CIFS, simply copying the website into the sandbox via CIFS is another way to go. The difference between the two approaches is that the WAR/ZIP import can only happen once. The import action complains if an archive contains nodes that already exist in the repository.

If you haven’t already done so, take a look at the contents of your sandbox. You should see index.html in the root of your User Sandbox and a someco folder that contains additional folders for CSS, images, JavaScript, and so on. The HTML file in the root is the same index.html file you deployed to the Alfresco web application in order to implement the AJAX ratings widget. Click the preview icon. (Am I the only one who thinks it looks eerily similar to the Turkish nazar talisman used to ward off the “evil eye”?) You should see the index page in a new tab or window. The list of Whitepapers won’t be displayed. That’s because the page is running in the context of the virtualization server, which is a different domain than your Alfresco server. Therefore, it is subject to the cross-domain restriction, which will be addressed later.

Playing Nicely in the Sandbox

Go back to the root of your web project folder. The link in the breadcrumb trail is likely to be the fastest way to navigate back. Click the Browse Website link in the Staging Sandbox. It’s empty. If you were to invite another user to this website, his/her sandbox would be empty as well. Sandboxes are used to isolate changes each content owner makes, while still providing him/her the full context of the website. The Staging Sandbox represents your live website. Or in source code control terms, it is the HEAD of your site. It is assumed that whatever is in the Staging Sandbox can be safely deployed to the live website at any time. It is currently empty because you have not yet submitted any content to staging. Let’s go ahead and do that now. If you click the Modified Items link in the User Sandbox, you’ll see the index.html file and the someco folder. You could submit these individually. But you want everything to go to staging, so click Submit All:

Provide a label and a description such as initial population and click OK. It is safe to ignore the warning that a suitable workflow was not found. That’s expected because you haven’t configured a workflow for this web project yet.

Now the files have been submitted to staging. Here are some things to notice:

• If you click the Preview Website link in the Staging Sandbox, you’ll see the website just as you did in the User Sandbox earlier.
• If you browse the website in the Staging Sandbox, you’ll see the same files currently shown when you browse the website in your User Sandbox.
• A snapshot of the site was automatically taken when the files were committed and is listed under Recent Snapshots:

Inviting Users

To get a feel for how sandboxes work, invite one or more users to the web project (Actions, Invite Web Project Users). The following table describes the out of the box web project roles:

You’ll notice that each new user gets his/her own sandbox, and that the sandbox automatically contains everything that is currently in staging. If a user makes a change to his/her sandbox, it is only visible within their sandbox until they commit the change to staging. If this is done, everyone else sees the change immediately. Unlike some content management and source code control systems, there is no need for other users to do an “update” or a “get latest” to copy the latest changes from staging into their sandbox.

It is important to note that Alfresco will not merge conflicts. When a user makes a change to a file in his/her sandbox, it will be locked in all other sandboxes to prevent conflicts. If you were to customize Alfresco to disable locking, the last change would win. Alfresco would not warn you of the conflict.

The Alfresco admin user and any user with Content Manager Access can see (and work within) all User Sandboxes. Everyone else sees only their own sandboxes.

Mounting Sandboxes via CIFS

All sandboxes are individually mountable via CIFS. In fact, in staging, each snapshot is individually mountable. This gives content owners the flexibility to continue managing content in their sandbox using the tools they are familiar with. The procedure for mounting a sandbox is identical to that of mounting the regular repository via CIFS, except that you use “AVM” as the mount point instead of “Alfresco”.

One difference between mounting the AVM repository through CIFS and mounting the DM repository is that the AVM repository directory structure is more complicated. For example, the path to the root of admin’s sandbox in the SomeCo site is:

|someco-site--admin|HEAD|DATA|www|avm_webapps|ROOT

The first part of the path, someco-site, is the DNS name you assigned when you set up the web project. The admin string indicates which User Sandbox we are looking at. If you wanted to mount to the Staging Sandbox, the first part of the path would be someco-site without –admin. The next part of the path, HEAD, specifies the latest-and-greatest version of the website. Alternatively, you could mount a specific snapshot like this:

|someco-site--admin|VERSION|v2|DATA|www|avm_webapps|ROOT

As you might expect, the normal permissions apply. Users who aren’t able to see another user’s sandbox in the web client won’t be able to do so through CIFS.