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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. Site management does not support publishing a page into the public area of the portal where anonymous users can see it.

  6. 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.

  7. 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.

  8. 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.

  9. 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.

  10. 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:


Script syntax

The following topics show the Portal Scripting Interface syntax for publishing, promoting, and demoting content.


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

 


+

Search Tips   |   Advanced Search