Pages / Build

What it can do

From a single page to a site of thousands, with shared templates, media libraries, redirects and live data. You ask for the result; the MCP knows how to use each of these.

20,000files per release
64 MBper file
2 GBper release
50releases kept per environment

Any website a browser can run

Pages serves anything a browser can run: HTML, CSS, JavaScript, images, fonts, video, PDFs. That includes sites built with modern JavaScript frameworks, single-page apps, interactive charts and maps. No CDN is needed: files are compressed, cached, served in ranges for video, and named files with a content fingerprint (like site.3f2a9c1b.css) are cached for good at a domain.

Layouts and generated pages

A site with a _layouts/ folder is assembled when it's published, with no build tools. Write the header and footer once and every page uses them. This guide works that way: one layout holds the navigation you see above, and each page is just its content.

In the siteWhat it is
_layouts/base.htmlA page template. The page's content goes where the layout says.
_includes/header.htmlA reusable piece, such as a header, used by any layout or page.
_data/shows/*.jsonRecords, one per file, in JSON, YAML or Markdown, such as one per show or event.
A page with front matterA page that uses a layout, sets a title, or is generated once per record.

From one template and a folder of records, Pages can make one page per record (one per show, per event, per team member), one page per tag, and paged lists. Sitemaps and feeds are ordinary pages that loop over the records.

Change a layout and every page using it updates in one release. A template mistake refuses the release and lists every file and line that failed, and the environment stays where it was.

Ask the PBS SoCal MCP (Plexara)Turn my events site into a layout-based site: one shared header and footer, one record per event in _data/events, one page per event, and a home page listing upcoming events by date.

Images and downloads

Images, video and downloads that don't change with the pages belong in a media folder: a folder in the PBS SoCal resource library, mounted at a path on the site, such as /photos/. A site can have up to 20 mounts.

  • Media sits outside releases: replace a photo in the library and the site shows the new one at once, with no publish.
  • It doesn't count toward a release's size limit.
  • The shared PBS SoCal brand folder, with official logos and PBS Sans, can be mounted the same way. This guide mounts it at /brand/.
  • A mounted folder is public at a public domain: mounting a folder publishes it. HTML, SVG, JavaScript and XML files in a mount are sent as downloads, so a media folder can't turn into an unreviewed second site.

Redirects and app routes

A _redirects file lists redirects, one per line, with wildcards:

/old-schedule      /schedule        301
/blog/*            /news/:splat     301
/app/*             /app/index.html  200

A rule with status 200 is a rewrite: the address stays the same and the named file answers. That's how a single-page app handles its own routes. A 404.html file is your not-found page.

Live data and forms

A site environment can be made part of a platform application. Its pages can then call the application's endpoints at /endpoints/<name> on the site's own address: live numbers from the data warehouse, a sign-up form, a search. Those endpoints run as the signed-in person, so what they return follows that person's access.

Even without an application, a page can read /_viewer to know who's signed in and tailor itself. See Knowing who is reading.

Ask the PBS SoCal MCP (Plexara)Make the prod environment of my membership-dashboard site part of an application with an endpoint that returns this month's new Passport members, and show the number on the home page.

Part of a Plexara Application

Pages are not limited to static files. When a site environment is part of a Plexara Application, the site can do what any advanced website does: call its own API, keep data in its own database, take form submissions, refresh itself on a schedule and react to events, all governed by Plexara and all running as the signed-in person.

APIendpoints at /endpoints/<name> on the site's own address
Databasea PostgreSQL schema of its own, built by migrations
Formsvalidated, stored, and protected from bots
Schedulesscripts that copy or compute data on a timer

See them working: the TV schedule, the reach dashboard and the suggestion form.

Bringing a site in

  • Copy a live site you don't have the source for. Pages crawls it into dev: each page keeps its address, redirects become redirect rules, and stylesheets, scripts, images and fonts come along. Forms can be swapped for platform forms. Up to 2,000 pages.
  • From source: publish from a zip archive in the resource library, a library folder, or a folder in object storage, for sites with thousands of files.

Editing in place

The MCP doesn't need to re-send a whole site to change one line. It can outline a page, find text across the site, read one file, compare two releases and patch just what changed. Each patch is a new release in dev, and several patches reach people together in one promote.

Any domain

Plexara Pages can serve a site on any domain. Any environment except dev can have one or more:

  • Internal subdomains such as hello.pmgsc-data.org (this guide) or team-news.pmgsc-data.org. DNS is already in place; an administrator switches the name on.
  • Custom domains such as example.com, a campaign domain or a show's own site. Whoever manages the domain points its DNS at Plexara, then an administrator switches it on.

Each certificate is issued automatically. Each domain is private until the owner or an administrator sets it public, so a custom domain can be tested behind the sign-in before launch day. See Any domain.