Protected Pages

You can put a password on any page or post. Visitors see a password screen; readers who know the password get the content. This page explains how to gate a page, what the “password protection” actually protects against, and the rules that come with it.

Gating a page or post

In the editor, open the Security section:

1. Type a password into the Set password field. The status line tells you whether the item is currently protected.
2. Save.

To remove a password, check Clear password (the option appears once a password is set) and save. To change a password, type a new one and save: the old one is replaced.

What the gate looks like to visitors

A protected page shows a simple screen: “This content is password protected,” with a password field and an Unlock button. When the right password is entered:

• The content is revealed immediately, with no page reload.
• The unlock is remembered for the rest of the browser session, if the visitor opens the page again in this tab, it stays unlocked. A new session asks again.
• Each protected page has its own password: unlocking one doesn’t unlock others. If you use the same password across several pages, that works, but nothing is shared automatically across tabs.

What the protection is, and isn’t

This is important to understand before relying on it:

• The gate is a reader-facing screen, not a locked box. The page content is still present in the published page’s HTML; the gate is JavaScript that hides it until the correct password is entered.
• A reader who knows the password gets in; a determined person who inspects the page source can also find the gated text. Treat the gate as hiding content from casual readers, not as a vault. For genuinely confidential documents, upload private documents through the Documents module instead (documents support real token-based access control with expiry and download limits).
• Search engines: protected pages are excluded from the sitemap they would otherwise appear in, which keeps them out of the site’s own search-surface submissions, but the content itself is still in the page source, as above.

The theme contract

Because the gate is implemented by your theme (the shipped default theme includes it), it only appears on templates that support it:

• The default theme’s page and post templates implement the gate.
• If you develop or install a custom theme that doesn’t wrap the content in the gate, protected content will render publicly with no visible gate; the system checks for this and will warn you when a template that protected content relies on loses its gate (“its password gate will stop rendering on the next rebuild”), so you get a chance to fix the theme before the rebuild lands.

Password handling under the hood (for the curious)

• Pages store the password as a plain SHA-256 digest; posts use a salted PBKDF2 digest (100,000 iterations). The shipped gate verifies both formats in the browser.
• Wrong-password attempts show “Incorrect password.” There’s no lockout on the gate itself: it runs entirely in the visitor’s browser and never sends the password to the server, so nobody can attack it off your server.
• Unlocked status lives in the browser’s session storage only; nothing about the password persists server-side after the initial hash is created, and nothing is stored about visitors.

Interaction with the rest of the site

• Protected pages and posts are excluded from the generated sitemap, so they shouldn’t surface in search engines unless linked from elsewhere.
• Listings, feeds, and public search exclude protected content from public output, so it won’t show up in “related” content on the site.
• Gating works the same in every language, each language version of the page has its own gate and can have its own password (or share one).