Publishing your page

After you have created and tested your content, which can be a page, label, or URL, you can publish it to a target server. You can perform the publish task by using the Resource Manager portlet on the Site Management page, or by using the Portal Scripting Interface. View information on publishing through the Resource Manager portlet.

Notes:

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 your 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 your 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 make sure that 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 your 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.

Perform the following steps to publish a page to a target server:

Create and test a page on your source server.
The following information, or referenced items, are published if they are included in a page:
- Unique names
- Page properties
- Page layout
- Page metadata
- Friendly URLs
- References to portlets on the page
  Note: The same portlets with the same unique name as on the source portal must also exist on your 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.
Limitations:
- 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.
- You can go back only one version on a publish, promote, and demote scenario. If you want 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.
Perform the following steps to select a server:
Note: You can select only your source server or you can also open your target server so you can compare them.
1. Navigate to the Site Management page by clicking Administration > Site Management.
2. Select the server from the pull-down list.
3. Click on the plus sign ( + ) next to the server name to expand the server site tree.
Perform the following steps to publish a single page or label or the entire page or label hierarchy from a test server to your production server:
1. Before you publish, you need to know the unique name of the page on the target server. To determine the unique name of the parent page on the target server, use the Copy page unique name feature. To do this, open the tree for the target server, right click the page that you want as the parent and select Copy page unique name. You will use this parent page unique name from the target server in a later step of this procedure.
2. Right click the source page or label and select Publish to > servername.
3. Select the Page radio button to publish a single page or label. If this is a hierarchy that you want to publish, select the Entire subtree radio button.
4. Enter the Parent page unique name, which is the unique name of the parent page on the target server. By alternative, click the Use saved unique name link to paste the unique name.
5. Optional: Enter the Sibling page unique name, which is the unique name of the page that comes after the published page in the target server hierarchy.
6. Click OK to publish the page to the target server or click Cancel to exit without publishing.
7. Optional: If the target server is also running and shows the list of pages, you can refresh the server site tree to verify that the page was published. Right click the page that is above the page to be published in the tree, that is the parent page of the page you want to publish, then click Refresh. The newly published page shows a round publish icon next to the page name. Only users who are authorized to view published pages, based on the specialized Personalization publish rule, can see this page on the target server. Clicking Refresh on the parent page refreshes only that page and node including its children pages, but not the grandchildren pages.
Log on to the target server as a user who has the authority to view published pages. Verify that the page(s) that you published is available on the server and is working as designed. If you are an administrator, go to the Manage Pages portlet and select Content Root > parent_page to review the configuration of the published page. You see a published version of the page with the following unique name: com.ibm.portal.published_page_name.
Note: The published page and the resources of the published page, such as the layout container and portlet instances, contain the object ID of the source page as metadata. This information will be used later to create the live page with the same object ID of the source page.