Headless WordPress + Next.js Is A Game Changer

Headless WordPress + Next.js Is A Game Changer 🔗 **Source:** [Headless WordPress + Next.js Is A Game Changer](https://www.youtube.com/watch?v=2BUZUjtz5sM) > [!note]+ Document Notes > tags: [headless-cms, nextjs, wordpress] > author: ByteGrad > source: YouTube > reference: https://www.youtube.com/watch?v=2BUZUjtz5sM > date created: 2024-12-28 15:45 > > # 🏷️ Title: Headless WordPress + Next.js Is A Game Changer >  ## 🧰 Action Inbox - [H1] Set up WordPress REST API endpoint exclusion from caching — avoid stale data during development #wordpress - [H2] Implement ISR with revalidate for dynamic content — balance performance with freshness #nextjs - [H3] Configure generate static params for dynamic routes — enable static generation at build time #performance ## 🧭 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) ### 🔗 References - [WordPress REST API](https://developer.wordpress.org/rest-api/) - [Next.js Documentation](https://nextjs.org/docs) ## 📝 Summary - Tutorial demonstrates building a headless WordPress setup with Next.js frontend using REST API - Covers fetching WordPress posts via REST API, handling caching strategies, and dynamic routing - Shows practical implementation using Cloudways hosting with real-world caching considerations - Addresses ISR (Incremental Static Regeneration) for balancing performance with content freshness - Provides foundation for developers wanting modern frontend with familiar WordPress backend ## 📖 Main Content The tutorial walks through creating a headless WordPress architecture where WordPress serves as a content management system accessed via its REST API, while Next.js handles the frontend presentation. This approach allows developers to leverage WordPress's familiar content management capabilities while using modern React-based frameworks for the user interface. Key technical aspects include configuring WordPress to exclude API endpoints from server-level caching, implementing Next.js server components to fetch data, and setting up dynamic routes with proper static generation. The tutorial emphasizes practical caching strategies, including ISR for automatic content updates and generateStaticParams for build-time static generation. The demonstration uses Cloudways hosting platform, showing real hosting considerations like cache configuration and multiple application deployment options. The approach is particularly valuable for teams already familiar with WordPress who want to modernize their frontend technology stack. ## 🗒️ Notes #### ⏱️ [00:00](https://www.youtube.com/watch?v=2BUZUjtz5sM&t=0) — [H1] Introduction to headless WordPress concept - Key idea: WordPress can serve as headless CMS for modern frontend frameworks - Evidence: "you can pull in data into your app using the WordPress REST API that comes with WordPress by default" #### ⏱️ [01:30](https://www.youtube.com/watch?v=2BUZUjtz5sM&t=90) — [H2] Setting up new Next.js project - Key idea: Starting from scratch with Next.js 16 boilerplate - Evidence: "Brand new NextJS16 as of recording" #### ⏱️ [02:45](https://www.youtube.com/watch?v=2BUZUjtz5sM&t=165) — [H2] WordPress hosting setup with Cloudways - Key idea: Need WordPress instance accessible via REST API - Evidence: "Cloudways is actually a digital ocean company, but they allow you to pick from these other providers as well" #### ⏱️ [04:20](https://www.youtube.com/watch?v=2BUZUjtz5sM&t=260) — [H3] Creating sample WordPress content - Key idea: Default WordPress installation provides sample posts for testing - Evidence: "by default there is this hello world post. Let's just add another post here" #### ⏱️ [05:15](https://www.youtube.com/watch?v=2BUZUjtz5sM&t=315) — [H1] Accessing WordPress REST API endpoints - Key idea: WordPress automatically exposes REST API at /wp-json/wp/v2/posts - Evidence: "if you use the URL for your site...and then if you tag on this bit here...I actually have a bunch of data here" #### ⏱️ [06:30](https://www.youtube.com/watch?v=2BUZUjtz5sM&t=390) — [H2] Fetching WordPress data in Next.js - Key idea: Server components can fetch REST API data directly - Evidence: "this is a server component. We can fetch data directly in here" #### ⏱️ [08:00](https://www.youtube.com/watch?v=2BUZUjtz5sM&t=480) — [H3] Displaying WordPress posts in React components - Key idea: Map over fetched posts to render dynamic content - Evidence: "just map over each of these posts...you can see now I have second post" #### ⏱️ [09:45](https://www.youtube.com/watch?v=2BUZUjtz5sM&t=585) — [H2] WordPress server-level caching issues - Key idea: WordPress caching can prevent API updates from appearing - Evidence: "There's also caching at the WordPress instance level...we may just want to exclude the API URL from that caching" #### ⏱️ [11:20](https://www.youtube.com/watch?v=2BUZUjtz5sM&t=680) — [H3] REST API optimization techniques - Key idea: Use query parameters to optimize API responses - Evidence: "_embed here...gives you additional information...reduce the payload as well as the speed" #### ⏱️ [12:30](https://www.youtube.com/watch?v=2BUZUjtz5sM&t=750) — [H3] Built-in WordPress REST API features - Key idea: WordPress REST API includes search, filtering, and ordering - Evidence: "if you have a search functionality, there is actually a built-in search feature...you can also specify the order by" #### ⏱️ [13:45](https://www.youtube.com/watch?v=2BUZUjtz5sM&t=825) — [H2] Creating dynamic routes for individual posts - Key idea: Use Next.js dynamic routing with WordPress post slugs - Evidence: "You can do it with route with square brackets...the slug will be in here in the URL" #### ⏱️ [15:30](https://www.youtube.com/watch?v=2BUZUjtz5sM&t=930) — [H1] Next.js caching strategies for WordPress content - Key idea: Static generation provides performance but needs revalidation strategy - Evidence: "the homepage is statically rendered...the HTML for that route is created and that will just be cached on a CDN" #### ⏱️ [17:00](https://www.youtube.com/watch?v=2BUZUjtz5sM&t=1020) — [H2] Implementing ISR with revalidate - Key idea: ISR balances performance with content freshness - Evidence: "this page will be cached for 1 minute...this is like ISR incremental static regeneration" #### ⏱️ [19:15](https://www.youtube.com/watch?v=2BUZUjtz5sM&t=1155) — [H2] Using generateStaticParams for dynamic routes - Key idea: Pre-generate static pages for all WordPress posts at build time - Evidence: "generate static params function...specify for all possible slugs for which we want to generate a page during the build" ## 📚 References - [WordPress REST API Documentation](https://developer.wordpress.org/rest-api/) - [Next.js ISR Documentation](https://nextjs.org/docs/app/building-your-application/data-fetching/incremental-static-regeneration) - [Cloudways Hosting Platform](https://www.cloudways.com/) ## 🗣️ Paraphrase - WordPress can function as a backend content management system while Next.js handles the frontend, connected through REST API calls - Caching strategies must be coordinated between WordPress server-level caching and Next.js application-level caching for optimal performance - Dynamic routing in Next.js combined with generateStaticParams enables static generation of all WordPress posts at build time ## 📰 Newsletter **Headless WordPress + Next.js: Modern Content Management Made Simple** Discover how to combine WordPress's familiar content management with Next.js's modern frontend capabilities. This approach lets your content team continue using WordPress while developers build with React-based tools. **Key Benefits:** - Keep existing WordPress content workflows - Gain modern frontend performance and flexibility - Use WordPress REST API for seamless data fetching - Implement smart caching with ISR for fresh content **Getting Started:** Set up WordPress with REST API access, create a Next.js app, and fetch content via standard HTTP requests. Configure caching strategies to balance performance with content freshness. **Pro Tip:** Exclude WordPress API endpoints from server-level caching during development to see content changes immediately. Resources: [WordPress REST API](https://developer.wordpress.org/rest-api/), [Next.js Documentation](https://nextjs.org/docs), [Learn WordPress](https://learn.wordpress.org/) ## ✅ Action Items #### DevRel - Developer education: Create workshops on headless WordPress architecture patterns - Documentation: Develop REST API integration guides for popular frontend frameworks - Developer experience: Build starter templates for common headless WordPress setups #### WordPress - Core: Improve REST API performance and caching documentation - Documentation: Expand headless WordPress guidance on DevHub - Community: Support headless WordPress meetup presentations and case studies #### Community - Contributors: Guide headless WordPress plugin development best practices - Ecosystem: Foster headless WordPress ecosystem coordination between WordPress and JavaScript communities ## 🧪 Hypotheses - Headless WordPress adoption increases when developers can maintain existing content management workflows - ISR implementation reduces server load while maintaining content freshness for most use cases - GraphQL vs REST API choice depends more on developer familiarity than technical requirements - Hosting platform caching configuration significantly impacts headless WordPress performance ### 📊 Methodology - Performance testing comparing traditional vs headless WordPress implementations - Developer survey on headless WordPress adoption barriers and motivations - Cache hit ratio analysis across different revalidation strategies ### ❓ Questions - How does headless WordPress performance compare to traditional WordPress with modern caching? - What are the optimal revalidation intervals for different content types and update frequencies? - How can WordPress admin UI be enhanced specifically for headless use cases? ### 🔮 Future Research - WordPress admin interface optimizations for headless workflows - Performance benchmarking of different headless architecture patterns - Integration patterns with modern deployment platforms and CDNs ### 💡 Implications - Practice: Headless WordPress enables modern frontend development while preserving content management familiarity - Education: Developers need training on both WordPress REST API and modern frontend caching strategies - Security: API endpoint security becomes critical when WordPress serves as headless backend - Performance: Caching coordination between WordPress and frontend frameworks requires careful configuration ### 🧠 Learning Styles Assessment Reading level estimate: Grade 10-12 #### 👀 Visual learners - Present: Code examples, terminal output, browser screenshots - Improve: Architecture diagrams showing WordPress-Next.js data flow, caching visualization #### 🔊 Aural learners - Present: Video tutorial format with narrated explanations - Improve: Audio summary of key technical concepts and decision points #### 🗣️ Verbal learners - Present: Clear technical terminology definitions, step-by-step explanations - Improve: Analogies for caching concepts, comparison with traditional WordPress #### 🧩 Kinesthetic learners - Present: Complete hands-on tutorial with working code examples - Improve: Interactive coding exercises, troubleshooting checklists #### 🧠 Logical learners - Present: Sequential build process, clear cause-and-effect for caching decisions - Improve: Decision trees for caching strategies, performance metrics #### 🧑‍🤝‍🧑 Social learners - Present: Implicit community discussion through tutorial format - Improve: Discussion prompts, community examples, team workflow considerations #### 🧘‍♀️ Solitary learners - Present: Self-contained tutorial with individual project setup - Improve: Self-assessment questions, independent exploration suggestions #### 🌿 Naturalistic learners - Present: Real-world hosting platform integration - Improve: Ecosystem thinking about WordPress and JavaScript communities ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading structure in tutorial, descriptive link text - Improve: Alt text for code screenshots, ARIA labels for interactive elements #### Keyboard navigation - Present: Standard video controls accessible via keyboard - Improve: Keyboard shortcuts for code sections, skip links for tutorial sections #### Contrast and readability - Present: High contrast code examples, readable font sizes - Improve: Dark mode code examples, increased line spacing #### Text resizing and reflow - Present: Responsive video player and text content - Improve: Ensure code examples remain readable at 200% zoom #### Media and captions - Present: Video tutorial format - Improve: Closed captions, downloadable transcript, audio descriptions #### Forms and interactions - Present: Standard form elements in examples - Improve: Form validation examples, accessible error handling ### 🌍 DEIB Assessment #### Cultural breadth - Present: Global hosting platform options mentioned - Improve: Multi-region deployment considerations, internationalization examples #### Inclusive language - Present: Gender-neutral technical language, defined jargon - Improve: Plain language summaries, avoid framework-specific idioms #### Neurodiversity support - Present: Structured tutorial format, consistent code patterns - Improve: Content warnings for rapid screen changes, summary sections #### Representation - Present: Technical content focuses on code and concepts - Improve: Diverse example use cases, varied business contexts #### Psychological safety - Present: Encouraging tone about learning complex topics - Improve: Explicit acknowledgment of learning curve, beginner-friendly alternatives ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Clear technical cause-and-effect for caching decisions - Inductive strength: Generalizes from specific Next.js example to other frameworks - Causal reasoning: Explains why headless architecture provides specific benefits - Analogical strength: Implicit comparison to traditional WordPress architecture #### Fallacies - Appeal to novelty: Slight bias toward "new shiny framework" without discussing tradeoffs - Hasty generalization: Claims about caching needs may not apply to all use cases #### Tone of voice - Overall tone: Educational and encouraging, with practical focus on implementation ### 🛡️ DARVO Analysis - Deny: No denials or minimization present - Attack: No attacks on accusers present - Reverse victim/offender: No victim/offender dynamics present - Emotional cues and rhetoric: Positive technical education with enthusiasm for modern development ## 🎯 Conclusion Headless WordPress with Next.js provides a powerful architecture for teams wanting to modernize their frontend while maintaining familiar content management workflows. The key technical considerations involve coordinating caching strategies between WordPress and Next.js, implementing appropriate revalidation intervals, and configuring hosting platforms for API performance. This approach enables developers to leverage WordPress's mature content management capabilities while building with modern React-based frameworks and deployment patterns. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad Purpose: Stage CEE units that become Literature notes. Split level: H3 ### [H1] WordPress REST API enables headless CMS architecture > [!quote] [Headless WordPress + Next.js Is A Game Changer](https://www.youtube.com/watch?v=2BUZUjtz5sM) by [[ByteGrad]] via [[YouTube]]. Published 2024. Accessed 2024-12-28. > "you can pull in data into your app using the WordPress REST API that comes with WordPress by default" Demonstrates practical implementation of headless WordPress using --- ## Full Transcript [00:00] Hey everyone, in this video we're going [00:01] to talk about how you can use your [00:02] WordPress instance as like a headless [00:05] CMS for a custom well next.js front end [00:08] in this case, but you may use a [00:10] different framework like React Vit or [00:12] some other full stack framework and the [00:14] fundamentals will stay the same. And [00:16] those are that you can pull in data into [00:18] your app using the WordPress REST API [00:21] that comes with WordPress by default, [00:23] but they actually also have a GraphQL [00:25] option if you prefer that. So, in this [00:27] video, I quickly want to go over how you [00:28] can do that. Some tips and tricks, show [00:30] you that it's a very realistic option. [00:32] And I think this can be really helpful [00:33] because maybe you are already familiar [00:35] with WordPress or you have clients that [00:37] want to stick to WordPress cuz they're [00:38] already familiar with it, right? So, you [00:40] may simply want to use WordPress, but [00:41] you may want to use a more new shiny [00:44] framework for the front end and that is [00:46] totally doable. And I will explain how [00:48] it works with uh caching as well, right? [00:50] So, in XJS, we have a bunch of caching. [00:52] So what you see here is actually an XJS [00:54] application that has data here and that [00:56] is coming from a separate WordPress [00:59] instance. So how can we do that? Let's [01:01] actually start from scratch, right? So [01:02] I'm just going to ignore the styling in [01:04] this video. You can style it like a blog [01:06] or whatever your use case is. The [01:08] essential thing is how can we get the [01:09] data into the next JS app and how do we [01:12] deal with caching like SSG and uh [01:15] revalidation and ISR. I'll explain what [01:18] those are. All right, so let's jump into [01:20] it. So I have a completely new folder [01:22] here. I have no app in here. I'm just [01:25] going to create a new NexJS app. Brand [01:28] new NexJS16 as of recording. All right. [01:30] And let me actually run the dev server [01:32] as well. And let's open it up. All [01:34] right. So here we have the standard [01:35] NextJS boiler plate. Let me remove this [01:37] boiler plate here. So we just have an [01:39] empty page. So I will just say hello [01:41] here. All right. So now you can see I [01:43] have one page here, the homepage, and [01:44] it's just displaying hello text. But we [01:47] want to display, let's say, posts from [01:49] our WordPress instance. Now, we will [01:50] need some WordPress instance. I'm going [01:52] to use Cloudways in this video. Yes, [01:54] they're also today's sponsor, but I had [01:55] a great time using them. And as of [01:57] recording, they actually have a great [01:58] sale going on. So, check out the link in [02:00] the description. And make sure to use my [02:02] coupon code, which I will display here [02:04] to get an even better price. So, if you [02:06] want to follow along, go ahead and [02:08] create a WordPress instance here with [02:10] Cloudways. Really powerful hosting [02:11] platform. And let me actually show you [02:13] that. So I will go ahead and go here [02:15] into the dashboard. The way it works is [02:17] that we can buy a server and you can [02:20] have multiple applications on one server [02:22] but by default we can get started with [02:24] one application. You can see it's [02:25] optimized for all sorts of PHP [02:27] applications. I will just go with a [02:28] default WordPress installation. Here I [02:31] can just say first app first server. For [02:33] the application stack they actually have [02:34] a lightning stack now which can be [02:37] faster. And then we can pick the [02:38] provider for the server. So, Cloudways [02:40] is actually a digital ocean company, but [02:42] they allow you to pick from these other [02:44] providers as well, in case you do prefer [02:46] that. We can pick the server type and we [02:48] can pick how powerful it should be. And [02:50] then we can pick the location. I [02:52] recommend that you pick the location [02:53] that is the closest to your actual [02:55] users, not yourself, to your actual [02:56] users. And then you can click on launch. [02:58] All right. So, after a few minutes, it's [03:00] good to go. We we have all the settings [03:02] here for the server itself. But we want [03:04] to see the actual applications on the [03:06] server. So here you can see the actual [03:08] details including access to the admin [03:11] panel and actually let's go to the admin [03:13] panel right here. I have my credentials [03:15] right here automatically generated here [03:17] by cloudways and I will log in right [03:19] here. All right, here we go. Here we [03:21] have our admin panel and here we have [03:23] our site just a standard boil plate. If [03:24] I go to posts now you can see by default [03:26] there is this hello world post. Let's [03:28] just add another post here. So we have [03:30] two. I will call that second post. This [03:32] is the second post. I will go ahead and [03:35] publish that. Cool. So now if I go there [03:37] on the front end that you get out of the [03:39] box with WordPress, uh this is what we [03:41] see. Now of course we want to have our [03:43] own custom front end with Nex.js in this [03:45] case. So how do we get these posts into [03:47] our next JS app? Well by default [03:49] actually you get a REST API. So if you [03:52] use the URL for your site, this is the [03:54] one I got from Cloudways. And then if [03:56] you tag on this bit here and if I go [03:58] there I actually have a bunch of data [04:01] here. This is in so-called JSON format. [04:04] I can click on preprint here to format [04:06] it nicely. Now what I see here are [04:08] actually those posts that we have. So [04:11] you can see this piece here is one post, [04:13] right? So here you can see title is [04:15] second post. It has an ID and if we [04:18] scroll down a little bit and here we can [04:19] see the content, right? The actual this [04:21] is the second post. We also see a slug [04:23] here. So if you're building a blog and [04:26] you want to have a slug in the URL, you [04:28] can use this. So this is all the data [04:30] about that one post. And then if I [04:32] scroll down, there is another post here [04:34] with a different slug and with its own [04:36] data as well. So there are two posts [04:38] here. Now, by the way, there's also an [04:39] option here for pages instead of posts. [04:42] So maybe that is something that you want [04:44] to use. But in this video, we'll focus [04:46] just on these posts here. So of course, [04:48] I can go here directly in the URL. But [04:50] how do we get this in the in my app here [04:52] right here? Now, I should mention there [04:53] are also plugins to use GraphQL instead [04:55] of the REST API. However, in this video, [04:57] we'll just use this. Okay, so now how do [04:59] I get that data into my actual NexJS [05:01] app? Well, here in the page component, I [05:03] can just make a fetch call, right? This [05:05] is a server component. We can fetch data [05:07] directly in here and we just have to use [05:08] that URL that we just used in the URL [05:11] address bar. So, it's my Cloudways URL [05:13] and then it's that piece at the end. I'm [05:15] just parsing that and that's JSON data. [05:17] So, I'm parsing that here and then I'm [05:20] just logging it here, not displaying it [05:21] on the page yet. Now when I do that you [05:23] will see the you you can see here the [05:26] log here in my terminal because it runs [05:28] on the server right server component but [05:30] you can see we get the same data here [05:32] that we just saw in the browser as well. [05:34] So now we can just display that here on [05:35] the page right so I can have like an H1 [05:38] and then just map over each of these [05:40] posts. Now if I go to my homepage you [05:43] can see I have blog post and then I have [05:45] second post and let me actually show it [05:47] like this. So you can see now I have [05:48] second post that's the [05:50] post.title.rendered rendered and then we [05:52] are also displaying the content and this [05:54] is the second post and then we have the [05:55] other post with this title and content [05:58] and let me actually remove the H1 so we [05:59] just have those post and let me actually [06:01] add a border to the bottom of each post [06:04] here right so now I've been able to get [06:06] data from my WordPress instance [06:07] basically use it as like a headless [06:09] WordPress right so now I can manage my [06:11] content from this dashboard pull it into [06:14] my next JS app so if I make a change [06:16] here and I add a bunch of exclamation [06:18] marks and I save here so post update did [06:21] it. All right. Now, when you make a [06:22] change and you don't see it reflected in [06:24] the app, there may actually be an issue [06:25] with caching. We'll talk more about this [06:26] later, but basically there is caching at [06:29] the Nex.js app level, that's actually [06:31] not the issue that I ran into. There's [06:33] also caching at the WordPress instance [06:35] level, right? So, typically this is [06:37] actually really beneficial because it's [06:39] going to be much faster. So, we we [06:41] typically do want it. However, we may [06:43] just want to exclude the API URL from [06:47] that caching. Right? So, here I have the [06:48] Breeze plugin. I can exclude a URL. So [06:52] everything here with WordPress JSON, I'm [06:54] just going to exclude from here. So that [06:56] if I make a change here and if I save [06:58] here and now if I refresh, you can see [07:02] it's updated here. There are a couple of [07:03] tricks by the way that we can do with [07:04] the URL as well. So I can add this [07:07] underscore embed here. And if I then log [07:09] the data that we get, it will actually [07:11] give you additional information that you [07:13] perhaps would have had to make an [07:15] additional request for. It comes now [07:17] included as part of this payload. for [07:19] example, an image URL or author [07:22] information. You can also specify the [07:24] exact fields that you want. So if I do [07:26] this, I only get the ID, slug, title, [07:28] and the content here. This may reduce [07:30] the payload as well as the speed. Now, [07:32] if you have many posts and you have like [07:34] pagionation, there are some settings for [07:36] that here as well. And actually, if you [07:38] have a search functionality, there is [07:40] actually a built-in search feature here [07:41] as well. So you can see if I'm searching [07:43] for the word second, it only gives me [07:45] that post, that keyword. So the second [07:48] post in this case you can also specify [07:50] the order by. So if you want to have it [07:52] sorted in a particular that is possible [07:55] and there are also options for [07:56] filtering. So for example only the post [07:58] in a particular category with a certain [08:00] tag. Now if you're building a blog we [08:02] can use that built-in slug property. So [08:05] we can just use the nextjs link [08:07] component and then uh make it /ost the [08:10] slug. So instead of displaying the [08:12] content here we're going to put it on [08:13] its own page. So I have created a new [08:15] page here in XJS. You can do it with [08:16] route with square brackets. So then when [08:19] you click on one of them the slug will [08:21] be in here in the URL. So we need to [08:22] grab the slug from the URL. We can do [08:24] that with params. We can get we can get [08:26] the slug like this. And then we need to [08:28] fetch the that individual post's data. [08:31] So we can do that with slug is and then [08:34] the slug from the URL. Right? So then we [08:36] can render its title and content very [08:38] similarly. Right? Just like before, but [08:40] now it's on its own page. So now if I go [08:42] to this one, you can see I get the data [08:44] just for that one post. All right. Now [08:46] what about caching everyone's favorite [08:48] topic. Uh so we just saw that there is [08:50] actually already a cache at the server [08:53] level. So the WordPress instance [08:55] depending on where you host it in some [08:56] settings may already have some cache. So [08:59] if you're still prototyping or [09:00] developing your app, it's typically best [09:02] I think to exclude it from the cache or [09:04] have like separate environments. But [09:06] basically as you saw on the server [09:07] level, I excluded the WordPress API URL [09:10] from any caching. Now of course we do [09:12] want to have some caching at the next.js [09:14] level. Now at the next s level how it [09:16] does it work here with caching. If I run [09:18] a build you will see some information [09:21] about the pages. Right. So you can see [09:23] the homepage is statically rendered. [09:26] Right? So during the build the HTML for [09:28] that route is created and that will just [09:31] be cached on a CDN. Right? So it's going [09:33] to be very fast. But what happens if you [09:34] do add another post in your WordPress [09:36] instance? that homepage does need to be [09:39] well recreated you could say right so [09:41] because then there's a new post so we [09:42] need to create a new list here new a new [09:44] page with a new list so next has some [09:46] options that we can use so I can specify [09:50] revalidate here should be 60 seconds so [09:52] this so basically 1 minute so this means [09:55] that this page will be cached for 1 [09:59] minute so if you quickly add another [10:01] post in WordPress it's not immediately [10:04] recreated but after a minute or how it [10:07] will be recreated with the latest post. [10:09] So you will have a little bit of time [10:11] where it's out of date but with a block [10:13] like this that doesn't really matter. So [10:15] you can specify that here or in this [10:16] case I can actually also specify it here [10:18] in the fetch I can say next revalidate [10:21] in 60 seconds. So then it also knows [10:23] that this page needs to be regenerated [10:27] after uh every minute or so, right? But [10:30] if I run a build now, so now if I run a [10:32] build, you can see the page is still [10:33] static, right? So it's it's still going [10:35] to be very fast, right? But at some [10:36] point we will have new data. So it needs [10:38] to be fresh again. So it will be [10:40] revalidated every 1 minute. And so this [10:42] is like ISR incremental static [10:44] regeneration. And so with this refund [10:46] date option, we basically accept there's [10:48] going to be a small, you know, period of [10:50] time where it may be out of date. If you [10:52] want it to be immediately updated when [10:55] you make a change, we could create an [10:57] API endpoint, a route handler, and then [10:59] you need to send a web hook to your [11:01] next.js app, then in that web hook, you [11:03] can call validate path to trigger [11:06] recreation of that page. But for a blog, [11:08] this typically makes more sense. Now, [11:10] what about this other page? This is a [11:12] dynamic page. So during the build there [11:15] is no caching. So the reason it's [11:16] dynamic is because nextjs during build [11:18] time does not know all the possible [11:20] slugs that there could be. So it doesn't [11:22] know for which slugs it needs to [11:23] generate this page. Right? Because this [11:25] page depends on that. There is a [11:27] generate static params function here. [11:29] And we can then specify for all possible [11:32] slugs for which we want to generate a [11:34] page during the build. So I can actually [11:36] just fetch just the slugs of my posts in [11:39] my WordPress. And that's what I'm going [11:41] to return here. So basically an array of [11:42] slugs. So then if I run another build, [11:45] you can see now it has statically [11:47] generated two pages here thanks to this [11:50] option that you have as well. So this [11:52] function runs only during build time. So [11:54] I don't want to add caching here. But I [11:56] could specify the revalidate here as [11:58] well. So if I change the title or [12:00] something else about this blog post, [12:02] this is reflected at some point in my [12:04] application as well. But if the caching [12:06] is not completely clear to you, that's [12:07] totally fine. It's one of the most [12:09] complex topics in Next.js. I will have a [12:11] new video soon that will give you a good [12:13] explanation. Now, in the meantime, if [12:15] you want to spin up a WordPress [12:17] instance, I highly recommend you check [12:18] out Cloudways with the link in the [12:20] description and use my coupon code. [12:22] Right? So, really powerful platform. I [12:24] just have one application on my server [12:26] right now, but I could have multiple [12:27] applications, not just WordPress. If [12:29] you're in if you if you have a PHP [12:31] application or Laravel, something like [12:33] that, you can host that on that server. [12:35] They also have an autonomous option here [12:37] with autoscaling as well. It's built on [12:39] Kubernetes. So, if you're looking for a [12:41] scalable WordPress hosting solution, [12:43] check out Cloudways. In any case, I hope [12:45] this helps you out. Thank you for [12:47] watching and I hope to see you in the [12:48] next one.  ## 📺 Video ![](https://www.youtube.com/watch?v=2BUZUjtz5sM) --- # 📄 Full Transcript *Auto-generated from YouTube captions · timestamps roughly every 30 seconds · [watch on YouTube](https://www.youtube.com/watch?v=2BUZUjtz5sM)* **[00:00]** Hey everyone, in this video we're going to talk about how you can use your WordPress instance as like a headless CMS for a custom well next.js front end in this case, but you may use a different framework like React Vit or some other full stack framework and the fundamentals will stay the same. And those are that you can pull in data into your app using the WordPress REST API that comes with WordPress by default, but they actually also have a GraphQL option if you prefer that. So, in this video, I quickly want to go over how you can do that. Some tips and tricks, show **[00:30]** you that it's a very realistic option. And I think this can be really helpful because maybe you are already familiar with WordPress or you have clients that want to stick to WordPress cuz they're already familiar with it, right? So, you may simply want to use WordPress, but you may want to use a more new shiny framework for the front end and that is totally doable. And I will explain how it works with uh caching as well, right? So, in XJS, we have a bunch of caching. So what you see here is actually an XJS application that has data here and that is coming from a separate WordPress instance. So how can we do that? Let's **[01:01]** actually start from scratch, right? So I'm just going to ignore the styling in this video. You can style it like a blog or whatever your use case is. The essential thing is how can we get the data into the next JS app and how do we deal with caching like SSG and uh revalidation and ISR. I'll explain what those are. All right, so let's jump into it. So I have a completely new folder here. I have no app in here. I'm just going to create a new NexJS app. Brand new NexJS16 as of recording. All right. And let me actually run the dev server **[01:32]** as well. And let's open it up. All right. So here we have the standard NextJS boiler plate. Let me remove this boiler plate here. So we just have an empty page. So I will just say hello here. All right. So now you can see I have one page here, the homepage, and it's just displaying hello text. But we want to display, let's say, posts from our WordPress instance. Now, we will need some WordPress instance. I'm going to use Cloudways in this video. Yes, they're also today's sponsor, but I had a great time using them. And as of recording, they actually have a great sale going on. So, check out the link in the description. And make sure to use my coupon code, which I will display here **[02:04]** to get an even better price. So, if you want to follow along, go ahead and create a WordPress instance here with Cloudways. Really powerful hosting platform. And let me actually show you that. So I will go ahead and go here into the dashboard. The way it works is that we can buy a server and you can have multiple applications on one server but by default we can get started with one application. You can see it's optimized for all sorts of PHP applications. I will just go with a default WordPress installation. Here I can just say first app first server. For the application stack they actually have **[02:34]** a lightning stack now which can be faster. And then we can pick the provider for the server. So, Cloudways is actually a digital ocean company, but they allow you to pick from these other providers as well, in case you do prefer that. We can pick the server type and we can pick how powerful it should be. And then we can pick the location. I recommend that you pick the location that is the closest to your actual users, not yourself, to your actual users. And then you can click on launch. All right. So, after a few minutes, it's good to go. We we have all the settings here for the server itself. But we want **[03:04]** to see the actual applications on the server. So here you can see the actual details including access to the admin panel and actually let's go to the admin panel right here. I have my credentials right here automatically generated here by cloudways and I will log in right here. All right, here we go. Here we have our admin panel and here we have our site just a standard boil plate. If I go to posts now you can see by default there is this hello world post. Let's just add another post here. So we have two. I will call that second post. This is the second post. I will go ahead and **[03:35]** publish that. Cool. So now if I go there on the front end that you get out of the box with WordPress, uh this is what we see. Now of course we want to have our own custom front end with Nex.js in this case. So how do we get these posts into our next JS app? Well by default actually you get a REST API. So if you use the URL for your site, this is the one I got from Cloudways. And then if you tag on this bit here and if I go there I actually have a bunch of data here. This is in so-called JSON format. I can click on preprint here to format **[04:06]** it nicely. Now what I see here are actually those posts that we have. So you can see this piece here is one post, right? So here you can see title is second post. It has an ID and if we scroll down a little bit and here we can see the content, right? The actual this is the second post. We also see a slug here. So if you're building a blog and you want to have a slug in the URL, you can use this. So this is all the data about that one post. And then if I scroll down, there is another post here with a different slug and with its own **[04:36]** data as well. So there are two posts here. Now, by the way, there's also an option here for pages instead of posts. So maybe that is something that you want to use. But in this video, we'll focus just on these posts here. So of course, I can go here directly in the URL. But how do we get this in the in my app here right here? Now, I should mention there are also plugins to use GraphQL instead of the REST API. However, in this video, we'll just use this. Okay, so now how do I get that data into my actual NexJS app? Well, here in the page component, I can just make a fetch call, right? This is a server component. We can fetch data **[05:07]** directly in here and we just have to use that URL that we just used in the URL address bar. So, it's my Cloudways URL and then it's that piece at the end. I'm just parsing that and that's JSON data. So, I'm parsing that here and then I'm just logging it here, not displaying it on the page yet. Now when I do that you will see the you you can see here the log here in my terminal because it runs on the server right server component but you can see we get the same data here that we just saw in the browser as well. So now we can just display that here on the page right so I can have like an H1 **[05:38]** and then just map over each of these posts. Now if I go to my homepage you can see I have blog post and then I have second post and let me actually show it like this. So you can see now I have second post that's the post.title.rendered rendered and then we are also displaying the content and this is the second post and then we have the other post with this title and content and let me actually remove the H1 so we just have those post and let me actually add a border to the bottom of each post here right so now I've been able to get data from my WordPress instance basically use it as like a headless **[06:09]** WordPress right so now I can manage my content from this dashboard pull it into my next JS app so if I make a change here and I add a bunch of exclamation marks and I save here so post update did it. All right. Now, when you make a change and you don't see it reflected in the app, there may actually be an issue with caching. We'll talk more about this later, but basically there is caching at the Nex.js app level, that's actually not the issue that I ran into. There's also caching at the WordPress instance level, right? So, typically this is actually really beneficial because it's going to be much faster. So, we we **[06:41]** typically do want it. However, we may just want to exclude the API URL from that caching. Right? So, here I have the Breeze plugin. I can exclude a URL. So everything here with WordPress JSON, I'm just going to exclude from here. So that if I make a change here and if I save here and now if I refresh, you can see it's updated here. There are a couple of tricks by the way that we can do with the URL as well. So I can add this underscore embed here. And if I then log the data that we get, it will actually **[07:11]** give you additional information that you perhaps would have had to make an additional request for. It comes now included as part of this payload. for example, an image URL or author information. You can also specify the exact fields that you want. So if I do this, I only get the ID, slug, title, and the content here. This may reduce the payload as well as the speed. Now, if you have many posts and you have like pagionation, there are some settings for that here as well. And actually, if you have a search functionality, there is actually a built-in search feature here **[07:41]** as well. So you can see if I'm searching for the word second, it only gives me that post, that keyword. So the second post in this case you can also specify the order by. So if you want to have it sorted in a particular that is possible and there are also options for filtering. So for example only the post in a particular category with a certain tag. Now if you're building a blog we can use that built-in slug property. So we can just use the nextjs link component and then uh make it /ost the slug. So instead of displaying the **[08:12]** content here we're going to put it on its own page. So I have created a new page here in XJS. You can do it with route with square brackets. So then when you click on one of them the slug will be in here in the URL. So we need to grab the slug from the URL. We can do that with params. We can get we can get the slug like this. And then we need to fetch the that individual post's data. So we can do that with slug is and then the slug from the URL. Right? So then we can render its title and content very similarly. Right? Just like before, but now it's on its own page. So now if I go **[08:42]** to this one, you can see I get the data just for that one post. All right. Now what about caching everyone's favorite topic. Uh so we just saw that there is actually already a cache at the server level. So the WordPress instance depending on where you host it in some settings may already have some cache. So if you're still prototyping or developing your app, it's typically best I think to exclude it from the cache or have like separate environments. But basically as you saw on the server level, I excluded the WordPress API URL from any caching. Now of course we do want to have some caching at the next.js **[09:14]** level. Now at the next s level how it does it work here with caching. If I run a build you will see some information about the pages. Right. So you can see the homepage is statically rendered. Right? So during the build the HTML for that route is created and that will just be cached on a CDN. Right? So it's going to be very fast. But what happens if you do add another post in your WordPress instance? that homepage does need to be well recreated you could say right so because then there's a new post so we need to create a new list here new a new **[09:44]** page with a new list so next has some options that we can use so I can specify revalidate here should be 60 seconds so this so basically 1 minute so this means that this page will be cached for 1 minute so if you quickly add another post in WordPress it's not immediately recreated but after a minute or how it will be recreated with the latest post. So you will have a little bit of time where it's out of date but with a block like this that doesn't really matter. So **[10:15]** you can specify that here or in this case I can actually also specify it here in the fetch I can say next revalidate in 60 seconds. So then it also knows that this page needs to be regenerated after uh every minute or so, right? But if I run a build now, so now if I run a build, you can see the page is still static, right? So it's it's still going to be very fast, right? But at some point we will have new data. So it needs to be fresh again. So it will be revalidated every 1 minute. And so this is like ISR incremental static regeneration. And so with this refund **[10:46]** date option, we basically accept there's going to be a small, you know, period of time where it may be out of date. If you want it to be immediately updated when you make a change, we could create an API endpoint, a route handler, and then you need to send a web hook to your next.js app, then in that web hook, you can call validate path to trigger recreation of that page. But for a blog, this typically makes more sense. Now, what about this other page? This is a dynamic page. So during the build there is no caching. So the reason it's **[11:16]** dynamic is because nextjs during build time does not know all the possible slugs that there could be. So it doesn't know for which slugs it needs to generate this page. Right? Because this page depends on that. There is a generate static params function here. And we can then specify for all possible slugs for which we want to generate a page during the build. So I can actually just fetch just the slugs of my posts in my WordPress. And that's what I'm going to return here. So basically an array of slugs. So then if I run another build, you can see now it has statically **[11:47]** generated two pages here thanks to this option that you have as well. So this function runs only during build time. So I don't want to add caching here. But I could specify the revalidate here as well. So if I change the title or something else about this blog post, this is reflected at some point in my application as well. But if the caching is not completely clear to you, that's totally fine. It's one of the most complex topics in Next.js. I will have a new video soon that will give you a good explanation. Now, in the meantime, if you want to spin up a WordPress instance, I highly recommend you check **[12:18]** out Cloudways with the link in the description and use my coupon code. Right? So, really powerful platform. I just have one application on my server right now, but I could have multiple applications, not just WordPress. If you're in if you if you have a PHP application or Laravel, something like that, you can host that on that server. They also have an autonomous option here with autoscaling as well. It's built on Kubernetes. So, if you're looking for a scalable WordPress hosting solution, check out Cloudways. In any case, I hope this helps you out. Thank you for watching and I hope to see you in the next one.