Everything a developer changes on a Core dna site lives in its theme repository. This guide covers the repository and its build, printing records in templates, stylesheets and client-side code, and the parts of a site around the main content.
L1–L2
Unit 05 · Around the main content
Markup that differs by environment
Around the main contentPage 31 of 35Updated
How a template tells the live site from a staging or development copy with the methods on _currentSite, two uses that are worth it, and why features and brands belong somewhere else.
Who this is for. Developers who need a site to behave differently off production: keep search engines and analytics away from staging, or label a test copy so nobody mistakes it for the live site. After this page you can write the check once and know what it answers on every environment.
Environments and hostnames
A site can have several environments, such as production, staging and development, each with its own hostnames. One of them is the site's primary environment, and each environment has a primary hostname. _currentSite, available in every frontend template, describes the site and the environment handling the request:
Method
Returns
isPrimaryEnvironment()
Whether the environment handling this request is the site's primary one
isPrimaryHostname()
Whether the hostname of this request is the primary hostname of the current environment
isPrimary()
Both of the above
getPrimaryHostname()
The primary hostname of the current environment
getPrimaryEnvironmentPrimaryHostname()
The primary hostname of the site's primary environment: on a staging copy, the live hostname
getEnvironmentName()
The environment's name as typed in the admin, such as "Staging"
isHostnameOfCurrentEnvironment($hostname)
Whether a hostname is one of the current environment's hostnames, ignoring case
isHostnameOfCurrentSite($hostname)
Whether a hostname belongs to any environment of the site, ignoring case
Environment configuration is not readable from a template (_config returns *** for every Environment setting), so these methods are how a template knows where it is running.
The check
Environment names are free text, so a test for the word "production" depends on what someone typed. Test two facts instead: the request is handled by the primary environment, and it arrived on one of that environment's own hostnames. The second half keeps development servers out, where the platform can recognise the site under a different hostname from the one in the browser; _request->getHostname() returns the hostname the browser sent. Compute the answer once, near the top of the base template, and reuse it:
{% set environment = (_currentSite.isPrimaryEnvironment() and _currentSite.isHostnameOfCurrentEnvironment(_request.getHostname())) ? 'production' : 'development' %}
Two uses worth it
Keep search engines off every copy but the live one
A staging copy that gets indexed competes with the live site in search results. Ask search engines not to index anything except production, where each record's own robots setting applies instead. The same branch is the place for analytics and tag manager includes, so test traffic stays out of the reports.
Printing the record's own robots value on production is on Robots and the sitemap. A robots.txt file cannot do this job: it is one static file, the same whichever hostname serves it.
Label a copy that is not live
A banner on staging stops people testing on, or sending links to, the wrong copy. Print the environment's own name rather than a fixed word, so the banner is right on every copy:
Template code
{if !$_currentSite->isPrimary()}
<div class="env-banner">{$_currentSite->getEnvironmentName()}: not the live site</div>
{/if}
{% if not _currentSite.isPrimary() %}
<div class="env-banner">{{ _currentSite.getEnvironmentName() }}: not the live site</div>
{% endif %}
What an environment check is not for
An environment check answers one question: is this the live copy? Keep other questions out of it.
Features. A feature turned on by an environment check is tied to the code: switching it on for the live site takes a template change and a deploy. A feature switch belongs in site data, where an administrator turns it on without one: see Site data and feature flags.
Brands and variants. Which brand, region or variant a site shows is a setting, not an environment. Keep it in site data or a menu.
Never compare an environment id with a number
A test such as {if $_currentSite->getEnvironmentId() eq 4}, repeated through a theme's templates, hides what it means: the next developer cannot tell which environment 4 is, and nothing in the templates still works if the environments are ever recreated with new ids. Use the named methods above for environment questions, and site data for everything else.