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.

A blank page (with empty body) can be provided.
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.
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.

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