Security and content visibility

Productions #

Other pages never depend on an entered password (Theater 0.7.0). On every page other than the production's own page — lists, person profiles, the general schedule, and a production placed in another page with [hype5_production], the other production shortcodes and blocks, or [hype5_schedule production="…"] — a production's details are shown only while it is public to everyone: published without a password, in its original language and in the reader's language. A protected production shows its title and the password form there also after the visitor has entered the password; the form takes the visitor to the production's own page, where the password unlocks it. WordPress's own feeds, archives, search results and core REST answers also keep a protected production protected after the password was entered. Such pages are the same for every visitor, so page caches may keep them. People who may read an unpublished or private production — an editor previewing a draft, a member of a private production — see its details on other pages too while it carries no password.

Output scoped to one production — its own page, and a schedule that the page's address filters to it (?hype5_production=…) — opens once the visitor has entered the password, and is sent with no-cache headers so that page caches do not keep the unlocked version.

Repertory status (Coming soon, Playing, On hold, Archived) never affects visibility. An archived production stays public and keeps its address.

Performances and ticket offers #

• A performance appears publicly only while its production is public to everyone, or unlocked on the production's own page (or in a schedule the page's address filters to it).
• Schedule counts use the same rule as the rows, so a count never includes performances that are not shown. The productions list's next performance order and its city filter use only productions public to everyone: a protected production sorts with the undated ones and never matches a city.
• Internal notes and attendance are never shown publicly, never returned by the public REST API, and are hidden from users who may edit the production but not manage performances.
• A purchase button appears only under the ticket rule.
• Performances of a deleted or unpublished production are ignored by public output.

People #

A hidden profile also hides its translations. A person profile lists only productions that are published without a password. See People.

Credits #

A hidden credit row is kept but never shown — not on pages, not in shortcodes and not in the public credits REST route. The public credits REST route also leaves out credits whose person profile is not published.

Venues #

A venue is named, and its accessibility defaults are used, only while it is published. A venue in the Trash is no longer named in public schedules; production pages keep naming it as the premiere venue until it is deleted permanently. See Venues.

Multilingual sites #

With a translation plugin (Polylang was tested with 0.7.0; WPML only simulated, see Compatibility), translations share credits, galleries, rows and performances through the original-language production. A password on any version in a production's chain — the version asked for, the original, or the reader's-language version — protects the shared data shown on that version. The first version that carries a password decides, so the password entered on a page always unlocks that page.

• Each version's own password opens its own page, including its dates and offers (Theater 0.7.0). WordPress remembers one entered password per visitor, so with different passwords on two language versions each page opens only with its own; use the same password on every version.
• The password of an unpublished version never opens the original: a draft translation's password does not unlock the published original's dates.
• A published translation of an unpublished original shows only its title, address and poster to visitors who may not read the original (see the table above).
• Search: visitors who are not logged in do not find any version of a production with a password in its chain.
• The productions list's next order and city filter, and schedule counts, follow the public to everyone rule in every language.
• Unpublished translations are never shown to visitors.

See Multilingual sites.

REST API #

The plugin's three public routes are read-only and follow the same rules: the credits route answers 401 while a password is required and 404 for an unpublished production. Answers scoped to one production with a password (the performances and credits routes filtered to it) carry no-cache headers. The productions route returns a production's excerpt only while it is public to everyone, so that list never depends on a visitor's password.

WordPress's own REST routes for Hype5 content leave out hidden profiles and mask Hype5 values of protected productions for users who may not edit them. Since 0.7.0 their answers never depend on the password cookie: a production with a password in its chain stays protected there also after the visitor entered the password on the production's page. WordPress's own password parameter still opens a post's own password. The routes under /hype5-theater/v1/app/ are private to the Hype5 app and require a logged-in user with a Hype5 Theater administration capability and the right capability for each route. See REST API.

Themes and custom code #

The plugin's templates receive prepared data that already follows these rules, so a template override that uses the data it is given shows nothing protected; an override that fetches data itself must apply the rules (Visibility::presentable()). Themes that call the plugin's PHP services directly must follow the rules themselves for services that return raw rows; since Theater 0.7.0 the plugin's visibility service (Data\Visibility, presentation API 1.0) tells them whether a production's details may be shown on the current page. See Presentation services and Theme integration.

Administration safeguards #

• Every screen, route and save checks WordPress capabilities. See User roles and permissions.
• Changing custom CSS needs the edit_css capability, as WordPress's own Additional CSS does. Users without it see the stylesheet read-only.
• Public texts (labels) are limited to 500 characters.
• The Hype5 app protects against overwriting someone else's newer changes: a stale save stops and marks the changed fields. This protection covers the app and the guarded classic forms, not REST clients, WP-CLI, other plugins, Bulk Edit or older browser tabs. See Known limitations.

What Hype5 does not store #

Hype5 Theater stores no visitor accounts, payment details or ticket purchases. Ticket offers are links to external sellers.