Field Type Variable Name

Text title Text Box abstract Image image Text Area body

1. Select Save and give the structure a name.
2. Go back to the main web content page and select the Templates tab.
3. Select Add Template.
4. Type in a name and description.
5. De-select the box labeled Cacheable.
6. Select VM as the language.
7. Click Select and choose a Structure that goes with the Templates.
8. If you've written the script beforehand, you can select Browse to upload it from your machine. Otherwise, you can click Launch Editor to type the script directly into the small editor window that appears.
9. Select Save.
10. Return to the Web Content tab and open the Company News content. You'll see the new element labeled Abstract just below the Title.

Below is the template script for this structure. It is written in Velocity:

#set ($renderUrlMax = $request.get("render-url-maximized"))
#set ($namespace = $request.get("portlet-namespace"))
#set($readmore = $request.get("parameters").get("read_more"))
<h1>$title.getData()</h1>
#if ($readmore)
<p>$abstract.getData()</p>
<p>$body.getData()</p>
#else
<p>
<img src="${image.getData()}" border="0" align="right">
$abstract.getData()</p>
<a href="${renderUrlMax}&${namespace}read_more=true">Read More</a>
#end

This template is pretty small, but it actually does quite a bit. First, a portlet URL which maximizes the portlet is created. Once this is done, the template gets the namespace of the portlet. This is important to avoid URL collisions with other URLs that might be on the page.

After this, the template attempts to get a request parameter called read_more. Whether or not this was successful is the key to the rest of the script:

• If the template got the read_more parameter, it displays the abstract and the body below the title (which is always displayed).

• If the template didn't get the read_more parameter, it displays the image, the abstract, and the link created above, which sets the read_more parameter.

When this template is rendered, it looks something like this:

Figure 3.13: Initial View

Figure 3.14: After Clicking "Read More"

Of course, there is much, much more you can do with structures and templates. Check out the Liferay Wiki (http://wiki.liferay.com) for further information and examples.

Assigning template permissions

Permissions for templates are similar to permissions for structures. As with structures, you only want specific developers editing and creating templates. You may, however, want to make the templates viewable to some content creators who understand the template scripting language, but are not directly writing the scripts. You can determine who views the template by selecting from the Viewable By select box beneath the Permissions tab. By default the Anyone (Guest Role) is selected.

You'll also want to determine how users can interact with the template. You can do this by selecting the More link.

From the More link, you can grant or deny permissions based on Roles. For instance, you may create a role with the ability to update the template and create a second role that can both update and delete. Liferay Portal makes it possible to assign permissions based on the roles and responsibilities within your organization.

Now that you can create all kinds of advanced content with structures and templates, you'll want to know how Liferay makes it possible to manage how that content is published. We'll cover that next.

Advanced Publishing Options

As we discussed above, as your site becomes larger and more complex, management of the content becomes more challenging. We've gone over Liferay management tools that help you create content quickly and in an orderly fashion. You created a simple announcement with Liferay's structure editor that allows you to quickly design a structure and prepare it for the template designers. Then you applied a template to the structure. You know how to display content using the Web Content Display portlet. Now, you're ready to take advantage of Liferay's advanced publishing options.

If a web site isn't properly managed, it can quickly become out of date, and that drives viewers away. If people are finding your site because of search engines, you don't want them presented with outdated (and now inaccurate) web content.

You also want your content to be found easily by your users. This is done through tags and categories.

Additionally, you may want to create content and send it through a review and approve process weeks before you want it displayed on the web site. Liferay gives you this flexibility with the Schedule and Workflow features.

Scheduling Web Content

Liferay's WCM lets you define when your content goes live. You can determine when the content is displayed, expired, and/or reviewed. This is an excellent to way to keep your site current and free from outdated (and perhaps incorrect) information. The scheduler is built right into the form that your users make use of to add web content, in the same column as the structure and template selectors.

Figure 3.15: Schedule for Publishing Content

Display Date: Sets (within a minute) when content will be displayed. Expiration Date: Sets a date to expire the content. The default is one year. Never Auto Expire: Sets your content to never expire. Review Date: Sets a content review date. Never Review: Sets the content to never be reviewed.

As you can see, the scheduling feature in Liferay Portal gives you great control in managing when, and for how long, your web content is displayed on your web site. Additionally, you have the ability to determine when your content should be reviewed for accuracy and/or relevance. This makes it possible to manage your growing inventory of content.

In addition to controlling when content displays, you can use the Display Page feature to control where content displays.

Display Page

If you've been using Liferay for a while, or you've just spent a little bit of time with this guide, you might have noticed something about how Liferay handles web content--content is never tied directly to a page. While this can be useful (because it means that you don't have to recreate content if you want to display the same thing on multiple pages), it also means that you don't have a static URL for any web content, which is bad for search engine optimization.

To fix this issue, Liferay has introduced the concept of Display Pages and Canonical URLs. Each web content entry on the portal has a canonical URL, which is the official location of the content that is referenced any time the content is displayed. A Display Page can be any page with an asset publisher set to its default settings. You can create the page yourself, or use the Content Display Page page template included with Liferay.

So right now you're thinking "Wait, you just told me that each Web Content item has its own URL, and that this is somehow related to pages where we display a whole bunch of content on the same page?" Yes. That's exactly what I said. Just watch--create a display page somewhere on your portal, using the Content Display Page template. Now click on Display Page, and select the page you just created as the display page for the content.

Figure 3.16: Selecting a Display Page

You can now click the link to display the content, and the canonical URL for content shows in your browser's address bar. You can create your own custom display page, and any additional portlets that you place on the page are displayed along with the content when you access it via the canonical URL.

Figure 3.17: The Canonical URL

Let's move on to tags and categories.

Tags and Categories

Tags are keywords that are attached to web content in order to help users find content. Categories are hierarchical structures of content that are defined by administrators. Tags and categories make it easier for your users to find content through search or navigation.

By assigning a tag to web content, you define metadata about that content. This is then used by Liferay's search engine to score the results of a search, enabling users to find content that is most relevant to their search. Tags can be created on the fly by creators of content, and it's important to tag content whenever it is created. If you don't tag content, all the search engine has to go on is the full text of the content (if you've made your content indexable), and that might not produce the most optimal results.

Tagging also helps with navigation. Liferay Portal has two portlets specifically designed for navigating content using tags: Tag Cloud and Tag Navigation. If you add either of these to a page, you can use them to show the topics contained in your content.

Tags can be added on the fly or they can be selected from the existing library of tags. For most of the portal, users tag content, but for web content, only the content creator tags the content, because there is no user interface for regular users to tag web content.

It is important that you both tag and categorize your content when you enter it.

Categories are a little bit different, and new users generally ask a valid question when presented with tags and categories: what's the difference? Categories are defined by someone with administrative access to the content. They are hierarchical, tree-like structures that users can use to find content. Categories are different from tags in that they're never created by end users. Instead, categories define how your content is organized from the point of view of the owner of the content. A good example of categories might be the table of contents of a book: it shows the hierarchical structure and organization for all of the content within that book. This shows that the structure of the book has been planned ahead of time by the author. Categories do the same thing as the table of contents.

By contrast, tags are like the index of a book: they show where many different topics are mentioned within the book in alphabetical order. When a search is done throughout the book, even the author might be surprised at how many times he or she mentions a particular topic outside of its category. So both ways of organizing content are important, especially if your users will be using search to find content.

Tagging and categorizing web content is easy. You can do it at the bottom of the same form you use to add content. If you open the Categorization section of the form, you'll be presented with an interface for adding tags and categories.

Figure 3.18: Tagging and categorizing content can be done at the same time you create it.

The control panel contains an interface for managing tags and categories for each site in the portal. This interface can be used to manage all your tags and categories in one place. We'll look at this interface in the next chapter.

Next, we'll look at how to configure the way pages are accessed by mobile devices.

Mobile Device Rules

Mobile device rules allow you to configure sets of rules and use those rules to alter the behavior of the portal based on the device being used to access Liferay. The proportion of mobile devices users browsing the web has been steadily increasing so it's important to be able to handle different kinds of devices appropriately. For instance, you can configure the look and feel of Liferay pages accessed by smartphone or tablet users differently than those accessed by PC users.

Both sites and individual pages can be configured with any number of rule groups. A rule group is designed to describe a group of devices. It can contain one or more rules which describe a category of devices, such as all android devices or all iOS tablets. Rule groups can be prioritized to determine which one will be applied to a given page request. You can define as many rules as you need to classify all the devices you want to take actions on.

In order to configure mobile device rules, you must install the wurlf-web plugin. This plugin enables Liferay to detect which mobile device or operating system is being used for any given request. To install the plugin, navigate to the Plugins Installation section of the control panel, located under the Server heading. Then search for the wurlf-web plugin and click Install.

Alternatively, if you have a working copy of Liferay's plugin repository, you can install the plugin manually. The plugin is available from Liferay's public SVN repository at http://svn.liferay.com/repos/public/plugins/trunk/webs/wurfl-web/ or from Liferay's public Github repository at https://github.com/liferay/liferay-plugins/tree/master/webs/wurfl-web. Once you have checked out or cloned the repository, navigate to the plugins root directory and create a build.username.properties file. Add the line app.server.dir = <path-to-app-server>, replacing <path-to-app-server> with the path to the application server running Liferay on your machine. Then navigate to the wurlf-web directory and execute the ant deploy target.

You can access the Mobile Device Rules administrative page from the Content section of the control panel. Make to select the appropriate scope using the context menu selector so that your rule groups are available where you expect them to be. The Mobile Device Rules administrative page displays a list of defined rule groups and allows you to add more. To add rules to a rule group, select Actions → Manage Rules or just click on a rule group to edit it and then click the Manage Rules link.

Figure 3.19: You can manage device rules from the Mobile Device Rules administrative page.

The rules defined for a rule group, along with the priorities of the rule groups selected for a particular site or page, determine which rule will be applied to a given request. From the Manage Rules page for a specific rule set, you can add a rule by specifying a rule type. Note that, by default, only the Simple Rule type is available. However, the rules are designed to be extensible and additional rule types can be added by your developers. Once added, you can edit the rule to specify a device type and operating system.

Figure 3.20: You need to install the wurlf-web plugin to populate the OS list.

Once you've created some mobile device rule groups and added some rules to them, you'll be ready to set up some actions. The actions defined for a rule group determine what happens to a particular request when the request's device has been detected and the rule group has been found to apply.

You can add actions to a rule group from the Site Pages page of the control panel. Select either the public or private pages and then look for the Mobile Rule Groups link in the right-hand menu. Use the Select Rule Group button to select rule groups to be applied either to a site or to a single page. If you select the page group itself from the left-hand menu, the selected rule group will apply to all the pages of the site by default. However, if you select an individual page and then click the the Select Rule Group button, the rule groups will apply to only that page. You can select multiple rule groups for a particular site or page and order them by prority. The rule groups are checked in decreasing order of priority: the actions defined by the first rule group that applies are executed.

Figure 3.21: You can select a mobile device rule group to apply for a site or page from the Site Pages section of the control panel.

To add actions to a selected rule group, use the Actions → Manage Actions button and then click Add Action. By default, there are four kinds of actions that be configured for mobile rule groups: layout template modifications, theme modifications, simple redirects, and site redirects. Layout template modifications let you change the way portlets are arranged on pages delivered to mobile devices and themes modifcations let you select a specifc look and feel. If it makes more sense for you to create separate mobile versions of certain sites or pages you can use a redirect to make sure that mobile devices users get to the right page. To define a simple redirect, you need to specify a URL. To define a site redirect, you only need to specify the site name and page name of the page you're redirecting to. Like mobile device rules, mobile device actions are designed to be extensible. Your developers can define custom actions in addition to the four actions provided by default. Next, let's discuss Liferay's asset publisher, which you can use to publish many different kinds of portal content.

Using the Asset Publisher Portlet

As we create web content, it's important to keep in mind that to Liferay, the pieces of content are assets, just like message board entries and blog posts. This allows you to publish your web content using Liferay's Asset Publisher.

You can use the Asset Publisher to publish a mixed group of various kinds of assets such as images, documents, blogs, and of course, web content. This helps in creating a more dynamic web site: you can place user-created wiki entries, blog posts, or message board messages in context with your content. Let's look at some of its features.

Querying for Content

The Asset Publisher portlet is a highly configurable application that lets you query for mixed types of content on the fly. By giving you the ability to control what and how content is displayed from one location, the Asset Publisher helps you to "bubble up" the most relevant content to your users.

To get to all the portlet's options, click the Configuration link in the portlet's menu (the wrench icon).

The ability to configure how content is displayed and selected by your users further demonstrates the flexibility of the Asset Publisher. You get to choose how content is displayed. You can select it manually for display in a similar way to the Web Content Display portlet, or you can set up predefined queries and filters and let the portal select the content for you, based on its type or its tags and categories.

Let's first look at how we might select content manually. You'll see that it's very similar to the Web Content Display portlet.

Selecting assets manually

By selecting Manual from the select box beneath Asset Selection, you tell the Asset Publisher that you want to select content manually. You can select what you want to be published within the portlet, or you can create new content from within the Asset Publisher.

Figure 3.22: Selecting assets manually is very similar to the Web Content Display portlet, except you have many other content types to choose from.

Clicking Add New gives you a menu of options, enabling you to create the content right where you are. You can create blogs, bookmarks, calendar entries, documents, images, and of course, web content. Anything you create here is added to the list below of assets that are displayed by the portlet.

Clicking Select Existing gives you a similar menu, except this time you can pick from existing content in the portal that either you or your users have created. Has someone written an excellent wiki page that you want to highlight? Select it here, and it will be displayed.

The Asset Publisher enables you to mix and match different content types in the same interface. Once you have your content selected, you can move on to the display types to configure how the content appears.

Most of the time, however, you'll likely be using the Asset Publisher to select content dynamically.

Selecting assets dynamically

Asset Publisher's default behavior is to select assets dynamically according to rules that you give it. These rules can be stacked on top of each other so that they compliment each other to create a nice, refined query for your content. You have the following options for creating these rules:

Scope: Choose the sites or organizations from which the content should be selected.

Asset Type: Choose whether you'll display any asset or only assets of a specific type, such as only web content, only wiki entries, or any combinations of multiple types.

Figure 3.23: You can filter by tags and categories, and you can set up as many filter rules as you need.

Filter Rules: Add as many filters on tags or categories as you like. You can choose whether the content contains or does not contain any or all categories or tags that you enter.

Once you've set up your filter rules for dynamically selecting your content, you can then decide how the content will be displayed.

Ordering and Grouping

You can display the content returned by the filters above in order by title, create date, modified date, view count, and more in ascending or descending order. For instance, you may have a series of "How To" articles that you want displayed in descending order based on whether the article was tagged with the hammer tag. Or, you may want a series of video captures to display in ascending order based on a category called birds. You can also group by Asset, Type, or Vocabularies. Vocabularies are groups of categories defined by administrators in the Categories section of the control panel. Again, we'll see more about categories in chapter 4.

In the Ordering and Grouping section of the Asset Publisher, you have great control over how content is ordered and grouped in the list, but this is only one aspect of how your content will be displayed. You can refine the display through many other display settings.

Display Settings

The Display Settings section gives you precise control over the display of your assets. There are a multitude of options available to configure how you want your content to appear. You can configure the style, length of abstracts, behavior of the asset link, maximum items to display, pagination type, and file conversions. Additionally, you can enable printing, flags, ratings, comments, and comment ratings, and these work the same way they do in the Web Content Display portlet.

Display Style

Abstracts: Shows the first 200-500 characters of the content, defined by the Abstract Length field.

Table: Displays the content in an HTML table which can be styled by a theme developer.

Title List: The content's title as defined by the user who entered it.

Full Content: The entire content of the entry.

Other Settings

Asset Link Behavior: When the link to the asset is clicked, it can be displayed in the Asset Publisher or in the portlet to which the asset belongs, such as the Blogs or Message Boards.

Maximum Items to Display: You can display 1-100 items.

Pagination Type: Select Simple or Regular. Simple shows previous and next navigation; regular includes a way of selecting the page to which you'd like to navigate.

Exclude Assets with 0 Views: If an asset has not been viewed, exclude it from the list.

Show Available Locales: Since content can be localized, you can have different versions of it based on locale. This will show the locales available, enabling the user to view the content in the language of his or her choice.

Enable Conversion To: If you have enabled Liferay Portal's OpenOffice.org integration, you can allow your users to convert the content to one of several formats, including PDF.

Below these options are the same ones in the Web Content Display portlet: enable print, enable comments, enable ratings, etc.

Show Metadata: Allows you to select from the available metadata types (see below).

Figure 3.24: Show Metadata

Enable RSS Subscription: This lets users subscribe to the content via RSS Feeds.

The Display Settings section of the Asset Publisher has numerous options to help you configure how your content selections are displayed to your users. Even though there are many choices, it's easy to go through the options and quickly adjust the ones that apply to you. You'll want to use the Asset Publisher to query for mixed assets in the portal that have relevant information for your users.

Next, we'll look at some of the most powerful features of Liferay WCM: staging and workflow.

Staging and Workflow

Staging is an important feature of Liferay WCM. The concept of staging is a simple one: you can modify your site behind the scenes, and then publish it all in one shot. You don't want your users seeing your web site change before their eyes as you're modifying it, do you? Liferay's staging environment allows you to make changes to your site in a specialized staging area, and then when you're finished, publish the whole site to your users.

You can use staging in multiple ways. You can have a staging server—-a separate instance of Liferay Portal which is used just for staging. Content creators can then use this server to make their changes while the live server handles the incoming user traffic. When changes to the site are ready to be published, they are pushed over the network to the live server.

You can also use staging in the same instance of your Liferay Portal. In this configuration, you have a local staging environment: you host both your staging environment and your live environment on the same server. Either way, once set up, the interface is the same; the only difference comes when it's actually time to publish your content.

In addition, Liferay 6.1 adds the capability to create multiple variations of staged pages, so that you can manage several future versions of a site simultaneously. Variations can be merged and published through an intuitive UI. Let's jump in to see how to use staging.

Enabling the staging environment

Staging configuration can be found in the Site Settings UI. The Staging tab allows us to make changes in a staging environment and preview our work before publishing it to the live site. Let's create a staging environment for Nose-ster's home page.

First, you'll add a new page. Click Add → Page from the toolbar in the default site and name the new page News and Events. Next, click the View Pages button and add the Alerts and Announcements portlets to it.

Now we're ready to activate the staging feature for this site. Go to the control panel then to Site Settings and select Staging from under the Advanced heading.

Figure 3.25: You can decide to use versioning and choose what content should be staged.

We'll assume we don't have a separate staging server, and so we'll select a staging type of Local Live. If you want to set up a remote staging environment, it's easy. First, select Remote Live, and then supply the name or IP of the remote server where staged content should be published, the port (80 if Liferay is sitting behind a web server, or the port your application server is listening on if not), and the remote site or organization ID. You can find this ID by selecting Actions → Edit on any site in the control panel. Either way, once you make a selection (Local Live or Remote Live), more options become available.

We'll cover many of the collaboration portlets listed here when we come to chapter 4. For now you just need to be aware that the option is available to enable or disable staging for any of them, and you need to decide if you want to stage content for these portlets. In the case of the collaborative portlets, the answer is usually "no." Why? Because portlets such as the Message Boards are designed for user interaction. If their content were staged, you'd have to manually publish your site whenever somebody posted a message on the message boards in order to make that message appear on the live site.

Generally, you'll want web content to be staged, because end users aren't creating that kind of content-—web content is the stuff you publish to your site. But portlets like the message boards or the wiki would likely benefit from not being staged.

Enabling Page Versioning makes it so that you can work in parallel with other users on multiple versions of the same pages, and it gives you the flexibility to revert easily to a previous version if you encounter any issues. Check Enabled On Public Pages so that we can look at versioning.

Using the staging environment

If you navigate back to the News and Events page you'll now notice some new items along the top of the screen. These will help us manage staged pages. You'll also notice that most of your page management options have been removed, because you can now no longer directly edit live pages--you'll now use the staging environment to do that. Click on Staging to view the staged area. Your management options are restored, and you have some new options related to staging.

Figure 3.26: You can see the new bar that staging adds to the top of your screen.

Add the Calendar portlet and then click on Live from the Dockbar. Notice that the Calendar portlet isn't there. That's because you've staged a change to the page, but haven't published that change yet to the live site. Go back to the staged page, and look at the options you have available. From here you can Undo changes, view a History of changes, Mark as Ready for Publication, and Manage Page Variations.

Undo/Redo: allows you to step back/forward through recent changes to a page, which can save you the time of manually adding or removing portlets if you make a mistake.

History: shows you the list of revisions of the page, based on publication dates. You can go to any change in the revision history and see how the pages looked at that point.

Manage Page Variations: allows you to work in parallel on multiple versions of a staged page. We will explain this later.

After you're done making changes to the staged page, click the Mark as Ready for Publication button. The status of the page changes from Draft to Ready for Publication and any changes you've made can be published to the Live Site. When you publish a page to live, only the version which was Marked as Ready for Publication is published.

The dropdown next to the Staging link at the top gives you the option to Publish to Live Now or Schedule Publication to Live.

Publish to Live Now: immedatiately pushes any changes to the Live Site.

Schedule Publication to Live: lets you set a specific date to publish or to setup recurring publishing. You could use this, for example, to publish all changes made during the week every Monday morning without any further intervention.

Click on Mark as Ready for Publication and then Publish to Live Now to publish your Calendar portlet to the live site.

Content publication can be also controlled using staging. Calendar events are staged by default (this can be changed in Staging Configuration). If you create an event in the staged site, it isn't visible in the live site until you publish it to the live site following the same steps you just performed (you can select which types of content are published when you publish to the live site). If workflow is enabled for Calendar Events, the event needs to go through the workflow process before it can be published to the live site.

Figure 3.27: Ready to publish to the live site.

One of the most powerful features of staging is page variations. Let's see how to use them to create multiple different variations of your site's pages for different purposes.

Site Pages Variations

Let's say that you're working on a product-oriented site where you'll have several major changes to a page or a set of pages over a short period of time, and you need to be working on multiple versions of the site at the same time to ensure that everything has been properly reviewed before it goes live. With staging in Liferay 6.1 you can do this with Page Variations.

For example, you can create several page variations, enabling the marketing team to give your site a completely different look and feel for Christmas. At the same time, the product management team can work on a different version that will be published the day after Christmas for launching of a new product. Additionally, the product management team is considering two different ideas for the home page of the site, so they can create several page variations of the home page inside their product launch site.

Variations only affect pages and not the content, which means that all the existing content in your staging site is shared by all your variations. In different site page variations you can have different logos, look and feel for your pages, different applications on these pages, different configuration of these applications, and even different pages. One page can exist in just one site page variation or in several of them.

By default, we only have one site page variation which is called Main Variation. In order to create a new one, use the dropdown next to the Staging link and click on Manage Site Pages Variations. This brings you to a list of the existing site page variations for your site. Click Add Site Pages Variation to create a new one. From the Add Site Pages Variation screen, you can set a Name, Description, and also set your new variation to copy the content from an existing variation. There are several options to choose in this selector.

Any existing Site Pages Variation: creates a new site page variation that contains only the last version of all the pages that exist in this variation. The current variation must be marked as ready for publication.

All Site Pages Variation: creates a new variation that contains the last version marked as ready for publication from any single page existing in any other variation.

None: creates a new, empty variation.

You are also able to rename any variation. For example, edit the Main Variation and change its name to something that makes more sense in your site, such as Basic, Master, Regular and create a variation for Christmas.

You can switch between different variations by clicking on them from the staging menu bar. It's also possible to set permissions on each variation, so that certain users have access to manage some, but not all variations.

You can now go to the home page of your Christmas variation and change the logo, apply a new theme, move portlets around, change the order of the pages, and configure different portlets. The other variations won't be affected. You can even delete existing pages or add new ones (remember to Mark as Ready for Publication when you are finished with your changes).

When you delete a page, it is deleted only in the current variation, and the same happens when you add a new page. If you try to access a page which was deleted in the current variation, Liferay informs you that this page is not enabled in this variation, and you can enable it. To enable it, navigate to the Manage → Site Pages screen. Here, all the existing pages for all the variations are shown in a tree. Pages that are not enabled for the current variation are shown in a lighter color.

To publish a variation to the live site, click on Publish to Live now in the dropdown next to the variation name. Publications can also be scheduled independently for different variations. For example, you could have a variation called Mondays which is published to the live site every Monday and another one called Day 1 which is published to the live site every first day of each month.

You can also have variations for a single page inside a site page variation, which allows you to work in parallel in different versions of a page. For example, you might work on two different proposals for the design of the home page for the Christmas variation. These page variations only exist inside a site Page variation.

To create a new page variation, click Manage Page Variations on the staging toolbar. This brings you to a list of existing page variations for the current page (by default, there is only one called Main Variation). You can create more or rename the existing one. You can switch between different page variations using the toolbar containing the page variations below the site pages variations toolbar. When you decide which page variation should be published, mark it as Ready for Publication. Only one page variation can be marked as ready for publication and that is the one that gets published to the live site.

Figure 3.28: Creating a new Page Variation

For example, we could create a page variation called Thanksgiving for the News and Events page inside of the Christmas variation and another one called Christmas Day to display different content on those particular days.

Figure 3.29: The Thanksgiving Page Variation.

Let's finish our discussion of staging by outlining a few more features.

Wrapping up staging

You can enable staging on an individual site basis, depending on your needs. This makes it easy to put strict controls in place for your public web site, but to open things up for individual sites that don't need such strict controls. Liferay's staging environment is extremely easy to use and makes maintaining a content-rich web site a snap.

Let's go one step further by introducing workflow into the mix.

Using Liferay's Integrated Workflow with Content Management

Workflow is essentially a predetermined sequence of connected steps. In Liferay WCM, workflow is designed to manage the creation, modification, and publication of web content. You can set up a workflow so that content can't be published without going through an approval process that you design. In this way, content is published to the site only after it has been reviewed and approved.

Liferay's workflow engine is called Kaleo workflow, and it ships with Liferay CE. If you have uninstalled it or are using EE, it needs to be installed and configured separately. This is covered in chapter 6. Since we have somewhat of a "What came first--the chicken or the egg?" problem, for now, we'll assume it's installed and look at how you can take advantage of workflow in getting your content through any approval steps between creation and publication.

You may have noticed that something appears to be missing from the staging process discussed above. In particular, you might be asking the question, "How do I reject changes?" Starting with Liferay 6.1, Staging is integrated with Liferay's Workflow engine. In order to have a review process for staged pages, you need to make sure that you have a workflow engine configured, and that you have staging set up in the workflow. To do this, select the workflow definition desired for page revisions in the Workflow Configuration.

When using a workflow, clicking Submit for Publication submits the staged pages into the workflow. Once all necessary approvals have been completed, the page status is marked as ready for publication. The Publish to Live Now and Schedule for Publication options publish the last version of the selected pages marked as ready for publication.

To enable workflow for Web Content, navigate to the control panel and select Workflow Configuration. From there, select a workflow that has been deployed to Liferay.

Figure 3.30: Enabling Workflow for Content Management

As you'll discover in chapter 6, you can design workflows to suit your organization's approval process. For Nose-ster's implementation we'll use the Single Approver workflow which ships with the product.

Defining Workflows for Web Content

Let's set up Liferay's Workflow for the Nose-ster web site.

1. Go to the control panel and select Workflow Configuration from the left panel.

2. From the select box, choose Single Approver for Web Content. Click Save. Note that you can add workflow to many of Liferay's portlets.

That's all it takes to set up workflow for web content. Now that workflow is enabled, publishing content works a little bit differently. Let's go through the process of publishing details for new class offerings at Nose-ster. Return to the home page and click the Add Web Content icon on the Web Content Display portlet. Call the new content Course Offerings and enter some content. Notice that the Publish button is now gone. In its place is a Submit for Publication button. Go ahead and click it.

Figure 3.31: Pending Workflow

Next, go to the Workflow Tasks in control panel and then select My Workflow Tasks. You will see the option to Review Content for Sales Goals. It shows because you are logged in as an Administrator. There is also a Content Approvers role which is defined by this workflow, and anyone in this role can approve content as well.

To approve the content, you must first take ownership of it. Click on the task. You should see the screen below.

Taking ownership of, reviewing, and approving content is very easy:

1. Click the Assign to Me button. Alternatively, you could assign it to someone else in the Content Approvers role or create / update a due date for the content's approval.
2. Once you've assigned it to yourself, buttons allowing you to approve or reject the content appear. Click Approve.
3. You're asked to submit a comment. You'd have to do this for either Approve or Reject. Add a comment and click Save.
4. The content is now approved.

In a real world situation, you obviously wouldn't want the person who created the content to be the one who approves it. Instead, you would have one or more roles designed for users who will be creating content, and you would have specific users assigned to one or more roles for approving content. Our example was of a very straightforward workflow, as it has only a single approver. Kaleo workflow allows you to design workflows that go through as many steps as you need to conform to your business processes. We look at Kaleo workflow in more detail in chapter 6.