Experience Management
      Back to home
      1. Creatable Support
      2. Guide for Developers
      3. Experience Management

      Gallery Header & Footer Sync

      The purpose of this document is to describe the process of synchronization of an e-commerce website’s header and footer for on-site galleries using either a reverse proxy or sub-domain.

      Note for sub-domain customers:

      For sub-domains (ex: something.domain.com), special consideration needs to be taken to ensure that the header and footer contain absolute links to resources, enable CORS rules for the resources requested from the sub-domain specifically and enable 3rd party service providers (ex: Adobe Fonts) to allow this domain to access those resources. The rest of this document applies to both solutions.

      Providing the header & footer

      The header & footer for a gallery are intended to match what is available on the ecommerce site. In some cases, a simplified static header & footer can be provided, but should be avoided.

      Ingesting a header and footer can be achieved in several ways.

      1. A blank page (with empty body) can be provided.
      2. A separate endpoint that delivers all visible header & head HTML. A separate endpoint that delivers all visible footer HTML. The combination of these two would effectively be the same as option 1 above.
      3. A JS script tag for the header and a JS script tag for the footer can be provided, which will render all header elements dynamically.

      Once this has been provided, we configure your gallery to ingest the header and footer in the method provided. In option 3, there is no “build” process for the pages, since it is dynamic via Javascript.

      Process

      The process for including your header & footer is as follows. Per the above, a one-time gallery configuration is made by the Creatable team to enable this.


      1. Start: On a scheduled 24-hour basis, a deployment process runs (the max frequency is 4 hours).
      2. The most recent gallery page templates are gathered.
      3. The header and footer are accessed via option 1 or 2 (see above).
      4. The header and footer are rendered into the gallery page templates.
      5. The gallery page templates are published.
      6. The gallery receives a “full-publish” command.
      7. All pages in the gallery are rendered, using the templates, and published for final output to the CDN.
      8. Automated tests are performed against the rendered pages to ensure operation.
      9. End.

      Technical requirements

      The above process only has a few technical requirements, see below for details.

      The header & footer must be available to be fetched by a server process that originates from the following sources IP addresses. Note: for these IP addresses to be utilized, a flag must be added to your account, please contact support@creatable.io and reference this article.

      • 3.228.39.90
      • 18.213.67.41
      • 34.194.94.201
      • 34.194.144.202
      • 34.197.6.234
      • 35.169.17.173
      • 35.174.253.146
      • 52.3.128.216
      • 52.4.195.249
      • 52.5.58.121
      • 52.21.153.129
      • 52.72.72.233
      • 54.92.235.88
      • 54.161.182.76
      • 54.164.161.41
      • 54.166.105.113
      • 54.167.72.230
      • 54.172.26.132
      • 54.205.138.102
      • 54.208.72.234
      • 54.209.115.53

      Please enable exclusion from any web filters or firewalls.

      If the request is being routed via a CDN like Cloudflare or Akamai (via public internet), be sure that requests from these IP addresses are allowed. Alternatively, if there is an origin server available, this is also a viable option in order to not change the configuration of your CDN.

      The header & footer must contain absolute paths to resources (Images, CSS, Javascript, etc…) This is to ensure that the proper resources are being accessed. If this is not possible, then some resources will be unavailable in lower testing environments, unless those environments have been specifically configured in a similar manner to the production environment with a reverse-proxy.

      Relative paths for resources is acceptable, but lower environments need to be configured with a reverse-proxy for this to function properly.

      If for some reason, the above process is unable to access/retrieve the header & footer resources, the deployment job will fail and no deployment will occur. This will result in the header & footer resources to not be up to date.