Some pages exist before they are allowed to be public. Some regulated providers must publish an annual quality report on their own website, and the report only counts once the organisation has formally adopted it. Until then, the page is a draft: it may be reachable for review, but it should not be indexed, should not appear in the sitemap and should say clearly that it is a draft. On a Yii2 site we built, all three behaviours hang off a single setting. This post explains that design, and the one trap it nearly hid.
The problem with three separate switches
A draft page needs three things to be true together:
- A visible banner saying the document is a draft.
- A
noindex, followrobots meta tag, so search engines leave it out of their results but still follow its links. - No entry in
sitemap.xml.
When the document is adopted, all three must flip at once, and the banner is replaced with "Adopted on" and the date. If these are three separate switches, sooner or later one is forgotten: an indexed page still showing a draft banner, or an adopted report that never makes it into the sitemap.
One setting, read in one place
The adoption date lives in the application's parameters, empty until the document is adopted:
// config/params.php
'qualityReport' => [
'adopted' => null, // e.g. '2026-11-30' once formally adopted
],A single method on the controller reads it, and everything else asks that method:
public static function qualityReportAdopted(): ?string
{
return Yii::$app->params['qualityReport']['adopted'] ?? null;
}The view uses it for the banner and the robots tag:
$adopted = SiteController::qualityReportAdopted();
if ($adopted === null) {
$this->registerMetaTag(['name' => 'robots', 'content' => 'noindex, follow']);
}<?php if ($adopted === null): ?>
<div class="alert alert-warning">Draft: not yet formally adopted.</div>
<?php else: ?>
<p>Adopted on <?= Yii::$app->formatter->asDate($adopted, 'long') ?></p>
<?php endif ?>And the sitemap action includes the URL only when the same method returns a date. Publishing the report needs no code change and no deployment: set the date, and the banner, the robots tag and the sitemap entry all change together.
The gate is the adoption itself, not some other condition. A document that has not been adopted should not be indexed, and a document that has been adopted should be, whether or not the organisation was required to publish it. A permanent noindex is wrong either way.
The trap: content hidden only by noindex
Reviewing the template before the first real publication, we found a sentence hard-coded in the view stating that the report had been submitted to the national body that collects these reports. It was not conditional on anything. While the page was a draft, nobody noticed, because the page was not indexed and hardly anyone saw it. The moment the adoption date was set, that sentence would have gone live as a public claim, true or not.
The single flag made publishing easy. It also meant that anything on the page that had not been checked would be published at the same moment. The fix was to give that claim its own parameter, which renders nothing when it is empty:
<?php if ($submittedTo = Yii::$app->params['qualityReport']['submittedTo'] ?? null): ?>
<p>This report has been submitted to <?= Html::encode($submittedTo) ?>.</p>
<?php endif ?>The order matters: the claim gets its own switch before the adoption date is ever set, not after. A rule we now apply to any page gated this way is to read the full draft as if it were already public before building the switch that publishes it. noindex keeps a page out of search results. It does not stop anyone who has the link from reading it.
Where the setting actually lives
On this site params.php is a shared file on the server, linked into each release by the deployment tool. The copy in the repository is not the one production reads. Adding a new parameter in the repository therefore does nothing in production until someone adds it to the server's copy, and that step needs checking after every deployment that introduces one. We check it by loading the page and reading the robots meta tag, the banner and the sitemap.
One flag, several jobs, on our own projects
We use the same pattern on pinuno.com.gh, and it shows the cost as well as the benefit. One setting, the GA4 property id, also gates the site's own campaign event function. Clearing it to switch off GA4 therefore silences every campaign event too. One flag doing several jobs is exactly the design this post recommends; the price is that someone has to know everything it switches.
Our config/params.php has the shared-file problem described above. Rather than rely on a manual check after each deployment, new keys go in a defaults file that ships with every release and is merged underneath, and the server value comes from the environment. For a publish flag that means one rule above all: a flag that does not exist on the server must default to "not published".
Our energy management product has a switch of the same kind. One setting, MARKETING_SITE_ENABLED, turns the marketing pages and their navigation links off together; with it off, those pages redirect to the login while authentication, the legal pages and contact stay reachable. The same August 2026 change also moved the analytics container id into an environment variable that defaults to empty, so a fresh install reports into nobody's analytics. Nothing told the operator the id now had to be set, and our own server recorded no analytics for a day after that deploy. A default that is safe for a new install still needs a line in the deployment checklist.
Conclusion
When one setting controls publication, everything on the page is published by that one setting. That is the reason to use one switch, and also the reason to check every sentence on the page before setting it.
If you want to learn to build PHP and Yii2 applications like this one, have a look at our PHP Application Developer course.