Practical Guide to Headless WordPress  🔗 **Source:** [Practical Guide to Headless WordPress](https://www.youtube.com/watch?v=CUiHnde9BmE) > [!note]+ Document Notes > tags: [headless-wordpress, nextjs, wordpress-rest-api, ai-assisted-coding, content-caching, custom-post-types] > author: LearnWebCode > source: LearnWebCode (YouTube) > reference: https://www.youtube.com/watch?v=CUiHnde9BmE > date created: 2026-10-12 11:15 > > > [!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: Practical Guide to Headless WordPress (Next.js) > <!-- 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--practical-guide-to-headless-wordpress-nextjs) ## 📝 Summary - **What happened.** LearnWebCode published a 47:30 tutorial on 2026-10-12 that builds a Next.js front end on top of a WordPress back end, then deploys it to Cloudways Velocity. The narrator writes almost no code by hand. Plain-English prompts to a VS Code AI agent produce the pages, and the narrator fixes problems by prompting again. The auto-transcript garbles file and tool names: the secrets file `.env` appears as "NV", "inv" and "yourv", "Next.js" appears as "Nex.js" and "NextJS", and "git config --global user.name" is half-mangled at 00:39:11. - **The claim.** Headless means WordPress keeps the editing experience and loses its public front end. A separate Next.js app reads WordPress through the REST API, writes back through it (a contact form that creates private `contacts` posts), caches responses on the Next.js server for 5 minutes, and never needs a rebuild when editors change content. - **The mechanism.** Steps in order: install Node.js, VS Code and Git; run `npx create-next-app .` with custom options (no TypeScript, no linter, Tailwind yes, App Router yes, cache components yes, AGENTS.md yes); put `WP_URL` in `.env`; prompt the agent for pages; add `WP_USERNAME` and `WP_APPLICATION_PASSWORD` for write access; push to a private GitHub repo with `.env` git-ignored; import the repo into Cloudways Velocity and re-enter the environment variables there. - **Why it matters.** The tutorial shows the full loop from empty folder to live site for an editor-friendly stack, and it covers three failure points that trip up first projects: Next.js `<Link>` and `<Image>` versus raw HTML, internal links inside WordPress post content that point back at the WordPress domain, and secrets handling. - **Key stakeholders.** Content editors who keep the WordPress admin, front-end developers who own the Next.js app, a separate WordPress theme codebase that locks block types (linked in the description), Cloudways (sponsor and hosting demo), GitHub (repo host and Copilot-style agent login), and the plugin authors behind Advanced Custom Fields and Secure Custom Fields. - **Risks and tradeoffs.** The application password acts "as if you were the admin" (00:27:36), which is broader than a form-submission job needs. The "secret cat name" check is a spam filter, not authentication. The 5-minute cache is a stale-content window, and the narrator never shows webhook-triggered revalidation, draft preview, or SEO metadata. The video is sponsored: Cloudways appears at 00:02:11, 00:37:44 and 00:46:27, with a 30% promo code. Cloudways claims (excellent security, speed) carry no numbers. - **Bottom line.** It's a practical, honest walkthrough of the happy path with the agent's mistakes left in. Treat it as a starting skeleton, then harden the credentials, add on-demand revalidation, and replace the secret-question trick before anything carries real traffic. ## 📖 Main content **What headless means.** The narrator defines it at 00:01:27: WordPress stays as the editing back end, and its public presentation (the theme "head") is replaced by anything else. The demo site has pages (About us, Our history), a `team members` custom post type (photo, job title, favorite color, favorite food, and a "best friend" relationship to another team member), blog posts, and a contact form that writes new `contacts` entries back into WordPress. **Prerequisites (00:02:54 to 00:04:21).** A WordPress install, Node.js from nodejs.org, and VS Code. A free github.com account unlocks the VS Code agent sidebar. The narrator verifies Node with `node --version` in the VS Code terminal (Cmd+J or Ctrl+J toggles the panel). **Scaffolding (00:05:03 to 00:07:59).** The narrator reads the Next.js "Installation" docs page, picks npm, and swaps the project name for a period so the app installs into the current folder: `npx create-next-app .`. Answers given: customize settings; TypeScript no; linter none; React Compiler no; Tailwind yes; `src/` directory no; App Router yes; cache components yes (default); customize import alias no; include `AGENTS.md` yes ("important that you say yes"); anonymous feedback no. `npm run dev` then serves `localhost:3000`. **Secrets (00:07:59 to 00:09:24).** A `.env` file holds `WP_URL=https://your-domain` with no trailing slash. The narrator's stated one takeaway: never put passwords, API keys or tokens in any other project file. **WordPress side (00:10:50 to 00:13:44).** Custom post types and field groups come from Advanced Custom Fields (ACF) or Secure Custom Fields (SCF). Two switches matter: the field group's group settings need "Show in REST API", and each custom post type needs "Show this custom post type in the REST API." Without them the Next.js app can't fetch the fields. The `contacts` post type is set private so only administrators see submissions. **The prompt-and-fix loop (00:13:44 to 00:25:21).** The first prompt is one paragraph: use WordPress as a headless CMS, read `WP_URL` from `.env`, build a minimal home page, a nav with About us, Our history, Team members and News, pull each page from the matching WordPress page or post type, render team members as an image grid with name and job title layered over the photo, and render news as a post list with detail pages. Follow-up prompts then correct what the agent got wrong or missed: 1. Use the Next.js `Link` component instead of `<a>` (already correct on this run). 2. Rewrite links inside post and page content: same-domain links stay on the Next.js site, external links (the Google example) stay external. The narrator hints at the `html-react-parser` package (transcript: "HTML React parser"). 3. Use the Next.js `Image` component instead of `<img>` for content and featured images. The check is to open an image in a new tab and see an optimized Next.js URL instead of the WordPress URL. 4. Show favorite color, favorite food and the best-friend link on the detail screen, with a graceful fallback when there is no best friend. 5. Fix missing styling: the agent's preview showed styles that the real browser didn't. A rebuild and restart didn't help. A direct, polite prompt describing the mismatch fixed it. 6. Paste the Next.js dev warning verbatim (URL data outside Suspense, which "may prevent the navigation from being instant") and ask for a fix. Repeat for blog post detail pages. **Writing back to WordPress (00:25:21 to 00:31:14).** Read-only access is the public REST API. Creating contacts needs authentication, so the narrator adds `WP_USERNAME` and `WP_APPLICATION_PASSWORD` to `.env`. The application password comes from Users, your profile, Application Passwords; WordPress shows it once. The form prompt asks for name, email, phone and message mapped to custom fields, a server-side function (not browser code) that creates a `private` post, and a `SECRET` environment variable ("meows a lot") for a case-insensitive question: the server never calls WordPress if the answer is wrong. The first live test fails with a generic error; the narrator then finds a wrong pasted application password was the cause ("WordPress rejected the site's application password"), and the new entry appears in the Contacts list as private. **Polish, caching and security (00:31:14 to 00:36:17).** Header and footer styling, hover states, spacing under images, and a hero animation arrive by prompt. The caching prompt asks for idiomatic Next.js caching with a refresh interval the narrator guesses at "maybe 5 minutes". A security prompt asks for a contact-page audit and a check that no `.env` value reaches client-side code. The demo shows "loading article" on first load, then instant loads, in Chrome and then Firefox, proving the cache sits on the Next.js server and not in the browser. **The WordPress theme (00:36:17 to 00:37:44).** A separate codebase, linked in the description, locks the editor to paragraph, image, heading and bold-list blocks, adds custom columns to the Contacts list, and renders an intentionally empty page for anyone who visits the WordPress site directly. The narrator calls that "a different video for another day". **Deploy (00:37:44 to 00:44:19).** Install Git (check with `git --version`), set `git config --global user.name` and `user.email`, create a private GitHub repository, then `git remote add origin ...`, `git add -A`, `git commit`, `git push origin main`. `.env` stays out of the repo because Next.js already put it in `.gitignore`. In Cloudways Velocity the narrator adds an application, connects GitHub, selects the repo, accepts the auto-detected Next.js server-side rendering defaults, re-enters the four environment variables by hand, and deploys. First deploys take a minute or two longer than later ones. **Live verification (00:44:19 to 00:47:30).** The live site renders all pages and the contact form creates a WordPress entry. An edit to the About us page shows up on the live site within the 5-minute window (the narrator says luck helped, since it appeared quickly). Images are cached too. The closing argument: a slow or cheap WordPress host matters less because Next.js absorbs reads. **Contested or unverifiable in this source.** The 5-minute interval is whatever the agent chose; the transcript never shows the code. "Excellent security, excellent speed and performance" for Cloudways Velocity has no numbers. "Faster" claims for `Link` and `Image` are demonstrated by feel, not measured. The agent's output is non-deterministic, as the narrator says at 00:15:59: "yours is going to look different than mine." ## 🗒️ Notes #### ⏱️ [00:00:00](https://www.youtube.com/watch?v=CUiHnde9BmE&t=0) What headless means - Pitch: keep WordPress for editing pages, posts and a `team members` type, and drop the PHP theme as the public site. - The demo has two directions: Next.js reads WordPress content, and the contact form writes new entries back. - Definition: WordPress for the back end only, with the presentation replaced by any stack. #### ⏱️ [00:02:11](https://www.youtube.com/watch?v=CUiHnde9BmE&t=131) Sponsor and prerequisites - Sponsor: Cloudways Velocity for hosting Node.js apps, priced per server instead of per app, with a 30% code for the first three bills. - Prerequisites: a WordPress install, Node.js (nodejs.org), VS Code. Create an empty folder and open it in VS Code. - VS Code's free tier includes a monthly allotment of agentic coding usage. #### ⏱️ [00:04:21](https://www.youtube.com/watch?v=CUiHnde9BmE&t=261) Scaffold the Next.js project - Open the VS Code terminal (Cmd+J or Ctrl+J) and confirm Node with `node --version`. Restart VS Code or the computer if the command isn't found. - Find the command on the Next.js docs: Get started, Installation, npm tab. Replace `my-app` with `.` to use the current folder. - Run `npx create-next-app .` and decline the defaults to customize. #### ⏱️ [00:05:47](https://www.youtube.com/watch?v=CUiHnde9BmE&t=347) Option choices and first run - Choices: no TypeScript, no linter, no React Compiler, Tailwind yes, no `src/`, App Router yes, cache components yes. - `npm run dev`, then `localhost:3000` shows the default site. > [!quote] [00:07:13] > Would you like to include agents a markdown file with guidance for the coding agent? #### ⏱️ [00:07:59](https://www.youtube.com/watch?v=CUiHnde9BmE&t=479) The .env file and agent login - `.env` holds `WP_URL` with the site address and no trailing slash. The narrator warns not to type the sample `sky color` values. - Sign in to the VS Code agent sidebar with a free github.com account. The narrator dictates prompts by voice. > [!quote] [00:08:41] > So, don't ever include sensitive values like passwords or tokens or API keys in any of your other files in your entire project. #### ⏱️ [00:10:50](https://www.youtube.com/watch?v=CUiHnde9BmE&t=650) The WordPress setup: custom post types and fields - The Tom the Turtle edit screen shows a custom UI: job title, favorite color, favorite food, biography, featured image and a "best friend" relationship to other team members. - Source of the custom UI: Advanced Custom Fields or Secure Custom Fields. Field groups show only for a chosen post type, here `team member`. - Both field group settings and the post type need REST API exposure turned on. > [!quote] [00:12:18] > Without this, nextJS will not be able to fetch all of the data that it needs. #### ⏱️ [00:13:44](https://www.youtube.com/watch?v=CUiHnde9BmE&t=824) The first prompt - Prompt content: headless architecture, `WP_URL` in `.env`, minimal home page, nav of About us, Our history, Team members, News. - Page mapping: About us and Our history map to WordPress pages; Team members maps to the custom post type; News maps to posts. - Team members: image grid, name and job title layered on the photo, whole card clickable to a detail page. - The narrator tells viewers to adapt the prompt to their own data shape, since their post types and forms differ. #### ⏱️ [00:15:59](https://www.youtube.com/watch?v=CUiHnde9BmE&t=959) Review pass 1: links and internal links - Check 1: no raw `<a>` for navigation. Use the Next.js `Link` component, which swaps content without a full reload. - Check 2: links inside WordPress content to the "Our history" page open the WordPress site. The fix prompt compares the link domain with `WP_URL`, keeps same-domain links in Next.js, and leaves external links alone. > [!quote] [00:16:42] > It's because it's not even performing a full page reload. #### ⏱️ [00:18:51](https://www.youtube.com/watch?v=CUiHnde9BmE&t=1131) Review pass 2: images - Symptom: right-click, open image in new tab, and the address is the WordPress URL. - Fix prompt: use the Next.js `Image` component for content images and featured images. After the fix, the image URL is a Next.js-served one. #### ⏱️ [00:20:19](https://www.youtube.com/watch?v=CUiHnde9BmE&t=1219) Team member detail screen and the styling mismatch - New prompt adds favorite color, favorite food and a best-friend link below the biography, with nothing shown when the field is empty. - Data and relationships work (Tom links to Bob and back), but the new section is unstyled in the browser while the agent's Playwright preview shows styles. - Two failed self-fixes: `npm run build` plus restart, then a hard refresh. > [!quote] [00:23:12] > You just got to be direct and firm and polite with the AI and it fixed it. #### ⏱️ [00:23:55](https://www.youtube.com/watch?v=CUiHnde9BmE&t=1435) Suspense warnings - Next.js dev overlay reports "URL data outside of suspense", which may keep navigation from being instant. - Fix: paste the exact message into the agent, tell it the port-3001 preview was closed, and repeat for the blog post detail page. #### ⏱️ [00:25:21](https://www.youtube.com/watch?v=CUiHnde9BmE&t=1521) Credentials for write access - The project has guest-level REST access only. Creating `contacts` posts needs authentication. - Add `WP_USERNAME` and `WP_APPLICATION_PASSWORD` to `.env`. Create the password under Users, your user, Application Passwords. WordPress displays it once. > [!quote] [00:26:07] > It's not going to let us in without some sort of password. > [!quote] [00:27:36] > But the application password can be easily revoked, right? #### ⏱️ [00:27:36](https://www.youtube.com/watch?v=CUiHnde9BmE&t=1656) The contact form prompt - Page: Contact us, with name, email, phone and message mapped to custom fields on the `contacts` post type. - Server-side function creates a post with status `private`, because it holds a phone number and email. - Add a `SECRET` variable ("meows a lot") and a question field. Compare case-insensitively on the server. A wrong answer never reaches WordPress. #### ⏱️ [00:29:47](https://www.youtube.com/watch?v=CUiHnde9BmE&t=1787) Testing the form - Wrong secret: the form says the answer was wrong and no request is made. - Right secret: generic "couldn't send" error, then a clearer "WordPress rejected the site's application password" message after a prompt for better errors. > [!quote] [00:31:14] > The AI was doing everything right. - A mistyped application password was the cause. After the fix, the private entry appears under Contacts in the WordPress dashboard. #### ⏱️ [00:31:14](https://www.youtube.com/watch?v=CUiHnde9BmE&t=1874) Design polish - Prompts for header and footer styling, hover states on nav, margin below content images, and a fade or drop-in hero animation. - The agent claims styling changes that don't render once, and a follow-up prompt asks it to investigate. #### ⏱️ [00:33:24](https://www.youtube.com/watch?v=CUiHnde9BmE&t=2004) Caching and security prompts - Caching prompt: idiomatic Next.js caching with a refresh interval the narrator suggests as about 5 minutes, so repeat visitors don't trigger repeat WordPress fetches. - Security prompts: audit the contact page, and confirm no `.env` value reaches client-side code. Secrets belong only in server functions. #### ⏱️ [00:34:51](https://www.youtube.com/watch?v=CUiHnde9BmE&t=2091) Why the server-side cache matters - First load of a detail page shows "loading article". A manual refresh then loads instantly. - Opening Firefox after Chrome shows the same instant load, so the cache isn't per browser. > [!quote] [00:34:51] > it's not a per user or per browser cache. It's cached on the Nex.js server side. - Editors changing content wait at most 5 minutes. No rebuild and no redeploy. #### ⏱️ [00:36:17](https://www.youtube.com/watch?v=CUiHnde9BmE&t=2177) The WordPress theme and admin lockdown - Editors get paragraph, image, heading and bold-list blocks only. Other blocks and patterns are removed. - Custom columns (email, phone, message) appear in the Contacts list. - The WordPress site itself shows an intentionally empty headless page. The theme is a separate repo, linked in the description. #### ⏱️ [00:37:44](https://www.youtube.com/watch?v=CUiHnde9BmE&t=2264) Git and GitHub - Stop the dev server (Ctrl+C), then `git --version`. Install from git-scm.com if the command isn't found. - Set `git config --global user.name` and `user.email` with the viewer's own values. - `.gitignore` already excludes `.env`; the narrator says to exclude it even from private repos. > [!quote] [00:40:41] > still never ever ever want to include yourv file. - Steps: new private GitHub repo, copy the `git remote add origin` line, `git add -A`, `git commit`, `git push origin main`. #### ⏱️ [00:42:10](https://www.youtube.com/watch?v=CUiHnde9BmE&t=2530) Deploy to Cloudways Velocity - Add an application to an existing Velocity server, connect GitHub the first time, and pick the repository. - Cloudways auto-detects a Next.js server-rendered app; the narrator keeps every default. > [!quote] [00:42:54] > recognize just by the files that this is a NextJS project. - Environment variables go in by hand, one name and value at a time: all four values from `.env`. First deploy takes an extra minute or two. #### ⏱️ [00:44:19](https://www.youtube.com/watch?v=CUiHnde9BmE&t=2659) Live checks, caching demo and close - Live site: About us, Our history, team members, news and the contact form all work. A live submission appears in the WordPress dashboard. - Edit test: a new paragraph on About us appears on the live site within the window, which the narrator calls lucky timing. - Images are cached as well, so a team member photo loads instantly in a second browser. - Closing pitch: a slow WordPress host is acceptable because Next.js only asks for data every 5 minutes and the public front end stays fast. The narrator thanks Cloudways again and ends the video. ## 📚 References The transcript itself contains no links; the following come from the video description or are primary sources for named entities. - [Practical Guide to Headless WordPress (Next.js): LearnWebCode](https://www.youtube.com/watch?v=CUiHnde9BmE): the source video, 47:30, uploaded 2026-10-12. - [brads-headless-classic-theme](https://github.com/LearnWebCode/brads-headless-classic-theme): from the description: the example WordPress theme that locks block types and adds custom columns for the Contacts post type. The narrator points to it at 00:37:01. - [Cloudways Velocity](https://www.cloudways.com/en/velocity.php): sponsor and the Node.js host in the demo. The description lists an affiliate link and the promo code `BRADNODE26` (spoken at 00:02:11 as "brad node 26"); the base URL here omits the tracking parameters. - [LearnWebCode](https://learnwebcode.com/): the channel's site, listed in the description. - [Next.js documentation](https://nextjs.org/docs): the Get started and Installation pages the narrator reads at 00:05:03. - [Node.js](https://nodejs.org): runtime download named at 00:02:54. - [Visual Studio Code](https://code.visualstudio.com): editor and agent host named at 00:03:37. - [Git](https://git-scm.com): installer named at 00:38:28. - [GitHub](https://github.com): repo host and sign-in for the VS Code agent. - [WordPress REST API handbook](https://developer.wordpress.org/rest-api/): the API the narrator tells the agent to use at 00:15:13. - [Application Passwords in WordPress](https://make.wordpress.org/core/2020/11/05/application-passwords-integration-guide/): the Core integration guide for the credential type the narrator creates at 00:26:52. - Advanced Custom Fields and Secure Custom Fields: the plugins that supply custom fields and post types at 00:11:35. The transcript names both; no URLs are given. - `html-react-parser`: the npm package the narrator hints at, transcribed as "HTML React parser" at 00:18:08. Verify the exact package name in the npm registry before installing. - Tailwind CSS, Playwright: named in the scaffold choices and in the agent preview at 00:21:45. No links in the transcript. ## 🗣️ Paraphrase The tutorial argues that headless WordPress is no longer a specialist project. You keep the WordPress admin your editors already know, leave the theme as an intentionally empty page, and build the public site in Next.js. Then you describe each page in plain English to an AI agent in VS Code and review what it builds in the browser. The method is a loop: prompt, look, and correct. The agent gets navigation links wrong or right depending on the run, leaves WordPress image URLs in place, and links back to the WordPress domain from inside post content. It also shows styles in its own preview that don't reach the real browser. Each problem gets one specific follow-up prompt, and where an error message exists, the message gets pasted in as-is. When the contact form fails, the cause turns out to be a mistyped application password, and the narrator says so on camera. Two ideas hold the architecture together. Secrets live in `.env`, which stays out of Git and gets re-entered in the host's environment settings. And the Next.js server caches WordPress responses for about 5 minutes, so editors never trigger a rebuild, and a slow WordPress host stays hidden behind the cache. ## 📰 Newsletter **A 47-minute headless WordPress build you can finish in one sitting.** LearnWebCode's tutorial takes an empty folder to a live Next.js site that reads from WordPress and writes contact-form entries back as private posts. The narrator writes almost no code. A VS Code AI agent builds the pages from prompts, and the narrator corrects it as it goes: use the Next.js `Link` and `Image` components, keep same-domain links inside post content on the Next.js site, and paste dev-overlay warnings straight into the agent. Three details are worth copying. First, the field-group and post-type settings for "Show in REST API" decide whether Next.js can read your custom fields at all (00:12:18). Second, writes use a WordPress application password that's revocable, though it carries admin-level permission, so make a dedicated user instead. Third, the 5-minute server-side cache means editors don't wait on a deploy. The video is sponsored by Cloudways, so read the hosting praise as marketing and the architecture as the useful part. Gaps to fill yourself: draft preview, on-demand revalidation, SEO metadata, and a real anti-spam control instead of a secret question. Links: [the video](https://www.youtube.com/watch?v=CUiHnde9BmE), [the example theme](https://github.com/LearnWebCode/brads-headless-classic-theme), [WordPress REST API handbook](https://developer.wordpress.org/rest-api/). ## ✅ Action items #### DevRel - Developer advocacy: publish a headless WordPress tutorial that follows this prompt-and-verify loop on a Pantheon-hosted WordPress back end, including the steps this video skips (a limited-role application password, revalidation on publish, draft preview). - Education: run one workshop where attendees paste their own Next.js dev warning into an agent, using the 00:23:55 Suspense warning as the warm-up. - Developer experience: write a checklist of the five checks the narrator runs on agent output (`Link`, `Image`, internal links in content, server-only secrets, cache window) and attach it to any headless quickstart. - Developer marketing: when quoting this video, label the hosting praise as sponsored. Cloudways claims about security and speed carry no numbers. - Community management: collect the common failure (a wrong pasted credential masquerading as a code bug, 00:31:14) as a troubleshooting FAQ entry. - Internal/external: ask the creator whether a follow-up covers revalidation webhooks and draft preview, since both are the first questions from agencies. #### OSPO - Policy and governance: decide whether agent-generated front ends using WordPress REST credentials are acceptable in contributor tooling, and document the minimum credential scope. - License compliance: if the pattern enters shared tooling, check licenses of `html-react-parser` and Tailwind CSS once the exact packages are confirmed in the registry. - Security management: add the application-password path to the threat model. The narrator says it acts "as if you were the admin" (00:27:36). Require a dedicated low-privilege user for form submissions. - Software inventory: record Next.js, the REST endpoints used, and the hosting platform as separate dependencies with owners. - Developer support: publish guidance that `.env` is git-ignored by the Next.js scaffold but that hosting dashboards need the same values entered by hand, with a rotation procedure. - Community engagement: invite the narrator's example theme into a showcase of locked-down editor experiences. - Strategic alignment: track time from empty folder to live site as a measurable onboarding metric. This video's runtime of 47:30 is one baseline. #### Community - Maintainers: for any headless starter repo, add an `AGENTS.md` and keep it current. The scaffold step at 00:07:13 treats it as important for agent results. - Contributors: document how to test the contact flow with a private post and an application password revoked afterward. - Sponsors: when a host funds a tutorial, ask for a disclosure line in the first 30 seconds of the video, not only at the sponsor read. - Ecosystem: encourage ACF and SCF docs to state the "Show in REST API" requirement in the first setup screen, since this video shows it blocks front ends. #### WordPress - Core: no direct action. Nearest relevance: the REST API's default exposure for custom post types is the setting this tutorial toggles by hand, and a short Core note on `show_in_rest` for custom types would help. - Core Performance: document that server-side caching of REST responses in a front end (5 minutes here) shields slow origins, and add the measurement the video lacks. - Core AI: consider a guideline for agent-built front ends that call authenticated REST endpoints, with a recommendation to use scoped users. - Core Program Team: none directly. If a headless showcase is planned, this tutorial is a candidate source. - Mobile: none. The same REST contract would serve an app, which the video doesn't mention. - Playground: build a Blueprint that seeds the `team members` and `contacts` types and a limited application password so learners can run the Next.js side without a host. - Community: collect local-meetup talk proposals around "WordPress as editor, Next.js as site," with the cache-window tradeoff as the discussion point. - Training: turn the 17 Notes segments into a lesson plan with a checkpoint after each (scaffold, `.env`, first prompt, links, images, form, deploy). - Marketing: avoid using "lightning fast" language without a measurement. The video offers none. - Support: add a triage entry for "front end can't see custom fields" with the two REST API checkboxes at 00:12:18 as the first fix. - Design: none. Nearest relevance: the video leaves styling to the agent, so a design-token handoff from Figma or theme.json would be a useful follow-up. - Documentation: add a headless section covering the application-password flow, private posts for submissions, and the empty headless theme pattern. - Photos: none. - TV: this is a clean candidate for a captioned, chaptered walkthrough. The 17 segments in Notes give the chapter list the video lacks. - Polyglots: none from this source. Nearest relevance: a headless front end must handle locale routing itself, which isn't shown. - Accessibility: audit an agent-generated front end like this for focus states, heading order, form labels and the secret-question field before it ships. - Meta: none. - CLI: provide a WP-CLI recipe that creates a limited-role user and an application password, so the step at 00:26:52 becomes scriptable. - Hosting: write a Node.js front-end-plus-WordPress-back-end deployment guide covering environment variables, server-side cache, and failover when WordPress is slow, which is the closing argument at 00:46:27. - Tide: none. Nearest relevance: a headless site still depends on plugins, so the plugin checks apply to the WordPress half. - Openverse: none. - Themes: publish a "headless theme" reference that locks blocks and returns an intentionally empty front end, using the linked example at 00:37:01 as a model. - Plugins: ACF and SCF are central to the demo. Plugin authors can add REST exposure defaults and clearer onboarding for headless use. #### The WPOCC - Programs: none directly. A headless starter-kit challenge could fit a program, with limited-role credentials as a judged criterion. - Projects: none from this source. - Funding experiments: if The WP Open Community Collective funds headless templates, require a security checklist and a revalidation approach as deliverables. ### FAIR - Technical independence: the architecture splits content (WordPress) from delivery (Next.js plus a host). Document which side is portable and which side the host controls. - Policies and covenants: none from this source. Nearest relevance: sponsored tutorials about distribution infrastructure should disclose the sponsor near the top. - Productized governance artifacts: add a "front-end dependency" row to operator scorecards that covers the delivery stack, not only the WordPress install. ## 🧪 Hypotheses 1. Prompting an agent with the same page spec on 10 fresh scaffolds produces a correct `Link`-and-`Image` implementation on first try in fewer than 7 of the 10 runs, which would confirm the narrator's remark that the results vary run to run. 2. A 5-minute server-side cache cuts WordPress REST requests by more than 90% on a page set with steady traffic. 3. Replacing the shared admin application password with a dedicated limited-role user does not break the contact form, because creating a private post of one type needs fewer capabilities than administrator. 4. On-demand revalidation triggered from a WordPress publish hook reduces the median time from edit to visible change from the 5-minute window to under 30 seconds. 5. The secret-question field blocks naive form bots but fails against any bot that scrapes the question text once, so spam rates will return to baseline within weeks of launch. 6. A headless front end with cached reads keeps median page time under 300 ms even when the WordPress origin responds in 2 seconds, which the closing argument at 00:46:27 depends on. ## 📊 Methodology - **Design for H1.** Script 10 clean `create-next-app` runs with the same prompt. Count whether each page uses `next/link`, `next/image` and the same-domain link rewrite on first generation. Record the agent and model version. - **Design for H2.** Put a request counter on the WordPress origin (access log or query monitor). Replay a fixed 1,000-request traffic trace over 30 minutes with and without the cache. Compare REST hits per page view. - **Design for H3.** Create a user with the narrowest role that can create the `contacts` type. Run the form against it, and record which capabilities the REST call requires. Revoke and recreate the application password to test rotation. - **Design for H4.** Add a publish webhook that calls a revalidation route. Measure the time from clicking Update in WordPress to the new text appearing on the live site, 20 samples, p50 and p95. - **Design for H5.** Run 500 scripted submissions, half from a bot that has the question text and half from one that doesn't. Count how many reach WordPress as private posts. - **Design for H6.** Throttle the WordPress origin to 2 s response time. Measure front-end time to first byte and largest contentful paint from 3 regions with a warm and a cold cache. - **Controls.** Pin Next.js, Node and agent versions. Use one seed content set. Report how many runs were excluded and why. ## ❓ Questions - What revalidation interval and API did the agent actually write, and was 5 minutes a fixed number or a Next.js default? - Does the cache hold in memory per server instance, and what happens on a Velocity server with more than one process? - Which minimum role can create a private `contacts` post, and could the application password belong to that role instead of an administrator? - How does the app handle a WordPress outage on a cold cache: error page, stale copy, or timeout? - How do drafts, previews and scheduled posts reach the editors, if the front end only reads published content? - Where do SEO titles, meta descriptions and social cards come from in this design? - How is the contact form protected from abuse beyond the secret question: rate limiting, nonce-like tokens, or captcha? - What does Cloudways Velocity cost per server, and what are the stated limits for Node.js apps? ## 🔮 Future research - **Agent output variance.** The narrator warns results differ across runs. A published rubric for agent-built headless sites (link handling, image handling, secrets exposure) would turn anecdotes into a comparison. - **Credential scope for write-back.** Application passwords inherit the user's capabilities. Research a recommended least-privilege pattern for form-to-post flows. - **Cache semantics under editor workflows.** Studies of stale-content windows, preview and scheduled publishing for headless WordPress are thin compared with studies of build-time static generation. - **Training value of AGENTS.md.** The scaffold asks to include one "for much better results". Measure whether it changes link and image correctness across runs. - **Slow-origin shielding.** The closing claim that a slow host stays invisible behind a cache needs numbers for cold-cache and first-visitor cases. ## 💡 Implications - **Practice.** Describe pages in prose, review in the browser, and paste exact error text back into the agent. The tutorial's loop is repeatable and each failure has a named fix. - **Policy.** Teams adopting agent-generated front ends need a credential policy for authenticated REST calls: dedicated users, rotation, and no admin passwords in hosting dashboards. - **Security.** Server-only secrets, `.gitignore` for `.env`, private posts for submissions, and a server-side check before writing to WordPress are the four controls on screen. A secret question is not a substitute for rate limiting. - **Education.** The video is a complete first-project lesson, but it skips preview and revalidation. Course designers should add those as a second module. - **Funding.** Per-server pricing (stated at 00:02:11) favors agencies running several small apps on one server. Sponsored tutorials fund this content, which is why disclosure matters. ## 🧠 Learning styles assessment - **Reading level estimate.** Flesch-Kincaid Grade Level on the transcript body is approximately grade 7, and Flesch Reading Ease is near 75. Short conversational sentences, with domain terms (REST API, environment variable, Suspense, remote origin) spoken once each and defined by context. #### 👀 Visual learners - Present: constant screen capture of VS Code, the browser, the WordPress admin and the Cloudways dashboard. - Improve: no architecture diagram of WordPress, Next.js server, cache and browser. One diagram would replace the two minutes of narration at 00:00:44 and 00:34:51. #### 🔊 Aural learners - Present: continuous, unhurried narration, with dictated prompts spoken aloud. - Improve: file names and symbols (`.env`, `WP_URL`) are hard to hear. The auto-captions render `.env` as "NV", "inv" and "yourv", so spoken spelling would help. #### 🗣️ Verbal learners - Present: full prompts are read aloud, so the exact wording is recoverable from the transcript. - Improve: no written summary in the description. A text recap of the prompts and the five review checks would serve readers. #### 🧩 Kinesthetic learners - Present: step-by-step "pause and type with me" instructions at 00:05:47 and 00:09:24, and a deploy anyone can repeat. - Improve: the narrator's own prompts aren't in the description. A copyable prompt list would let viewers act without transcribing from audio. #### 🧠 Logical learners - Present: ordered pipeline (scaffold, secrets, prompts, review, security, push, deploy) and a stated reason behind each step (for example, secrets in `.env` because of `.gitignore`). - Improve: the 5-minute cache number appears without its derivation. State the revalidate setting and where it lives in the code. #### 🧑‍🤝‍🧑 Social learners - Present: a pinned comment and description link for the promo, and an invitation to watch to the end. - Improve: no discussion prompt or community link for sharing prompts and agent results. Disagreement over TypeScript is invited out of the comments at 00:06:30, which closes a conversation. #### 🧘‍♀️ Solitary learners - Present: self-paced, with explicit permission to pause and install tools. - Improve: no end-of-video checklist to confirm each step passed. A list such as "node --version, localhost:3000, REST fields visible, private post created" would help. #### 🌿 Naturalistic learners - Present: demo content uses animals (Chris the Chipmunk, Tom the Turtle, a cat riddle), which adds warmth. - Improve: no environmental angle. Cached reads reduce origin load, a claim a hosting provider could back with energy-per-request data. ## 📊 Accessibility assessment #### Screen reader semantics - Present: YouTube supplies the player landmarks, and the transcript is machine-readable. The description holds the main links. - Improve: on-screen code, dashboards and the WordPress admin carry information that narration only partly speaks. WCAG 2.2 AA 1.1.1 (Non-text Content) and 1.2.5 (Audio Description, Prerecorded) aren't met for screens the narrator doesn't describe. #### Keyboard navigation - Present: the YouTube player is keyboard operable with visible focus. The narrator names keyboard shortcuts (Cmd+J or Ctrl+J, Ctrl+C), which helps keyboard users of VS Code. - Improve: the tutorial uses arrow keys for the scaffold prompts but depends on mouse steps in the WordPress admin and Cloudways. 2.1.1 passes via the platform, and no content-level barrier is added. #### Contrast and readability - Present: unverifiable from a transcript. The narrator's editor is shown in a dark or light theme at default size. - Improve: small terminal and editor text at 1080p risks 1.4.3 (Contrast Minimum) failures on mobile. Zoom into command-line steps. #### Text resizing and reflow - Present: the player and captions scale. - Improve: burned-in text (dashboard labels, terminal output) doesn't resize. 1.4.4 (Resize Text) and 1.4.10 (Reflow) fail for text in the frame. #### Media and captions - Present: an auto-generated transcript exists, which is how this analysis was produced. The description has no chapter list, so navigation relies on scrubbing. - Improve: auto-captions garble the key technical tokens: `.env` appears as "NV", "inv", "Eenv" and "yourv"; Next.js as "Nex.js"; `git config --global` partly. That's a 1.2.2 (Captions, Prerecorded) failure in substance. Chapters would satisfy 2.4.5-style multiple-ways navigation; human-corrected captions are the fix. #### Forms and interactions - Present: the demo contact form has labels for name, email, phone and message, and the narrator tests wrong and right answers. - Improve: the "name of the cat that meows frequently" question is a cognitive barrier, which fails 3.3.8 (Accessible Authentication, Minimum) in spirit because it asks users to recall a riddle. The narrator doesn't show a text alternative. 3.3.2 (Labels or Instructions) and 3.3.1 (Error Identification) apply to the form the agent generated and aren't verified. #### Standards reference - Primary gaps against WCAG 2.2 AA: **1.2.2** (inaccurate captions on code tokens), **1.2.5** (no audio description for on-screen steps), **1.1.1** (screens conveyed visually only), **1.4.4 / 1.4.10** (burned-in text), and **3.3.8** for the demo form's secret-question approach. The captions failure is the highest-impact and cheapest to fix. ## 🌍 DEIB assessment #### Cultural breadth - Present: examples are animal team members and a cat riddle, which travel across cultures and avoid people's names or faces. - Improve: an English-only site is built. A short mention of locale routing, translated content and `Intl` formatting would acknowledge multilingual WordPress sites. #### Inclusive language - Present: plain, direct second-person language. The narrator tells viewers they don't have to match names or version numbers. - Improve: phrases such as "give the AI a piece of my mind" (00:22:27) and "you just got to be direct and firm" frame agent management in aggression terms. Low severity; "state the problem directly" says the same thing. #### Neurodiversity support - Present: strong chunking. Each segment does one task, and each prompt follows prompt, run, check, fix. The narrator says when to pause. - Improve: no chapters, and the sponsor reads at 00:02:11, 00:37:44 and 00:46:27 interrupt the flow. Chapter markers and a sponsor timestamp would help viewers skip and return. #### Representation - Present: one narrator, whose self-description as "not a Typescript kind of guy" at 00:06:30 is the only identity cue; the transcript gives no other personal detail. - Improve: no guest, no other voices, and no mention of whether the tooling is usable by developers who use assistive tech. A guest segment with a screen reader user reviewing the output would add both. #### Psychological safety - Present: the narrator shows mistakes openly ("I was the problem") and says "I'm not trying to create a controversy in the comments" about TypeScript, which lowers the stakes of a different choice. - Improve: the TypeScript aside and the "don't pay" assurances for GitHub are friendly, but the narrator never says that a failed step is normal for beginners. A line at the start would help new developers. ## ✅ Logical validity #### Strong reasoning - **Causal and diagnostic, 00:12:18.** "Without this, nextJS will not be able to fetch all of the data that it needs" ties a specific setting (Show in REST API) to a specific symptom (missing data). Testable by toggling it off. - **Controlled correction, 00:16:42 to 00:20:19.** Each fix has a visible check: open the image in a new tab and read the URL; click the internal link and see whether the page stays on the Next.js domain. These are verifiable observations rather than assertions. - **Honest root-cause finding, 00:31:14.** The narrator blames a mistyped application password after the error text shows WordPress rejected the credentials, and says the agent "was doing everything right." - **Security reasoning, 00:08:41 and 00:40:41.** Secrets in one git-ignored file, never in other files, even in private repos, is a sound rule because repo visibility can change and clones copy history. - **Mechanism demonstration, 00:34:51.** Loading the same page in Chrome and then in Firefox shows the cache is server-side. It's a clean two-browser test that supports the narrow claim. - **Disclosure, 00:02:11.** The sponsor is named at the start and the end, with the promo code. #### Fallacies - **Unsupported superlatives, 00:02:11.** "Excellent security, excellent speed and performance." Quote from the sponsor read: no figure, no benchmark, no comparison host. *Fix:* cite a measured result or drop the adjectives. - **Hasty generalization, 00:44:19.** One live edit appearing "already there" is used to show the 5-minute window works, but the narrator admits luck. *Fix:* test 20 edits and report the observed delay distribution. - **Overgeneralization from one host, 00:46:27.** "even if it's on a bargain bin basement hosting ... that's okay" holds only while the cache is warm and the origin is up. Cold cache, restarts and instance counts aren't covered. *Fix:* show a cold-cache request against a throttled origin. - **Appeal to convenience, 00:02:11.** "You just send them your files and you're basically done" understates the GitHub, environment variable and first-deploy steps the narrator later performs. *Fix:* say "connect a repo and re-enter your variables." - **Missing alternatives, 00:08:41.** "If the only thing you get out of this video is this, then I did my job" is stated as a bare rule. Alternatives like secret managers or per-environment overrides are skipped. *Fix:* name host-level secrets as the supported complement. - **Auto-caption ambiguity, throughout.** Not the author's fallacy, but "NV", "inv" and "yourv" (all `.env`) make some quoted text unusable as a citation. *Fix:* human-corrected captions. #### Tone of voice - Friendly, teacherly and unhurried, in second person with contractions throughout ("I'll click no. I want to customize the settings"). Humor is gentle: Chris the Chipmunk, a cat riddle. The tone turns firm at 00:22:27 when the agent keeps missing the styling issue, then relaxes once it's fixed. Sponsor reads at 00:02:11 and 00:37:44 shift to a promotional register with adjectives; the middle of the video, where the building happens, is concrete and caveated ("yours might have completely different problems"). Marketing sits at the sponsor reads and engineering fills the rest. ## 🛡️ DARVO analysis Not applicable to this source. DARVO (Deny, Attack, Reverse Victim and Offender) describes a response pattern to accusation or criticism. This is a tutorial with no accusation or accuser. For completeness across the three prongs: **Deny**: nothing is denied; the narrator admits the credential mistake at 00:31:14 ("I was the problem") and the agent's styling failures at 00:22:27. **Attack**: no critic or competitor is attacked; the TypeScript aside at 00:06:30 explicitly avoids controversy. **Reverse victim/offender**: no such move appears; the narrator briefly blames the agent, then corrects it. ## 🎯 Conclusion The durable content is the architecture and the review checklist, and both survive the sponsor read. WordPress stays the editor, Next.js becomes the public site, `.env` carries the secrets, and a server-side cache turns editor changes into a 5-minute delay instead of a redeploy. The narrator verifies each agent output in the browser: `Link` over `<a>`, `Image` over `<img>`, same-domain links kept on the Next.js site, and no secret reaching the client. The gaps are the ones a production team would fill first. The application password carries admin-level permission, so a limited-role user is the safer pattern. The secret-question check is spam friction, not authentication, and it adds a cognitive barrier. The 5-minute window is untested beyond one lucky edit, preview and revalidation aren't shown, and Cloudways praise has no numbers. **Next steps for readers:** follow the video on a test site, then change three things before sharing it: create a dedicated user for write access, add a revalidation call on publish, and replace the secret question with rate limiting. Measure the cache hit rate and the edit-to-visible delay with the methods above before relying on the closing claim about slow hosts. ## 🔄 Refactor Appendix — Practical Guide to Headless WordPress (Next.js) > Density: 2–5 Literature atoms (H3 pad), 0–3 Permanent candidates (H4 pad). > Emitted: 5 Literature, 2 Permanent. Resonance filter applied: the sponsor reads and > the cosmetic design prompts were dropped as low-evidence and low-reuse. > > 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] Secrets belong in one git-ignored file > [!quote] [00:08:41] > So, don't ever include sensitive values like passwords or tokens or API keys in any of your other files in your entire project. **Context & use**: - 00:08:41, introducing `.env` right after the `WP_URL` setup. - Pairs with 00:40:41, where the file stays out of GitHub even for private repos, and with 00:43:37, where the same values are re-entered in the host dashboard. **Tags**: #xref #share <!-- atomicity: 1 idea ✓ --> #### [H2] Headless drops the WordPress presentation layer > [!quote] [00:01:27] > It means you're using WordPress only for the backend and you've essentially removed its head or its public presentation **Context & use**: - 00:01:27, the plain-language definition after the two-way demo (read pages, write contact entries). - Useful as the one-sentence definition for training and documentation, with the narrator's empty-theme pattern at 00:36:17 as the proof. **Tags**: #xref #articleseed <!-- atomicity: 1 idea ✓ --> #### [H3] Server caching removes the rebuild step > [!quote] [00:35:34] > What's nice is we don't need to rebuild or redeploy anything. **Context & use**: - 00:35:34, after the Chrome and Firefox test shows the cache lives on the Next.js server. - The cost is a stale window of up to 5 minutes. The video shows it working once and calls the timing lucky at 00:45:01. **Tags**: #xref #articleseed <!-- atomicity: 1 idea ✓ --> #### [H4] REST exposure settings gate front-end access > [!quote] [00:12:18] > Without this, nextJS will not be able to fetch all of the data that it needs. **Context & use**: - 00:12:18, on the field group's "Show in REST API" setting. The post type has its own matching switch at 00:13:01. - The first thing to check when a headless front end can't see custom fields. Fits a support triage entry. **Tags**: #xref #share <!-- atomicity: 1 idea ✓ --> #### [H5] A cached front end hides a slow origin > [!quote] [00:46:27] > if it's slow, that's okay because Nex.js is caching the data and only needing it every 5 minutes. **Context & use**: - 00:46:27, the closing argument for the architecture. - Holds while the cache is warm and the origin is up. A cold cache and a WordPress outage are untested in the video. **Tags**: #xref #articleseed <!-- atomicity: 1 idea ✓ --> ### 🧠 Atomic Split Pad #### [P1] Cache the read path, authenticate the write path narrowly **Claim** (one sentence, Courtney's voice): A headless WordPress front end is safe and fast when public reads come from a server-side cache and writes use a revocable, narrowly scoped credential. **Evidence pointer**: [[#H3]] · [[#H5]] · [[#H1]] **Scope & conditions**: Holds when content tolerates a stale window and the write path is a single known form. Breaks when editors need instant publishing or preview without a revalidation hook, or when the credential belongs to an administrator, as in the video at 00:27:36. **Links**: - [[Headless WordPress architecture]] — because extends - [[Application passwords and least privilege]] — because contrasts on credential scope — the video uses an admin user, the safer pattern is a dedicated user - [[Next.js caching and revalidation]] — because applies-in a 5-minute interval <!-- atomicity: 1 idea ✓ --> #### [P2] Show the check next to every agent prompt **Claim** (one sentence, Courtney's voice): AI-agent tutorials teach better when each prompt is paired with a visible check, such as an image URL or a link target, that a reader can run in the browser. **Evidence pointer**: [[#H4]] **Scope & conditions**: Applies to any agent-built front end where the output varies per run. Doesn't apply to one-shot generation with no review step, and doesn't replace automated tests or a security review. **Links**: - [[Agent-assisted development workflow]] — because extends - [[Training lesson design]] — because applies-in checkpoint after each step - [[Reading vendor benchmarks]] — because contrasts on evidence: a visible check is verifiable, an adjective isn't <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Confirm the exact npm package name for the link-rewriting library the narrator calls "HTML React parser" before recommending it: https://www.youtube.com/watch?v=CUiHnde9BmE #fleeting #inbox - [F2] Find where the 5-minute revalidate interval is set in the generated code, and whether it is a fixed value or the cache components default #fleeting #inbox - [F3] Open question: which minimum WordPress role can create a private `contacts` post, so the application password can drop from admin to a limited user #fleeting #inbox - [F4] Article seed: "Four checks for any agent-built Next.js front end": Link, Image, internal content links, server-only secrets #fleeting #inbox #articleseed - [F5] Add on-demand revalidation (publish hook) and draft preview to the follow-up list, since neither is in the video #fleeting #inbox - [F6] Ask whether the example theme at the description link also handles cache purge or webhooks on publish #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Prototype the contact flow with a limited-role user and a revocable application password, and record which capabilities the REST call needs: headless WordPress test, 45 min #things - [ ] Add on-demand revalidation on publish to the same prototype and measure the edit-to-visible delay: cache test, 45 min #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Practical Guide to Headless WordPress.md|Practical Guide to Headless WordPress by LearnWebCode]] ## Highlights - [00:01:27] Chipmunk. I can click on Chris to see the full biography. And it's not just a one-way street of pulling data from WordPress. I can push or send data to WordPress. If I click on contact us and I fill out this form, it will programmatically add it as a new entry in this contacts area where I've captured their email, phone, message. You get the idea. So, back to the question, what is headless? It means you're using WordPress only for the backend and you've essentially removed its head or its public presentation and then you can substitute that with anything you want. In this video, I'm going to walk through this process of creating a NextJS front end that pulls from a WordPress backend. We'll build it [00:02:11] step by step and even deploy it live up onto the public web. And that brings us to the sponsor of today's video, Cloudways, specifically Cloudways Velocity. Velocity lets you host NodeJS applications. Now, in the past, hosting a node app was fairly complex, but Velocity has made it as simple as possible. You just send them your files and you're basically done. Excellent security, excellent speed and performance. You don't pay per app, you pay per server. If you want to check it out and save 30% on your first three bills, you can use the code brad node 26. You'll find a link in the pinned comment and description with that promo code already applied. Huge huge thank ([View Highlight](https://read.readwise.io/read/01m4rb8wjyhqzkjxcrt58fet97)) - Note: [H2] Headless drops the WordPress presentation layer - Tags: atom/literature/h2 - [00:08:41] hack us or run up a big bill on behalf of us. So, don't ever include sensitive values like passwords or tokens or API keys in any of your other files in your entire project. If the only thing you get out of this video is this, then I did my job. All of your actually truly sensitive values should go in this one file called env. And this is the format. So you have all uppercase the name of the variable, right? And then equal and then whatever your actual value is. We don't need sky color and grass color. Instead, type this in with me. WP URL equals. And obviously your value is going to be different than mine, but just include the address to your [00:09:24] WordPress website or your WordPress installation. So that would begin with, you know, https and then don't have it end with the forward slash. Just have it end in your domain. Go ahead and save this file. So command or controls. And then don't close VS Code as a whole, but just close this one. Eenv file. So this X right about here. From here, we are ready to take our hands off the keyboard and let the AI agent do the job. Now, if you've never used VS Code before, this icon right about here in the top right corner, that is how you toggle like open and close the right-h hand sidebar. And the very first time you're using VS Code, you will not be logged in. So, you will not see access to actually chat with the AI agent. As you open this ([View Highlight](https://read.readwise.io/read/01m4rb8t4np5th0f07zk30n7ew)) - Note: [H1] Secrets belong in one git-ignored file - Tags: atom/literature/h1 - [00:11:35] fields. I don't want this video to become an hour-ong tutorial on how to use advanced custom fields or secure custom fields. You can use these plugins for free. And what they let you do is create custom post types. So, in the lefth hand sidebar, in addition to just posts and pages, I also have contacts, team members, so on and so forth. And then from team members, I made this up. I said, hey, there should be a field called job title. There should be a field called favorite color. There should be a field called favorite food. There should be a field called best friend, which is a relationship, and you can select other team member posts. So on and so forth. So all of that is set up through either secure custom fields [00:12:18] or advanced custom fields. You just create custom post types and then you create field groups that show up if it's a certain post type. Let me give you an example like for team members. My field groups called team members. I said only show this field group if post type is equal to team member. So then it's not going to show up for posts or pages. It's just for team members. Now, one thing I did want to show you is that for example, like for this team member field group down here uh at the bottom, if I click on group settings, it's very important that this is enabled for show in the rest API. Without this, nextJS will not be able to fetch all of the data that it needs. So, make sure that's ([View Highlight](https://read.readwise.io/read/01m4rb919qbqqvjc1tsmdj8gas)) - Note: [H4] REST exposure settings gate front-end access - Tags: atom/literature/h3 - [00:34:51] I wanted to give you a 30 to 40 second explanation on why I like Nex.js JS uh and the way that it handles caching so much. So, check this out. Especially in combination with WordPress and making edits. So, when I go to team members, the very first time I click on like Tom the Turtle, well, it actually didn't display there. I was trying to show you a brief moment where it says loading content. Maybe if I click on one of these blog posts. No, unfortunately, they're all already cached. But if I click on one and manually refresh, see how it says loading article. And now when I refresh, it's instant. So once that cache is established, it's not a per user or per browser cache. It's cached on the Nex.js server side. So then this is Chrome. But even if I open [00:35:34] up like Firefox, you know, now when I click on one of these team members, this data that was fetched from WordPress, you know, from my original request, it is cached on our Nex.js server side. So for the next 5 minutes, it is instant to all visitors. Now, what if someone who's a non-technical user, you know, makes a change, uh, you know, one of our content contributors makes a change to a piece of content. What's nice is we don't need to rebuild or redeploy anything. We don't need to trigger a redeploy or a rebuild. Nex.js, you know, the longest we'll have to wait is 5 minutes at the absolute maximum. And then it will pull in the next time someone visits this, ([View Highlight](https://read.readwise.io/read/01m4rb8z3w7wf2aj05vx0vbd59)) - Note: [H3] Server caching removes the rebuild step - Tags: atom/literature/h3 - [00:46:27] and it's slow, as long as it doesn't crash entirely, if it's slow, that's okay because Nex.js is caching the data and only needing it every 5 minutes. So, your public front end is lightning fast. It's also fun because you're not dependent on WordPress for limiting you on the front end. Anything you can cook up in your imagination. And then we saw how easy it is to use Agentic AI to just have it do what you tell it to do. I think this is a fun architecture to work with. Hopefully you learned something in this video. And again, I want to give a huge shout out to Cloudways, specifically Cloudways Velocity and their NodeJS hosting for making this educational video possible. Excellent speed, excellent security. You don't pay per app, you pay per server. You saw how [00:47:11] easy it was for me to add an additional app to the velocity server I already had. Huge shout out and thank you to Cloudways. And thank you to you for watching until the very end. Hopefully this video was helpful. Hopefully you feel like you learned something. Stay tuned for more web development tutorials and I'll see you ([View Highlight](https://read.readwise.io/read/01m4rb93jfn2q5e79kg5hwe6gh)) - Note: [H5] A cached front end hides a slow origin - Tags: atom/literature/h3