Portal Scripting Interface extension for site management
You can use the site management extension bean of the Portal Scripting Interface to publish, promote, or demote portal content.
The portal content can consist of content nodes, labels, pages or partial hierarchies, compositions, or links to both internal and external URLs.
Example scenario: A sales company has a test portal and a production portal. The administrator creates a page for a special sale on the test portal. When the approving parties are happy with that page, the administrator publishes the page by moving it from the test or source portal to the production or target portal. By personalization rules, only the administrator can view the page. For the start day of the sale, the administrator promotes the page on the production portal. This makes the page visible to portal users with the appropriate access permissions. When the sale period is over, the administrator demotes the page on the production portal. Users can then no longer view the page.The methods listed in the following are available for site management. You can use them to publish, promote, or demote a page. All commands start with $Publish .
Notes:
- None of the parameters for the methods listed here have default values. You need to specify values for all of the parameters, otherwise the script will not run.
- Pages that you publish by using site management, their parent and sibling pages, and the portlets on these published pages must all have unique names assigned to them on both the source and target servers. For a portlet the unique name must be the same on both the source and the target server. Make sure that when you create page that you assign it a unique name; otherwise, you cannot publish the page to another server. If you try to publish a page that does not have a unique name, you will merely see the word Refresh in the user interface. This is an indication that this page is not ready for publication yet. When you create a new page, the system assigns the page a Unique Identifier; this is not the unique name. To assign a unique name to page or label, edit the page properties and enter a value in the Unique Name field, or use the Manage Custom Unique Names portlet.
- The Site Management portlet must maintain control over the entire life cycle of all the pages that it manages. The portlet does this by using the custom unique names assigned to the pages. Pages that have been created on the target server prior to the publish step cannot have their unique names in common with pages that Site Management controls on the source server, otherwise the publish step will fail.
- If the pages or portlets that you publish have existing personalization visibility rules associated with them, site management will publish the rule associations, but not the rules themselves. You must verify the same rules exist on both the source and target servers, and preserve the correct page-to-rule association by creating a Publish Server using the Personalization tools. Publish the required rule by selecting the Publish Selected menu option under Extra Options.
- Site management does not support publishing a page into the public area of the portal where anonymous users can see it.
- When a page hierarchy that you publish contains a page that is marked private for yourself on the source server, that private page is published as a public page on the target server. In other words, users of the target portal might be able to see private page there. This also applies to private changes that you made to a page that you publish. When you publish that page, other users can see the page just the same as you with all private changes that you made to the page.
- Pages that exist on the target server, but have not been created by a by site management publish step cannot be replaced by using the site management functionality. In such a scenario an error message is displayed. In this case you can delete the target page and then trigger the publish action.
- Pages managed by site management must only be changed on the source server, not on the target server; otherwise the site management function may not work any more.
- Site management does not support the merge of multiple publish events from different users. If two administrative users attempt to publish different versions of the same page at the same time, there is no support for merging these multiple publish actions. The last publish process overwrites previous publish versions. As a result, the last version of the page to be published is displayed. It overwrites other versions.
- To publish, promote, or demote portal content by using a secure connection with SSL (Secure Socket Layer), append the letter s to the http string of the source or target server URLs as follows: https. You might have to perform additional steps for the connection to work, such as importing a cert into cacerts.
Published items
The following information, or referenced items, are published if they are included in a page:Limitations:
- Unique names
- Page properties
- Page layout
- Page metadata
- Friendly URLs
- References to portlets on the page
The same portlets with the same unique name as on the source portal must also exist on target portal. References to JSR portlets and to IBM portlet without binary parameters are supported.
- Shared or default portlet preferences
- Portlet wires within the same page
- Advanced options under Edit page properties.
- You can only publish pages that have a unique name.
- The following items that a page can reference do not get published:
- Page permissions or access controls
- URL mappings
- Derived pages
- Composite applications
- Web Content Management content or libraries
- Private resources
- Private wires
- Personalized portlet preferences
- Portlets or portlet WAR files. You can publish references to portlets only if the portlets exist on the target server.
- Personalization rules. These must exist on the target server.
- Web content mappings on page templates.
- You can go back only one version on a publish, promote, and demote scenario. To go back farther than that, you need to create backups of the versions that you might want to go back to. You can do this by using the XML configuration interface.
- Site management publishing does not support cross page wires.
Script syntax
The following topics show the Portal Scripting Interface syntax for publishing, promoting, and demoting content.
- Publish a page using the Portal Scripting Interface
- Promoting a page using the Portal Scripting Interface
- Demoting a page using the Portal Scripting Interface
- Example scripts for site management
Parent
Manage the site
Work with the Portal Scripting Interface
Related tasks
Enable remote access to servers
Configure resource management
Manage the servers
Publish page
Provide reviewer access to a published page
Promoting page
Demoting page
Republishing and promoting a page
Manage sites