text:
Second Edition
Published January 2011
© Copyright IBM Corporation 1993, 2011
In keeping with IBM's commitment to accessibility, this edition of the product documentation is accessible.
You can save a local copy of this document from your browser. Each browser has different menus and menu options. Consult the browser help if you need assistance saving the document locally.
If you would like to provide feedback about this document, then Submit Feedback.
Lotus Web Content Management is included with WebSphere Portal to provide a robust web content management solution. It includes an authoring interface that can be customized and extended, workflow, versioning, taxonomy, and much more.
Web Content Management is used to create, manage, and deliver content for your Web site. You can create content using the Web content authoring portlet, or create your own customized authoring interface. Web content stored in external content management systems can also be referenced within a Web Content Management system. You can deliver your Web content using Web content viewer portlets, the Web Content Management servlet or pre-render your site to HTML.
Web Content Management version 7.0 includes new features such as folders and projects, and various improvements to existing features.
Authoring templates can now be configured to store file resources as content items. This is useful when you want to store a file, such as a PDF file, and render it directly on a page but would also like to have the PDF file listed in navigational components such as menus and navigators.
Option selection elements can now be populated with categories from an existing taxonomy. The categories selected in option selection elements can also be used to profile content items. This enables you to add multiple option selection elements to an authoring template to make the process of profiling a content item easier for content creators.
See Working with items in a project for further information.
See Web content authoring interface strategies for further information.
See Working with Web content pages for further information.
The process of configuring your Web content environments has been improved through the use of the WebSphere Application Server resource environment provider so you can edit Web Content Management system properties using the WebSphere Application Server administration console.
The logging and tracing features of Web Content Management have been improved to enable problem determination without the need to install specific debugging modules from IBM support. This support includes the use of the WebSphere Application Server public APIs for FFDC logging.
Web Content Management provides support for the notification of events such as item state changes or services starting and stopping. These notifications can be delivered as messages to the Java messaging service.
See Enabling Java messaging services for web content for further information.
The starting point for information is the product documentation. Previously the product documentation was delivered using an information center framework For WebSphere Portal 7.0, the product documentation is delivered in the WebSphere Portal Family wiki. There are still other sites and resources available to you when working with WebSphere Portal, but this consolidation is intended to make finding information easier. It is also intended to drive improvements into the content and let the community edit and comment on the documentation. Knowing where to look for information can save you time and money. Learn more about primary and secondary resources for WebSphere Portal and Lotus Web Content Management documentation and supplemental content.
There are two primary sources for content: the WebSphere Portal Family wiki and WebSphere Portal Support site. An excellent secondary source is developerWorks, where you can find examples and tutorial-based articles.
Each content source links to the other sources to help you navigate between the resources. Each content source has a specific objective and is intended to be used with the other sources.The product documentation delivered in the wiki (on the Product Documentation tab) is developed by IBM to help you take advantage of features based on expected usage patterns. You can contribute to the content to reflect your experience with the product. The wiki content accessed from the Home tab is developed by the community, both inside and outside of IBM. The intent is to share experiences with the product and based on actual usage patterns and use cases. The Support content is developed by IBM Support to help you avoid and diagnose issues with the intent of being as responsive as possible.
Accessibility features help users who have a physical disability, such as restricted mobility or limited vision, to use software products successfully.
This version of IBM WebSphere Portal:
When appropriate, the documentation for specific product features contains additional information about accessibility.
See the IBM Human Ability and Accessibility Center for more information about the commitment that IBM has to accessibility:
Different types of websites will require different solutions and use different applications and features. This section contains examples of different websites and the types of applications and features required to deliver them.
An intranet portal site is designed to allow information to be quickly disseminated to employees, to make common internal business processes more efficient and to provide a sense of community within an organization.
The site provides access to:
The intranet portal also has a personalized home page that is dynamically built using a set of rules that retrieve content based on the current user's role, department, and location. By appropriately tagging the content, and then matching this content with the current user, the content that is displayed can appropriate for the user.
The size of an intranet portal tends to scale with the size of the organization. A large organization has more information to disseminate, more business processes, more communities of employees. This means that the content and the user population tend to grow at the same rate.
An e-business site is an externally facing site designed to market a company's products and services to consumers and allow them to purchase these items online. The focus of the site is on helping a consumers match their needs to the appropriate product or service and maximizing their purchases.
The home page of the site is used to highlight the latest promotions, and to give a strong sense of the brand of the organization. Throughout the site, collaborative filtering is used to help suggest products and services to consumers based on their purchasing and navigational activity. A discussion system may also be used to allow users to build a community where they can comment on and rate various products and services.
An e-business site can generate a large amount of traffic with a relatively small amount of content.
A brochureware site is an externally facing site that acts as an organization's presence on the World Wide Web. The overriding focus is on representing the organization's brand to its potential customers.
This type of site is relatively static and does not need the aggregation capabilities of WebSphere Portal and is instead delivered using both the servlet delivery and pre-rendering features of Web Content Management. The site is also designed to be easily indexed by search engines like Google.
The components in this site are limited with Web Content Management providing all the presentation, navigation, and content.
A brochureware site can generate a large amount of traffic with a relatively small amount of content.
An online library site is dedicated to providing access to a large amount of content. The prime example is a news site, where new content is created throughout the day, every day of the week and is published online and then archived as it becomes out of date. Other examples include journals, analyst reports, and software libraries.
Users would typically have to register for these sites, and may then be sent e-mails on a regular basis summarizing the latest content. On a news site the latest news may be free, but users may have to pay for access to archived content. On other types of "library" sites, you may have to pay for access to any of the content.
An e-library site may have a large audience and a large amount of content.
The audience for a partner site are the partners of an organization. The site provides information and applications that are not applicable to the broader audience of consumers. A partner site would typically require a login but would not use an automated registration system. The business partners would be known to the company and given a login to access the partner site.
A partner site is likely to have a limited audience but a large amount of content.
When you create a web content library, you can choose to include a set of default web content items in the new library. These can be used as a starting point for your Web Content Management system and web site.
The following items are created when you select Include default items in the new library when you create a library.
As the web content library default items are configured to inherit their access settings from the library they are stored in, users are not able to access these items until you have configured the access settings of the library.
Before building a website, it is best practice to take time to analyze, plan, and design the website that you want to build, the web content system that you need to manage the website, the infrastructure required for the system, and the roles and users required to build the website and install infrastructure.
It is important to have an understanding of the objectives, deliverables, and scope of a web content system. Your project definition outlines the what, why, and who of the project and can be used throughout the life of your web content system.
You define the following information in your project plan:
It is essential to determine the objectives of the project. These objectives can be provided by the project team, determined from meetings with the project stakeholders, and usability workshops with users. It is important that all stakeholders agree on the final objectives of the site. Each objective should be clear and concise. There should be no room for assumptions or varied interpretations.
These roles are examples of the type of work performed by the people who create and manage a website. A single person can be responsible for more than one of the roles outlined in this section. The roles you implement in your organization to support your website are determined by the size and complexity of the system being deployed. Not all the following roles are required for every website, but all aspects of these roles must be considered during any system deployment.
Large complex deployments require a project manager to ensure that there are sufficient resources available to deploy a system, that the correct users have been assigned to the project and that the tasks required to deploy the system occur at the correct time in the overall deployment process.
A business analyst is responsible for developing an analysis document.
Based on the data collected in the analysis document, the architecture and design team documents all the things required by the WebSphere Portal system. The design documents the team develops are used by the deployment and development teams to deploy and manage the WebSphere Portal system.
The technical architects are responsible for designing the overall server topology required for the entire system and the architecture of the servers that make up the system. The technical architecture team can include technical architects, database architects, security architects, performance engineers, and other resources as required.
The information architect determines the overall informational structure of the website based on requirements gathered in the analysis document.
A website designer is responsible for designing the layout and style of the web pages in a website. A graphic designer might also be employed to create graphics and color schemes for the website.
The authoring system architect is responsible for determining the architecture of the authoring system used to create and manage web content.
Based on the design documents developed by the technical design team, the deployment team builds and manages the WebSphere Portal system.
A database administrator is responsible for deploying the database servers and data repositories based on the technical architecture developed by the database architect.
The database administrator is responsible for installing all databases used by the website and related systems. The databases the administrator sets up are based on the technical architecture developed by the technical and database architects. The database administrator will need to become familiar with the user documentation of the data and user repositories used by the web content system.
A WebSphere Portal administrator is responsible for the overall deployment and management of the servers in a WebSphere Portal deployment based on the architecture developed by the technical architect.
A web content administrator is responsible for configuring the web content servers within a WebSphere Portal system.
A user acceptance testing environment is set up like authoring and delivery environments depending on the type of UAT being performed. The tasks required to set up the UAT environment are the same as those for the authoring and delivery environments.
A security administrator is responsible for securing the overall system including access control strategies and firewalls.
Based on the design documents developed by the technical design team, the development team is responsible for creating custom applications using the product API.
The portlet developer is responsible for developing new portlets.
The portlet developer is primarily responsible for creating custom portlets used to aggregate content and function from external applications. The portlets they develop are based on the portlets identified in the design document.
A theme developer is responsible for creating new themes based on the designs developed by the information architect and the graphic designer.
The theme developer is primarily responsible for creating custom themes based on the Web site designs outlined in the design architecture and the HTML used in the website prototype. Themes are a set of JSPs, images, and style sheets packaged together in a common directory structure. They can either be packaged directly in the wps.war or inside a separate WAR file of their own, or with other themes, skins, and resources.
A web content developer is responsible for extending Web Content Management by using the Web Content Management API, developing JSP components and creating web content plug-ins.
Based on the design documents developed by the technical design team, the website creation team is responsible for creating the website and related systems.
A website creator is responsible for building a website by creating presentation templates, authoring templates, site areas, components and categories. The web site creator is also responsible for creating content management items such as folders and workflows. The items created by a website creator are based on the designs created by the information architect and graphic designer.
A web content author is responsible for creating web content for the sites developed and managed using Web Content Management.
A web content manager is responsible for performing ongoing site maintenance activities.
Based on the content identified in the analysis document, the content acquisition team is responsible for importing content from legacy systems into the new website. The team consists of a mixture of administrators and developers. Team members need to be experts in both legacy products and WebSphere Portal
Based on the maintenance architecture developed by the technical design team, the maintenance team is responsible for the ongoing monitoring and maintenance of the overall system.
An analysis document is used to record the information gathered from stakeholders that determines the design of the website, its content, and its features.
These are some examples of the analysis that can be undertaken when designing a web content system.
Website requirements describe the features and functions of a website. They document what the site must have and also what users can do. The requirements are not used to describe how to build the website, which is detailed in the design document.
Before you create a design document for your web content system, it can be useful to create a prototype of your site using HTML. This prototype should be based on the outline defined in your project plan and the data gathered in your analysis document. The site structure, design, and HTML code you develop for your prototype can be used as the basis for many of the items defined in your design document.
By creating a prototype website using HTML, you get to see what your actual website will look like, plus you develop many of the features used by your web content system and website.
A useful method to begin the design of your content management system is to use HTML to develop a prototype of your site. Do this task in consultation with the web content information architect.
The HTML site can then be used to help you determine what web content items need to be created for your web content management system.
Other features of your design, such as images and stylesheets, will determine what components need to be created and whether you need to develop a new WebSphere Portal theme.
After defining the project and creating an analysis document, you define the requirements of your web content system in a design document. The design document outlines what types of content will be needed for your site, how they will be structured, how content will be authored, and what the final website will look like.
Your technical architects define what web content environments are required for your system and the servers required for each environment. This information ensures that you have fully resourced the hardware required to support your web content system
Every Web Content Management system consists of at least one authoring environment and one delivery environment. The authoring environment is used to create and manage the individual items that make up your website. The delivery system is used to deliver the web content to your viewers. In addition to these environments, you might also require testing environments where you perform user acceptance testing (UAT).
The security architecture describes what groups are required for your site and what access is required for different groups to the authoring portlet and rendered website.
Group | Details |
WCMAdmins | Members of this group require access to all features of the authoring portlet. |
SiteAdmins | Members of this group require access to all features of the authoring portlet except workflow. |
SiteDesigners | Members of this group require access to content items, presentation templates, authoring templates, and components. |
ContentAuthors | Members of this group require edit access to content items only. |
ContentApprovers | Members of this group require contributor access to content items only. |
Roles | Allow propagation | Allow inheritance | User or group |
Administrator | Yes | Yes | |
Manager | Yes | Yes | |
Editor | Yes | Yes | |
User | No | Yes | Anonymous Portal User |
Contributor | Yes | Yes | WCMAdmins SiteAdmins SiteDesigners ContentAuthors ContentApprovers |
The SiteDesigners group is assigned editor access to authoring templates as they are required to create new authoring templates.
Roles | Allow propagation | Allow inheritance | User or group |
Administrator | Yes | Yes | WCMAdmins |
Manager | Yes | Yes | SiteAdmins |
Editor | Yes | Yes | SiteDesigners |
User | Yes | Yes | |
Contributor | Yes | Yes |
SiteDesigners are assigned editor access to components as they are required to create components.
Roles | Allow propagation | Allow inheritance | User or group |
Administrator | Yes | Yes | WCMAdmins |
Manager | Yes | Yes | SiteAdmins |
Editor | Yes | Yes | SiteDesigners |
User | Yes | Yes | |
Contributor | Yes | Yes |
Both the SiteDesigners and ContentAuthors groups are assigned editor access to content as they are required to create content items.
The ContentApprovers group is assigned Contributor access only, because they are not required to create new content items, but need approve access to content items during a workflow. You must also assign the ContentApprovers group approve access in the properties section of any workflow stages that ContentApprovers will use to approve content items.
Roles | Allow propagation | Allow inheritance | User or group |
Administrator | Yes | Yes | WCMAdmins |
Manager | Yes | Yes | SiteAdmins |
Editor | Yes | Yes | SiteDesigners ContentAuthors |
User | Yes | Yes | |
Contributor | Yes | Yes | ContentApprovers |
The SiteDesigners group is assigned editor access to presentation templates as they are required to create new presentation templates.
Roles | Allow propagation | Allow inheritance | User or group |
Administrator | Yes | Yes | WCMAdmins |
Manager | Yes | Yes | SiteAdmins |
Editor | Yes | Yes | SiteDesigners |
User | Yes | Yes | |
Contributor | Yes | Yes |
Roles | Allow propagation | Allow inheritance | User or group |
Administrator | Yes | Yes | WCMAdmins |
Manager | Yes | Yes | SiteAdmins |
Editor | Yes | Yes | |
User | Yes | Yes | |
Contributor | Yes | Yes |
Roles | Allow propagation | Allow inheritance | User or group |
Administrator | Yes | Yes | WCMAdmins |
Manager | Yes | Yes | SiteAdmins |
Editor | Yes | Yes | |
User | Yes | Yes | |
Contributor | Yes | Yes |
Roles | Allow propagation | Allow inheritance | User or group |
Administrator | Yes | Yes | WCMAdmins |
Manager | Yes | Yes | |
Editor | Yes | Yes | |
User | Yes | Yes | |
Contributor | Yes | Yes |
By default, each role's access is automatically inherited down to each item in a library. To prevent a user or group from automatically having inherited access to an item, you need to turn off inheritance on that item.
The permissions set for item type do not automatically give you access to individual items. They give you access only to specific tasks and views within the authoring portlet.
You can also assign specific access to individual groups or users on each item.
The information architecture describes the information structure of the site and how users will navigate through the site.
The information architect is responsible for determining what taxonomies are required to allow users to profile content. This information determines what content will be displayed within menu components.
This is an example of a taxonomy for a financial services company:
The design architecture describes what your website will look like, and what components will be needed to build your site. You will need to define presentation templates, components, and themes.
You list the themes, style-sheets and styles in the design architecture. These designs can be based on the styles developed for your prototype website.
Page wireframes can be used to describe the basic structure of each page-type in your site and the elements used on each page.
The website designer also determines what content needs to be personalized for specific users. For example, you might want to display a personalized home page for each individual user based on the user profile. The personalization strategies documented in the design architecture will determine what rules, content spots, and campaigns need to be created when using the Personalization application.
The authoring architecture describes what types of content will be required for the site and what change management strategies will be applied when updating content and design. You will need to define what authoring templates are required for your system, what workflows will be used to manage changes and what folders will be used to group items in the authoring portlet.
The library architecture describes where you will store your web content items. For example, you could split your site between the items that control the look and feel of your site, such as presentation templates and components, from the content of your site. You could also separate your libraries into different team libraries such as "human resources" and "support".
You will need a separate authoring template for each type of content item used by your site. The list of authoring templates defined in your authoring architecture is based on the different page types identified in the project plan, analysis document, and prototype website.
Each workflow, workflow stage and workflow action required for your web content system is listed in the authoring architecture.
Folders are used to group sets of item types into logical groupings. This is useful when you have large numbers of items in your library and want to distinguish between different groups of items within each item type view. Each folder required for your web content system is listed in the authoring architecture.
You can configure your system to either automatically save a version of an item each time it is published, or allow users to select when to save a version of an item. The version management strategy for different item types are documented in the authoring architecture.
The content acquisition architecture is used to define what existing content will be imported into your web content system, how it will be imported, and what content will need to be created.
Your technical architect and information architect need to define what delivery methods are most appropriate for the website you are delivering.
The delivery architecture describes which delivery methods are required for your web content system.
There are a set of tasks that you need to plan for that will maintain the health and integrity of your web content system. Your technical architect and database architect need to define what maintenance procedures are required for your system, and when and how often they need to be run.
The process and timing of software updates are defined in the maintenance architecture. This not only applies to Web Content Management and WebSphere Portal, but to all software products in your web content system.
For example, you would document procedures to install cumulative fixes for Web Content Management on a regular basis.
You document the process and timing of running each maintenance tool. This documentation not only applies to Web Content Management and WebSphere Portal, but to all software products in your web content system.
For example, you would document when and how often to run maintenance tools, such as the member fixer task, and when to clear item and version histories to maintain server performance.
To build a web content system you need to deploy hardware, configure servers, design an authoring system, configure a delivery environment and enable syndication. Get an overview of the steps required to build your web content system. Keep in mind the analysis and design documents developed during the planning phase of a project as you review the roadmap.
The first environment to deploy is your authoring environment. This environment can initially be used by a small team as a development environment, but can eventually be used as the authoring environment for all your users. The authoring environment is deployed based on the technical architecture defined in the project design documents.
Before you can start adding content to your web content system, you need to create all the items that will be used to manage and deliver your web content.
When the authoring system is ready, you then import and create the default content for your system. This is often managed by a separate team from the team that builds the web content authoring system.
Lotus Web Content Management is installed using the WebSphere Portal installation interface. Complete installation instructions are included in the WebSphere Portal product documentation. Follow the installation instructions for WebSphere Portal, then configure the authoring and delivery environments based on your needs and instructions provided in this documentation. Migration instructions are also included in the WebSphere Portal product documentation; Lotus Web Content Management is migrated as part of the overall WebSphere Portal migration process.
Set up a content server by installing IBM Lotus Web Content Management in various deployments to provide robust and flexible environments for web content development and delivery. After you install the content server, there are additional configuration steps you need to complete, according to the role that the server plays in your web content environment.
Configuration for Web Content Management is managed through services defined as resource environment providers in IBM WebSphere Application Server. For each service you can edit existing properties and add new properties through the WebSphere Application Server administrative console.
Set up the authoring environment by installing the authoring portlet and enabling other features required to support the authoring environment.
Pages that include the Web Content Management authoring portlet and the local rendering portlet are created when you first install WebSphere Portal. You only run the authoring portlet configuration task if you have previously uninstalled your authoring or local rendering portlets. The authoring portlet configuration task will automatically create Web Content Management pages and install the authoring portlet and local rendering portlets.
The language displayed in the authoring portlet is determined by the region or locale of the user. There are, however, some elements of the authoring portlet that use WebSphere Portal functions, such as date selection fields. These will be displayed using the locale of the WebSphere Portal server. For this reason, the language and locales of the site being created, the client and server should be consistent.
If your site contains content in different languages, then a separate Web Content Management authoring applications should be setup for each language on different WebSphere Portal Servers. These can then be combined into one site using a staging server.
Additional authoring portlet configuration options can be specified using the portlet administration view.
To add additional authoring portlet configuration parameters:
Parameter | Details |
htmlfield.rows | Defines the number of rows to display in an HTML field used in an element design or presentation template. If not specified, the default setting of 15 rows is used. |
htmlfield.columns | Defines the width of an HTML field used in an element design or presentation template. The width is defined as the number of characters to display per row. If not specified, the default setting of 85 characters is used. |
htmlfield.embedded.rows | Defines the number of rows to display in an HTML field used in an element design or presentation template, but not an HTML component. If not specified, the number of rows defined using htmlfield.rows is used. |
htmlfield.embedded.columns | Defines the width of an HTML field used in an element design or presentation template, but not an HTML component. The width is defined as the number of characters to display per row. If not specified, the number of characters defined using htmlfield.columns is used. |
htmlfield.htmlcomponent.rows | Defines the number of rows to display in the HTML field used in an HTML component. If not specified, the number of rows defined using htmlfield.rows is used. |
htmlfield.htmlcomponent.columns | Defines the width of the HTML field used in an HTML component. The width is defined as the number of characters to display per row. If not specified, the number of characters defined using htmlfield.columns is used. |
htmlfield.presentation.rows | Defines the number of rows to display in the HTML field used in a presentation template. If not specified, the number of rows defined using htmlfield.rows is used. |
htmlfield.presentation.columns | Defines the width of the HTML field used in a presentation template. The width is defined as the number of characters to display per row. If not specified, the number of characters defined using htmlfield.columns is used. |
EDIT_LIVE_CUSTOM_LICENCE | Use this is enter a custom license key to use
in place of the OEM license for Ephox EditLive using this format:Account ID,Domain,Expiration,License Key,Licensee,Product,Release |
You can tailor the authoring behavior of your web content environment by changing configuration settings such as workflow, profiling, and version control.
You define and manage authoring options in the WCM WCMConfigService service using the IBM WebSphere Application Server administration console.
Individual items can still be moved through workflow stages by accessing them through the normal item views and approving them.
If a version control strategy is not defined for an item type, then the version control strategy specified in by the versioningStrategy.Default property is used.
Property name | Value |
wcm.authoringui.lock.taxonomies | true |
wcm.authoringui.lock.categories | true |
wcm.authoringui.lock.siteareas | true |
When locking is enabled for site areas you cannot create any children under the locked site area. For example, if a site area is locked, you will not be able to create any new site areas or content items under that site area until it is unlocked. This only applies to items located one level below a locked parent. Items located under a child of a locked parent are not affected.
Active content filtering provides the ability to strip specified HTML fragments from HTML entered in elements. This includes rich text and HTML elements. Active content filtering is configured using the active.content.filtering.enable property. By default, active content filtering is enabled.If enabled, this will prevent a user from introducing malicious code into a web site such as cross site scripting.
Welcome <a href="javascript:window.alert("boo!")">my link</a> <script language="javascript">window.alert("boo 2!")</script> Click the link for a surprise.It would be changed to this when saved:
Welcome <a href="<"- active content removed -->">my link</a> <"- active content removed --> Click the link for a surprise.
You can change the configuration of the authoring portlet to change how search works.
You define and manage authoring portlet search options in the WCM WCMConfigService service using the IBM WebSphere Application Server administration console.
Because importing large files into IBM Lotus Web Content Management can have a negative impact on performance, you can adjust several settings to ensure better performance when importing files.
If users are experiencing timeout errors when saving items, you can increase the total transaction lifetime timeout setting of your WebSphere Portal server.
The total transaction lifetime timeout setting is changed using the WebSphere Application Server administration console.
Go to Servers > Server Types > WebSphere application serversportal_server> Container Services > Transaction Service
The total transaction lifetime timeout setting should be changed to the same amount on all the servers in your web content system.
Option | Details |
Authoring Templates | If a large number of elements have been added to an authoring template, you may experience a timeout error when saving. Instead of using a single authoring template, create multiple authoring templates that contain only those elements required for a specific task. |
Presentation templates and components | You may receive timeout errors when saving presentation templates or components that contain large amounts of HTML or rich text in their designs. You should instead create multiple HTML or rich text components and then reference these in the presentation templates or component designs. |
Site areas and content items | You may receive timeout errors when saving site areas and content items that contain elements that use large amounts of HTML. You should instead create multiple HTML or rich text components and then reference these in element designs. If a large number of elements have been added to a site area or content item, you may also experience a timeout error when saving. In this case, you should reduce the number of elements stored in the site area or content item. |
Downloadable files | Another alternative to creating web content containing large amounts of HTML or rich text is to provide information on your website in the form of downloadable files. These can be stored as file resource elements. |
Before you can add links to files and documents stored in remote content management systems into web content elements, you must configure your server with information about the remote system and the settings used to handle communication with the system.
Access to remote server www.example.com has not been granted. Please contact your system administrator.
Before you can access metadata from federated documents, you need to configure the federated documents feature. You can also tune the cache settings that are used with the federated documents feature.
To retrieve metadata information for documents on remote content management systems, configure the federated documents feature with information about the remote system and the settings used to handle communication with the system.
The federated documents feature uses the document list cache and the document data cache to manage information about the list of documents and the document data.
To tune these caches you can configure the Cache Manager Service (WP CacheManagerService) in the IBM WebSphere Application Server administrative console. Properties for the document list cache are identified by cacheinstance.com.ibm.pzn.wcm.ecm.DocumentListCache, and properties for the document data cache are identified by cacheinstance.com.ibm.pzn.wcm.ecm.DocumentMetaDataCache.
The user-specific document list cache is explicitly invalidated each time the user logs in, so that the most current list of available document identifiers is available upon login.
Configure the staging environment to emulate the web content delivery environment and allow for testing before deployment.
You define and manage staging environment options in the WCM WCMConfigService service using the IBM WebSphere Application Server administration console.
Set up your delivery environment by installing web content viewers and enabling any other required features.
To track usage data for the JSR 286 web content viewer, you can configure the portal for site analysis logging for the web content viewer.
To take advantage of the site analysis logging available for the JSR 286 web content viewer, you need to configure the WP SiteAnalyzerLogService service and activate the SiteAnalyzerJSRPortletLogger service.
The site analysis log uses the NCSA Combined log format, which is a combination of NCSA Common log format and three additional fields: the referrer field, the user_agent field, and the cookie field. This example describes typical site analysis logging information for the JSR 286 web content viewer.
The IBM WebSphere Portal site analysis log is:
The following example displays a sample entry in the site analysis log as it is written by the web content viewer if the SiteAnalyzerJSRPortletLogger is enabled.
188.8.131.52 - jdoe [22/Nov/2008:22:11:27 +0100] "GET /Portlet/5_8000CB1A00U6B02NVSPH1G20G1/Web_Content_Viewer_(JSR_286)/Web%20Content%2fTestSite01%2fTestSiteArea01%2fTestContent01?PortletPID=5_8000CB1A00U6B02NVSPH1G20G1&PortletMode=view&PortletState=normal&RequestType=render&PUBLIC_CONTEXT=%2fWeb%20Content%2fTestSite01 %2fTestSiteArea01%2fTestContent01 HTTP/1.1" 200 -1 "http://myserver.company.com/Page/ 6_8000CB1A00UR402F0JC25U1O25/MyPage" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124) Gecko/20081029 Firefox/126.96.36.199" "JSESSIONID=0000JwIm04xm7btVLwzCj9Qo-uj:-1"
Field in the Example | Log Field Name and Explanation |
126.96.36.199 |
- |
jdoe |
[22/Nov/2008:22:11:27 +0100] |
"GET /Portlet/[...] HTTP/1.1" |
200 |
-1 |
"http://myserver.company.com/Page/6_8000CB1A00UR402F0JC25U1O25/MyPage" |
"Mozilla/5.0 [...]" |
"JSESSIONID=0000JwIm04xm7btVLwzCj9Qo-uj:-1" |
As with other portlets in your portal, you can use the XML configuration interface (xmlaccess command) to deploy and configure the JSR 286 web content viewer. To simplify the configuration of the portlet with the XML configuration interface, the portlet parameters you can specify accept path values in addition to the standard IDs.
Both IBM Lotus Web Content Management generated Web pages and content from external data sources can be cached by the Web Content Management application. If utilized correctly, Web Content Management caching can dramatically increase the performance of a site.
Learn about the types of caching used by IBM Lotus Web Content Management, basic web content caching and advanced web content caching.
This is the simplest caching option. The first time a web page is rendered by the Web Content Management application, it is stored in a cache. Users then access this page from the cache until it expires. Only then is the web page rendered afresh. The main benefit of this scenario is improved performance. Basic caching should only be used on static content that does not require "real-time" access.
Advanced caching type | Details |
Site caching | This is the same as the basic web content cache except that cache parameters in connect tags and URL requests can be used to override your server's default advanced web content caching settings. |
Session caching | When session caching is enabled, a copy of each Web page a user visits is stored in the session cache. The User accesses the cached version of a web page until they start a new session, or until the cached web page is expired from the cache. |
User caching | When user caching is enabled, a copy of each Web page a user visits is stored in the user cache. The user accesses the cached version of a web page until the cached web page is expired from the cache. |
Secured caching | Secured caching is used on sites where the item security features are used to grant different users access to different Web pages and components based on the groups they belong to. |
Personalized caching | Personalized caching is used to cache web pages of users who have the same "personalization profile". This means that users who have selected the same personalization categories and keywords, and who belong to the same group, share a single cache. |
Cache parameters in connect tags and URL requests can be used to override your server's default advanced web content caching settings allowing you to set custom cache settings for individual web pages or components.
In most cases, basic, site and session caching would only be used as your server's default web content cache. User, secured and personalized caching would mostly be used when using custom caching in connect tags and URL requests.
Function | Basic caching | Advanced caching |
Memory usage per item: | Medium | High |
Performance improvement: | Very High | High |
Custom caching available: | No | Yes |
Connect tag processing: | No | Yes |
Web Content Viewer Portlet: | No | Yes |
Web content caching can sometimes be used with Personalization components but will depend on the conditions set in the personalization rule, or the resources used to determine the rule results. Cache testing will be required to determine if the content returned by your personalization component can be cached using web content caching.
Content displayed in rendering portlets and through IBM Lotus Web Content Management can be cached. An alternative to caching is the use of the pre-rendering feature. View the differences between each strategy.
At first glance, the pre-rendering feature and basic caching do the same thing. There are however, some major differences that will determine which feature is the best for you.
The main difference between the two features is that the pre-rendering feature takes a snapshot of the entire site each time it is run. Basic caching only caches on a page-by-page basis. If performance is your main issue, then pre-rendering might be the answer. If not, then basic caching might be a better option.
Function | Basic caching | Pre-rendered site delivered with a web server |
Performance: | Very fast | Extremely fast |
Connect tag processing: | Yes | No |
Custom caching: | Yes | No |
Memory requirements: | Low to Medium | Memory requirements depends on the web server being used. |
Disk requirements: | Low to Medium | Potentially very high as the entire site must be able to fit on disk. |
Unexpected broken links: | Yes As some pages may be cached at different times, there is a small chance that not all the links on a cached page will be currently valid. |
No The site is pre-rendered in a single batch, greatly reducing the chances of inconsistencies in the site. |
These options are very similar. You may have to test both strategies before deciding which is best for your site.
Function | Advanced caching | Pre-rendered site delivered through Web Content Management |
Performance: | Fast when cached, but slower if the requested page has expired from the cache. (As tag processing has a cost, this depends on how many connect tags a page contains.) | Fast, but as tag processing has a cost, this depends on how many connect tags a page contains. |
Connect tag processing: | Yes | No |
Custom caching: | Yes | No |
Memory requirements: | Medium to high. | Medium to high. |
Disk requirements: | Medium to high. | Medium to high. |
Unexpected broken links: | Yes As some pages may be cached at different times, there is a small chance that not all the links on a cached page will be currently valid. |
No The site is pre-rendered in a single batch, greatly reducing the chances of inconsistencies in the site. |
Like caching strategies, a server's default expiring strategies can be set in the WCM WCMConfigService service using the IBM WebSphere Application Server administration console. Custom expiring parameters can also be set in connect tags and URL requests to override a server's default expiring strategies.
In most cases the expiry schedule is based around how often the source content is updated. So, if the source content is updated hourly, then each cache would be expired hourly. If the source content is updated daily, then each cache would be expired daily.
Beyond these examples, a different expiry schedule would be used. If your web pages were only updated weekly, or monthly, you would still schedule your caches to expire daily. Otherwise, when your source content was updated, it could take up to a week for it to appear on your site.
The expires parameter in a workflow is not related to the Expires parameter in IBM Lotus Web Content Management caching. A page that is set to expire at midnight as part of a workflow will only do so if it has not already been saved in a cache. The page will remain in the cache until expired by the Web Content Management application regardless of the Expires setting in a workflow.
You can tailor the caching behavior of your web content environment by changing configuration settings such as the default cache type and expire settings.
You define and manage web content cache options in the WCM WCMConfigService service using the IBM WebSphere Application Server administration console.
Parameter | defaultcache value | defaultcontentcache value |
No caching: | false | None |
Basic cache: | true | Not specified |
Site caching: | false | Site |
Session caching: | false | Session |
User caching: | false | User |
Secured caching: | false | Secured |
Personalized caching: | false | Personalized |
Web content cache configuration settings are specified by the following properties in the WCM WCMConfigService service.
Cache Type | Properties |
Basic cache: | connect.businesslogic.defaultcacheexpires connect.businesslogic.defaultcache |
Advanced cache: All | connect.moduleconfig.ajpe.contentcache.defaultcontentcache connect.moduleconfig.ajpe.contentcache.contentcacheexpires |
Advanced cache: Session cache only | connect.sessioncacheconfig.memcachesize |
Cache Property | Details |
contentcacheexpires | This sets the default expiry for all advanced caches. It can be either a relative period or an absolute date and time. |
defaultcache | If true, basic caching is enabled. If false or missing, advanced caching is enabled. |
defaultcacheexpires | This sets the default expiry for the basic cache. It can be either a relative period or an absolute date and time. |
defaultcontentcache | If the advanced cache is enabled, the default advanced cache is set here. |
resourceserver.browserCacheMaxAge | This is used to define the maximum time an item will be stored in a web browser cache. |
resourceserver.maxCacheObjectSize | This is used to define the maximum size of objects that can be cached in kilobytes. By default this is set to 300. |
Data caching is used to cache data retrieved by the IBM Lotus Web Content Management application from external sources using connect tags or by requests made through URLs.
You define and manage data cache options in the WCM WCMConfigService service using the IBM WebSphere Application Server administration console.
Specify the following properties for data cache options:
You can enable pre-rendering so that content can be viewed either through a IBM Lotus Web Content Management application or as a standalone site that is accessed through a web server.
You define and manage pre-rendering options in the WCM WCMConfigService service using the IBM WebSphere Application Server administration console.
This option is used when you are accessing the pre-rendered site through Web Content Management. This will increase performance as static content is accessed from the pre-rendered site, but dynamic content will still be rendered through Web Content Management.
This option is used when you are using Web Content Management to generate a pre-rendered site, but are not using Web Content Management to view the pre-rendered site. You will need to use a web server to view the pre-rendered site.
The temporary directory that is required to build the site cache prior to moving the data over to the base directory specified by the connect.moduleconfig.cacher.destdir property.
This is used to set the time, in seconds, between requesting a page while caching.
This is used to set the time, in seconds, of the busy delay setting. This is used if executing within the busy start to busy end period. Otherwise the delay setting is used.
These settings determine the times between which the busy delay setting will be used. Enter an absolute time as shown.
This determines the user to be used to render the Web Content Management content. Either type Anonymous or Administrator or a specific user or group name.
The site is pre-rendered based on this user's security rights. If the user specified here does not have access to a particular component it will not be pre-rendered.
The full URL to be used as the replacement for the connect servlet in pre-rendered pages. The URL should end with the string specified in connect.moduleconfig.cacher.task.servletpath property if it is not blank. The context of cacherurl is used when generating a URL with pre-rendering. This property is not used when a page belongs to a site that has not already been pre-rendered at a site level by the scheduled task or through a SRV=cacheSite request.
The path of the substituted connect servlet defined in the connect.moduleconfig.cacher.task.cacherurl property. This property can be left blank if the cacherurl context should be used unchanged.
This sets the name of the default or home file used when accessing the pre-rendered site. This normally would be index.html.
The site areas within a Web Content Management environment to cache are entered here, separated by commas. This property provides the option of specifying the library in addition to the site area. If the library is specified, the pre-renderer looks for the site area in that library. If no library is specified, the default library is used, as specified in the defaultLibrary property.
The recurring period in minutes for a recurring task.
The delay in minutes prior to starting the first recurring task.
All other resources that whose IDs begin with "79" will also be stored under this folder. This is done to reduce the number of sub-folders under the "resources" folders.
When working with the JSR 286 web content viewer or Web content pages, some scenarios involve web content authoring tasks accomplished with authoring tools components. Such authoring tasks are performed through a special instance of the authoring portlet that is reserved specifically for these tasks and is installed on page that is hidden from the page navigation available to typical users.
Typically authoring tasks are performed in a separate window that opens from the current page, but you can configure the behavior of authoring tools components to redirect users to the hidden page containing the reserved authoring portlet.
If either the authoring portlet instance or the hidden portal page are not available or if the user lacks the permission to access either of them, the authoring tasks requiring the reserved authoring portlet will fail, causing web content pages and the JSR 286 web content viewer to be unusable. For this reason, you must be careful when administering the reserved authoring portlet and the hidden portal page.
Error 400: EJPPH0006E: The resolution of a URI failed. Refer to the stack trace for more detailed information.
If any of these problems occur, verify that the conditions for proper operation of the reserved authoring portlet and hidden portlet page are fully implemented.
The reserved authoring portlet is essential to the proper operation of web content pages and the JSR 286 web content viewer, so it is important that the configuration of the reserved authoring portlet reflect similar settings for performing authoring tasks as the configuration of other instances of the IBM Lotus Web Content Management authoring portlet.
These configuration options are available to address installation requirements for additional deployment scenarios.
By default, you can specify any host name in a URL used to retrieve content. However, you can restrict access to a specified list of host names by modifying the configuration of the WCM WCMConfigService service.
IBM Lotus Web Content Management uses several substitution variables defined in the configuration for IBM WebSphere Application Server.
Variable | Description |
WCM_CONTEXT_ROOT | The context root for the enterprise
application for Web Content Management. Example: wps/wcm |
WCM_HOST | The fully qualified host name of the
machine running the portal. Example: www.example.com |
WCM_ILWWCM_HOME | This is the directory where the Web Content Management application is
installed Example: PortalServer_root/wcm |
WCM_PORT | The port number used to access the
portal. Example: 10038 |
WCM_SCHEMA | The database schema name of the JCR
domain configured for use with IBM WebSphere Portal. Example: jcr |
WCM_SEARCHSEED_CONTEXT_ROOT | The context root for the Search Seed
portlet. Example: wps/wcmsearchseed |
WCM_WEB_APP_HOME | The directory path where the ilwwcm.war
file is located. Example: was_profile_root/wp_profile/installedApps/node_name/wcm.ear/ilwwcm.war |
WCM_WPS_CONTEXT_ROOT | The context root or base URI for the
portal. All URLs beginning with this path will be reserved for the
portal. Example: wps http://hostname.example.com:10038/wps/portal |
WCM_WPS_DEFAULT_HOME | The default portal page. This is the
page for users who are not logged in. Example: portal http://hostname.example.com:10038/wps/portal |
WCM_WPS_PERSONALIZED_HOME | The portal page for users who have
already logged in to the portal. This page cannot be accessed by
anonymous users. Example: myportal http://hostname.example.com:10038/wps/myportal |
From time to time you may need to reset the web content event log.
Enable connect tags to reference web content components and apply customized caching to the components.
The remove authoring configuration task will uninstall the authoring portlet and related portal pages.
To remove the Authoring portlet:
Syndication is used to synchronize web content between servers. You can configure when syndication is run, and how often it is run.
You can tailor the syndication behavior of your web content environment by changing configuration settings such as the syndication interval and automatic syndication.
You define and manage syndication options in the WCM WCMConfigService service using the IBM WebSphere Application Server administration console.
Although the frequency of syndication is set by default during installation, you can change the syndication interval to better suit the needs of your environment.
To change the syndication interval, modify the deployment.itemChangedTaskDelay property. By default, the syndication interval is set to 30 seconds. Specify the number of seconds to use as the syndication interval, with a minimum of 0 seconds and a maximum of 65536 seconds. A value of 0 will prevent syndication from occurring. If you set the value to so short an interval that syndication cannot complete before the interval expires, syndication begins again when the previous syndication completes.
In some cases you might choose to rely only on manual syndication to have complete control over when syndication occurs. To do this, you must disable automatic syndication. When automatic syndication is disabled, the syndication interval setting is ignored. This property should be set to the same value on both the syndicator and the subscriber.
A syndicator server uses several processes to gather and queue content for syndication. These processes can sometimes impact server performance when run. However, a subscriber-only server does not require these processes, so you can improve performance on the subscriber-only server by disabling the processes.
To do this, ensure that deployment.subscriberOnly property is set to true.
In some cases you might choose to rely only on manual syndication to have complete control over when syndication occurs. To do this, you must disable automatic syndication.
Although the frequency of syndication is set by default during installation, you can change the syndication interval to better suit the needs of your environment.
You use Portal Search to search for text displayed in web sites created by IBM Lotus Web Content Management.
In order to search for web content, your content must first be indexed by the WebSphere Portal search engine. Once the content has been indexed, you can run searches using the search center or using a search component.
http://hostname:port_number/seedlist/myserver?SeedlistId=library/sitearea1/sitearea2 &Source=com.ibm.workplace.wcm.plugins.seedlist.retriever.WCMRetrieverFactory&Action=GetDocumentsYou will need to replace hostname, port_number, library and site area with values appropriate for your site. If your library name or site area names contain spaces, you will need to replace the spaces with a "+" symbol. For example, the path library one/site area one would be instead be defined as library+one/site+area+one
http://httpserver:port_number/seedlist/myserver?SeedlistId=library/sitearea1/sitearea2 &Source=com.ibm.workplace.wcm.plugins.seedlist.retriever.WCMRetrieverFactory&Action=GetDocumentsYou will need to replace httpserver, port_number, library and site area with values appropriate for your site. If your library name or site area names contain spaces, you will need to replace the spaces with a "+" symbol. For example, the path library one/site area one would be instead be defined as library+one/site+area+one
http://httpserver:port_number/seedlist/myserver/virtualPortalContext?SeedlistId=library/sitearea1/sitearea2 &Source=com.ibm.workplace.wcm.plugins.seedlist.retriever.WCMRetrieverFactory&Action=GetDocumentsYou will need to replace httpserver, port_number, virtualPortalContext, library and site area with values appropriate for your site. If your library name or site area names contain spaces, you will need to replace the spaces with a "+" symbol. For example, the path library one/site area one would be instead be defined as library+one/site+area+one
http://vphostname:port_number/seedlist/myserver/?SeedlistId=library/sitearea1/sitearea2 &Source=com.ibm.workplace.wcm.plugins.seedlist.retriever.WCMRetrieverFactory&Action=GetDocumentsYou will need to replace vphostname, port_number, library and site area with values appropriate for your site. If your library name or site area names contain spaces, you will need to replace the spaces with a "+" symbol. For example, the path library one/site area one would be instead be defined as library+one/site+area+one
Search services and search collections are separate for individual virtual portals and are not shared between individual virtual portals. You set up an individual search service and separate search collections for each virtual portal. These collections can be used to crawl and search the same set of documents.
You must perform these steps for each virtual portal in your system.
You can edit the following search options to manage how the search service works with Web Content Management search forms
You can use the Search and Browse portlet to search for web content by adding a web content search collection to the configuration of a new Search and Browse portlet.
You can use the Search Center to search for web content by adding a web content search collection to the Search Center.
Portal Search supports the use of seedlists to make crawling websites and their metadata more efficient and to provide content owners fine-grained control over how content and metadata are crawled. You can configure the portal to leverage seedlist support when crawling content generated with IBM Lotus Web Content Management.
Search seedlist 1.0 can make access control information available in a way that makes pre-filtering of contents possible. Pre-filtering provides the fastest filtering approach because it takes place in the search index level. An additional advantage of pre-filtering is that remote secured content sources can be searched from the portal. The filtering mode is defined as part of the search service configuration parameters.
By default Portal Search is configured to support the search seedlist 1.0 format. Using the seedlist 1.0 format makes it possible to leverage the web content page type to render content found in the search results on the corresponding web content page. You can also include custom metadata fields from a web content item that will appear in the search seedlist but not in the HTML source.
Search seedlist 1.0 can make access control information available in a way that makes pre-filtering of contents possible. Pre-filtering provides the fastest filtering approach because it takes place in the search index level. An additional advantage of pre-filtering is that remote secured content sources can be searched from the portal. The filtering mode is defined as part of the search service configuration parameters.
If you want to use Portal Search to crawl your web content and leverage features like web content pages you must enable seedlist 1.0 support for the Portal Search crawler.
With the search seedlist 1.0 support, custom metadata fields specified on content items are added to the search seedlist as metadata information, without requiring the metadata to appear in the HTML source for the content items.
The IBM Lotus Web Content Management API for retrieving application content through a seedlist is based on the REST architecture style. To obtain seedlist content, third party crawlers or administrator applications only need to construct and send HTTP requests to the application servlet. With seedlist format 1.0, the syntax of the seedlist URL has changed
The request is a standard HTTP GET command. The URL is formed by combining the seedlist servlet host name, port number, and path; followed by a collection of name-value pairs (input parameters) separated by ampersand (&) characters.
https://hostname:port_number/seedlist/myserver?SeedlistId=library/sitearea1/sitearea2 &Source=com.ibm.workplace.wcm.plugins.seedlist.retriever.WCMRetrieverFactory&Action=GetDocumentsYou will need to replace hostname, port_number, library and site area with values appropriate for your site.
http://httpserver:port_number/seedlist/myserver?SeedlistId=library/sitearea1/sitearea2 &Source=com.ibm.workplace.wcm.plugins.seedlist.retriever.WCMRetrieverFactory&Action=GetDocumentsYou will need to replace httpserver, port_number, library and site area with values appropriate for your site.
http://httpserver:port_number/seedlist/myserver/virtualPortalContext?SeedlistId=library/sitearea1/sitearea2 &Source=com.ibm.workplace.wcm.plugins.seedlist.retriever.WCMRetrieverFactory&Action=GetDocumentsYou will need to replace httpserver, port_number, virtualPortalContext, library and site area with values appropriate for your site.
http://vphostname:port_number/seedlist/myserver/?SeedlistId=library/sitearea1/sitearea2 &Source=com.ibm.workplace.wcm.plugins.seedlist.retriever.WCMRetrieverFactory&Action=GetDocumentsYou will need to replace vphostname, port_number, library and site area with values appropriate for your site.
Parameter | Default Value | Description |
SeedlistID | No default; must be specified. | Identifies the seedlist. This parameter can be specified
in either of the following ways:
Start | 0 | Defines the start number for currently returned section. |
Range | 100 | Defines the number of returned entries for current section. |
Date | No default. If not specified, all applicable results are returned. | Indicates that entries (documents) that were updated after
this date will be retrieved. The date format (compliant to standard
ISO 8601) is the following : dateTtimezone, where date is yyyy-MM-dd, time is HH:mm:ss, and zone is ±hhmm.
This format includes time zone information, which is critical if the
client and server are in different time zones. Important: Proper HTML URL encoding must be performed (for example, the plus
symbol + should be represented as %2B).
Action | GetDocuments | Defines requested action to execute.
Format | ATOM | Defines the output format : ATOM / HTML/ XML. |
Timestamp | No default. | Indicates the content provider timestamp from a previous crawling session. The timestamp represents for the content provider some snapshot of the content and allows the crawler to get only the content changes on the next crawling. This is used for incremental crawghtling. |
Although Portal Search is configured to support the search seedlist 1.0 format by default, you can reconfigure the portal to use the standard seedlist 0.9 format when searching for web content with the Search Center. For example, you might choose to use seedlist format 0.9 because you want to make use of older search collections or because you retrieve the seedlist 0.9 contents using the seedlist URL, which uses a different syntax from the URL used with the search seedlist 1.0 format.
To use the seedlist format 0.9, you essentially disable the default support for the seedlist format 1.0.
When using tagging and rating with web content, the JSR 286 web content viewer provides additional scope options for the filtering of tagging and rating results. Because changes in the web content system can affect the accuracy of the tagging and rating information used by the portal, it is important to keep the scope information up to date by synchronizing the scopes on a regular basis.
Scoping is typically used to filter the tag cloud or ratings overview according to hierarchical metadata attached to the resources being tagged. When applying tagging and rating to web content, you can scope these display components according to authoring template, category, or content item parent.
When users are tagging or rating web content, the JSR 286 web content viewer provides the tagging or rating information to the portal, where it is stored. If information in the web content system changes, this can cause the tagging and rating information stored in the portal to be out of sync. This can happen, for example, if content items are moved or category information changes. To ensure the tagging and rating information is current, synchronize the scopes used for web content.
To automatically perform scope synchronization whenever an item changes in the web content system, specify the tagging.syndication.enableItemModificationSynchronization property in the Web Content Management configuration service.
To automatically perform scope synchronization whenever syndication occurs, specify the tagging.syndication.enableTagSynchronization property in the Web Content Management configuration service.
You can schedule scope synchronization to be performed at specific times by defining the schedule with the XML configuration interface.
If you have not enabled automatic synchronization of the scopes used for web content or if you want to perform synchronization outside of a scheduled synchronization period, you can manually start the synchronization process.
<?xml version="1.0" encoding="UTF-8"?> <request type="update" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="PortalConfig_7.0.0.xsd"> <portal action="locate"> <task action="create" name="com.ibm.portal.cp.SynchronizationTask"/> </portal> </request>
Setting up a portal site includes customizing the portal's look-and-feel, creating pages, setting up search, and adding content to the site. Themes are used to customize the portal's look-and-feel. Out-of-the-box templates and the site wizard can help you setup your portal site faster. You can add wikis and blogs to your site and let users tag and rate content on your site.
WebSphere Portal includes a site wizard, sample sites, templates and more to make site creation fast and easy. Before you start creating your site, get familiar with the out-of-the-box samples and learn more about the site wizard.
IBM® WebSphere® Portal includes sample Internet and Intranet Web sites that you can use as a template to streamline development of your own portal site. Use the New Site Wizard to generate your own portal site without learning portal development skills.
The sample Intranet and Internet sites are not automatically installed when you install WebSphere Portal, but you can add them after installation completes by running the configure-express task before you configure the portal database, user registry, context root, or security. For more information, see the instructions on setting up a stand-alone server or a clustered server on your particular platform.
Use the Intranet site template as a starting point for creating your own employee site. Home, Work, and Resources pages come seeded with placeholder content that you can use as is or customize. Easy to use list portlets let you organize and manage announcements, news, events, FAQs, and links.
Use the Internet site template to get a jumpstart on building a Web site where customers can learn about product offerings, marketing promotions, and company news.
More content samples are available on the IBM WebSphere Portal Business Solutions Catalog.
Use the New Site Wizard to generate your own site – without needing any portal development skills or assistance from an administrator. Just select a site template from the available samples, choose the look and feel you want, and then let the wizard do the rest.
The wizard automatically creates new sites as virtual portals; however, administrators and developers can extend the wizard to create any type of portal site. Portal developers can also enhance the New Site Wizard by creating custom site templates, and then adding them to the wizard.
Download the New Site Wizard from the IBM WebSphere Portal Business Solutions Catalog. Package contents include the portlet .war (Web Application Archive) file, supporting files and directories, and detailed instructions in a .pdf file. After deploying the wizard, you need to add the portlet to a page that users can access. For more information, see the .pdf file that comes with the wizard.
Before you begin to work on your own, take time to test drive and explore the default Internet and Intranet sites templates that are provided with the product.
Understanding the underlying concept of workflow is key to working with the Intranet and Internet site templates. Different authoring templates such as Announcements, Events, Company News, and FAQs help to simplify the content creation process. However, before any content that you create can appear on a site, it must pass through a series of stages (a workflow) and be in the Publish stage. The authoring templates in the intranet and internet site templates use two predefined workflows: Standard Workflow and QuickFlow.
Standard Workflow has 4 stages: Draft, Review, Publish, and Expire. When you work with authoring templates that use Standard Workflow, content that you save goes to Draft stage. An administrator must review and publish draft content before it can appear with other available contents. Alternatively, to move the content to the Review stage, you can choose Save and approve. From there, click Next stage to publish the content. Authoring templates that use Standard Workflow include Latest News (in the Intranet site template), and Products and Company News (in the Internet site template).
QuickFlow has just 2 stages: Publish and Expire. When you work with authoring templates that use QuickFlow, content is published immediately when you click Save. Authoring templates that use QuickFlow include Announcements and Events (in the Intranet site template) and What's New, Promotions, and FAQs (in the Internet site template).
By default, users in the All Authenticated Portal Users group have privileged user access to the Intranet and Internet Site Templates. Thus every authenticated Portal user can customize these pages. To restrict this group to view access, remove the group from the Privileged user role of the Intranet and Internet Site Templates and add it to the User role.
In addition to privileged user access, users in the contentAuthors group have editor access to the Internet and Intranet Site Template content that is created and maintained with Web Content Management. A content author can edit the content that is delivered out of the box, as well as create, edit, and delete new content for the Internet and Intranet Site Templates.
Before customizing your portal site, understand the underlying structure of the portal.
Within this location, subdirectories for markup, locale, and client types are used to support portal aggregation.
The starting place for building the portal page is Default.jsp in the /themes directory. The screen and skin are called by their corresponding tags from the portal-core tag library: the screen is called by the <portal-core:screenRender/> tag, while the skin is called by the <portal-core:pageRender/> tag.
You can add your own elements to the HTML portal page and rearrange the layout by creating a new theme and changing the layout in Default.jsp and the JSPs that are included. Learn about the order and layout in which the portal page theme is built using the JSPs that are provided after installation. Use this information to learn how to include some of these components as you build your own themes.
For most requests, the portal page is rendered starting with Default.jsp in the /themes directory. The only exception is when the request has been modified by a newWindow="true" parameter. In this case, the page is rendered using Plain.jsp. Plain.jsp is normally used to render portlet help or for portlets that use the iFrame skin.
Theme policy is used to control how a theme is rendered on a page. A policy is created and stored using the XML configuration interface. Once stored, it can be applied to a page either through the XML configuration interface using the page metadata attribute com.ibm.portal.ThemePolicy or through the Properties portlet. Theme policy is inherited so it only needs to be set on a page which requires a different policy than its parent.
Head.jspf provides the necessary header information to correctly render the portal page. This file is used to link the style sheets and client-side scripts as well as set the page title and the text direction.
Flyout.jspf contains a hidden document division (<div/>) which is used by actions in the banner's toolbar to display content which is dynamically displayed and hidden as needed.
The drag-and-drop feature lets you quickly change the placement of individual portlets using your skins. The drag-and-drop feature lets you move a custom portlet from its current position by dropping it to another position on a page. This lets you quickly change the arrangement of your custom portlets on a page.
Theme policies control how a theme renders for a particular page. The attributes of the theme policy assigned to the current page are consumed by the theme JSPs to control what gets rendered, as well as how it is rendered.
The switch to using JSPs for style sheets provides a great advantage in the reduction of the number of files that must be maintained or generated when a style sheet is updated. However, a performance concern is introduced in that the output of the compiled JSPs needs to be cached to avoid having to be generated on each request. WebSphere Portal provides the <portal-theme:cacheProxyUrl/> JSP tag to solve this problem.
Learn about theme policy, theme policy attributes, and the theme policies available with WebSphere Portal. Learn about setting a theme policy on a page using the XML configuration interface, using theme policy in a JSP, creating your own theme policy, and updating, exporting, and deleting a theme policy.
Theme policy is used to control how a theme is rendered on a page. A policy is created and stored using the XML configuration interface. Once stored, it can be applied to a page either through the XML configuration interface using the page metadata attribute com.ibm.portal.ThemePolicy or the Properties portlet. Theme policy is inherited so it only needs to be set on a page which requires a different policy than its parent.
A theme policy is made up of several attributes. Each attribute controls one aspect of the theme. For example, the Boolean renderBreadCrumb attribute controls whether the bread crumb will be displayed while the breadCrumbMaxLevels attribute controls the number of steps listed in the bread crumb when it is displayed.
Attribute | Type | Function |
renderMainMenu | Boolean | If true, the main menu is rendered |
renderTopNavigation | Boolean | If true, top navigation is rendered |
renderMainMenuActions | Boolean | If true, the main menu actions are rendered |
renderSelfCare | Boolean | If true, Selfcare is rendered |
renderBreadCrumbTrail | Boolean | If true, the bread crumb trail is rendered |
renderSearch | Boolean | If true, search is rendered |
renderToolBar | Boolean | If true, the tool bar is rendered |
renderContentPalette | Boolean | If true, the portlet palette is rendered |
renderPeoplePalette | Boolean | If true, the people palette is rendered |
renderContextMenus | Boolean | If true, context menus are render |
renderSideNavigation | Boolean | If true, side navigation is rendered |
renderTaskBar | Boolean | If true, the task bar is rendered |
renderFavorites | Boolean | If true, favorites is rendered |
renderExtensions | Boolean | If true, extensions are rendered |
renderBannerTitleGraphic | Boolean | If true, the banner title graphic is rendered as long as one exists |
renderPortletFragmentIDAnchor | Boolean | Used to determine if the user is on a palette page |
renderBannerTitle | Boolean | If true, the banner title is rendered as long as one exists |
breadCrumbMaxLevels | Integer | Indicates the number of steps listed in the bread crumb trail |
breadCrumbStartLevel | Integer | Indicates which level to start the bread crumb trail |
rootNavigationStartLevel | Integer | Indicates the start level for root navigation |
rootNavigationStopLevel | Integer | Indicates the stop level for root navigation |
topNavigationNumRows | Integer | Indicates the number of rows to render for top navigation |
topNavigationStartLevel | Integer | Indicates the start level for top navigation |
topNavigationStopLevel | Integer | Indicates the stop level for top navigation |
sideNavigationStartLevel | Integer | Indicates the start level for side navigation |
isCustomizable | Boolean | If true, the policy can be edited in the Theme Customizer portlet. |
isDeletable | Boolean | If true, the policy can be deleted in the Theme
Customizer portlet. Note: xmlaccess ignores this attribute.
colorPalette | String | If specified, the value in this attribute is the name of the color palette. The search order for the
name of the color palette used on the page is:
The name of the color palette must be the name of a properties file provided in the theme without the .properties extension. |
colorPaletteProperties | String | Color Palette information. This is a stored java.util.Properties object created by the Theme Customizer portlet. The theme first loads the color palette for the page and then overwrites those values with any that may be present in this attribute. |
graphicFilesMimeData | String | If specified, graphic files uploaded through the Theme Customizer portlet. This attribute is a standard multipart/mixed MIME text stream containing attachments encoded with Base64 encoding. |
styleVersion | Integer | The version number of the policy. This value is incremented each time the Theme Customizer portlet saves the policy so updates to the policy can be loaded without clearing the browser cache. |
bannerTitleText | String | Indicates the text that is to be displayed as the title in the banner and browser title bar. If this value is empty, the bannerTitleTextResourceBundle and bannerTitleTextResourceKey attributes are used to determine the title text. |
bannerTitleTextResourceBundle | String | Indicates the resource bundle containing the title text. |
bannerTitleTextResourceKey | String | Indicates the resource bundle key that is to be used to locate the title |
bannerTitleGraphic | String | Indicates the URI of the title graphic to be displayed in the banner. This value is passed on the uri attribute of the portal-resolver:url tag. Values created by the Theme Customizer portlet are of the form: "themeGraphic:policy:filePath:xxx" where xxx is the name of the attachment stored in the graphicFilesMimeData attribute. |
renderBannerQuickLinks | Boolean | If true, banner quick links are rendered |
renderHelpLink | Boolean | If true, the help link is rendered |
renderQuickLinksShelf | Boolean | If true, the quick links shelf is rendered |
quickLinksShelfStyle | Integer | Style attributes for the quick links shelf. This is a bitmask field. If bit 1 is turned on, the quick links shelf default state is expanded. If bit 2 is turned on, the expand/collapse link is hidden. As such, the following values are supported:
renderApplicationName | Boolean | If true, the application name is rendered |
renderCustomizeThemeLink | Boolean | If true, the theme customizer link is rendered |
WebSphere Portal provides ten policies that may be used without alteration. The following information provides lists of each policy along with the corresponding attributes, values, and types.
Custom theme attributes
In addition to the attributes in each policy above, you can add an attribute to the theme policies and then use it in your JSP or JSPF. The following code samples show how the custom attribute renderTestAttribute is added to theme policy and how it is accessed in a JSP or JSPF.
<policyValue Name="renderTestAttribute" Factory="com.ibm.wps.policy.parse.BooleanFactory"> <value>true</value> </policyValue> <policyValue Name="renderTestAttributeLock" Factory="com.ibm.wps.policy.parse.BooleanFactory"> <value>false</value> </policyValue>
The policy value sets consisting of attributes and their values can be nested. Child attributes can either inherit or override the values from the parent attribute. When you specify the value of a lock attribute corresponding to a policy attribute as true, you lock the policy node. In this case, the child attributes necessarily inherit the values from parent attributes and cannot override these values.
<policyValue Name="renderTestAttribute" Factory="com.ibm.wps.policy.parse.BooleanFactory"> <value>false</value> </policyValue>Since this is a Boolean, the value would be set to true or false.
<% boolean isTestAttribute = themePolicy.getValueAsBoolean("renderTestAttribute", false); if(isTestAttribute){%> <p> Display this paragraph if renderTestAttribute is true. </p> <%}%>
In the above example, if the value of renderTestAttribute is true, the paragraph is displayed. themePolicy is defined in the Using theme policy in a JSP section of this topic.
Theme Policy can be applied to a page through the XML configuration interface using the page metadata attribute com.ibm.portal.ThemePolicy. The following provides an example of an XML script that sets the page metadata for the theme policy for the page ThemePolicyPageTest:
<request type="update" create-oids="true" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="PortalConfig_1.4.xsd"> <portal action="locate"> <content-node action="update" ordinal="last" uniquename="ibm.portal.ThemePolicyPageTest" content-parentref="Content.Root" active="true" allportletsallowed="false" create-type="explicit" objectid="wp.theme.policytestpage" type="page"> <supported-markup markup="html" update="set"/> <!--@LocaleData_1@--> <parameter name="com.ibm.portal.ThemePolicy" type="string" update="set">theme/SingleTopNavMinimal</parameter> </content-node> </portal> </request>
You can also use a theme policy directly in a JSP. Use the following code to do this:
<themepolicy:initthemepolicy/> <jsp:useBean id="themePolicy" class="com.ibm.portal.theme.policy.ThemePolicyBean" scope="page"/> <% themePolicy.setValuesMap(portalThemePolicyMap);%>
In this code sample, the theme bean is initialized which wrappers the theme policy attributes.
To use an attribute in the JSP, reference it with the following syntax: ${themePolicy.attribute) where the attribute would be, for example, renderSideNavigation. The following code tests renderSideNavigation. If it is TRUE, the following code is executed:
<c-rt:if test = "${themePolicy.renderSideNavigation}"> <!-- following code --> <….> <….> </c-rt:if>
The following code sample sets startLevel to the value of the theme policy attribute sideNavigationStartLevel:
<portal:navigation startLevel="${themePolicy.sideNavigationStartLevel}"
<?xml version="1.0" encoding="UTF-8"?> <request build="wp700_586_01" type="update" version="184.108.40.206" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="PortalConfig_7.0.0.xsd"> <portal action="locate"> <policy-node action="update" path="/theme/TestThemePolicy"> <parameter name="Description" type="string" update="set"><![CDATA[Test Theme Policy]]></parameter> <parameter name="Path" type="string" update="set"><![CDATA[./TestThemePolicy]]></parameter> <parameter name="PathType" type="string" update="set"><![CDATA[/theme]]></parameter> <parameter name="PznRule" type="string" update="set"/> <parameter name="PznType" type="string" update="set"><![CDATA[TestThemePolicy]]></parameter> <parameter name="Remote" type="string" update="set"/> <parameter name="Title" type="string" update="set"><![CDATA[TestThemePolicy]]></parameter> <parameter name="Type" type="string" update="set"><![CDATA[theme]]></parameter> <parameter name="breadCrumbMaxLevels" type="integer" update="set">5</parameter> <parameter name="breadCrumbStartLevel" type="integer" update="set">1</parameter> <parameter name="renderBannerTitle" type="boolean" update="set">true</parameter> <parameter name="renderBannerTitleGraphic" type="boolean" update="set">true</parameter> <parameter name="renderBreadCrumbTrail" type="boolean" update="set">false</parameter> <parameter name="renderContentPalette" type="boolean" update="set">true</parameter> <parameter name="renderContextMenus" type="boolean" update="set">true</parameter> <parameter name="renderExtensions" type="boolean" update="set">true</parameter> <parameter name="renderFavorites" type="boolean" update="set">true</parameter> <parameter name="renderMainMenu" type="boolean" update="set">true</parameter> <parameter name="renderMainMenuActions" type="boolean" update="set">true</parameter> <parameter name="renderPeoplePalette" type="boolean" update="set">true</parameter> <parameter name="renderPortletFragmentIDAnchor" type="boolean" update="set">true</parameter> <parameter name="renderSearch" type="boolean" update="set">true</parameter> <parameter name="renderSelfCare" type="boolean" update="set">true</parameter> <parameter name="renderSideNavigation" type="boolean" update="set">true</parameter> <parameter name="renderTaskBar" type="boolean" update="set">true</parameter> <parameter name="renderToolBar" type="boolean" update="set">true</parameter> <parameter name="renderTopNavigation" type="boolean" update="set">true</parameter> <parameter name="rootNavigationStartLevel" type="integer" update="set">1</parameter> <parameter name="rootNavigationStopLevel" type="integer" update="set">1</parameter> <parameter name="sideNavigationStartLevel" type="integer" update="set">4</parameter> <parameter name="topNavigationNumRows" type="integer" update="set">2</parameter> <parameter name="topNavigationStartLevel" type="integer" update="set">2</parameter> <parameter name="topNavigationStopLevel" type="integer" update="set">3</parameter> </policy-node> </portal> </request>
Extending and updating a theme policy
<?xml version="1.0" encoding="UTF-8"?> <request xsi:noNamespaceSchemaLocation="PortalConfig_7.0.0.xsd" create-oids="true" type="export" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <portal action="locate"> <policy-node action="export" path="/theme" /> </portal> </request>
<?xml version="1.0" encoding="UTF-8"?> <request xsi:noNamespaceSchemaLocation="PortalConfig_7.0.0.xsd" create-oids="true" type="export" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <portal action="locate"> <policy-node action="export" path="/theme/TestThemePolicy" /> </portal> </request>
<request xsi:noNamespaceSchemaLocation="PortalConfig_7.0.0.xsd" create-oids="true" type="update" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <portal action="locate"> <policy-node action="delete" path="/theme/TestThemePolicy"> </policy-node> </portal> </request>
By using the Eclipse Extension Point Framework, themes provide various points where theme functionality can be extended by simply putting a new JAR file in the classpath.
<%-- Declares extension point ID that you want to retrieve attached extensions for --%> <portal-theme-ext:themeExtension id="com.ibm.portal.theme.plugin.SimpleLinks" > <%-- loop over active extensions, if any --%> <portal-theme-ext:themeExtensionLoop> <%-- Use extension properties to add content to the page --%> <a href="<portal-theme-ext:themeExtensionItemUrl />" > <portal-fmt:title varname= '<%=(com.ibm.portal.theme.plugin.ThemeItem)themeExtension%>' /></a> </portal-theme-ext:themeExtensionLoop> </portal-theme-ext:themeExtension>
Refer to the descriptions in Tags used by the portal JSPs for more information about the theme extension tags and their usage options. Refer to the Javadoc information for the Themes public API as the <portal-theme-ext> tags will only work with those interfaces.
The table below describes the extension points included in the Portal theme. The ID field is the extension point identifier used in the plugin.xml. The Default Implementation field describes the interface which provides the information the default extension point requires. Type enforcement is not performed at runtime.
ID | Description | Default Implementation |
com.ibm.portal.theme.plugin.MetaTagDataItems | provides components with a method of adding data to the meta tags of a page | {@link DefaultThemeTextItem} |
com.ibm.portal.theme.plugin.Styles | provides components with a method of contributing CSS styles to the page (either a link or embedded css) | {@link DefaultThemeTextItem} |
com.ibm.portal.theme.plugin.JavascriptItems | provides components with a method of adding javascript to a page (either a link or actual js code) | {@link DefaultThemeTextItem} |
com.ibm.portal.theme.plugin.HorizontalPageBarItems | provides components with a method of adding jsp content to the horizontal page bar | {@link DefaultThemeJspInclude} |
com.ibm.portal.theme.plugin.VerticalPageBarItems | provides components with a method of adding jsp content to the vertical page bar | {@link DefaultThemeJspInclude} |
com.ibm.portal.theme.plugin.PageContextMenuItems | provides components with a method of adding an item to the page context menu | {@link DefaultThemeLinkItem} |
com.ibm.portal.theme.plugin.PortletContextMenuItems | provides components with a method of adding an item to the portlet context menu | {@link DefaultThemeLinkItem} |
com.ibm.portal.theme.plugin.Flyouts | provides components with a method of adding a flyout to the page | {@link DefaultThemeJspInclude} |
For background information on the Active Site Analytics extension point, refer to the Instrumenting a theme for Active Site Analytics and Injecting custom aggregators topics.
A screen is a page of portal content. When the portal page is first loaded, the Home screen is initially shown (Home.jsp). Other screens can also be displayed, such as the Error screen. Selection of screens is determined by links or buttons on the toolbar, which is provided by a theme. The Home screen includes the <portal-core:pageRender/> tag, which renders the pages layout and content.
Portlet content is rendered only within the Home screen. However, you can provide content in other screens that you create. For example, you could create an introductory screen that displays a multimedia greeting to users before they log in to your portal site. The <portal-navigation:url screen="name"/> tag is used to create the link to the JSP in the /screens directory. The name value must be the name of the screen JSP file without the .jsp extension.
In the following example from banner_toolbar.jspf, a URL to the ForgotPassword screen is created for the HREF attribute of the link.
<%-- forgot password button --%> <portal-logic:if loggedIn="no" notScreen="ForgotPassword"> <% if (firstButton) { firstButton = false; } else { %> | <% } %> <a class="wpsToolBarLink" href='<portal-navigation:url screen="ForgotPassword" home="public"/>'> <portal-fmt:text key="link.password" bundle="nls.engine"/> </a> </portal-logic:if>
Skins represent the border rendering around components, such as row containers, column containers, or portlets. The skin is loaded in the portal page by the <portal-core:pageRender/> tag. Skins are installed independently from themes. However, a skin can be associated with a theme.
Skins define more than the look and feel of portlets; they define the look and feel of components. These components include the containers and controls. This hierarchical structure is depicted in the following diagram.
The components of the skin are called in the following order.
Note: Some of the icons in the portlet title bar have an impact on performance.
The IBM, Noskin, ThinSkin, and IFRAME skins are provided by WebSphere Portal for rendering portlets.
Page Builder - Standard and Page Builder - Thin are two new skins that can be assigned to the Page Builder theme. These skins are located in wp_profile_root/installedApps/node_name/Enhanced_Theme.ear/wp.theme.enhancedtheme.war/skins/html
The IFRAME (inline frame) skin that is provided has a more practical purpose than the other skins. It renders portlet content in an HTML IFRAME on the page. IFRAMES are treated as separate browser windows and are used for the inclusion of external objects including other HTML documents.
The IFRAME skin is especially useful for portlets that are slow to render, allowing the rest of the portal page to render without waiting on the content from the portlet within the IFRAME. The width of this skin is set to 100% and height is set to 250 pixels.
To change this setting, use following steps:
<iframe src='<%wpsURL.write(out);%>' SCROLLING="auto" FRAMEBORDER="0" Width="100%" height="250">
To configure all portlets to automatically maximize when the mode is changed, set the portlet.automaximize configuration service parameter to true.
This behavior can be implemented in portlet skins, using the <portal-navigation:urlGeneration/> tag, so that the administrator can control which portlets are automatically maximized. For example, you could create a skin called Highlight and a skin called Highlight_Max, with the only difference between the two is that Highlight_Max is used to automatically change the portlet state when the portlet enters another mode other than View.
To configure specific portlets to automatically maximize, the portlet developer can com.ibm.portal.automaximize initialization parameter to true.
WebSphere Portal provides fully dynamic aggregation of pages from page descriptors that are held in the portal database.
The portal should provide users with a consistent view on portal applications and allow users to define specific sets of applications that are presented in a single context. Depending on the device of the user, the rendering of this application set has to vary to fulfill the requirements of the device. Consider, for example, a set of applications that includes News, Stocks, Weather, and Search, that are to be rendered on a conventional phone using voice interactions, on a WML device with a limited display and keyboard, or on a PC-based browser. The aggregation component must provide the following tasks with each request from the device:
After the active page is determined, the layout of the selected page is used to aggregate the content of the defined applications, arrange the output, and integrate everything into a complete page. WebSphere Portal provides fully dynamic aggregation of pages from page descriptors that are held in the portal database.
Rendering of page components is done using JSPs, images, style sheets, and other resources. These resources are located in the file system in a path-naming convention that the portal server uses to locate the correct resources for the client. You must first understand how the location of these resources supports aggregation before you can customize the visual appearance, layout, or add support for other markup languages or clients.
During aggregation, the portal server searches for themes and skins starting with the most specific subdirectory and moving up to the more general, higher-level directory.
Location in the /themes directory | Location in the /skins directory |
For example, consider a request from a client using Internet Explorer with the locale set to en_US and the user's skins set to Shadow. The aggregation component of the portal server searches for the file Control.jsp in the following order.
1. /skins/html/Shadow/ie/en_US/Control.jsp 2. /skins/html/Shadow/ie/en/Control.jsp 3. /skins/html/Shadow/ie/Control.jsp 4. /skins/html/Shadow/en_US/Control.jsp 5. /skins/html/Shadow/en/Control.jsp 6. /skins/html/Shadow/Control.jsp 7. /skins/html/ie/en_US/Control.jsp 8. /skins/html/ie/en/Control.jsp 9. /skins/html/ie/Control.jsp 10. /skins/html/en_US/Control.jsp 11. /skins/html/en/Control.jsp 12. /skins/html/Control.jsp 13. /skins/Control.jsp
In this example, if the file is not found in the ../ie/en_US directory, the portal server looks for the file in the ../ie/en directory. The portal server keeps moving through this hierarchy until this file is found. If the file is required, it should at least exist in the /skins or /themes directory, with more specific versions of the file placed in the appropriate subdirectory.
After a file is located by aggregation, the information is stored in memory. This search is not repeated for subsequent requests until the portal server is restarted. As a result, if a file is removed from its original location, the file can not be sent to the client on subsequent requests. For example, if aggregation finds and stores the location of /themes/html/ie/en/Styles.css, subsequent requests, from Internet Explorer with the language preferences set to English, are returned without the file rather than returning /themes/html/ie/Styles.css.
Read about the different tasks associated with the Manage Pages portlet.
Both administrators and users with appropriate access can create and delete pages. Users can only delete the pages they create or the pages for which they have at least Manager access.
Understanding the behavior and difference between shared pages derived pages, and hidden helps you manage pages and create the right type of page for your needs.
A page is an organization element that defines how content is displayed. A page can contain portlets and other pages. Shared pages enable you to share a layout model with multiple pages. After a page is shared, other pages can reference the layout of the shared page. Derived pages are children of shared pages and have specific behavior you should be aware of.
Changes made to the original parent page may be reflected to the derived pages that reference it. Layers can be created on other layers to create a chain of cascading pages, referred to as delegated page specialization. This process means that a root page can be created, and the top level administrator can decide the initial layout and content of the page. The next level administrator can then control and modify a specialized layer of this page, adding more content and layout. This process can continue down a chain of page managers and submanagers. Managers or submanagers in the chain only see their individual layer of the chain; however, they must have the User role for every layer above theirs in order to see the content of the previous layers. An end user is only able to see a layer of the page if appropriate access is given. Here are some examples to illustrate this concept.
John, the superadministrator, creates a page named Home and titles it Home. Brandy, a subadministrator, manages the next level of this page, named Home_operations, and determines what additional content should be added to the Home page for employees in the operations group. Nick, the next level administrator, manages the next level of the Home page, Home_operations_transportation, and determines the content that should be available on the Home page for employees in the transportation department. Nick, as the transportation page administrator, must have the Manager role for Home_operations_transportation so that he can make changes to this page that will affect all users, as well as the User role for Home_operations and the User role for Home; he must have the User role on every layer that combines to create the Home_operations_transportation level. Desi, an end user of the Home_operations_transportation page, must have the User role for Home_operations_transportation, and she must also have the User role for Home_operations and the User role for Home. When Desi, the end user logs on to the portal, she sees one Home page. This Home page will be an aggregation of all the layers associated with the root Home page.
Using and altering locks in conjunction with access permissions on the parent pages may result in changes on derived pages depending on the complexity of the derivation structure. The following scenario describes the behavior of derived pages.
An administrator with the editor role creates a page with a two-column layout and places a portlet in each column. The blue arrows in the following figure indicate the child-to-parent relationship of the components of the page:
Two column layout
Then a user with an editor role creates an explicit derivation from this page (under Advanced Options, selects A page that uses content from a shared page) and adds two portlets to the explicitly derived page, one portlet in each column as indicated in the following figure:
Two column four portlet layout
The red boxes around the two new controls indicate that these controls are on a new layer of the page. The original page content and the new layer together comprise the complete page.
The user with an editor role creates a third column next to the two existing columns and moves all portlets to the new column. The new column exists on the layer of the derived page (red box); whereas, the original portlets are moved into the column through additional information (green arrows) as indicated in the following figure:
Three column layout
Rendering the explicitly derived page shows all four portlets arranged vertically as shown in the previous picture.
Next, the administrator locks all containers and portlets on the original page. This has no impact on the aggregated pages (original page and derived page). The administrator then removes the editor right from the user who created the derived page and assigns only privileged user permissions to that user.
If this privileged user navigates to the derived page, the following issues occur:
If the administrator reassigns editor permissions to the user for the derived page, the layout appears differently to the user from any of the stages of the derived page. The layer of additions to the derived page becomes visible again but the information about moving the original portlets has been deleted as indicated in the following figure:
Three column layout with missing information about moving the portlets
The same principle applies to other layer scenarios in similar ways. Movement information of elements from the original page is deleted; whereas, actions on the layer of the derived page; for example adding portlets, rows, or columns; may persist after reassigning permissions as described above.
A page displays content, such as portlets and other pages, in a single area. By creating pages, you can organize your information and add new navigational elements to the site.
You can create a new page under an existing page, reference an existing page, apply a layout, and select supported markups. For public pages, you must have the Administrator, Manager, or Editor role assignment. For private pages, you must have the Administrator or Privileged User role assignment.
When you create a page, you always have the option to create a new page with a new layout. You can create a derived page to a derivation parent page if you have the Editor and Priviledged User role assignment. If you have Editor role on the derived page, you can change anything except markups. If you have Privileged User role on the derived page, you can change the title, skins, layout on derived page. For layout, this is restricted by the derivation parent page. If you reference an existing page, layout, supported markups, locks, skins, portlet list, and locale specific titles are predetermined by the existing page you reference. Any changes to the original page results in the same change to all pages that are referenced.
When creating a new page, you can give it a title. All other settings are optional.
To create a new page, perform the following steps:
A page can be set to reference an existing page only during page creation.
To simplify the creation of pages, define pre-configured pages that can be used as templates when creating new pages.
Page creation and customization is easier than ever before. You can create a page with a single click by using the Page Builder theme. Users can use the portal Page Builder feature to quickly and easily create, customize, and share pages with teammates and community members. They can add content to these pages using a variety of sources made available on the content catalog, such as portal portlets and shared pages. Other custom content sources that you can configure include IBM Mashup Center feeds, widgets, and pages, and IBM Lotus Connections activities, communities, and social bookmarks.
In previous portal versions, the process of customizing a page involved multiple user actions which involved many pages and portlets to perform regular tasks such as adding content, changing the layout and appearance of a page. Page Builder brings these capabilities to the forefront of a user's authoring experience, as it streamlines the process of modifying a page via editing tools found directly on a page instead of through alternative dialogs on disparate pages. To enable these new customization features, the user can go into Edit mode by clicking the
.On pages with Page Builder you can create pages and change the layout of pages. Use the Customize button to add content or change the style and layout of the current page. Select from a predefined list of styles and layouts. Use the Actions button for other options. You can also share pages that you created or customized with other users. To create new pages, click the New Page link in the navigation.
Once you have created portal pages and added portlets, feeds, widgets, and social elements for teamwork, such as activities, communities, social bookmarks, you can change the style of pages by applying a lightweight theme. You can change the layout of pages by using a template or drag and drop components within a page. You can also search users and groups to share pages with and assign user access to view and edit pages. Users with whom a page has been shared can access the page by using the Share menu on the place bar below the page tabs. Users of shared pages can bookmark (Dogear) the friendly URLs of pages. You can manage portal content by managing shared pages and the portlets, feeds, widgets, and social components that they contain.
Before you can create children pages, you need to create a top level page tab. Only the page title and privacy mode of the page can be customized from this dialog.
Once you have created a tab, you can create child pages.
You can move page tabs to other locations.
You can create a new child page under an existing page. Only the page title and privacy mode of the page can be customized from this dialog.
To do this, use the New child page option of the More actions menu in the Tab Menu - Page Builder theme.
You can move child pages to other locations.
To do this, proceed as follows:
Add content to a page by selecting a portlet for portal pages or a widget for mashup pages from the content source that is listed in the content catalog: All sources, IBM Mashup Center, or the portal.
When you create a page in the portal, you can customize page content from several content categories.
For instructions about customizing your portal pages, refer to Adding content.
You can also add your own custom content.
You can also add other content than only adding custom content to a page.
Change the appearance of a page by selecting a style from the list of predefined themes. When you select a theme, it is previewed on the page. You can add custom styles to the list of page themes that are available for selection.
You can select a page layout from a list of predefined formats. Portlets and widgets are automatically positioned into the new layout. You can add custom layouts that you define to the list of page formats available for selection. Use drag-and-drop to adjust the layout of your pages.
You can also add your own custom layouts.
One of the features of the page builder is its drag-and-drop capability.
For details about Dojo and drag-and-drop refer to the documentation link given below.
dojo.addOnLoad(com.ibm.portal.dnd.PORTLET_MEDIATOR.init);The portlet drag-and-drop classes are located with the portal Dojo Resources application. The location of the classes is as follows:
files at that location are used in addition to the core Dojo drag-and-drop
functionality. These files are listed in the following: wp_profile_root/installedApps/[node]/Dojo_Resources.ear/dojo.war/com/ibm/dnd
creator: function(item, hint){ if(hint=="avatar"){ ... Modify this code to create a custom node that is to be used as the avatar. The default avatar is the portlet markup itself. ... }else{ ... When there is no avatar creator function given, a default avatar is created. The default avatar is based on the one defined in dojo.dnd.Source in the functions _normalizedCreator/onDropExternal." ... } }
By default, the portal uses Dojo Version 1.4.3 for its themes. If required, you can use a previous Dojo version.
Learn about hints and tips and known limitations of page builder.
Page Builder does not use drag and drop tags. Page builder uses the Dojo drag and drop framework.
The page customizer contains portlets for editing the layout, content, and appearance of pages. It also provides the Wires portlet, which allows users to set up connections between cooperative portlets on a page, and the Locks portlet, which allows users to lock and unlock containers and container content. You can configure the settings for these portlets to show a certain set of functions, restricting basic users from performing more advanced tasks.
Skins represent the border around a portlet, including its title bar. Users with appropriate access can select skins for individual portlets using the Appearance portlet of the page customizer. To set a skin for portlets, access the Page Customizer and select the Appearance portlet. See the portlet help for further information.
A page is deactivated when you start making changes to it. While editing the page, all changes are effective immediately and cannot be undone or cancelled. Other users will not be able to access the page and icons that launch the edit mode of portlets on the page are deactivated until you commit the changes by clicking Done.
Editing a shared page can have different results, depending on the role assigned to the user editing the page.
The Edit Layout portlet allows you to define the layout and content of a portal page.
This portlet is located in the Page Customizer. Some of the options you can select on the page include:
If the Show layout tools option is not displayed by the Edit Layout portlet, you can display it by clicking the edit icon and checking the option, Show toggle link for "Show layout tools/hide layout tools".
The sample page below has the following layout:
The structure of an example page might look like this:
Portlets are added to the page by submitting a search and then selecting from the list of available portlets. Only portlets available in the portlet list can be placed on the selected page. Once you place a portlet in a row or column, you cannot modify the row or column without removing all portlets from that outlined container.
Objects such as portlets and containers can be rearranged on the page.
Use the appropriate arrows to move portlets and containers to the location you want. If the page manager has locked a column or row container or the content of a container, modifications to the page may be limited. Icons representing tasks that have been restricted are not displayed.
You can create columns and rows and place portlets within these containers and rearrange the containers on the page.
Selecting Show layout tools provides more options for moving objects on the page. For example, you can place a check by multiple portlets and click the move portlets icon to move the selected portlets to a new location.When you create a page, you can choose one of the layout templates displayed above the portlet display area. In most cases, you need only to add portlets to one of those predetermined layouts.
If you need more control over the layout, click Show layout tools to display the advanced layout icons. You can nest spaces and add rows and columns.
Users can click the option Show layout tools only if prior the checkbox Show toggle link for Show layout tools/hide layout tools has been enabled within the Configuration or Edit shared settings mode of the Edit Layout portlet.
You can change the unique name of a portlet on a page while editing the layout of the page from the page customizer. The unique name that you set only affects the portlet instance on the page.
You can change the settings of each portlet listed in the Edit Layout portlet. These options are available from the drop-down menu on each portlet shown in the container.
You can manage personalization rules for a particular portlet from the Edit Layout portlet.
Use the Locks portlet to set permissions for moving containers or content, or for deleting portlets. This allows you to lock content to certain locations on a page. Any element on the page, such as a row container, a column container, or a portlet, can be locked or unlocked for many variations that give a user control of what can be modified. On a page where content and layout should be preserved, both can be locked, preventing other users from altering the arrangement of containers or portlets on the page.
In order to modify the locks for a certain page, a user must have Editor role on that page. If a user has appropriate access rights, the user can determine what other users are able to do with a page.
Be aware of the effect that locks and access permissions can have on pages that inherit content from a shared page. To lock or unlock content on a page:
As an administrator, you are able to restrict the tasks that may be performed with the contents of a container:
Enable or disable users to delete a portlet.
The Portlet Wiring Tool allows you to configure connections, or wires, between cooperative portlets. Cooperative portlets can exchange information, or properties, with each other through the property broker. Properties are exchanged either by prompting the user with a Click-to-Action menu or automatically using preconfigured wires. As a result, portlets on the page can react in an integrated and unified manner to the user's actions.
Setting up a wire between portlets allows the user's transfer selection choices to be saved. The wire may be used to automatically transfer properties to target portlets when specific interactions are performed without displaying the pop-up menu prompting the user for more information. The Portlet Wiring Tool allows you to view the properties that portlets on the page can send or receive. If a match is available between two portlets, you can create a wire between the two portlets. Existing wires may also be deleted using the tool.
The Portlet Wiring Tool also provides the functionality to implement cross-page portlet communication. Cross-page wires allow portlets to exchange properties across pages. Before creating a cross-page wire, the target page must have receiving actions defined as global on its portlets. Setting an action as global will also make that action available to Click-to-Action menus. To set an action as global, navigate to the target page and select Edit Page Layout from the drop-down menu on the title bar. Then select the Wires tab and click on Manage Actions. This will bring up a listing of the portlets on a page and their corresponding receiving actions.
As an alternative to the Portlet Wiring Tool, wires can also be created interactively in the portlet. Depending on the browser, users with sufficient permissions can create wires by holding either the CTRL or ALT keys and clicking an icon or hotspot in the portlet that is already associated with a Click-to-Action function. A dialog is displayed that allows the user to create a wire to other portlets on the page.
The wiring tool allows wires to be created in situations which are not handled by the interactive approach. For example, the tool does not require the existence of Click-to-Action menus to initiate wire creation, and can be used to create multiple wires from a single source property (using the interactive approach, a single source can be wired to a single target or all targets, not an arbitrary subset). Wire creation or deletion is subject to the access control checks as described below.
In order to view the tool itself, users must possess at least "User" role permissions on the page and the portlet. Further access checks are performed before allowing the user to view, create, or delete wires between portlets. The user must possess at least "User" role permissions on a page and the wired portlets on it to be able to view wires for the page. Users may also be able to create or delete personal wires, which affect their view of the page, or create or delete public wires, which affect all users' view of the page. Users must possess at least "Privileged User" role permissions on the page and "User" permissions on the portlets to be able to create or delete personal wires, while at least "Editor" role permissions are required on the page and "User" permissions on the portlets to be able to create or delete public wires.
A theme determines the global appearance of a page. The purpose of this is to ensure visual consistency. Themes affect the navigational structure, the banner, the colors and fonts, the available portlet skins, and other visual elements of a page. A skin determines the frame that is displayed around a portlet.
Use the Themes and Skins portlet to do the following:
You find this portlet under
. Refer to the respective portlet helps for additional instructions.Select a theme that is used to across the entire portal.
Select a skin that is used as the default for all portlets across the portal.
The Portlet Palette provides you with a collection of portlets that you can drag to the page for quick and easy page customization.
You can organize and group the portlets available to you for deployment from your collection through the use of categories. Categories provide you with a way to organize your portlets using your own classification scheme. You can create new categories for grouping and organizing portlets in your collection, and you can rename categories as appropriate. You can customize the Portlet Palette further by rearranging categories, adding portlets to categories, and by moving portlets from one category to another. You can also search by title for portlets of interest. You can apply these customizations to your individual instance of the Portlet Palette or change the settings to affect all or selected instances of the Portlet Palette as needed.
The Portlet Palette provides you with a quick and easy way to deploy portlets to the page. You can drag a single portlet or multiple portlets within the same category to the page. Categories provide you with a way to organize portlets in the Portlet Palette. It is recommended that you only add portlets to the page using the drag-and-drop feature from the Portlet Palette.
To add a portlet to a page, perform the following steps:
A mouse is required to use the drag-and-drop feature of your portal. Alternatively, you can use your keyboard to add portlets to a page as an accessible alternative to dragging portlets from the Portlet Palette to the page.
Perform the following steps as an alternative to using the drag-and drop feature for adding a portlet to a page:
You can change the placement of individual portlets on a page using the drag-and-drop feature of your portal. The drag-and-drop feature is present for all themes and for row and column containers that are not locked. You should be logged into the portal site using an ID with sufficient access rights to modify a page.
A mouse is required to use the drag-and-drop feature of your portal. Alternatively, you can use your keyboard to rearrange portlets on a page as an accessible alternative to dragging portlets to a new destination on the page.
You can define widths for containers. You can use this feature to restrict the possibility for users to move portlets on a page. The portal provides this functionality by a portlet placement filter or width filter. This width filter compares width of a portlet to the width of a column container. If the width of the portlet is larger than that of the container, the portlet cannot be moved to this container.
Categories provide you with a way to organize your portlets using your own classification scheme. You can create new categories for grouping and organizing portlets in your collection.
You can search for a portlet in the Portlet Palette by entering part or all of the portlet title in the Search field. The search is not case-sensitive, and only portlets where you have the correct permissions are displayed in your search results.
Perform the following steps:
The number of search results is limited by a configuration parameter which can be changed by the administrator. The default value limits the search results to 100.
To change the number of search results displayed in the Portlet Palette to a value other than 100, perform the following instructions:
You can rearrange a category by dragging the category to a new destination in the Portlet Palette.
Perform the following steps:
You can drag a copy of a portlet from one category to another category to customize the Portlet Palette. A portlet is not removed from the original category when you move this portlet to another category. When you drag a portlet to another category, you can only move this portlet to one category at a time. You can also add a copy of a portlet to multiple categories at one time by accessing the drop-down menu by the portlet name in the category.
Perform the following steps to move a portlet to another category:
You can add a copy of a portlet in a category to multiple categories at one time if you have the proper access level. If you only need to add a copy of a portlet to a single category, you can simply drag a copy of the portlet to the appropriate category. A portlet is not removed from the original category when you add a copy of this portlet to multiple categories.
Perform the following steps:
Default categories are provided to you in the Portlet Palette. Depending on your access level, you can customize your Portlet Palette by renaming these categories and categories you later create to provide the best organizational scheme for portlets in your Portlet Palette.
Perform the following steps:
When you rename a category in the Portlet Palette, you have the option to edit the category names for other languages.
Perform the following steps:
You can return the Portlet Palette to the default settings currently maintained by your administrator. Resetting the Portlet Palette to use the current administrator settings removes any customizations you have made.
Perform the following steps:
You can delete a category in the Portlet Palette as needed if you have the proper access level.
Perform the following steps:
You can delete a portlet from a category in the Portlet Palette as needed.
To delete a portlet from a category, perform the following steps:
You can change the settings to affect all instances of the Portlet Palette on every page or selected instances of the Portlet Palette by selecting a different portlet mode. When you initially open the Portlet Palette, you are either in the View or Personalize mode depending on your access level.
These instructions assume that you are leaving the View or Personalize mode to modify the settings for other users by using the Edit Shared Settings or Configure mode as appropriate. Depending on your access level, you may not see all of these options.
You cannot drag portlets to the page while in Edit Shared Settings and Configure modes.
Perform the following steps to change the settings of the Portlet Palette:
Access control for customizing and working with the Portlet Palette is based on portlet roles, portlet modes, and page permissions. By default, users are assigned to the All Authenticated Portal Users role which only provides read access to the Portlet Palette. Users will only see portlets on the Portlet Palette that they have user access to view.
Portlet and Page Roles | Description of Permissions |
User@portlet, User@Portlet Palette page | Read-only access to the Portlet Palette. Users can drag portlets from the Portlet Palette to the page but cannot modify or customize the Portlet Palette. |
Privileged User@portlet, Privileged User@Portlet Palette page | All of the privileges of the User role,
plus the ability to customize your private view of the Portlet Palette
while in the Personalize mode. You can perform the following tasks:
Note: You cannot delete portlets or categories that are created
in the Edit Shared Settings and Configure modes.
Editor@portlet, Editor@Portlet Palette page | All of the privileges of the User role,
plus the ability to customize the Portlet Palette while in the Edit
Shared Settings mode. These changes will display to all users who
have access to this specific page. You can perform the following
tasks while in the Edit Shared Settings mode:
Manager@portlet, Manager@Portlet Palette page | All the privileges of the Editor role plus
the ability to modify all instances across all pages of the Portlet
Palette while in the Configure mode. You can perform the following
tasks while in the Configure mode:
Administrator@portlet, Administrator@Portlet Palette page | All the privileges of the Privileged User
and Manager roles. The Administrator role can perform tasks within
the Personalize, Edit Shared Settings, and Configure modes. Note: You
cannot drag portlets to the page while in the Edit Shared Settings
or Configure modes.
Use wires to exchange information or actions between portlets.
Wires allow portlets to interact with each other. For example, portlets can exchange information, or an action in one portlet can update another portlet.
A wire allows two or more portlets to transfer information so that an action, publishing event, or click in a source portlet automatically triggers an action or event and updates the display in the target portlet. As a result, multiple portlets can be updated simultaneously when information is changed. You can create wires only between cooperative portlets and portlets that define events, that is portlets that have been developed to share information with other portlets. When you first open the Wires portlet, all public wires and your personal wires for the page are displayed.
Select the matching mode to determine under which circumstances a wire can be created between portlets.
Learn how to add a wire.
Learn how to delete a wire.
To delete a wire, proceed as follows:
Learn how to define global targets.
Cross-page wires allow portlets to exchange properties across pages. Before you create a cross-page wire, you must define communication targets for the target page as global on its portlets. Defining a target as global will also make that target available to Click-to-Action menus. To set global targets on the target page, proceed by the following steps:
WebSphere Portal 7 provides improved page builder and improved client side rendering and has a new default portal theme, the Page Builder theme. Themes define how your portal site will look. After installation, a default theme is deployed and you can either customize that theme or create your own. The new themes approach introduced in 7 involves less editing of JSPs and allows you to mix iWidgets and portlets on the same portal page and take advantage of both client side and server side rendering mode. WebSphere Portal 7 continues to support other themes, including your custom themes. If you have an existing portal site you can continue to use your existing themes or you can migrate your themes to the new standard.
IBM WebSphere Portal Version 7.0 introduces a page and theme architecture that allows you to mix iWidgets and portlets on the same portal page and take advantage of both client side and server side rendering mode. This can simplify creating and editing themes for you.
The Page Builder theme facilitates the rapid creation, customization, and sharing of portal pages. Page Builder supports a page and theme architecture that allows you to mix iWidgets and portlets on the same portal page and take advantage of both client side and server side rendering mode. This can simplify creating and editing themes. You can work with and customize themes, theme resources, theme templates, skin templates, widgets, and portlets.
Portal themes need to fulfill a set of requirements.
Themes contains various elements that you can work with, including JSPs, theme HTML, layout templates, and skins.
All themes in Portal begin with a Default.jsp, which is deployed in the system theme WAR file.
You can use static HTML to write portal themes.
The static theme template is named theme.html . It is located in the root directory of the theme folder in the WebDAV filestore. The theme.html includes the full HTML structure of the page including <html> , <head> , and <body> sections. It can include both static and dynamic content.
Dynamic content changes per user, or per page, or per some other server state. Therefore you cannot define it statically in the file theme. Instead, you insert it into the response at runtime. To do this, you edit the theme.html and identify these dynamic content spots. Then at runtime a server side theme parser identifies and resolves dynamic content spots, and streams their output into the final response to the browser.
<a rel="dynamic-content" href="{path to dynamiccontent}"></a>
<a rel="dynamic-content" href="lm:template"></a>
<a rel="dynamic-content" href="dyn-cs:/tabNav"></a>
<a rel="dynamic-content" href="res:/PageBuilder2/themes/html/PageBuilder2.0/tabNav.jsp"></a>
Layout templates control the layout and positioning of the content of the current page. The author of the layout template defines the HTML fragment markup and CSS for laying out the container and component layout of the page, using the static HTML page container and component microformat to specify containers and portlets to include in the page.
<div class="hiddenWidgetsDiv"> <div class="component-container hiddenWidgetsContainer ibmDndRow" name="ibmHiddenWidgets"></div> <div style="clear:both"></div> </div> <div class="component-container ibm2Col ibmDndColumn" name="ibmMainContainer"></div> <div class="component-container ibm2Col ibmRightCol ibmDndColumn" name="right"></div>The example above defines a two-column layout, with a hidden container for widgets which participate in the wiring of the page, but are not visible themselves. The meaning of the elements is as follows:
You can add portlets and iWidgets directly to the layout template definition by using the portlet microformat for static pages, or the iWidget definition specification. You can add portlets or iWidgets inside or outside of containers. The template is applied to the page as a copy. Therefore every page that uses the template has a new instance of the portlet or iWidget.
The static skin template is named skin.html . It is located in the root directory of the skin folder of the WebDAV filestore. The skin.html provides the full markup for decoration around a portlet or iWidget. Just as with theme templates, you can use dynamic content spots to add dynamic elements to the skin template at runtime.
skinNode.setDynamicContent(skinConstants.DYNAMIC_CONTENT_ICON, "http://www.mysite.com/icon.gif")
<span class="lotusLeft"> <img class="lm-dynamic-icon" src=""/> <span class="lm-dynamic-title asa.portlet.title decoration-title"><a rel="dynamic-content" href="lm:title"></a></span> </span>Where:
skinNode.setDynamicContent(skinConstants.DYNAMIC_CONTENT_TITLE, "My new title")
This topic lists the location of theme resources. Theme resources consist of dynamic J2EE resources, such as JSPs, and static resources, such as static HTML, CSS, Javascript, and image files.
/theme/theme_name/nlsExample: /themes/html/PageBuilder/en/. For more information refer to the topic about Aggregation under the section about the Search order for portal resources.
You can edit portal pages with the Page Builder theme by assigning theme templates to pages.
com.ibm.portal.theme.template.file.name.html=[name_of_file]where name_of_file can be, for example customized-theme.html . This allows you to implement different templates for customize how different parts of your site can look, without implementing an entirely different theme. Before you use multiple templates, consider the additional maintenance required, as changes to elements that are shared between multiple templates must be made to each template.
iWidgets are modeled in the portal as portlets. Therefore iWidgets registered in the portal can be added and rendered wherever portlets can be added to a page.
To add iWidgets to a page, users use either the Edit Layout administration portlet or the Page Builder customization shelf in the theme. The portal user interface makes no distinction between a portlet and a widget. If you require such a distinction, you can achieve it by assigning tags to the portlets and iWidgets when you deploy them. In the Page Builder theme Customize shelf portlets are categorized by tags.
For wiring widgets together, the Page Builder theme includes the wiring widget that the IBM Mashup Center and mashup integration use.
This widget has been extended to accommodate the additional wiring options. These include wire matching by qname and the payload matching supported by iWidgets.
The wiring interface works in the same way, regardless of whether the source or target component is a widget or portlet.
To wire two components together, proceed as follows:
The Page Builder theme supports two rendering modes. These are referred to as client-side and server-side aggregation modes.
To render the portal theme, the same theme elements are used in both rendering modes. In general, you can write navigation iWidgets to fire a SWITCH_PAGE event. The internal JavaScript NavigationController of the theme determines the current rendering mode of the page and processes the event appropriately.
http://my_server:portal_port/wps/mycontenthandler/dav/contentmodel/wps.content.root/metadata.propertiesMake sure the following two lines have been added:
com.ibm.portal.rendertype=iwidget com.ibm.portal.rendertype.version=2.0
You can use WebDAV for WebSphere Portal to administer portal themes and skins by using the WebDAV standard operating system tools. This way you can browse, read, and write themes and skins by using file explorers or editors.
You can work with folders as usual, for example by performing drag-and-drop operations with theme or skin resources. The folders also contain property files that represent metadata, such as the title and description of the theme or skin. You can edit the property files to update theme and skin metadata. When you save the updated file, the updates are transferred and applied to the portal model directly. The provided folder and file structure is only simulated and is not a real file system structure.
http://server:port/wps/mycontenthandler/dav/themelist/If you want a specific theme rather than the full list of themes, you can add the friendly name, unique name, or object ID of the theme to the URL above.
http://server:port/wps/mycontenthandler/dav/skinlist/If you want a specific skin rather than the full list of skins, you can add the friendly name, unique name, or object ID of the skin to the URL above.
You can activate client side rendering for portal pages. Client side rendering mode is only active if the theme that renders the page supports client side rendering mode, for example, the Page Builder theme. If the theme does not support client side rendering, server side rendering is used as the fallback.
com.ibm.portal.rendertype=iwidget com.ibm.portal.rendertype.version=2.0To set server side rendering mode, use the following metadata:
With WebSphere Portal Version 7.0 and the Page Builder theme you can use pages from your previous portal versions.
The page builder theme architecture allows the portal to render both iWidgets and portlets alongside on the same portal pages.
For easy handling of iWidgets WebSphere Portal provides a dedicated IWidget Wrapper portlet. This portlet maps the iWidget concept into the portal administration model.
The portal unique name of this portlet is wp.p.IWidgetWrapper .
The portal maps all preferences exposed by individual iWidgets, that is elements of the iWidget attributes item set, directly to corresponding portlet preferences. Consequently you can configure the values for those preferences by using the corresponding portal administration interfaces. For example, if an iWidget defines an attribute named zipcode, the corresponding IWidget Wrapper portlet clone defines a portlet preference named zipcode. You can modify this value, for example, by using the Manage Portlets portlet. You can also create additional clones of such IWidget Wrapper portlet clones for supporting multiple pre-configuration variants of the same iWidget definition. Users can overwrite these preferences in the Edit Shared Settings and Personalize modes in the same way as portlet preferences.
The iWidget specification includes an attribute named sandbox. You can use it to determine whether you want the corresponding iWidget definition to be rendered in an iWidget sandbox. For details about the iWidget sandbox refer to the iWidget specification. The portal maps this iWidget sandbox attribute to a portlet preference named com.ibm.portal.iw:iwidget:sandbox. You can modify this preference by using the same approach as mentioned in the previous section to control whether the corresponding iWidget definition is rendered in an iWidget sandbox.
To make your portal aware of available iWidgets, you register the iWidget definitions in your portal by telling the portal the location from where it can load the iWidget definition XML.
<div class="iw-iWidget" id="sampleID" style="skin:csa2.standard"> <a class="iw-definition" href="dav:fs-type1/iwidgets/sampleWidget/SampleWidget.xml"></a> </div>In this case the static page deployment process makes sure that the iWidget defined by the SampleWidget.xml file contained in the location /iwidgets/sampleWidget of the WebDAV file store is registered in your portal after the page is created.
The process of registering a new iWidget definition in the portal includes duplicating the IWidget Wrapper portlet. Therefore it requires the same access right privileges as duplicating the IWidget Wrapper portlet.
When you register an iWidget in your portal, a copy or clone of the IWidgetWrapper portlet is created to map the iWidget model to the portal model. The new portlet carries the title and the description as defined in the iWidget definition: this way you can locate and manage it as other portlets in your portal.
While this mechanism allows for the most common use cases, you can also reuse and customize registered iWidgets.
When you register an iWidget in your portal, most sections of the iWidget definition and microformat are stored in the portal model as portlet preferences of a copy or clone of the IWidgetWrapper portlet.
Each iWidget definition corresponds to a distinct copy of that portlet. The portlet preferences carry a prefix com.ibm.portal . This identifies them as parameters that are used internally. Values of iWidget attributes, that is items of the attributes item set of an iWidget are stored without prefix. Instead, the item identifier is used as a key to the item value. This way you can easily distinguish iWidget attributes from other preferences when you want to customize their values after registering an iWidget in your portal. This is useful to preconfigure an iWidget definition that is integrated on different portal pages by using the corresponding iWidget microformats.
Another important aspect of iWidget attributes and their corresponding portlet preferences in the portal model is that the update behavior can be specified, which allows for use cases when you want to retain customization across updates of an iWidget definition.
In general, when you refresh an iWidget definition, the previous iWidget definition data stored in the portal model of the portal are replaced. The exception to this rule are iWidget attributes, that is items of the attributes item set, which are defined in the iWidget definition.
Previous iWidget attribute: id="someAttribute" |
New iWidget attribute: id="someNewAttribute" |
Update result |
value: previousValue readOnly: true or false |
value: newValue readOnly: true |
value: newValue readOnly: true |
value: previousValue readOnly: true or false |
value: newValue readOnly: false |
value: previousValue readOnly: false |
value: previousValue readOnly: true or false |
value: newValue readOnly: n/a |
value: previousValue readOnly: false |
value: previousValue readOnly: true or false |
value: n/a readOnly: true |
value: n/a readOnly: n/a |
value: previousValue readOnly: true or false |
value: n/a readOnly: false |
value: previousValue readOnly: false |
value: previousValue readOnly: true or false |
value: n/a readOnly: n/a |
value: previousValue readOnly: false |
value: n/a readOnly: n/a |
value: newValue readOnly: true |
value: newValue readOnly: true |
value: n/a readOnly: n/a |
value: newValue readOnly: false |
value: newValue readOnly: false |
value: n/a readOnly: n/a |
value: newValu readOnly: n/a |
value: newValue readOnly: false |
You can create custom themes that contain the styles and branding for your portal site.
You can develop custom themes that suit your specific needs by adding static or dynamic content to themes. For example, you can add images, iWidget definitions, JavaServer Pages (JSP), and so on to your custom themes.
The best way to start creating your own custom theme is by copying the portal Page Builder theme. This ensures that your theme has all the required elements for the theme to function.
You can customize your theme in several ways as described in the following.
You can use some resources in multiple themes, such as JavaScript libraries and common CSS style sheets. You can store these resources in the WebDAV folder /wps/mycontenthandler/dav/fs-type1/common-resources/ .
You can reference these resources as if they were relative to your theme folder. If the resource is not found in your theme folder, the portal uses the folder /common-resources/ as a fallback location. This also allows a theme to override a file from the folder /common-resources/ by providing its own file of the same path.
<a rel="dynamic-content" href="res:/[''context root of theme WAR'']/themes/html/[''theme folder name'']/tabNav.jsp"></a>This works by using a dynamic content spot. The theme parser recognizes the snippet rel="dynamic-content" and resolves the value of the href attribute through the resource addressability framework. This invokes the JSP and streams its output into the corresponding position in the file theme.html at runtime.
You can add dynamic content to your custom theme by using either client-side or server-side logic.
<a rel="dynamic-content" href="dyn-cs:/tabNav"></a>
<a rel="dynamic-content" href="res:/PageBuilder2/themes/html/PageBuilder2.0/tabNav.jsp"></a>
<div class="iw-iWidget id="myWidget"> <a class="iw-Definition" href="/path-to-widget-definition.xml"></a> <span class="iw-ItemSet" style="display:none" title="attributes"> <a class="iw-Item" href="#key">value</a> ... </span> </div>
Name of the content spot | Value |
head | res:/PageBuilder2/themes/html/PageBuilder2.0/head.jsp |
bannerNav | res:/PageBuilder2/themes/html/PageBuilder2.0/bannerNav.jsp |
searchAndEdit | res:/PageBuilder2/themes/html/PageBuilder2.0/searchAndEdit.jsp |
tabNav | res:/PageBuilder2/themes/html/PageBuilder2.0/tabNav.jsp |
pageToolbar | res:/PageBuilder2/themes/html/PageBuilder2.0/pageToolbar.jsp |
layout | lm:template |
You can add new layout templates so that they can be assigned to portal pages.
Layout templates are stored in the WebDAV filestore at the location /fs-type1/layout-templates. To add a new layout template so that it can be assigned to Portal pages, create a new folder or copy and rename an existing layout template folder inside the root folder.
For details about the syntax and elements of layout templates refer to the topic about Theme layout templates.
When you promote code from staging to production, you need to make sure to move all theme artifacts.
The new Page Builder theme architecture of WebSphere Portal Version 7.0 is designed to be a single architecture to replace past traditional portal themes and Mashup themes.
You can migrate your JSP-based theme to the new theme architecture by using different ways.
Mashup themes are already a static theme.html file that contains client-side iWidgets to handle the interaction model. Therefore the conversion effort is small.
Some hints and tips for working with the Page Builder theme and widgets.
You use IBM Lotus Web Content Management to create, manage and deliver web content within your WebSphere Portal system. Set up your web content system by defining libraries, building templates, and specifying other key components of the system. Once the system is in place, you can begin adding elements to your templates and use them to create content items.
Before setting up your web content system, you should read the entire WebSphere Portal Planning and Installing sections to determine the best overall configuration for your WebSphere Portal system.
You should also review the WebSphere Portal Family Wiki. This site covers a wide variety of topics that product experts have found critical to a successful implementation.
As an administrator you need to periodically assist content managers with library maintenance, such as disabling or deleting a library. Keep in mind that some library tasks can reduce the performance of your server while running. Therefore library maintenance should only occur during off-peak periods when the least number of users are accessing a library.
You create web content libraries in the WebSphere Portal administration portlet.
Ensure that your library is named correctly when first created as renaming a library after you have started to create web content can lead to errors. For example, menus and navigators may not correctly display results after a library has been renamed until all caches have been cleared.
When a web content library is no longer required, you can delete the library.
To delete a library:
When a web content library is no longer required, you can disable the library. This prevents the library from being accessed from an authoring portlet, preventing users from updating any items stored in the library. Any items referenced from this library are still rendered in web content.
A library can become locked when a long running task, such as restoring all content items in a library, fails to unlock the library. In the rare event where a library becomes locked, you can use the unlock library tool to unlock the library.
You can define the access of a user or group for a library to determine who has access to a library, and to define access to the different views within the authoring portlet.
You can assign roles to both a whole library, and the item types within a library using either an additive or subtractive methodology.
For example, with an additive methodology, you apply the "All Authenticated Portal Users" to the "Contributor" role to the entire library. This grants "All Authenticated Portal Users" access to the library and any authoring portlets configured to use the library. You then apply Editor, Manager, or Administrator roles to specific resource types to grant additional access to specified users or groups.
With a subtractive methodology, you apply the Manager or Administrator role to a user or group to the entire library. You then apply Editor, Contributor, or User roles to specific item types and clear the inheritance check box. This reduces the access to different item types for specified users or groups.
We recommend that propagation from the web content library is enabled because this simplifies administering library access and because disabling propagation results in access-related errors.
Assigning access permissions to a library and library item types:
By default, each role's access is automatically inherited down to each item in a library. To prevent a user or group from automatically having inherited access to an item, you need to turn off inheritance on that item.
The permissions set for item types in a library do not automatically give you access to individual items. They only give you access to specific tasks and views within the authoring portlet.
You need to restart WebSphere Portal to enable any configuration changes.
You can restore a set of items within a library that either have the same label or were versioned at, or before, a specified date and time.
You can apply a label to the most recent versions of all items in a library. This action does not create a version, it simply updates the label of the most recent version. If you have created a label, at a later time you can restore items in the library based on that label.
You must be an Administrator to work with web content libraries.
By default, only administrators have access to work with Web content libraries. To allow other users to work with web content libraries, such as virtual portal administrators, you need to assign them access to the JCR content root node.
The primary role of a web content authoring system is to allow your content creators to author content in the form of content items. There are various features you can use to customize the Web Content Management user interface to simplify the content authoring process for your content creators.
You do not have to use the default Web Content Management page to create content. You can create a new portal page to act as the home page of your authoring system.
You can also create pages specifically for different types of users. For example, you can create a separate page for your site designers and content creators. The authoring portlets you add to each page can be configured specifically for each user type.
In this example you have two users groups; site designers and content creators. The website is split between a design library and a content library.
Site designers page | Content creators page | Header |
The roles you assign each library on your authoring system will determine what views and features in an authoring portlet are accessible to your users.
You can edit the shared settings of each authoring portlet on your authoring system to customize each authoring portlet for the people who use them.
An authoring portlet is used to create and manage web content. You can edit the settings of an authoring portlet from within the Preferences section of the authoring portlet.
Use the Configure mode to specify settings for all users of all instances of the authoring portlet, regardless of the page on which the portlet instance appears.
Use the Shared Settings mode to specify settings for the current instance of an authoring portlet.
You select which libraries are available to users when using this authoring portlet in the Library Selection section.
Libraries selected using the "configure" view are available on all instances of the authoring portlet, regardless of the page on which the portlet appears. Libraries selected with the "edit shared settings" view are only available for the current instance of an authoring portlet.
The libraries available in the "insert links" and "insert images" dialogues are based on the libraries selected in the "configure" view. If you select a library in the "edit shared settings" view that is not selected in the "configure" view, you are not able to select items from this library when using the "insert links" and "insert images" dialogues.
If you syndicate or import a library, it is not automatically added to the list of configured libraries for an authoring portlet on the target server. You need to add the syndicated or imported library to each authoring portlet on each server.
The preview options determine how content can be previewed. Preview options are defined within the Previewing Options section.
You use the User Interface Options section to define the user interface options of an authoring portlet.
You can configure IBM Lotus Web Content Management to use either the standard rich text editor, an advanced rich text editor, or a third-party rich text editor in rich text fields.
There are three options available when configuring the default rich text editor for your authoring portlet:
Selecting Custom allows you to use a third-party rich text editor as your default editor. Before using a compatible third-party rich text editor, you should read the installation and configuration instructions of the third-party rich text editor. These should include instructions for enabling the third-party rich text editor to be used in a Web Content Management solution.
When configuring a third-party rich text editor, you need to copy a JSP file supplied by the third-party rich text editor. This file is used to launch the third-party rich text editor. You enter the name of this JSP file in the Rich Text Options section of the authoring portlet configuration.
If the third-party rich text editor is not available the standard rich text editor is used.
JSP files can be located:
The JSP page is also stored in the client war directory of the local rendering portlet or of the servlet or portlet that calls the JSP, if using the Web Content Management API. For example, to render a JSP page on a local rendering portlet, you would also need to store a copy of the JSP file under was_profile_root/installedApps/node-name/PA_WCMLocalRendering.ear/ilwwcm-localrende.war
For example: /wps/customapplication;/jsp/editor.jsp
An authoring template determines the design of a content form, defines what fields and elements appear on a content form and specifies default values for fields and elements.
The fundamental purpose of the authoring template is to provide a way for the template author to select the elements that appear on the content form. When constructing the authoring template, you can select more than one element field of the same element type. For example, you might add three text element fields, two rich text element fields, and four image element fields to the same authoring template.
When you create an authoring template, you can specify default values to be used when creating new content based on the template. Well selected default values can make it easier and more efficient for a content author to create new content and can streamline the content creation process.
The authoring template provides features that help you simplify the presentation of the content form and screen the content author from unnecessary complexity.
When referencing content components in a presentation template:
You should also be aware that an authoring template could be used by different presentation templates in different site areas.
The names of element labels in different content items must be the same if an element reference in a presentation template is to change depending on the current content. This is an important consideration if two authoring templates will be using the same presentation template. The element types however, do not have to be consistent.
Site area | Element label | Element type |
Business | Heading | Image |
Personal | Heading | Rich Text |
Features | Heading | Text |
News | Heading | Text |
You can use the Web Content Management API and remote action parameters to create customized authoring interfaces specifically for your content creators.
You may not want to use an authoring portlet as the user interface for all your users. In some cases it may be better to create a custom authoring interface using the the Web Content Management API and remote action parameters. For example, you could create a very simple content authoring interface for a specific content authoring team.
You can configure an authoring portlet to use a launch page of your own design instead of the default user interface. A custom launch page can either be a JSP or HTML file. You use remote actions to call different views and functions from with the authoring portlet's user interface. You can also use the web content API to add other functions to your launch page. Once you have created a custom launch page, you then configure your authoring portlet to use the custom launch page instead of the default authoring portlet user interface.
Remote actions are used in the query string of a URL to trigger actions from the Web Content Management application. You can use remote actions to add standard Web Content Management functions to a custom user interface.
An inline editing system is used to deliver editable web sites such as an intranet or a wiki. It combines the features of both an authoring system and a delivery system.
The authoring tool element is used to add authoring portlet functions to web pages.
Authoring tools can be referenced within presentation templates, menu element designs and navigator element designs. When added to menus and navigators, the edit, delete and approve functions are applied to each item displayed in a menu or navigator.
You can only use an authoring tool element by creating an authoring tool component. You cannot add an authoring tool element to authoring templates, site areas or content items.
The authoring tool will also be visible when viewing a published site.
When using an authoring tool on more than one server, you use two-way syndication to keep each server being used to author content synchronized. This may lead to the occasional "save" conflict where an item updated on one server will be overwritten with changes to the same item on another server when syndication occurs.
When rendering authoring tool components in the JSR 286 Web content viewer, you must account for some changes in the way placeholder tags are specified and in the way users navigate to pages containing authoring tool components. Authoring tasks accessed through a JSR 286 web content viewer, such as inline editing, require the use of an instance of the IBM Lotus Web Content Management authoring portlet that is reserved specifically for such tasks.
Authoring tools components rendered in a JSR 286 web content viewer enable you to create, read, edit, delete, approve, or reject content items directly in the web content viewer, instead of requiring you to navigate to the IBM Lotus Web Content Management authoring portlet to perform the same action. While the traditional web content viewer launches authoring actions in its portlet window, the JSR 286 Web content viewer either launches a pop-up window that opens from the current page or redirects the user to another portal page that contains the authoring portlet.
When using a pop-up window to perform an authoring task, the pop-up window opens above the portal page and can be moved within the boundaries of the browser window while still showing the portal page underneath. After you complete the task triggered by the authoring tools element, the pop-up window closes automatically, and the portal page refreshes, updating the view in the JSR 286 web content viewer. You can cancel the authoring task by clicking the close icon in the pop-up window's title bar. When cancelling the task, no Web content information is saved, unless you explicitly save changes before manually closing the window.
<Placeholder tag="namelink"/> <Placeholder tag="namelink" format="tag"/> <a href="<Placeholder tag="href"/>"> <Placeholder tag="name"/> </a> <a href="<Placeholder tag="href" format="tag"/>"> <Placeholder tag="name"/> </a>
Instead of performing tasks from authoring tools elements in a pop-up window above the current page, you can perform authoring tasks by navigating to a hidden portal page that contains a JSR 286 web content viewer containing the reserved authoring portlet. Clicking a link for an authoring tools element automatically redirects you to the other page, but after you complete the authoring task, you must manually navigate back to the original page. If the page with the reserved authoring portlet was opened in a new browser window or tab, you must close the window or tab and manually refresh the original page to see any changes.
<Placeholder tag="namelink" format="url"/> <a href="<Placeholder tag="href" format="url"/>"> <Placeholder tag="name"/> </a> <a href="<Placeholder tag="href" format="url"/>" target="_blank"> <Placeholder tag="name"/> </a>
You use the web content authoring portlet to create and manage web content items including site areas, content items, authoring templates, presentation templates, components, categories, folders, projects, and workflow items.
The authoring portlet is used to create and manage the items you use to create websites. There are a common set of features within the authoring portlet to assist you work with items.
To access the authoring portlet, open the main menu and go to Applications > Content > Web Content Management .
The first time you use a Web Content Management system you will, at some point, be asked to authorize a Java Applet. Click Grant Always and this dialog will no longer display.
You use different views within the authoring portlet to perform different tasks.
Any views or items that are currently open are listed in the Open Views or Open Items navigator.
By default, expired items are displayed alongside published and draft items.
Large websites contain large numbers of items. You can filter the items displayed within an index by using the filter feature.
You can select any open item or view as a favorite. These are then accessible within the Personal Views menu.
Large websites contain large numbers of items. You can search for items by using the search feature.
Search indexes are updated periodically. This means newly created or updated items are not found in the search results until the search index has updated.
As you work in collaboration with other users, you will encounter items that are locked by other users, either because they are being edited by another user, or a draft item has been created.
When a user is editing an item, the item is locked to other users. This means other users cannot edit the item until the current user closes the item being edited. A lock symbol is displayed against items that are currently locked.
Users with administrator access to an item can lock an item by selecting an item and then clicking the Lock button. This prevents any user from editing an item.
Users with administrator access can also unlock items currently being edited by a user by selecting an item and then clicking the Unlock button.
Users with manager access can also lock and unlock items so long as they have manager access to both the item and the library it is stored in.
Locking of site areas, taxonomies, and categories are configurable and is not enabled by default.
When locking is enabled for site areas you cannot create any children under the locked site area. For example, if a site area is locked, you cannot create any site areas or content items under that site area until it is unlocked. This only applies to items located one level below a locked parent. Items located under a child of a locked parent are not affected.
When a new draft of a published item is created, a tick is displayed against the published item. This means that no other user can create a draft until the current draft progresses through a workflow and its state changes to published.
You cannot always immediately delete items. Sometimes you need to perform steps to prepare an item for deletion.
You can view a list of deleted items in either the My Items>Deleted or All Items>deleted views.
You can restore a deleted item by restoring a version of an item. See Managing Versions of items for further information.
Users who have been granted manager access or above to a library can purge deleted items by selecting deleted items in the "All Items" view and then clicking Purge. This removes all occurrences of the selected item, including all versions. You cannot restore purged items.
The "view references" tool assists you to view and manage all the links between items.
Accessibility features help a user who has a physical disability, such as restricted mobility or limited vision, to use software products successfully.
You can customize the detached accessible toolbar keystrokes by editing the KeySequence.properties file located under the wp_profile_root\PortalServer\config\com\ibm\wps\odc\editors folder.
The Web Content Management application does not check whether content written in Web Content Management is accessible or not. You will need to test your website to ensure the content is accessible.
The basic item creation task is the same for all item-types.
You create a folder when you need to store a set of the same type of items in a logical grouping.
Specify identification information for the folder, including the name, title and description of the folder.
When creating a folder you can specify the location of the folder.
To create a site framework, you need to create site areas.
When creating a site area you can specify the location of the site area.
Specify identification information for the site area, including the name, title and description of the site area.
You add elements to site areas to store Web content specific to the site area.