TIL Frontend Builds for PHP Sites on Pantheon  🔗 **Source:** [TIL Frontend Builds for PHP Sites on Pantheon](https://www.youtube.com/watch?v=bwOmZEgXKTU) > [!note]+ Document Notes > tags: [pantheon-frontend-builds, pantheon-yml, wordpress-theme-builds, npm-build-pipeline, github-deploy-workflow, webops-platform] > author: Chris (Pantheon Developer Relations; surname unverified from captions) > source: Pantheon (YouTube) > reference: https://www.youtube.com/watch?v=bwOmZEgXKTU > date created: 2026-09-24 13:57 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: TIL Frontend Builds for PHP sites on Pantheon > <!-- deep-read:sections start --> ## 🧭 Table of contents - [📝 Summary](#-summary) - [📖 Main content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning styles assessment](#-learning-styles-assessment) - [📊 Accessibility assessment](#-accessibility-assessment) - [🌍 DEIB assessment](#-deib-assessment) - [✅ Logical validity](#-logical-validity) - [🛡️ DARVO analysis](#️-darvo-analysis) - [🎯 Conclusion](#-conclusion) - [🔄 Refactor appendix](#-refactor-appendix--til-frontend-builds-for-php-sites-on-pantheon) ## 📝 Summary - **What happened.** Pantheon published a 3:19 "today I learned" tip on 2026-09-21, presented by Chris Boulton, who introduces himself as senior manager of developer relations. The auto-captions render the surname as "Boulton"; confirm the spelling against Pantheon's staff page before crediting him in print. This is first-party product content: the employer's own channel describing the employer's own feature. - **The claim.** Pantheon's frontend builds feature, announced in July 2026 for Next.js sites, also runs npm builds for WordPress and other PHP sites. Adding a `frontend_build` block to `pantheon.yml` with `enabled: true`, one or more paths, a Node version, and a build command makes the platform compile theme or plugin assets on push, with the npm output visible in the workflow log. - **Why it matters.** Teams that keep a GitHub repo, a CI job, and a second Pantheon repo just to run `npm run build` can collapse that to one repo plus a YAML block, and can use Pantheon's native GitHub integration to trigger builds on commit. - **Key stakeholders.** Pantheon (vendor and publisher), WordPress and Drupal agencies on Pantheon that ship compiled CSS/JS, and the reader's own developer relations team, which owns the docs and talks this tip feeds. - **Risks and tradeoffs.** The presenter states one limit at 00:02:15: this does not provide a Node binary at site runtime, so anything that needs Node while serving requests is out of scope. The transcript never spells the exact sub-key names for Node version or build command; the docs page is the authority for those. Nothing in the video is independently verified; it is a demo by the vendor. - **Bottom line.** A three-line mental model: `frontend_build` in `pantheon.yml`, `enabled: true`, a list of paths each with a Node version and a build command. Build-time only. Everything else in the video is workflow simplification that follows from that. ## 📖 Main content **What the feature does.** Pantheon runs your JavaScript and CSS build during deployment instead of requiring you to commit compiled assets or run an external CI. At 00:00:06 the presenter says the feature was announced "back in July" and frames the surprise: he assumed it applied only to the Next.js sites Pantheon already builds "out of the box," and learned it applies to PHP sites too. The video description links the July release note at docs.pantheon.io/release-notes/2026/07/frontend-asset-builds, which is the primary source for the announcement date. **The demo site.** A vanilla WordPress install whose theme uses npm to build CSS and JS and pulls in "a couple JavaScript libraries" (00:00:49). The theme is a Critical Role fan site: a custom front page listing campaigns, a countdown timer to the next episode, and a "Feywild mode" that switches the site to dark mode. None of the theme code is shown line by line; the front end is described, not read. **What is shown on screen (per the narration).** Three artifacts are walked through: 1. The theme directory (00:00:49): a `node_modules` folder and a `dist` folder. The narration says the `dist` folder "is get ignored" and holds the compiled CSS and JS. Whether `node_modules` is also ignored is not stated; assume yes as standard practice, but the transcript doesn't confirm it. 2. `package.json` (00:00:49 to 00:01:33): committed alongside the lockfile, which the captions render as "package.lock.json" (an ASR mangling of `package-lock.json`). Scripts named: a build script, "some watch scripts," and clean. 3. `pantheon.yml` (00:01:33): the block that "activates the magic." Spoken structure: a `frontend_build` key (captions: "front end build"), `enabled true` beneath it, then "any number of paths." The demo lists one theme path; the presenter notes a plugin with its own build could be added as a second path. Each path carries "a parameter for the node version and the build command." The default command shown is `npm run build`; the presenter's example of an alternative is `npm run launch`. 4. The workflow log (00:02:15): after a push, the log "exposes the full process, including this section right here that shows the actual npm build process." **What is asserted but not shown.** The July announcement date (linked in the description, not shown), the claim that Next.js sites get this "out of the box," the claim that the GitHub integration can now trigger these builds on commit, and the two-repo workaround pattern the feature replaces (00:02:15). These are plausible and consistent with Pantheon's public docs, but the video demonstrates none of them. **The stated limitation.** At 00:02:15 the presenter says the feature "doesn't solve situations where you might need an actual node binary in these site runtime to do things more on the fly." The scope is build time: run npm, produce `dist`, deploy. Server-side rendering with Node, Node-based cron, or a Node process alongside PHP is not what this is. **Terms.** *Frontend build*: a compile step (bundling, transpiling, minifying) that turns source JS/CSS into browser-ready files. *`pantheon.yml`*: Pantheon's per-site configuration file committed to the repo root. *Workflow log*: the per-deploy log Pantheon's dashboard exposes for each code push. *Native GitHub integration*: Pantheon's feature that syncs a GitHub repo to a Pantheon site so pushes to GitHub deploy without a second remote. **Uncertainties.** Exact YAML sub-key spelling for Node version and build command (not spoken). Whether paths accept globs or only literal directories (not addressed). Supported Node versions (not addressed). Whether `bun` is supported as a runtime or only mentioned as something you no longer need to vendor (00:00:06 mentions "node js or bun" as external dependencies the feature removes). Behavior when the build fails: does the deploy halt? Not addressed. ## 🗒️ Notes #### ⏱️ [00:00:06](https://www.youtube.com/watch?v=bwOmZEgXKTU&t=6) Intro, presenter, and the TIL premise - Presenter: Chris Boulton, "senior manager of developer relations." Surname spelling is auto-caption output; verify. - Frontend builds announced "back in July"; the description's release-note URL dates it to 2026-07. - Core value statement: no external dependency to pull in Node or Bun, no external CI, for sites that compile JS or CSS. - The TIL: the feature applies to PHP sites, not only Next.js sites. > [!quote] [00:00:06] > you no longer need to use some external dependency to pull node js or bun in or use an external CI to compile your assets. #### ⏱️ [00:00:49](https://www.youtube.com/watch?v=bwOmZEgXKTU&t=49) The demo site and the theme directory - Vanilla WordPress; theme uses npm for CSS and JS and pulls in a couple JavaScript libraries. - Fan-site content: Critical Role campaigns, episode countdown timer, "Feywild mode" dark theme. - Theme directory shows `node_modules` and `dist`; `dist` is gitignored and holds compiled output. - `package.json` and the lockfile (captions: "package.lock.json") are committed. #### ⏱️ [00:01:33](https://www.youtube.com/watch?v=bwOmZEgXKTU&t=93) package.json scripts and the pantheon.yml block - Scripts: build, watch scripts, clean. Described as "nothing weird." - `pantheon.yml` is what activates the feature. - Structure as spoken: `frontend_build` key, `enabled true` beneath it, then a list of paths. One theme path in the demo; a plugin path could be added. - Per path: a Node version parameter and a build command parameter. Default `npm run build`; example alternative `npm run launch`. > [!quote] [00:01:33] > To enable front end build, you need to add the front end build to your pantheon.yml. Underneath that, you must add enabled true to actually turn it on. #### ⏱️ [00:02:15](https://www.youtube.com/watch?v=bwOmZEgXKTU&t=135) Workflow log, the runtime limit, and the GitHub simplification - On push, the workflow log shows the full process including the npm build section. - Limitation stated plainly: no Node binary at site runtime. - Replaces: build tools, CI, "or other workarounds to just do npm run build." - Enables the native GitHub integration to trigger builds on commit, instead of two repos (GitHub plus Pantheon) with CI pushing built output to the second. > [!quote] [00:02:15] > Now, this doesn't solve situations where you might need an actual node binary in these site runtime to do things more on the fly, #### ⏱️ [00:02:58](https://www.youtube.com/watch?v=bwOmZEgXKTU&t=178) Close: docs, comments, roadmap - Documentation links are in the description (release note, `pantheon.yml` reference, roadmap). - Asks for comments on the feature and on uncovered use cases. - Points viewers to roadmap.pantheon.io for feature requests. - Sign-off: "we'll see you on the internet." Video ends at 3:19. ## 📚 References The transcript itself contains no links; the following come from the video description or are primary sources for named entities. - [TIL Frontend Builds for PHP sites on Pantheon](https://www.youtube.com/watch?v=bwOmZEgXKTU): the source video, 3:19, uploaded 2026-09-21 to the Pantheon channel. - [Frontend asset builds release note (July 2026)](https://docs.pantheon.io/release-notes/2026/07/frontend-asset-builds): linked in the description; the primary source for the announcement the presenter references at 00:00:06. - [pantheon.yml configuration reference](https://docs.pantheon.io/pantheon-yml): linked in the description; the authority for exact key names, since the transcript spells none of them. - [Pantheon product roadmap](https://roadmap.pantheon.io/): linked in the description; the feature-request destination named at 00:02:58. - [Critical Role](https://critrole.com/): the subject of the demo fan site. Incidental to the feature. - npm `package.json` and `package-lock.json`: standard Node project manifests referenced at 00:00:49; see [docs.npmjs.com](https://docs.npmjs.com/cli/v10/configuring-npm/package-json). ## 🗣️ Paraphrase Chris Boulton opens by admitting he missed something his own company shipped: the frontend build feature announced in July isn't only for Next.js. If your WordPress or Drupal theme runs `npm run build` to produce its CSS and JavaScript, Pantheon can now run that build for you during deployment. No vendored Node, no external CI, no committing `dist` to the repo. He proves it with a small WordPress site whose theme has an ordinary `package.json` with build, watch, and clean scripts. The theme's `dist` folder is gitignored. The only new piece is a block in `pantheon.yml`: turn `frontend_build` on with `enabled: true`, list the paths that need building (one theme here, but a plugin could join it), and for each path give a Node version and a build command. Push, and the workflow log shows npm doing its work. He's clear about the edge: this is a build step, not a Node runtime. If your site needs Node while serving pages, this isn't that. But if the only reason you have a separate GitHub repo and a CI pipeline is to run one npm command and push the result to Pantheon, you can now delete that pipeline and use the native GitHub integration instead. ## 📰 Newsletter **One YAML block replaces your build CI.** Pantheon's Chris Boulton spent 3 minutes this week on a feature he says slipped past him: frontend builds, announced in July for Next.js, also work for WordPress and other PHP sites. If your theme or plugin runs `npm run build`, add a `frontend_build` block to `pantheon.yml` with `enabled: true`, list the directories to build, set a Node version and a command per directory, and Pantheon compiles your assets on every push. The npm output lands in the workflow log where you can read it. The practical payoff is for the two-repo crowd: a GitHub repo, a CI job that builds, and a Pantheon repo the CI pushes to. That collapses to one repo and the native GitHub integration. The honest caveat, stated in the video: this is build time only. No Node at runtime. Full disclosure for this newsletter's readers: this is Pantheon describing Pantheon. The claim is easy to test on any site you have, and the release note is public. Links: [the video](https://www.youtube.com/watch?v=bwOmZEgXKTU), [release note](https://docs.pantheon.io/release-notes/2026/07/frontend-asset-builds), [pantheon.yml reference](https://docs.pantheon.io/pantheon-yml). ## ✅ Action items #### DevRel - Developer advocacy: reproduce the demo on a fresh WordPress site with a block theme that has a real `npm run build`, screenshot the workflow log section, and publish a 400-word companion post with the exact YAML. The video shows the block but never reads the sub-keys aloud. - Education: add a 10-minute "delete your build CI" segment to the next office hours, using the two-repo pattern at 00:02:15 as the before state. - Developer experience: check that docs.pantheon.io/pantheon-yml has a copy-pasteable WordPress theme example, a plugin example with two paths, and a "what this is not" note matching 00:02:15. File gaps as docs issues. - Developer marketing: title the follow-up around the constraint ("build time, not runtime") so the feature isn't oversold to teams wanting SSR. - Community management: watch the video's comments for uncovered use cases, as the presenter requested at 00:02:58, and route them to the roadmap with a link back. - Internal/external: ask product whether build failure halts the deploy and whether paths accept globs; both are unanswered in the video and will be the first two questions in any talk. #### OSPO - Policy and governance: no direct action from this source; nearest relevance is whether platform-side builds change where a project's build reproducibility is documented. - License compliance: a platform-run `npm install` pulls dependencies at deploy time. Confirm the lockfile is honored (`npm ci` vs `npm install`) so license scans on the repo match what ships. - Security management: same mechanism. Dependencies resolved at build time on the platform need the same provenance checks a local build gets; ask whether the build environment has network egress restrictions. - Software inventory: if builds move to the platform, the SBOM source of truth is the committed lockfile, not a CI artifact. Note that. - Developer support: no direct action; nearest relevance is a one-line guidance note on lockfile hygiene for sites adopting the feature. - Community engagement: none from this source. - Strategic alignment: none from this source. #### Community - Maintainers: theme and plugin maintainers who ship compiled assets can stop committing `dist`. Worth one line in a maintainers' channel. - Contributors: a contributor who only has to push source, not built output, has a shorter first-PR path. Update contributing docs for any Pantheon-hosted community site. - Sponsors: none from this source. - Ecosystem: none from this source; nearest relevance is other hosts' equivalent features for comparison. #### WordPress - Core: none. This is host tooling. - Core Performance: none directly; compiled assets are the same bytes wherever they're built. - Core AI: none. - **Core Program Team:** none. - Mobile: none. - Playground: none; Playground has no deploy step. - Community: none. - Training: a lesson on "where does the build run" (local, CI, host) would use this as the host example. - Marketing: none. - Support: Pantheon-hosted sites asking why `dist` is missing after a GitHub push are the likely support pattern; a KB entry pointing at the `frontend_build` block pre-empts it. - Design: none. - Documentation: none for WordPress.org docs; the relevant docs are Pantheon's. - Photos: none. - TV: none. - Polyglots: none. - Accessibility: none from this source. - Meta: none. - CLI: none; the video doesn't mention Terminus. - Hosting: the Hosting team's cross-host checklist could add "host-side asset builds" as a capability row; Pantheon now has one for PHP sites. - Tide: none. - Openverse: none. - Themes: theme authors distributing source-only themes to Pantheon customers can document the `frontend_build` block in their README. - Plugins: same as Themes, and the video explicitly names a plugin as a second path (00:01:33). #### The WPOCC - Programs: none from this source. - Projects: if The WP Open Community Collective hosts any project site on Pantheon, this removes a CI dependency from that project's release process. - Funding experiments: none from this source. ### FAIR - Technical independence: a host-run build is a convenience with a dependency cost. Any FAIR-related site adopting it should keep the build runnable locally so the host isn't the only place the site can be built. - Policies and covenants: none from this source. - Productized governance artifacts: none from this source; nearest relevance is a "build location" field in an operator scorecard. ## 🧪 Hypotheses 1. A WordPress theme with a standard `npm run build` script deploys with compiled assets on Pantheon after adding only a `frontend_build` block to `pantheon.yml`, with zero changes to the theme source. 2. Two paths (a theme and a plugin) in one `frontend_build` block each run their own build command in a single deploy, as the presenter implies at 00:01:33. 3. A failing npm build blocks the deploy rather than shipping the previous `dist`, which the video never states. 4. Replacing a GitHub Actions build-and-push workflow with the native GitHub integration plus `frontend_build` cuts deploy wall-clock time, because one hop (CI to Pantheon push) is removed. 5. The platform build honors `package-lock.json` exactly (equivalent to `npm ci`), so the deployed dependency tree matches the committed lockfile. ## 📊 Methodology - **H1.** Fork a block theme with a Vite or webpack build. Gitignore `dist`. Add the block per the docs page. Push to a Pantheon dev environment. Check that `dist` exists in the deployed filesystem and that the workflow log contains the npm output described at 00:02:15. - **H2.** Add a second path for a plugin with a different build command. Confirm both sections appear in one workflow log and both `dist` folders exist. - **H3.** Introduce a syntax error in the theme's entry file. Push. Record whether the deploy status is failed and whether the previous compiled assets remain served. - **H4.** Time 5 deploys through the old GitHub Actions path and 5 through the native integration, measured from `git push` to the dashboard reporting the environment updated. Report median and range. - **H5.** Pin a dependency in `package.json` to a range and lock it to a specific older version in the lockfile. After deploy, inspect `node_modules/<pkg>/package.json` in the build output (or the log) for the resolved version. - **Controls.** Same site, same environment, same Node version across runs. Record the docs page version consulted, since key names come from it. ## ❓ Questions - What are the exact sub-key names for Node version and build command under a path entry? The transcript never spells them. - Which Node versions are supported, and what happens if the requested version is unavailable? - Does a build failure halt the deploy, or does the site go live without compiled assets? - Do paths accept globs, or must each build directory be listed literally? - Is `bun` supported as a build runtime, or is it only mentioned as a dependency you no longer need to vendor (00:00:06)? - Does the build environment have network egress, and are private npm registries supported? - Does `frontend_build` run on every environment (dev, multidev, test, live) or only on code push to dev? - Is the build output cached between deploys, and does `node_modules` persist? ## 🔮 Future research - **Build reproducibility across hosts.** Compare Pantheon's `frontend_build` with equivalent features from other WordPress hosts on the same theme: config surface, Node version pinning, lockfile handling, failure behavior. A table would serve the Hosting team's cross-host checklist. - **Supply-chain posture of host-side builds.** When `npm install` runs on the host at deploy time, who controls registry access, and what logging exists for resolved packages? Unaddressed in the video and relevant to any OSPO review. - **Migration cost.** Count how many existing Pantheon WordPress sites use a GitHub Actions build-and-push pattern, and estimate the pipeline lines deleted per migration. A DevRel case study needs that number. - **Failure modes.** Catalog what a broken build looks like from the dashboard, from the workflow log, and from the site. The video shows the happy path only. ## 💡 Implications - **Practice.** Stop committing compiled assets on Pantheon-hosted PHP sites. Source plus lockfile plus a YAML block is the new minimum. - **Policy.** Teams with a "builds run in our CI" rule need to decide whether a host-run build satisfies it. The lockfile becomes the compliance artifact. - **Security.** Dependency resolution moves from a CI runner you control to a build environment the host controls. Ask the questions in ❓ before adopting on a regulated site. - **Education.** The two-repo workaround at 00:02:15 is a common pattern that many teams inherited without knowing why. This video is a clean teaching moment for "where should a build run." - **Funding models.** A CI minute budget spent only on `npm run build` goes to zero. Small agencies on free CI tiers notice this first. ## 🧠 Learning styles assessment - **Reading level estimate.** Flesch-Kincaid Grade Level on the transcript body: approximately grade 8. Flesch Reading Ease near 65: conversational sentences, but `pantheon.yml`, `dist`, lockfile, and CI assume a working developer. #### 👀 Visual learners - Present: screen recording of the theme directory, `package.json`, `pantheon.yml`, and the workflow log, per the narration. - Improve: no diagram of the before (GitHub, CI, Pantheon) versus after (GitHub, Pantheon) flow. One slide would carry the 00:02:15 argument better than words. #### 🔊 Aural learners - Present: clear single-voice narration, no music bed reported in the captions. - Improve: the YAML sub-keys are never read aloud. Speaking each key name once would make the audio self-sufficient. #### 🗣️ Verbal learners - Present: plain definitions by example ("the dist folder is the compiled CSS and JS"). - Improve: "native GitHub integration" and "workflow log" are Pantheon terms used without a one-clause definition. #### 🧩 Kinesthetic learners - Present: a reproducible recipe in three steps. - Improve: no repo link for the demo theme. Publishing it would turn a 3-minute watch into a 10-minute lab. #### 🧠 Logical learners - Present: clear scope statement (build time, not runtime) at 00:02:15. - Improve: no statement of failure behavior or ordering when multiple paths exist. #### 🧑‍🤝‍🧑 Social learners - Present: explicit ask for comments and roadmap submissions at 00:02:58. - Improve: no community channel named (Slack, forum) for follow-up discussion. #### 🧘‍♀️ Solitary learners - Present: short, self-contained, linked docs in the description. - Improve: a one-line self-check ("do you have a separate repo only to run npm build?") would convert the pitch into a personal audit. #### 🌿 Naturalistic learners - Present: nothing explicit. - Improve: removing a CI hop removes compute; a sentence on fewer build runs per deploy would land with this group. ## 📊 Accessibility assessment #### Screen reader semantics - Present: YouTube supplies player landmarks; the description carries the three doc links as real links. - Improve: the `pantheon.yml` contents are shown on screen but the sub-keys aren't spoken. WCAG 2.2 AA 1.1.1 (Non-text Content) is not met for that block; speaking the keys or putting the block in the description fixes it. #### Keyboard navigation - Present: the player is keyboard operable by default. - Improve: nothing in the content adds barriers. 2.1.1 passes via the platform. #### Contrast and readability - Present: unverifiable from a transcript. - Improve: editor and terminal text at default size is the usual failure; zoom into the YAML block during the 00:01:33 segment to stay clear of 1.4.3 (Contrast Minimum) on small screens. #### Text resizing and reflow - Present: captions resize independently of the frame. - Improve: on-screen code does not reflow. 1.4.4 (Resize Text) and 1.4.10 (Reflow) fail for burned-in text; the description snippet is the remedy. #### Media and captions - Present: auto-generated captions exist. - Improve: captions render `package-lock.json` as "package.lock.json," `frontend_build` as "front end build," and possibly the presenter's surname. For a config tutorial, wrong key spellings in captions are a 1.2.2 (Captions, Prerecorded) failure in substance. Human-corrected captions for 3:19 of audio is a 10-minute fix. #### Forms and interactions - Present: none in the video. - Improve: not applicable in-video; the roadmap site it points to should meet 3.3.2 (Labels or Instructions). #### Standards reference - Primary gaps against WCAG 2.2 AA: **1.2.2** (caption accuracy on technical terms), **1.1.1** (config shown, not spoken), **1.4.4 / 1.4.10** (burned-in code). No chapters on a 3-minute video is acceptable; the five natural segments above would still help. ## 🌍 DEIB assessment #### Cultural breadth - Present: the demo subject (Critical Role, a US web series) is a personal-interest example, not a cultural claim. - Improve: a second example from a non-entertainment domain (a municipal site, a nonprofit) would widen the audience who sees themselves in it. #### Inclusive language - Present: "Hello people of the internet" as the greeting; second person throughout; no exclusionary terms. - Improve: "activates the magic" (00:01:33) is a small idiom; "activates the feature" reads the same in every locale. #### Neurodiversity support - Present: one idea per segment, predictable order (what, demo, config, limit, close). - Improve: an on-screen checklist of the three config steps would reduce working-memory load. #### Representation - Present: one named presenter, self-identified by role. - Improve: none needed for a 3-minute tip; a customer voice in a follow-up would add a non-vendor perspective. #### Psychological safety - Present: the presenter models not knowing ("it completely zipped by my brain"), which lowers the bar for viewers to admit the same. - Improve: nothing needed. The self-deprecating frame is the strongest DEIB feature of the video. ## ✅ Logical validity #### Strong reasoning - **Deductive, 00:02:15.** If the host runs `npm run build` on push, then a separate CI whose only job is `npm run build` and push is redundant. Valid; the conclusion follows from the feature's stated behavior. - **Scope discipline, 00:02:15.** Stating what the feature is not (a Node runtime) before stating the benefit prevents the most likely misreading. This is a concession against the vendor's interest. - **Demonstration, 00:00:49 to 00:02:15.** The claim is shown end to end on a real site: source, config, push, log. For a config feature, a working example is the appropriate evidence. - **Extension by example, 00:01:33.** Generalizing from one theme path to "a plugin that has a different build process" states the rule (one entry per build root) rather than leaving the viewer to infer it. #### Fallacies - None found. Checked for: unsupported quantification (no numbers are claimed), appeal to authority (the role is stated as identification, not as proof), false dilemma (the two-repo pattern is described as one workaround among "build tools, CI, or other workarounds," not the only alternative), and undisclosed interest. On the last: the video is on Pantheon's channel by a Pantheon employee about a Pantheon feature, and the presenter identifies himself and his employer in the first sentence. The interest is disclosed by context. Readers should still treat every claim as vendor-stated until reproduced. - **Unspoken specifics, 00:01:33.** Not a fallacy but a gap: the exact YAML sub-keys are shown, not spoken, so the transcript alone can't reproduce the config. Fix: read the block aloud or put it in the description. #### Tone of voice - Casual, first-person, self-deprecating ("today I learned something that I probably should have already been aware of," 00:00:06). Second-person instruction in the config segment ("you must add enabled true"). Sign-off is the channel's stock line, "we'll see you on the internet" (00:02:58). No superlatives about the feature; the only enthusiasm is "the magic" at 00:01:33. The register is a colleague showing a colleague, which suits a TIL. ## 🛡️ DARVO analysis Not applicable to this source. DARVO (Deny, Attack, Reverse Victim and Offender) describes responses to accusation. This is a product tip with no accuser and no dispute. For completeness: **Deny**: nothing is denied; the presenter volunteers a limitation at 00:02:15 and admits his own oversight at 00:00:06. **Attack**: no competitors, critics, or prior workflows are disparaged; the two-repo pattern is described neutrally. **Reverse victim/offender**: no such move. Emotional register is light self-deprecation; no defensive rhetoric appears. ## 🎯 Conclusion The tip reduces to one config block. In `pantheon.yml`, add `frontend_build`, set `enabled: true`, list the directories that need building, and for each give a Node version and a build command (default `npm run build`). Push, and the npm output appears in the workflow log (00:02:15). The presenter's own surprise at 00:00:06 is the point: a feature announced in July for Next.js has applied to PHP sites all along. Two things to hold onto when reusing this. First, the transcript never spells the sub-key names; the `pantheon.yml` docs page does, so cite that and not the video for exact syntax. Second, the scope line at 00:02:15 is the sentence that prevents misuse: build time only, no Node at runtime. That should be in the first paragraph of any doc or talk built from this. **Next steps for readers:** if you maintain a GitHub repo whose CI exists only to run `npm run build` and push to Pantheon, reproduce H1 in the Methodology on a dev environment this week. Record the deploy time before and after. Then delete the pipeline. And because this is the employer's own content, run the check before writing it up as fact. ## 🔄 Refactor Appendix — TIL Frontend Builds for PHP sites on Pantheon > Density: 2–5 Literature atoms (H3 pad), 0–3 Permanent candidates (H4 pad). > Emitted: 2 Literature, 1 Permanent. Resonance filter applied: the demo-site > description (Critical Role, Feywild mode) was dropped as incidental to the feature. > > Konik claim-header rules: present tense, declarative, ≤10 words, searchable, unique. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Split Pad #### [H1] pantheon.yml frontend_build block enables host-side npm builds > [!quote] [00:01:33] > To enable front end build, you need to add the front end build to your pantheon.yml. **Context & use**: - 00:01:33, the config walkthrough; followed by `enabled true`, a list of paths, and per-path Node version and build command. - Captions render the key as "front end build"; the description spells it `frontend_build`. Cite the docs page for sub-key names. **Tags**: #xref #share <!-- atomicity: 1 idea ✓ --> #### [H2] Frontend builds run at build time, not site runtime > [!quote] [00:02:15] > Now, this doesn't solve situations where you might need an actual node binary in these site runtime to do things more on the fly, **Context & use**: - 00:02:15, the scope statement placed before the benefit claim. - The one sentence that prevents the feature from being pitched as SSR or a Node runtime. Lead with it in any doc or talk. **Tags**: #xref #share <!-- atomicity: 1 idea ✓ --> ### 🧠 Atomic Split Pad #### [P1] A build step belongs where the deploy happens **Claim** (one sentence, Courtney's voice): When a CI pipeline's only job is to compile assets and push them to the host, the host running that compile removes a repo, a pipeline, and a failure point at once. **Evidence pointer**: [[#H1]] · [[#H2]] **Scope & conditions**: Holds when the build is a pure function of the committed source and lockfile, and the host pins the runtime version. Breaks when the build needs secrets or private registries the host can't reach, when the site needs Node at runtime, or when compliance requires builds to run on infrastructure the team controls. **Links**: - [[Where should a build run]] — because extends - [[Two-repo deploy pattern]] — because contrasts on number of hops - [[Pantheon GitHub integration]] — because applies-in Pantheon-hosted WordPress and Drupal <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Confirm the presenter's surname spelling and title against Pantheon's staff listing before crediting; captions give "Chris Boulton, senior manager of developer relations". https://www.youtube.com/watch?v=bwOmZEgXKTU #fleeting #inbox - [F2] Pull the exact `frontend_build` sub-key names (Node version, build command, paths) from https://docs.pantheon.io/pantheon-yml; the transcript never spells them #fleeting #inbox - [F3] Open question: does a failing npm build halt the deploy or ship stale `dist`? Not addressed at 00:02:15 #fleeting #inbox - [F4] Docs gap check: does the pantheon.yml page have a two-path (theme plus plugin) example, as implied at 00:01:33? #fleeting #inbox - [F5] Talk seed: "delete your build CI" using the two-repo before state at 00:02:15 #fleeting #inbox #articleseed ### → Things 3 (max 2 actions) - [ ] Reproduce the frontend_build demo on a Pantheon dev site with a block theme, capture the workflow log section, and note the exact YAML keys from the docs page — DevRel docs, 45 min #things - [ ] Ask product whether a failed frontend build halts the deploy and whether paths accept globs — before the next office hours #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/TIL Frontend Builds for PHP Sites on Pantheon.md|TIL Frontend Builds for PHP Sites on Pantheon by Pantheon]] ## Highlights - [00:01:33] Nothing weird, a build script, some watch scripts, clean, all the basic sort of stuff you'd expect. But let's go higher up and take a look at the pantheon.yml, because that's what activates the magic. To enable front end build, you need to add the front end build to your pantheon.yml. Underneath that, you must add enabled true to actually turn it on. And then you can have any number of paths listed below. For me, I just have the one theme path, but I could have a plugin that has a different build process that I could add here as well. I also have a parameter for the node version and the build command. So, if my command wasn't npm run build and was like npm run launch or something, I just change that here and that's what gets [00:02:15] run. When I push my code up to the site, the workflow log exposes the full process, including this section right here that shows the actual npm build process. Now, this doesn't solve situations where you might need an actual node binary in these site runtime to do things more on the fly, but if you're currently using build tools, CI, or other workarounds to just do npm run build, now you can do that natively by making a few small changes in your Pantheon YAML file. This also means that you can use our native GitHub integration, triggering these builds on commits to that rather than keeping two separate Git repositories, one on Pantheon and a separate one on GitHub that pushes to ([View Highlight](https://read.readwise.io/read/01m3a9brs90f8jb4rpxh9q2cxp)) - Note: [H1] pantheon.yml frontend_build block enables host-side npm builds - Tags: atom/literature/h1