Push Publishing of dotCMS Pages requires both an Enterprise license, and the configuration of a Push Publishing connection between the sending and receiving servers.
Static vs. Dynamic Publishing
There are a few important differences between Static and Dynamic Publishing. When pushing pages to a Static Endpoint, the page is force pushed automatically in an effort to bring all dependencies on the page over to the static endpoint. However, since static pages do not dynamically render the navigation tool, then if a top level Nav item is added or subtracted, this will require the entire site be statically pushed in order for the top level navigation to change on all static pages. Pushing individual pages to a static endpoint requires that the user creating the push be extremely knowledgeable concerning the dependent files/pages/etc., that also need to be pushed for the update to be properly reflected on the static endpoint. For this reason, as a best practice, it is recommended that entire sites be pushed, instead of individual pages, to static endpoints.
Pushing pages to a Dynamic dotCMS endpoint is much more straightforward. Dynamic endpoints are dotCMS servers, so tools, velocity code, etc., exist on the receiving endpoint and dependent links/files either push with the page, or react to changes to the page and reflect changes in the same way as on the sending dotCMS server. There are still a few dependency exceptions that should be mentioned, even when pushing dynamic pages. If a user edits a field on a piece of content that refers to an externally located file, such as a hyperlink to an image in the WYSIWYG, or in a dynamic widget placed on the page, then users need to be aware that merely push publishing the page is insufficient. The files referred to in widget code or in the WYSIWYG fields, need to be pushed in addition to the page itself. Even when dynamically pushing pages, a staging environment is recommended, so that the push can be tested as successful, before the same push is made to a production environment.
Locations Where Pages can be Pushed
Pages can be Push Published from an authoring server to a staging/production server in the following ways:
Pushing Pages from Page Edit Mode
When editing a Page in dotCMS, the “Remote Publish Page” option will appear as long as there is a configured Push Publishing connection. After clicking on “Remote Publish Page” the following options for Push Publishing will be made available:
- Push - Push Publish the Page now, or choose a future date/time to publish the Page
- Remove - Remove the Page from the remote server (completely), now or at a future time/date
- Push & Remove - Choose dates and times for both the Push publishing & the removal of the Page
- Force Push - Force the Page to Push Publish, even if no changes to the Page have been made since the last Push Publish
- Push To - Choose the server to which the Page should be Push Published
Pushing Pages from the Site Browser
From the Site Browser tab, right-click a Page in either the detail area or under “Sites and Folders”, then select “Push Publish“. Pages can also be added to a Bundle, then Push Published later from the Site Browser - Publishing Queue.
Pushing Pages from Content Search
There are three different ways to Push Publish a Page from the Content Search screen:
- Right-click and Push Publish on an individual Page in the Content Detail area
- Right-click and “Add To Bundle“,then Push Publish the Bundle from the Site Browser - Publishing Queue
- To Push Publish multiple pages at once:
- Select the checkbox to the left of one or more Pages.
- Click the Available Workflow Actions button at the top of the Content Detail area.
- Click the Push Publish button in the popup.
For more information about recommended Push Publishing environment setup, please see the What to Know Before Push Publishing documentation.