You Need a UX So Good It Gives Users Goosebumps

One of the primary signs that you need a Headless WordPress website is if you desire to provide an exceptional user experience. Headless architectures allow developers to utilize modern frontend technologies like React, Vue.js, or Angular to build highly interactive and responsive user interfaces.

Decoupling the frontend from the WordPress backend allows you to create faster, more engaging websites or applications that deliver a seamless user experience across multiple devices that’s so shockingly good you’ll think a wizard is in control.

Complex Content Delivery

An enterprise-grade site that demands complex content delivery across various channels or platforms is a compelling sign you need a Headless WordPress website. This was recently the case with the website project we completed for NBA G League.

Data from various APIs were integrated throughout the Headless WordPress Multisite Network of websites. Retrieving and displaying data from various sources becomes less complex with a decoupled frontend.

Hosting a decoupled frontend on the JAMstack virtually eliminates the threat of a WordPress server or database hack, since hackers don’t even know WordPress is installed in the first place. The backend, or admin dashboard in WordPress, can be hosted on a separate platform with unique authentication, keeping the separation between the public website and the admin dashboard disconnected.

When a traffic spike occurs, as is often the case during NBA games, they can rest assured that their site won’t go down because the frontend is nothing more than HTML, CSS, and JavaScript served by highly capable CDNs. There are no server-side rendering or database calls to slow things down.
Scalability and Performance

As your website grows, scalability becomes a crucial factor. Headless WordPress offers superior scalability compared to traditional WordPress setups. Since the frontend and backend are decoupled, you can independently scale each component based on its specific needs. Generally speaking, your admin dashboard will have less traffic, as only team members who need to manage the website and content will have access. The public view of the website, which all visitors see, handles the bulk of the load.

This flexibility allows you to handle high traffic volumes, optimize server resources, and ensure a smooth user experience even during peak times. Additionally, you can improve page load times and overall performance by offloading the frontend rendering to specialized systems or CDNs.

Customized Frontend Experiences

Headless WordPress is an excellent choice if your website demands a highly customized frontend experience. It enables developers to create tailored frontend interfaces without constraints imposed by traditional WordPress themes.

By leveraging modern frontend frameworks, developers can design unique, interactive user interfaces that align perfectly with their brand identity. Headless WordPress empowers developers to think beyond the traditional blog-style layouts and craft innovative and engaging digital experiences.

With headless CMS, your hands are free, and you are not locked to a specific framework or a library. You can build your frontend with React, Svelte, or anything that fits your requirements. You build the headless infrastructure once, and then you can tweak and use it in the future.
Integration with Third-Party Services

A sign that you need Headless WordPress is if your website relies heavily on third-party services or APIs. A headless WordPress setup can streamline integration processes. With the separation of concerns, developers can easily connect WordPress to various services or data sources, such as e-commerce platforms, CRM systems, payment gateways, or external databases.

This flexibility lets you leverage the best tools available in each domain while seamlessly integrating them into your WordPress-powered website.

When a Headless WordPress Website Might Not Be Ideal

Simple Content Publishing

A traditional WordPress setup might suffice if your website primarily focuses on content publishing and you don’t require complex frontend interactions. WordPress offers built-in themes and plugins that can cater to most content publishing needs without the complexity of a headless architecture.

Limited Development Resources

Headless WordPress, with its decoupled nature, often requires additional development resources. If you have limited time, budget, or technical expertise, opting for a traditional WordPress setup could be more practical.

Headless architectures generally involve more complex setups, custom development, and ongoing maintenance. You’ll need the help of an experienced team. Contact WebDevStudios.

Conclusion

A Headless WordPress website offers numerous advantages, such as enhanced user experience, flexible content delivery, scalability, and customization options. There are definite signs that indicate when you need a Headless WordPress website. However, it’s essential to carefully consider your specific requirements before embracing a headless approach.

If your website focuses primarily on content publishing without complex frontend interactions or if you have limited development resources, a traditional WordPress setup may be more suitable. By understanding the signs that indicate the need for a Headless WordPress website, you can harness the power of decoupled CMS to unlock new possibilities for your online presence. When you see the signs, contact WebDevStudios.

The post Spooky Signs That You Need a Headless WordPress Website: Unlocking the Potential of Decoupled CMS appeared first on WebDevStudios.

However, as we’ve begun entering content, we realized that we can make improvements to the editing experience for the client. In this blog post, we outline how by optimizing the WordPress Block Editor experience, we make it easier for editors to perform their jobs.

Background

The set of websites contains one main site and many subsites. We created several custom post types to handle a variety of content, some of which exist on both the main site and the subsites.

All custom post types contain meta fields, created with Advanced Custom Fields, which are used to add custom content to the post. Additionally, we use the content from two post types from the main site on the subsites.

To build the blocks for this website, we used Advanced Custom Field (ACF) blocks. For a Headless WordPress website, ACF makes it easy to structure data the way we want on the frontend, with minimal extraneous information.

Because of the complexity of information and the challenges of building a headless site, we wanted to make sure the editing experience was as straightforward as possible. We identified five ways to make improvements, optimizing the WordPress Block Editor. It’s all detailed below.

Instructional Text

When creating the blocks, we made sure to clearly label each field and add instructions for editors. We included information like image dimension requirements, character or word length limits, and location specifications (sidebar, main content, etc.).

With these instructions, editors can easily jump in and edit the website. They don’t need to search for documentation or be trained. This detail is especially important with 20+ subsites, each with different editors in different locations.

Tabs in Blocks

Advanced Custom Fields provides several layout fields, allowing you to organize content. We leveraged the tab field to separate sections and let users enter specific content in each tab.

For example, if we build a block that contains event details and a sponsor, we can create two tabs. One is for the event information, such as venue, time, etc. The other tab is to input the event’s sponsor information, such as the sponsor’s name, logo, and link.

This sounds so simple and obvious, yet this makes it more convenient than usual for users to add content. Would you prefer a long form where you scroll up and down in the editor or a tabbed block?

Leveraging the power of tabs keeps the user interface and experience better, which allows for optimizing the Block Editor experience for the editor.

Dropdowns

To decrease the chance of human error, we identified places where a dropdown select menu should be used instead of a text field.

Using Advanced Custom Fields, we were able to create custom dropdowns generated from post types and meta fields. For example, we have a block on the subsites that needs to return the ID for an organization, which is a custom post type on the main site.

Initially, we created a Text field for that input, but realized that it opened the door for user error. We changed the Text field to a Select field and queried the organization post type on the main site to get the organization ID from the meta field.

This allowed us to create the options in the Select field with the organization name as the display and ID as the return value. Using a Select field in this way significantly reduces the likelihood of human error, and allows for a more bespoke user experience on the backend.

Readonly Fields

Another way we have addressed the possibility of human error is through ‘readonly’ fields. This is helpful when you want to keep data intact on fields like identifiers imported from an API that doesn’t require any manual editing. The user can view the field values and confirm that content has been entered, but cannot change them.

Frontend Previews

ACF blocks are great for creating complex blocks quickly, but the editor loses the Gutenberg experience of seeing a styled block as they’re building a page. Additionally, since we’re using ACF blocks in a Headless WordPress website, an editor can’t see a preview of the page and blocks they’re editing in the Gutenberg editor.

That’s because the website doesn’t use a standard WordPress theme. Plus, the CSS, Javascript, and PHP aren’t pulled into the preview.

To solve this problem, we included a screenshot of the block as a tab, but our lead developer developed functionality that displays an iframe of the block from the frontend when the “Switch to Preview” button is toggled when editing the site. This lets editors preview the block with the content they’ve entered before saving the page.

Conclusion

Working on this complex site reminded our team that not only is frontend usability important, but the editor user experience is also equally important. If an editor can’t enter content correctly, it doesn’t matter what a website looks like or how it functions.

This brings us to the end of learning the ins and outs of optimizing the WordPress Block Editor experience. We’d love to know the steps you take to improve the editing experience for your WordPress websites. Please tell us in the comments below.

The post Optimizing the WordPress Block Editor Experience appeared first on WebDevStudios.

Why Not Remix?

Every day, we see new changes and improvements in the JavaScript ecosystem. Remix gained popularity with the hype from top website agencies and developers.

Is it worth the hype? Give it a try and you can conclude for yourself.

With in-built hooks and components, Remix makes it easy to fetch data, create dynamic routes, use forms and handle errors. It also comes with HTTP helpers to get responses in JSON and to redirect.

Remix offers only server-side rendering and that makes it different from Next.js. In this example, we will build a simple application that displays a list of posts from a WordPress blog and has a details page and a comments form.

I assume you are a React developer and used some other React-based frameworks like Next.js. This is not a step-by-step tutorial, yet covers the points that you will like to try and explore. Here is the repository for this demo if you like to see the code first.

Installation

Prerequisites

• Node.js 14 or greater
• npm 7 or greater

Start the installation by running the commands. This will ask you a series of questions that allows you to choose the location, typescript, and app server.

View the code on Gist.

This is the last step of the installation; you will get a message like:

That’s it! `cd` into "/Users/lax/local/remixwp" and check the README for development and deploy instructions!

README file contains more detailed information about the commands.

Folder Structure

• app – This is like the src/ folder in create-react-app (CRA), where the components of our app are located.
• node_modules
• public – A folder for static files like images and other public assets
• .gitignore
• jsconfig.json – A configuration file for the compiler
• package – lock.json and package.json
• Remix.config.js – Remix configuration file; keep the default config

Let’s start the development. Change your working directory to Remix-wp or the folder where you installed the app and run:

npm run dev

If any app is running on the default port 3000, Remix will increment the port number. In my case, my app started on port 3002 since I have 2 other apps running.

This index page is clean and easy to get started with bare minimal code. I chose just the basics for this demo without using any predefined templates.

Remix comes with a jokes app and a developer blog app example. You can install them and take a quick look.

App folder

The app is the heart of the application. Let’s see what it contains

• routes – Remix supports file-based routing. The folders and files here control the routes.
• entry.client.jsx – As the name suggests, this acts as the entry point for the client. HTML gets hydrated and added to DOM through this file.
• entry.server.jsx – This runs only on the server side. This acts as the entry point to the server and generates the HTML and server response.
• root – This file is equivalent to App.jsx of the CRA and the default component that loads first.

Tailwind

Install tailwind package.

npm install -D npm-run-all tailwindcss

Create Tailwind config file.

npx tailwindcss init

Update tailwind config and mention the files to be added.

content: ["./app/**/*.{ts,tsx,jsx,js}"],

Add the commands to scripts in package.json.

View the code on Gist.

Then, import tailwind on app/root.jsx.

View the code on Gist.

Add Document, Layout

As this app doesn’t contain a global document, layout, and error boundaries set. Let us add them to root.jsx.

This works similar to the Next.js Document file, where you load the child components and nest them to the main layout. Remix provides an outlet component that will render content according to routes. To keep the layout of the app uniform, let’s wrap the outlet component with a layout, which in turn is wrapped inside a document.

View the code on Gist.

Document will return the child components and the HTML markup, as described here.

View the code on Gist.

This is a simple layout that contains a header and footer.

View the code on Gist.

Setting up an error boundary is easy, as it comes out of the box with Remix. To keep things simple, I have added a console.log to check error messages on the log and also display them on the frontend.

View the code on Gist.

Components and Hooks

The header, footer, and comments form are the components of this app.

• Link – Used to add hyperlinks
• Form – Renders an HTML form and provides the submitted form data using the useActionData hook
• useLoaderData – This hook is the Remix version of getServerSideProps in Next.js. This allows you to fetch data and make it available via the loader function.

Routes

It is no wonder that routes are easy in Remix, as it is created by the same people behind React Router. You don’t have to manually define each route. A folder or a dynamic route that has ‘$’ in the file name would be considered a route.

Fetching data

Posts/index.jsx file fetches data and lists them out using the loader function. Each post item is linked to its detail page using slug as the dynamic route.

useParams hook is used to access parameters on the dynamic route.

View the code on Gist.

Comment Form

Import the form component. You can intercept the form submission and validate each field. Then, process the submitted data.

As a PHP developer, I found the usage of forms with Remix so exciting.

You can set the form action and access the submitted data there. In this example, we have a comments form and display the raw submitted comments. You can extend this by sending data to the WordPress source and displaying the response.

Deployment

Deployment instructions will get added to the README file during installation. You can deploy this app as you would deploy any node app.

npm run build

Then run:

npm run start

Test your app locally. Choose a host of your choice. I used Vercel to deploy this app. Once you choose the repository, Vercel will automatically pick up the configuration for build commands and run.

Conclusion

There are a few areas that you can continue working on in this example:

• Make the WordPress source URL an environment variable.
• Add components for each post item in the posts list.
• Add a frontend form to allow users to submit post content.
• Add a terms route for tags or category archives.

And the list goes on!

I hope you find this quick overview of Remix helpful. Try it out and let us know what you think in the comments below.

The post Creating Your First Remix App appeared first on WebDevStudios.

Headless WordPress Webinar

“Post Status Live: The Legend of the Headless Website” is aimed to be an easy-to-understand virtual introduction to this hot technology that has everyone talking. Topics covered include:

• Headless WordPress defined
• Whether or not this solution is a fit for your needs
• How and why a headless approach is faster, more secure and scalable
• How the technology supports advanced functionality
• Recommended list of tools, hosts, and partners for going headless

Headless WordPress Experts

Our panel of experts include:

• Brad Williams, CEO and Co-Founder
• Lisa Sabin-Wilson, COO and Co-Founder
• Greg Rickaby, Director of Engineering
• Amor Kumar, Frontend Engineer

Who Should Attend

Anyone curious about going headless stands to benefit from this free webinar.

• Marketers just hearing about Headless WordPress for the first time
• Developers who have not worked with the technology before
• Technologists looking for advice on implementation

Registration

Remember, this webinar is free and open to anyone.

• October 28th, Noon Central
• Registration link: wds.af/Headless-Webinar

Ready to go headless? You just might be. Register today for “Post Status Live: The Legend of the Headless Website,”  and let’s remove the fear from this growing website solution.

The post Headless WordPress Webinar appeared first on WebDevStudios.

Whether it’s fashion, up-and-coming authors, or the hottest TikTok challenge, marketers love to find ways to make trends work for their company or brand. For the past few years, website design and development companies have been talking about both Headless CMS and Headless WordPress. Lately, however, the chatter has increased significantly and beyond the walls and virtual hallways of internet technologists, inspiring marketers across the various commercial industries to ask, “Why is Headless WordPress trending? Should we go headless, too?”

At WebDevStudios (WDS), our WordPress agency is super excited about Headless WordPress and all the potential that accompanies this solution. However, because we’re passionate about WordPress, our enthusiasm is a bit biased. It would simply be irresponsible to push our zeal for Headless WordPress onto anyone without first empowering them with proper information.

That’s the point of this blog post—to provide you with the background intel you need to better understand why Headless WordPress is trending. Below, I have gathered pertinent Headless WordPress articles together to help guide you through the basics, peppered with a bit of a dev-oriented nudge for a deeper understanding. Then, after beefing up your knowledge, we hope you’ll be able to decide for yourself if this is in fact a passing fad or the best digital solution for your brand.

Headless WordPress: Taking Posts Everywhere

This blog post by Frontend Engineer, Scott Anderson, was our first attempt to address Headless WordPress from a high-level point of view. We had written about the topic previously from a technical and developmental angle, but Scott’s article gives a very basic overview that helps marketers and website owners understand what Headless WordPress is and what it can do for you.

Read “Headless WordPress: Taking Post Everywhere” for some easy guidance on the subject.

Headless WordPress and Headless CMS

Director of Engineering, Greg Rickaby, dives deeper into the topic. He begins his piece by first explaining what Headless CMS is, addressing its popularity. Greg even explains the subtle nuance between a decoupled frontend and a true Headless WordPress website.

What’s especially meaningful about Greg’s article is that he defines Jamstack and then lists out the benefits of going headless. Bookmark “Headless WordPress and Headless CMS” to share with your team later. It’s one of our most popular blog posts.

Using Next.js, WebDevStudios Built a 1,000 Headless WordPress Website

Yes. It’s true. It sounds incredible, doesn’t it? Well, it is quite a feat—building a 1,000-page Headless WordPress website. Nonetheless, our team made it happen.

When the time comes to research a viable example of a headless project, read and share “Using Next.js, WebDvStudios Built a 1,000 Headless WordPress Website” to learn about the challenges and success.

Is Headless WordPress the Right Solution for You?

This is the million dollar question, isn’t it? Discovering new technological solutions is exciting for any marketing executive, but using one without proper research can spell disaster.

Before diving into any Headless CMS, we urge you to thoroughly investigate the platform, weigh the pros and cons, then talk to some experts. Is Headless WordPress the right solution for you? Maybe, but before you decide, read this blog post.

Explore Headless WordPress Now

The technology is already available for you to investigate and play with today. Take a look at some options below. Also, there’s an upcoming webinar you won’t want to miss.

WebDevStudios Next.js WordPress Starter

Earlier this year, Greg announced the release of our own Next.js WordPress Starter, which is available to the public and is used for headless projects. You can watch a video of Greg talking about this starter and its importance here.

You are invited to access the WDS Next.js WordPress Starter on GitHub.

WP Engine Atlas

Longtime WordPress partner, WP Engine, has developed an enterprise-grade Node hosting platform called Atlas. Atlas is a headless framework plugin that has been designed to lock down the frontend. Learn more about Atlas at the WP Engine website.

Headless Webinar

In partnership with Post Status, WebDevStudios’ team of Headless WordPress experts are presenting “The Legend of the Headless Website” on October 28, 2021 at noon Central. This webinar is FREE. Register now.

For more details on this upcoming event, read our announcement blog post.

Talk to the Headless Experts

Now, you should have a greater understanding as to why Headless WordPress is trending. You’re equipped with resources and knowledge to help you make an educated decision about it. Are you ready to go headless? Contact us. We’re ready to get you there.

The post Why Is Headless WordPress Trending? appeared first on WebDevStudios.

It’s 2021, and WordPress is only growing in popularity, representing as much as 41.4% of all websites! If you are in the market to make a new website, perhaps you should consider Headless WordPress.

Because of the recent developments of Next.JS and WPEngine Atlas, this year is now the best time to get started. This article intends to help those who may not be full-time WordPress developers better understand what Headless WordPress means and if it’s a right fit for your organization.

If you’re wanting to get a little nerdy, I’ve already written a few other articles about Headless WordPress centered for developers: Headless WordPress: Making Your Own API Endpoints and Headless WordPress: Deeper Dive API Primer and How to Post to Other Platforms.

Let’s get started!

1. What is Headless WordPress?

Before you even consider committing to a Headless WordPress website, it would help to start with what makes a headless site any different from a normal WordPress site. Nearly all modern websites comprise two elements: what you see (the frontend) and what you don’t see (the backend).

The frontend consists of HTML, CSS, and JavaScript to present the site to you. The backend is where the data is stored and processed before being sent to the frontend. Today, most websites have the frontend and backend powered by the same technology framework, in our case, WordPress.

When we choose to go headless, we only use WordPress for the backend to easily store and edit our content while allowing a faster frontend framework, such as Next.js, to act as our frontend. The whole definition of a headless website is taking off the part that people see.

Note: If you would like to know more about Headless WordPress, check out my post on Headless WordPress: Taking Posts Anywhere.

2. Where is headless going?

Going headless is here to stay, but what are the current emerging changes to this space to be aware of? The two biggest areas where changes are happening are in the frontend space and the hosting space.

Frontend – NextJS

All the data in the world is useless unless users can see it. There are many great frontend frameworks to choose from, such as React, Angular, Vue.js, and more. If you pick any of these, you’ll have great support and documentation to get the job done. However, if you are not already sold on the framework, consider your next site build using Next.js. This framework is React but with so much more out of the box. Next.js provides tools such as internationalization to support multiple languages, hybrid rendering for faster load times, and so much more with little configuration required.

Backend – Atlas

A website is only as good as its hosting. Announced this Spring 2021, WPEngine has launched Atlas, “The complete Headless WordPress Platform for absurdly fast dynamic sites.”

Atlas, in a nutshell, is a new architecture used to develop your website. It’s designed to be fast, secure, and scalable. This means fast load times for your users, secure protection of your users’ data, and scalability, knowing that your site won’t go down as your business grows.

3. Headless WordPress Example

The Bill of Rights Institute provides thousands of resources about American history and government to classrooms around the nation. The site features a large user base and a vast library of content.

To achieve fast loading times, BillOfRightsInstitute.org is developed using a Headless WordPress installation and a Next.js frontend. These two framework choices allow for the website’s vast content to be easily managed in the WordPress dashboard while leveraging the speed benefits of a modern frontend framework.

4. Is it right for you?

WordPress is an infinitely flexible framework to build out your next big idea, from a simple blog to a multi-million dollar publisher and eCommerce platform. With its flexibility, you have thousands of pre-made site themes and plugins that allow you to make your dream with no coding required.

Unfortunately, at this time, there is no viable way to build a Headless WordPress without getting headless experts involved. That said, if you’re just getting started with your idea, or just need a simple website, Headless WordPress might not be for you. But, if your project vision is grand and requires the benefits of a decoupled frontend, Headless WordPress is a great way to go. When you need help, our WordPress agency can get you started!

The post Is Headless WordPress the Right Solution for You? appeared first on WebDevStudios.

Thanks to some well-placed WordPress hooks, we have technically had WPGraphQL support for a long while now, but never formally as part of the plugin itself. Jason Bahl, the creator and maintainer of WPGraphQL was also maintaining a Custom Post Type UI (CPTUI) extension that provided the UI fields to set and save WPGraphQL integration within the settings for post types and taxonomies registered with CPTUI.

Going into our March Five for the Future day, Greg informed me that Jason reached out about getting official integration for the two pieces, and after a touch of consideration, I agreed that it was time to merge them into one. Utilizing that day’s time, I set out to adapt and pull in Jason’s work into our primary plugin. If you are not using WPGraphQL at all with your site, or are perhaps not even sure what it is, you have nothing to worry about. We made sure to load the related changes only if the WPGraphQL plugin is available. If it is not, then you will only see the other 1.9.0 changes.

To help with transitions, we set up an admin notice for those with the now legacy CPTUI integration, letting the users know that they no longer need that original extension and can remove it without any loss of data. It should switch over seamlessly.

We are excited about the future of Headless WordPress and the types of creations developers around the world can produce with it. We are even more excited that users of Custom Post Type UI who are wanting to explore and try out Headless WordPress can now do so without having to leave us behind.

So what are you waiting for? Download or upgrade to Custom Post Type UI 1.9.0 and share with us what you are thinking about making in the comments below.

The post Custom Post Type UI Supports WPGraphQL appeared first on WebDevStudios.

Here at WebDevStudios, we recently used Context as a data store for WordPress menus in our Next.js WordPress Starter project. Context made accessing menu data from the Headless WordPress installation painless across the various navigational components.

In this article, we’ll take a quick look at the steps involved in setting up Context and how we used it to store menu data in the Next.js WordPress Starter.

How to Use React Context with Next.js

Implementing Context into Next.js applications can be broken down into the following tasks:

1. Create Context
2. Passing Data into Context
3. Importing Context into Components

Create Context

To begin, we need to initiate a new Context . This involves creating the Context object and setting up the Context Provider.

The Context object will be used to store the menu data and the Provider component is responsible for delivering the Context to its children when requested.

// components/common/MenuProvider.js
import { createContext, useContext } from 'react'

// Create Context object.
const MenuContext = createContext()

// Export Provider.
export function MenuProvider(props) {
	const {value, children} = props
	
	return (
	   <MenuContext.Provider value={value}>
		{children}
	   </MenuContext.Provider>
	)
}

// Export useContext Hook.
export function useMenuContext() {
	return useContext(MenuContext);
}

Passing Data into Context

The next step is to pass data into the Context object. For this, we’ll use the Context Provider (MenuProvider) that was exported in the first step.

In our custom Next.js App component, we fetch the menu data from pageProps, convert it to state (navMenu) and then pass it as a value prop to the MenuProvider component.

// ./pages/_app.js
import {useState} from 'react'
import {MenuProvider} from '@/components/common/MenuProvider'

export default function App({Component, pageProps}) {
  // Get menu data via GraphQL query in `pageProps`.
  const {menu} = pageProps

  // Store menu as state for the MenuProvider.
  const [navMenu] = useState(menu)

  return (
    <MenuProvider value={navMenu}>
      <Component {...componentProps} />
    </MenuProvider>
  )
}

Note: The menu data above is being queried via GraphQL from a Headless WordPress installation in getStaticProps. An example of the returned object array is shown below.

// Example object array returned from GraphQL.
const menu = [
  {
    label: 'Homepage',
    href: '/'
  },
  {
    label: 'About',
    href: '/about'
  },
  {
    label: 'Blog',
    href: '/blog'
  },
  {
    label: 'Contact',
    href: '/contact'
  }
]

Importing Context into Components

Now that we’ve created the MenuContext object and hydrated the object with data, it’s time to import the MenuContext object directly into our Navigation component for rendering.

For this, we’ll import the useMenuContext function created in step one and map over the results to display the individual menu items.

// ./components/header/navigation.js
import {useMenuContext} from '@/components/common/MenuProvider'

export default function Navigation() {
  const menu = useMenuContext() // MenuContext object.
  return (
    <ul id="primary-menu">
      {!!menu &&
        menu.map((item, index) => {
          return (
            <li key={index}>
              <Link href={item.href}>
                <a>{item.label}</a>
              </Link>
            </li>
          )
        })}
    </ul>
  )
}

The big advantage in using Context in this situation is you no longer have to worry about passing data around via props; you can simply import the object directly into components as needed.

When Context May Not be the Right Choice

We love the Context API for how it simplifies sharing state between unrelated or distant components in a tree. However, that simplicity can also become a major pitfall of the API if not used moderately throughout an application.

The issue with Context is simple—when the state of a Context object is updated it triggers a re-render within all consumer components. This can expose significant performance issues in an application if many components are being re-rendered every time a state value is updated.

When using Context, it’s good to take into consideration how many components will be affected by a single state update and act accordingly on your findings.

Wrapping Up

The React Context API is an intuitive way to share data and state across an entire Next.js application. Props that are typically global, such as locale, user authentication and navigational menus are just a few examples of how Context can be used to make prop sharing easier than ever.

What are you using Context for in your Next.js applications?

The post Quick Tip: Sharing Data in Next.js with React Context appeared first on WebDevStudios.

But what about making a headless WordPress site with GraphQL? How do you add your custom post types and custom meta fields to the GraphQL API?

It’s worth noting that our plugin for creating custom post types, Custom Post Type UI, now does this automatically! But if you’re not using a plugin to create your custom post types, read on to see the code behind the scenes.

I ran into this issue working on a personal website and using the WP GraphQL plugin. This website would be for my music, so I need a custom post type called “Album.”

View the code on Gist.

There are three extra arguments being passed to the register_post_type function: show_in_graphql, graphql_single_name, and graphql_plural_name. The first enables the custom post type to be added to the GraphQL API, and the last two give the name for the object:

That takes care of our custom post type! But what about the custom meta field?

View the code on Gist.

This code is a little more complicated, so we’ll step through it:

1. We hook into the graphql_register_types action. This will make sure that our next code is called at the right time.
2. We call the register_graphql_field field with:
   1. The name of the object we are creating the field on (“Album”)
   2. The name of the field we are creating (externalLinks)
   3. Extra arguments for the function
3. The extra arguments include a callback function that returns the value of the field.

For our callback function, we’re cheating a little bit. The meta field, find_links, can have multiple values. The purist approach would be to create a new GraphQL object and allow the links to be individually queryable. The pragmatic approach is to instead make our GraphQL field a String and encode the full meta field into a JSON object.

The end result here is that we get the data out of WordPress and into our Next.js frontend where we can use it.

You can see the full Next.js source code for my website on GitHub.

With a few tricks, it’s not hard to get the full power of WordPress into your Headless WordPress site. Using a decoupled frontend like Next.js means that the final website can be as complicated or as simple as it needs to be. And when it comes time to update or make new content, it’s as easy as… well, as easy as WordPress.

Want to see what we can do for you? Get in touch!

The post Quick Tip: Add Custom Meta Fields to GraphQL appeared first on WebDevStudios.

Next.js just blends into the background, so you can focus on building components and ship a JAMStack website in no time.

Background

Around that same time, I was rolling out our Gutenberg First initiative to help level-up our engineers and start shipping Gutenberg-based websites for our clients. JavaScript was on a lot of our engineers minds as well as potential clients. Sales leads were starting to come in with requirements around building headless WordPress. Admittedly, we did not have a solid process in place for building Headless WordPress websites.

Part of my role as Director of Engineering is to write those very processes; and in order to do that, I had to learn as much as I could about Next.js and WordPress. I had already made some contributions to the Next.js docs but noticed that they were building a WordPress Example so I offered to help. The team at Vercel was excited to collaborate, and a few weeks later, we shipped the official WordPress Example.

The official Next.js WordPress example is not very feature rich on purpose. It’s there to provide a low barrier of entry, so it wasn’t long after the official Next.js WordPress example shipped that we decided to fork it and started to add functionality. When our engineers had downtime, they were helping contribute to an alpha version of the WebDevStudios Next.js WordPress Starter.

We aimed to support advanced features like Menus, Custom Post Types, Gravity Forms, Custom 404 Pages, Yoast SEO, and more. Right in the middle of development, things got busy at WebDevStudios—so busy, that I was asked to jump in and lead some client projects, including a massive site rebuild with a headless frontend.

A Real Headless Project!

In August 2020, we began work on a huge project that involved moving a client from a traditional WordPress frontend to a decoupled one. The client’s website is very popular and their mission is to share educational content to educators and students across the United States. Their website was ranked on the first page of Google for several prominent keywords, and as such, received a large amount of traffic.

They were also managing over 1,000 pieces of educational, page-based content as blog posts (yikes). So, a total overhaul of the data architecture was needed. We paused work on our Next.js WordPress Starter, and took what we learned so far over to this new 1,000+ page Headless WordPress project.

The primary requirement was speed. The website had to have static content served from the JAMStack, but it also needed to dynamically update pages in the background without having to run a build. Other requirements included serving images from Amazon S3, 301 redirect management in WordPress, and over a dozen custom post types.

As Lead Engineer on the project, I was responsible for coming up with the technical stack and chose Next.js as the framework, since one of the key features of Next.js is Incremental Static Regeneration. This would help us meet the primary requirement. Other parts of the frontend stack included:

• Axios
• DayJS
• TailwindCSS
• Algolia
• ESLint, Stylelint, and Prettier
• Storybook
• Next Sitemaps
• Next Auth0
• Hosted on Vercel

The backend (WordPress) stack included:

• Advanced Custom Fields Pro
• CPTUI
• Formstack
• WP GraphQL (and several other addons)
• WP Offload Media
• WP Search with Algolia
• Yoast SEO Premium
• Vercel Deploy Hooks
• Hosted on Pantheon

In early September 2020, I assembled my team and away we went….

Challenges

Complex Data Structures

The previous implementation of educational content was poor at best. They were using posts, categories, and tags, along with a complex mixture of parent and child pages to manage relationships between those posts. The content team was mostly interns, and one of the challenges was onboarding them as content editors while trying to explain the relationship between everything.

After meeting with the migration team, we worked on restructuring their content into 17 different custom post types. This would make creating and managing content much easier for interns, since Lesson would be under “lesson,” a Resource would be a “resource,” and so on.

The challenge on the frontend would be querying all of these data types and their relationships via GraphQL.

Data Fetching

Because of the complex nature of the queries, one of the biggest challenges was server timeouts (status code 5xx errors) during builds.

This was in large part due to how the complex relationship between data in WordPress was structured, but the tooling was also a problem…Take a look at the screenshot below which was taken during a build. There were 1.25 million requests to WP GraphQL in one minute alone!

While Incremental Static Regeneration is amazing, it doesn’t come free! The whole “updating in the background” concept really means dozens of server(less) functions (spread over 1,000+ pages) querying WordPress and WP GraphQL constantly, which would literally take down the Pantheon server.

To help, we increased the Incremental Static Regeneration delay from one minute to 10 minutes. This update alone was a game changer. Additionally, we added the Axios Retry package, which also helped reduce 500 errors because retry requests are based on exponential backoff. Finally, we activated Redis caching and verified that GraphQL queries were being saved.

Was Axios the best choice for this project? No. In hindsight, I should have recommended Apollo Client, since it supports in-memory caching of queries. Given the complexity of the data structure, this could have reduced server load and build issues right out of gate.

Dependency Hell

Because we were using two stacks (WordPress and Next.js), it meant double the dependency hell.

Like WordPress plugins, NPM packages can easily be installed to help solve problems. I mean, why build your own date formatting system, when you can install DayJS instead?

The trouble was maintaining both WordPress Plugins and NPM Packages. Dependency updates for both stacks had to be carefully tested, and sometimes the site would build and test perfectly on our locals only to break the development environment. In the end, much of my time was devoted to maintaining and troubleshooting dependencies.

Error Handling

We still haven’t fully cracked the code on this one, but Next.js simultaneously has some of the best and worst error handling we’ve ever seen. Normally during development, Next.js will throw an error in the terminal and it’s very clear what’s going on. It can even display links to error codes for more information. This is awesome. However, during builds, this sorta falls on its face.

To quote one of the engineers from the project team:

Tracking down bugs was a nightmare. Documentation for both (and WP GraphQL) was decent on some things, entirely lacking in others, and sometimes wholly misleading. A lot of my work I had to just figure out on my own with no direction or reference points from the creators of the particular tool/API.

In fact, as I was writing this blog post, the client reported a section of the website was 404-ing. I quickly spun up my local and ran a build. No errors in the terminal nor in the console on the browser. But when I’d visit the page route? The page would 404! Again, no errors. Super frustrating! It took about 30 minutes to discover that there was an issue with a GraphQL query and pushed up a hot-fix. How can a statically generated website build successfully, yet still 404?!

Successes

Even though there were some challenges, the positives definitely outweigh the negatives. Remember when I mentioned the client’s requirement for speed? Well, Next.js websites are fast, like really fast! As expected with JAMStack based frontends, we definitely met the primary requirement for speed! Check out the screenshots from GTmetrix and WebPageTest.org.

Frontend Tooling: Github, Vercel, and Linting

We leveraged ESLint, Stylelint, and Prettier to enforce coding standards and deal with code formatting. Additionally, we used Husky + Lint-Staged to double check staged on the pre-commit git hook. This meant during pull request reviews, we could focus on how the engineers built their feature, instead of squabbling over semi-colons and spacing.

In addition to linting, Vercel has really, really impressive integration with Github. Each pull request was given its own unique build and URL for testing. This was great! An engineer could work locally, then open a draft pull request (which would kick off a testing build) so they could code in a Vercel-powered environment.

Finally, Chromatic made it possible to do UX/UI reviews on React components at the pull request level too. This was incredibly helpful as a Lead Engineer doing reviews. In the screenshot below, you can see the changes highlighted in bright green (bottom right):

I wish we could use this frontend workflow on every project; it was an absolute pleasure to work with.

Core Web Vitals

Google announced a new set of metrics for Lighthouse and PageSpeed Insights coming this year. They are:

• Largest Contentful Paint (LCP)
• First Input Delay (FID)
• Cumulative Layout Shift (CLS)

These metrics inform the “search signals for page experience,” which is a fancy way of measuring the perceived experience of a web page. The bottom line is that your website needs to load fast, be quick to accept interactivity from the user, and be visually stable.

Using Vercel Analytics, you can see how amazing our Next.js website (and Vercel as a host) are measuring with Core Web Vitals over a seven-day period.

Meeting these requirements will ensure the client’s website will retain its high rankings on Google.

Storybook

The first four weeks of the project was dedicated to building out atomic design-based components in Storybook. At first glance, that probably seems like way too much time, but once we were done? Implementing components throughout the React codebase just worked.

As one of the frontend engineers mentioned, working on components in isolation via Storybook made his developer experience a pleasure. The best part is now the client (and future developers) have access to a library of over 242 components.

Site Map and 301 Redirects

I feel like this topic doesn’t get enough attention among the development community, but it’s really important. As seen in the screenshot (earlier in this article), the client’s website is ranked on the first page of Google for several keywords; and migrating from a traditional WordPress frontend to a decoupled frontend (plus all the other data restructuring) would mean different URLs, thus the need for a new sitemap and 301 redirects to preserve their rankings.

Using Yoast SEO’s Redirect Manager, the client was able to import over 1,000 URLs and then manage every aspect of where they wanted them to point. Since Next.js supports redirects, we wrote a Node-based script that queries the list of 301 redirects via GraphQL, and writes them to redirects file at build time, which is then imported into next.config.js.

We also leveraged an NPM package named Next Sitemap, which also runs at build time, and creates a standard sitemap.xml as well as robots.txt, which we re-submitted to Google Search Console.

As you can see below, there was an initial dip since Google needed to re-crawl 1,000+ pages, but it quickly recovered, and the new website is tracking back toward the average position and click-through ratio it had prior:

Algolia

Leveraging our WP Search With Algolia plugin, we were able to easily index all of the client’s content and custom fields and push those indices to Algolia. On the frontend, we relied on Algolia’s React InstantSearch widget to create a live search field. We also used Algolia’s faceted search widget to refine the results.

One of the team members, Darren Cooney, shared some tips and tricks for using the WP Search With Algolia plugin based on the lessons we learned on this project.

Wrap Up

We learned a lot on this project. Sure, it had its moments, but in the end? I’m really proud of the work the team did and the partnership we’ve formed with the client. The engineering team has leveled up and has an entirely new skillset; and the client is especially thrilled about keeping the content management system they love and have a blazing fast JAMStack frontend.

We took all the lessons we learned and poured them into our Next.js WordPress Starter, an open-source project which we plan to use on future Headless WordPress projects. We love open-source at WebDevStudios, and invite you to give it a star on Github.

If you’re looking for an experienced team to develop your next Headless WordPress website, check out our headless solutions and services. If you’re ready to get started, contact us today.

The post Using Next.js, WebDevStudios Built a 1,000 Page Headless WordPress Website appeared first on WebDevStudios.