Dynamic and Static Publishing

A single Push Publishing environment can be set up to send to many endpoints. The receiving endpoints can be either “dynamic” dotCMS servers or “static” Amazon AWS endpoints that receive static HTML pages and files. Both Dynamic Endpoints and Static Endpoints can be set up under a single environment, but Push Publishing will function differently, based on whether the endpoint is static or dynamic.

In any environment, from development to production, both dynamic and static endpoints can be set up during any level of deployment process, where appropriate dependent on the use case or need.

Note: Static Endpoints are only supported in dotCMS Enterprise editions for customers with a Site License (Platform level license). Please see the list of dotCMS versions for more information on features supported in different version of dotCMS.

Dynamic Endpoints

Dynamic endpoints are dotCMS servers receiving pushes of content/objects/etc. from a secondary dotCMS or “sending” server. Dynamic endpoints preserve all of the dotCMS backend features and front end tooling. Dynamic endpoint are usually ideal for both development and staging environments. Production environments can be either Dynamic or Static, based on need, use case, and/or business rules.

Advantages of Dynamic Endpoints

1. End point is a fully functional dotCMS server - all backend and frontend dotCMS features are retained
2. Files/content/templates/etc., can be sent individually to dynamic endpoints.
3. Dependencies are pushed with objects such as a dotCMS webpage, whereas static publishing requires users to have a deeper knowledge of files that may be loosely related to the object being sent (similar to FTP transfers).
4. Allow and respect permission-based front-end logging, intranet access, etc.

Limitations and Important Considerations when using Dynamic Endpoints

1. Require more resources, including a dotCMS server
2. Dynamic pages require a bit more processing and do not serve as fast as simple HTML pages.
3. Dynamic endpoints retain login functionality, and therefore are not as secure as static pages that do not expose any route to elevated privileges.

Static Endpoints

When an endpoint is defined as “Static AWS S3“, then only the static html is bundled for the specific object(s) being sent. The configuration documentation shows how these static AWS bundles can be served as production websites for fast, secure, and low-overhead production site delivery. Multiple static endpoints can be set up for every website being managed by dotCMS and delivered to various endpoints around the world in different languages for global, enterprise-level site delivery.

Common Uses for Static Endpoints

There are many reasons why you might want to perform static publishing of your dotCMS content (often in addition to rather than in place of dynamic publishing); some of these include:

• Provide enhanced security/reduced attack surface for highly sensitive sites or content via static HTML.
• Improve performance and take advantage of cloud scalability by serving most of your site statically, with callbacks to a Dynamic Endpoint for a few services (such as forms and searches) that require dynamic content.
• Archive your site for historical, regulatory compliance, or legal purposes (using the {date} variable in the bucket name).
• Send all files to the Static Endpoint and use the Amazon AWS S3 bucket(s) as a Content Delivery Network (CDN).
• Use static push as a Disaster Recovery (DR) option.

Advantages of Static Endpoints

1. In many cases, Static HTML sites serve faster than dynamic sites/pages
2. Require far less resources, reducing production environment costs.
3. Static HTML pages provide maximum site security:
   • Do not allow backend user logins
   • Do not run dynamic server-side technologies such as Java
   • Do not have running databases
4. Static Endpoints require less administration and maintenance.
   • They do not need to be regularly updated with the latest versions of dotCMS software, databases, the operating system, or dynamic technologies like Java for the push to work correctly.
   • Permissions to push content for Static Endpoints are relatively straight-forward and rarely change.

Limitations and Important Considerations when using Static Endpoints

1. Individual pieces of content or files can NOT be static published.
   • Only sites, folders, and pages can be statically published from a dotCMS server.
2. Not all dependencies (linked files in coded widgets, or WYSIWYGS) are bundled with a particular object, such as an HTML page.
   • Therefore, it is recommended that static pushes include the complete site when the user creating the push is not sure of all the related files associated to the HTML pages being pushed.
   • This is very similar to FTP push requirements, and requires the user pushing the page/folder both know of and push all file dependencies required to render the page properly.
   • This is why pushing the complete site is recommended when static publishing.
3. Changes to common page elements (such as headers and footers, navigation menus, Containers and Templates) are not automatically updated on all pages.
   • To avoid broken dependency links when static publishing, it is recommended that the entire site be pushed again. This ensures that the static versions of all pages are updated, such as in the case of a top level navigation change, which would affect all static pages.

Dynamic vs. Static Content

The terms Dynamic and Static refer to how the content is stored and delivered from the server where your web site is served. In simple terms, dynamic content refers to content which can change “on-the-fly” based on various conditions, while static content is content that is fixed until it manually changed.

Dynamic Content

Dynamic content is “living” content that can change what content is displayed and how it is displayed to each different user each time it is displayed. Dynamic content can change based on almost any conditions you wish to consider, from the server or domain where the content is being displayed (e.g. when the same Widget is displayed on multiple sites), to the authorization level of the user, to the preferences or past behavior of the user currently browsing the content (e.g. Personalization). You can even extend dotCMS with your own Java plugins to deliver completely custom content and behavior.

The dotCMS content architecture is designed to deliver dynamic content, and all content created within the dotCMS back-end or served from a dotCMS server (a Dynamic Endpoint) is inherently dynamic.

Dynamic content includes all of the following:

• Content Types and URL Maps
• Shared Page Elements
  • Content
  • Containers
  • Images (especially when processed)
  • Navigation and Vanity URLs
  • Templates
  • Themes
• Server-side Code
  • Velocity Code
    • Container code
    • Custom Fields in Content Types
    • Widgets
  • Sass and Less Files
• Multilingual Content
• Personalization
  • Rules
  • Personas
  • Visitors

Note: Files, Folders and Pages all have specific locations (both on the server and within a URI), and are thus not as dynamic as other dotCMS elements. However all of these can still contain dynamic elements, or reference other dynamic elements, making them all dynamic depending on how they're used in your site.

Static Content

Static content is “fixed” content that, once it is written to the server (e.g. a Static Endpoint), doesn't change on the server - and is displayed the same to all users accessing the server - until it is explicitly changed (via Push Publishing).

Static Content stored and delivered from a Static Endpoint includes:

• Plain HTML Pages.
  • No Velocity or other server-side code is executed on the Static Endpoint.
  • All code is evaluated and the resulting HTML is rendered in the page before the HTML page is written to the Static Endpoint.
• CSS Files.
  • No Sass or Less files are written to the Static Endpoint.
  • Server-side Sass and Less files are compiled to plain CSS files during the push to a Static Endpoint, and plain CSS files are written to the Static Endpoint instead of Sass or Less.
• Static Images.
  • No image transformations (resize, crop, etc.) are performed on any images served from the Static Endpoint.
  • All images on your dotCMS site are transformed during the push to the Static Endpoint, and are written to the Static Endpoint in their final displayed form (after being resized, cropped, etc.).
  • If the same image is displayed with different transformations in different locations on your site, each transformation will be written as a separate image file to the Static Endpoint.

Static content may include dynamic elements such as scripting, but all dynamic behavior of static content is delivered by the user's browser, rather than the Static Endpoint server.

Converting Dynamic Content to Static Content

When content is pushed to a Static Endpoint, all dynamic content (as listed above) is evaluated during the push and sent to the Static Endpoint as static HTML. For example, all Velocity code is evaluated at the time of the push, and the resulting HTML is sent to the Static Endpoint (as plain HTML, without any reference to the Velocity code that generated it).

The following table lists how different types of dynamic content are handled when sent to a Static Endpoint:

Note: Any content which is in any way duplicated on the Static Endpoint can get out of sync if the underlying dynamic content is changed without the Pages that depend on it being re-pushed. For more information, please see the Push Publishing Best Practices documentation.