DEV Community: Fabian Reinders

Headless WordPress and Next.js

Fabian Reinders — Sat, 13 Jan 2024 14:52:10 +0000

Storyblok, Ghost, Markdown files… I’ve tried them all. And even though some CMS solutions out there bring incredible and innovative features, all roads led me back to WordPress as a CMS for my blog and portfolio.

This article breaks down my headless WordPress and Next.js setup and highlights some of of the things I’ve learnt while re-building my blog and portfolio website with this stack.

Why WordPress??

WordPress isn’t exactly the most modern CMS out there and unlike Storyblok, for instance, it has never been designated to work as a headless CMS.

The Gutenberg editor

This is probably a controversial take but I honestly like the Gutenberg editor a lot. For many use cases it still offers the best WYSIWYG(-ish) experience on the market and the customization options through plugins and themes are endless.

Especially when thinking about a portfolio that showcases projects, custom Gutenberg blocks can provide an amazing and interactive editing experience. This is, for instance, how I can edit a project on my portfolio page within the Gutenberg editor:

The ecosystem

Sometimes, you just want to get things done without having to re-invent the wheel. The fact that there’s a WordPress plugin out there for almost everything really helps with that

Implementing an email newsletter, an automatic table of contents, automatic Facebook posting… Adding such features can be done in a single click in WordPress.

Force of habit

WordPress is really wide-spread. Almost anyone who works with websites, has worked with it at least once in their life. This makes it the perfect choice for a CMS when building projects for clients who may not be as experienced with other systems and like working in their familiar environment.

And even I have to confess that the reason I used WordPress as a headless CMS for my website has to do with the fact I’ve been working as a WordPress developer a lot the last couple of years and have grown really fond of it.

My headless WordPress setup

Here’s a little drawing of how my setup looks:

VPS and Docker

In my previous article “Scaling Node.js Web Apps with Docker” I already talked about deploying and scaling a Next.js app on a VPS using Docker and Docker Compose. I still use that setup with slight modifications as it provides a simple and really cost-efficient way of deploying both the Next.js front end and the WordPress instance.

WP REST

The REST API built into WordPress already provides everything I need to query posts and other metadata such as taxonomy (category/tag data) and author data.

However, if GraphQL is your thing, I definitely recommend the WPGraphQL plugin.

The WordPress REST API is really easy to use which is why I didn’t opt for a client-side SDK within my Next.js app. All I did was build a very light wrapper around the HTTP calls to handle things like authentication and building the querystring:

/**
 * Light wrapper around the WordPress REST API to fetch resources.
 *
 * @param endpoint The endpoint to fetch from 'wp-json/wp/v2/{endpoint}'.
 * @param query The query parameters to append to the querystring.
 *
 * @returns The JSON response from the WordPress REST API.
 */
export const getWpRessource = async (endpoint: string, query: any) => {
  const WP_REST_API_URL = env.WP_REST_API_URL + '/wp/v2';

  // Create the querystring from the query object.
  const requestQueryString = querystring.stringify(query, { arrayFormat: 'bracket' });

  // Put together the full URL for the call.
  const requestUrl = `${WP_REST_API_URL}/${endpoint}/?${requestQueryString}`;

  // Make the HTTP request to the WordPress REST API using the fetch API.
  const response = await fetch(requestUrl, {
    method: 'GET',
    headers: {
      'Content-Type': 'application/json',
    },
  });

  // Return the JSON response.
  return await response.json();
};

Webhooks

Why do I need webhooks in the first place? I’ll go into detail about that a bit later in this post. For now, it’s just important to know that WordPress does not provide a way to create webhooks natively.

However, there are many plugins out there that take on that task. I created a very lightweight webhook plugin myself which I use in my setup. It’s called WP Hook Expose. WP Webhooks is a great option too, if you would like more control over your webhooks and the data they send.

Part 1: Building the blog

Building the blog on my website using Next.js for the front end and WordPress for the content was probably the most straightforward thing in the process.

Routing

Using the Next.js app router and the built-in file-based routing, the setup looks like this:

.
├── [slug]
│ └── page.tsx (A single blog post)
├── categories
│ └── [slug]
│ └── page.tsx (A single category)
└── page.tsx (Overview of all blog posts)

Exporting paths

To properly pre-render each blog page at build time, it is important to fetch the paths for each blog post and provide it to Next.js.

Statically fetching the paths from WordPress in [slug]/page.tsx looks something like this:

/**
 * Export possible paths for this page.
 */
export async function generateStaticParams() {
  // Get all post slugs from WordPress.
  const postSlugs = await getWpRessource('posts', {
    _fields: 'slug',
  });

  return postSlugs.map((post: { slug: string }) => ({ slug: post.slug }));
}

The paths are static and only fetched at build-time. They can, however, still be updated at a later point during runtime using On-Demand-Revalidation and webhooks. But more on that later!

Rendering the blog post

The rendered HTML for the blog posts can simply be retrieved through WP Rest and injected into the DOM using dangerouslySetInnerHTML:

/**
 * A single blog post page.
 */
const BlogPostPage = async ({ params }: { params: { slug: string } }) => {
  // Get the full post from WordPress.
  const posts: WP_Post[] = await getWpRessource('posts', {
    slug: params.slug,
    _embed: true,
  });
  const post = posts[0];

  // If the post doesn't exist, return a 404.
  if (!post) {
    notFound();
  }

  return (
    <main>
      <div className={styles.wordPressContent} dangerouslySetInnerHTML={{ __html: postContent }} />
    </main>
  );
};

And that’s it! Now all that’s left to do is building some styling around it and an overview page to list the blog posts.

Part 2: Building the portfolio

For the portfolio part of my website I wanted a bit more interactivity and client-side rendering. I implemented a lot of it in native React components.

Nevertheless, I wanted the content (in this case the projects to showcase) to be dynamic and editable at any time in WordPress.

That is why I decided to create a Custom Post Type for portfolio projects:

You can create Custom Post Types either through code or the plugin “CPT UI“.

The idea is that Next.js can query all posts of the post type “Portfolio Project” and render them in a designated area on the portfolio page.

The rendering of each project itself, however, is done by WordPress which gives you ultimate control over the look in the Gutenberg editor (perfect if you want to build your own blocks like me).

This way, we can even encapsulate different styles for different projects in our custom blocks (e.g. “Large Project”, “Projects Grid”, “Project Banner”, …).

But you can, of course, also just stick to the default blocks built into Gutenberg or use blocks of third-party plugins.

Updating posts and pages

As you can see above, so far the pages and paths are static. That means, Next.js will fetch all content and data from WordPress at build-time, render every page, and then never re-fetch data from WordPress.

This results in a great performance as we don’t have the overhead of additional HTTP requests or the overhead of all the dynamic PHP code and database queries WordPress needs to render a page.

But one would still want to update their content every once in a while… and re-building as well as re-deploying the entire site for that seems kind of exhausting.

A solution for that is On-Demand-Revalidation. This feature of Next.js allows you to re-build static pages on your site at runtime and only if necessary which results in a great balance between server-side-rendering and serving static assets.

Implementing On-Demand-Revalidation

One way to make On-Demand-Revalidation work in your Next.js app when using WordPress as a CMS is through API routes.

You simply create an endpoint in your Next.js app that can revalidate the cache and send a request to that endpoint everytime the content in WordPress changes.

In Next.js, you can create API endpoints using Route Handlers.

Here’s an example of how that could look like (/api/revalidate/route.ts):

export async function POST(request: NextRequest) {
  // Get the request body (JSON).
  const body = await request.json().catch(() => ({}));

  // Check if the request body has the required fields.
  if (body['wp_webhook_secret'] === undefined || body['args'] === undefined) {
    return new Response(JSON.stringify({ success: false, message: 'Missing token or args field.' }), { status: 400 });
  }

  // Check if the webhook secret is correct.
  if (body['wp_webhook_secret'] !== process.env.ADMIN_API_KEY) {
    return new Response(JSON.stringify({ success: false, message: 'Invalid webhook secret.' }), { status: 401 });
  }

  // Check if the args field has the required fields.
  if (body['args'][1]['post_type'] === undefined) {
    return new Response(JSON.stringify({ success: false, message: 'Missing post_type field.' }), { status: 400 });
  }

  // If post_type is post, revalidate the blog cache.
  if (body['args'][1]['post_type'] === 'post') {
    revalidatePath(`/blog`, 'page');
    revalidatePath('/blog/[slug]', 'page');
    revalidatePath('/blog/categories/[slug]', 'page');
    return new Response(JSON.stringify({ success: true, message: 'Post revalidation order created successfully.' }), { status: 200 });
  }
}

Implementing webhooks

Now, the only thing left to do is sending an HTTP request to this API endpoint every time content in WordPress changes.

There’s a bunch of different ways this can be done. For instance, you could build a custom WordPress plugin that hooks into the save_post action and send the HTTP request to Next.js from there.

Another way would be to use a plugin that enables you to create webhooks within WordPress.

I decided to build my own, lightweight plugin to do this. I didn’t really want the overhead of a full-fledged webhook plugin but I also didn’t want to hard-code everything in my WordPress instance.

My plugin is called WP Hook Expose and it is open-source and free for anyone to use. However, if you would like a plugin with a bit more configuration options, I can recommend WP Webhooks.

Conclusion

There are tons of amazing content management systems out there. What it comes down to is your personal preference and the kind of site you want to build.

For highly interactive sites it can be detrimental to render a big portion of your HTML outside of React. However, for content-driven sites that need extensive editing and content management WordPress is definitely worth a shot!

It ships with a huge ecosystem of plugins that can save a lot of time and many content editors and developers are familiar with WordPress and the Gutenberg editor.

Cheers!

📣 This post was originally published on my website on January 13, 2024.

SEO for Developers: Pagination

Fabian Reinders — Sun, 20 Aug 2023 08:38:41 +0000

Learn how to optimize SEO when using pagination on your website. This is a guide for web developers that covers my best practices, code examples, and tips to ensure your paginated content is accessible and visible to both users and search engines.

Introduction

Pagination is great! When your site grows in complexity and you have a lot of content that needs to fit on one page, Pagination can help you structure everything without overwhelming your users or increasing loading times.

Pagination divides the content into smaller, more manageable pages.

However, pagination can also present challenges for search engine optimization (SEO), as search engines may not always crawl all pages in a paginated series, potentially leading to a loss of visibility and traffic. In this blog post, we will explore some best practices for optimizing SEO when implementing pagination on your website or web app.

1. Use a consistent URL structure

Search engines and web crawlers are smart! They see certain patterns themselves. But for that, there must be patterns!

Therefore, I recommend to use a consistent URL structure for your paginated content.

A consistent URL structure could look something like this:

<a href="/page/1">1</a>
<a href="/page/2">2</a>
<a href="/page/3">3</a>

If you want to, you can remove the 1 for the first page.

Make it as clear as possible that the different URLs are the same content split into chunks.

DON’T do something like this:

<a href="/page-1">1</a>
<a href="/page-2">2</a>
<a href="/page-3">3</a>

and DON’T mix it up:

<a href="/page-1">1</a>
<a href="/page/2">2</a>
<a href="/page?p=3">3</a>

According to Google, It doesn’t matter if you include the page number in the path itself or as a parameter, so this example is okay too:

<a href="/?page=1">1</a>
<a href="/?page=2">2</a>
<a href="/?page=3">3</a>

Just be consistent about what pattern you use.

2. Implement rel=prev/next tags

Another very important tip. Not so much for Google, but for any other search engine this is crucial.

In case you didn’t know: You can use HTML tags in the <head> of your page to signal web crawlers the relations between your paginated pages and how they are linked together.

Imagine we’re browsing through a pagination and we’re on page 3.

Then, we can tell the browser/search engine/web crawler what the previous and next pages are using the <link> tags below:

<head>
  <link rel="prev" href="/page/2" />
  <link rel="next" href="/page/4" />
</head>

Google themselves say in their documentation:

“Google no longer uses these tags, although these links may still be used by other search engines”

So even though Google does not seem to use these tags anymore, they are still very much important for any other search engine.

3. Canonicalization of links

This tip is something you should be doing already, regardless of whether you have paginated content or not. But be careful! It’s very easy to mess up canonical links when dealing with paginated content.

What is canonicalization?

There’s another kind of <link> tag that can signal a search engine what the preferred URL for a piece of content is.

On a website, there are all kinds of redirects and a lot of ways duplicate content could end up on search engines, further decreasing your ranking.

One example: A web page is accessible at http and https . Boom! Now there are two versions of the same webpage.

Another example: A web page is accessible at www.fabiancdng.com and fabiancdng.com . Boom! Another version.

You can prevent this from being a problem by telling search engines that all these versions are the exact same piece of content by including the following tag in your <head> :

<head>
  <link rel="canonical" href="https://example.com/blog/posts" />
</head>

Now, the search engine knows that the preferred way of accessing this page is https://fabiancdng.com/blog/posts , regardless of how it got there.

Canonicalization and pagination

Canonicalization can also help you make sure search engines understand your link structure when you have paginated content BUT only if every sub-page has it’s own, unique canonical link tag.

Imagine we’re on page 3 of a blog:

https://fabiancdng.com/blog/posts/3

Correct ✅:

<head>
  <link rel="canonical" href="https://example.com/blog/posts/3" />
</head>

Incorrect 🚫:

<head>
  <link rel="canonical" href="https://example.com/blog/posts" />
</head>

Note: When on a sub-page, do not link back to the root page in the canonical link tag!

4. Optimize page titles and meta descriptions

My last tip is to use dynamic variables in page titles and meta descriptions that give more context and make them unique.

You could include the page number in the title and description, for instance.

<head>
  <title>Page {{ page_number }} - fabiancdng.com</title>
  <meta name="description" content="Page {{ page_number }} of our collection of articles on {{ category_name }}." />
</head>

Conclusion

By following these best practices, you can make it much easier for search engines to understand your site and its structure. Even when not all your pages are crawled at the same time and in a row (which is very likely), your chances of ranking in the search results and having search engines discover all the content on your page are high.

Cheers!

📣 This post was originally published on my website on April 9, 2023.

Scaling Node.js Web Apps with Docker

Fabian Reinders — Wed, 02 Aug 2023 18:04:06 +0000

This article explores how Node.js web applications can be scaled across multiple CPU cores and even machines using Docker.

Introduction

Deploying and scaling a Node.js web app (like a Next.js app) is easier than ever thanks to the cloud and serverless!

But what if you still want to be in charge of your own server architecture? Or maybe you just want to pay for your server resources and not your traffic or execution time?

Deploying your web app on a VPS (Virtual Private Server) is the perfect option in that case!

The problem with Node.js and single-threading

Node.js is single-threaded by nature. That means that it can usually only utilize one CPU core/thread and only achieve "concurrency" by switching between tasks on that single thread (the so called "Event Loop").

But what if your server has more than one CPU core? How can you leverage those to be able to handle more incoming traffic?

Utilizing multiple CPU cores with Node.js

Despite its single-threaded nature, Node.js still allows you to utilize multiple CPU cores.

Node.js introduced "cluster mode" to achieve some level of "multi-threading". However, because Node.js is still a single-threaded runtime, all cluster mode does is running multiple instances of your app each having their own interpreter/runtime.

There are also very popular third-party libraries like "pm2" that implement this concept. pm2 also has built-in load-balancing, so it's definitely worth checking out!

Multiple Node.js instances with Docker Compose

If you're already using Docker and Docker Compose in your setup, it can be a great alternative to skip implementing cluster mode or pm2 altogether.

You can just use Docker Compose to create multiple replicas of your Node.js app (a Next.js app in my case).

The `docker-compose.yml`

Docker Compose makes it super easy to create multiple containers running the same service ("replicas"). They can all utilize a different CPU core without the need for any tools or additional code in your app.

It just requires a little edit of the docker-compose.yml :

version: '3.7'

services:
  your-web-app:
    image: registry/.../your-website-image:latest
    ...
    deploy:
      replicas: 3
    ...

Simply add the deploy key to the service you want to replicate and specify the amount of replicas you wish (just like in the example above).

Load Balancing

The last thing you have to figure out now is load balancing. After starting your Docker Compose stack, there are three containers running the same application. Your reverse proxy or load balancer needs to evenly send requests to one of the replicas.

For an example setup see the example below.

A real-world example: This website

Let's take a look at my website fabiancdng.com as a real-world example:

The hosting requirements

My website is a Next.js application that uses Server Side Rendering (SSR) on some pages. Therefore, it needs the Node.js runtime and can't just be deployed as static assets.

I deployed the site in a Docker container (with Docker Compose) on a cheap VPS with 6 virtual CPU cores.

In configured Docker Compose to run three replicas of the Next.js app (all in their own container).

For routing and distributing incoming traffic evenly across the replicas, I need a reverse proxy that also acts as a load balancer.

The reverse proxy and load balancer

I use Traefik as a reverse proxy that takes all the incoming traffic to http(s)://*.fabiancdng.com/* and routes it to the corresponding Docker container within the internal Docker network.

NGINX is another popular solution for this purpose. And both NGINX and Traefik support load balancing.

In my case, Traefik supports load balancing between replicas of the same service out of the box so there was no additional configuration needed.

Once you've got your load balancing between the replicas in place, your traffic will be distributed among CPU cores, making your service able to handle many more incoming requests. 🥳 🎉

A look ahead: Scaling horizontally across machines

If you run this configuration using a container orchestration tool like Kubernetes or Docker Swarm, you can even scale your app horizontally this way. You can distribute the load not just across replicas on one server, you can have a ton of replicas running on a ton of different servers.

Docker Swarm has built-in load balancing between nodes. So if you plan on doing this, that might be worth checking out.

However, if your application has reached an amount traffic that is worth distributing across multiple machines, you might just consider moving to the cloud and a managed infrastructure.

Conclusion

Whether this is a good alternative to just moving to a managed service like Vercel or AWS Amplify (when deploying a Next.js app, for instance) or a managed container orchestration service is hard to tell...

Even though those services can get quite expensive for high-traffic sites, they often offer generous free-tiers and pay-as-you-go models. Also, they guarantee availability all around the globe thanks to edge routing and CDNs.

However, you can scale a loooong way with just a cheap VPS and you can protect yourself from unexpected costs for traffic or execution time. Also, you can deploy many different services on a single machine (maybe you would like a database or a free, open-source analytics tool as well?) and you can learn a lot about server administration, Docker and the complexity behind web applications and their architecture.

My recommendation: If you plan on building a full-stack side project or small SaaS and you need to deploy front end, back end, database, caching layer, etc., use a VPS, if you are okay with the additional configuration effort.

If you need to scale and you're just getting started with networking and backend engineering... Don't even bother with tools like Kubernetes. The growing complexity and maintenance effort to just keep your service running is likely not worth your time. Focus on building the app rather than the architecture around it and just use a cloud service.

Cheers.

📣 This post was originally published on my website on May 6, 2023.

Pagination in Next.js using SSG

Fabian Reinders — Sat, 17 Jun 2023 11:26:03 +0000

In this blog post, I will break down how I implemented pagination on my Next.js blog using Static Site Generation (SSG).

What is Pagination?

Pagination is a common technique used in web development to improve user experience when navigating through a large set of data. If you are building a blog using Next.js, you may need to implement pagination to display a limited number of blog posts per page.

In this article, we will discuss how to implement pagination in Next.js using Static Site Generation (SSG) or Incremental Static Regeneration (ISR).

As a real-world example, we'll take my blog that is built using Next.js and Storyblok CMS. I recently implemented pagination for the overview page showing all blog posts.

Feel free to take a look at the full code for that on GitHub.

The URL structure

First we need come up with a structure for the URLs as the pagination "parameters" like the current page need to be in there for SSG or ISR to work. For that we make use of Next.js Dynamic Routes.

The structure I decided to use:

`/blog`

Simply redirecting to /blog/posts/ .

`/blog/posts`

First page showing the latest X blog posts.

`/blog/posts/[page]`

The other pages reachable through the pagination.

Note that this is only an example and you can design your URLs any way you want.

The file structure

In the next step, we need to create a file structure in our Next.js app according to our URL schema.

In my case it looks like this:

.
└── pages/
    └── blog/
        └── posts/
            ├── [page].tsx
            └── index.tsx

The Pagination component

To easily include a pagination at the bottom of our pages, we create a <Pagination /> component taking all necessary pagination parameters in as props.

You will have to style this component yourself.

For inspiration you can take a look at my original code on GitHub for this component.

import Link from 'next/link';

interface PaginationProps {
  currentPage: number; // Page the user is currently on.
  totalPages: number; // Total number of pages.
}

const Pagination = ({ currentPage, totalPages }: PaginationProps) => {
  const pageNumbers = [];

  for (let i = 1; i <= totalPages; i++) {
    pageNumbers.push(i);
  }

  return (
    <nav id="blog-posts-pagination">
      <ul>
        {/* The "Prev" button, if needed. */}
        {currentPage > 1 && (
          <li>
            <Link href={currentPage - 1 <= 1 ? '/blog/posts' : `/blog/posts/${currentPage - 1}`}>Prev</Link>
          </li>
        )}

        {/* The individual pages. */}
        {pageNumbers.map((number) => (
          <li key={number}>
            {/* Current page: Page not clickable. */}
            {currentPage === number && <button disabled>{number}</button>}

            {/* Other pages: Page is clickable. */}
            {currentPage !== number && <Link href={number === 1 ? '/blog/posts' : `/blog/posts/${number}`}>{number}</Link>}
          </li>
        ))}

        {/* The "Next" button, if needed. */}
        {currentPage < totalPages && (
          <li>
            <Link href={`/blog/posts/${currentPage + 1}`}>Next</Link>
          </li>
        )}
      </ul>
    </nav>
  );
};

export default Pagination;

The first page

This is the "first" page in the pagination. I designed the structure so that /blog/posts/1 doesn't exist (or is being redirect) and instead /blog/posts is the main URL for the blog posts overview.

Implementing the index.tsx page

index.tsx is the file responsible for this page.

Note that this is a shortened example from my blog. I use Storyblok as a CMS and therefore fetch the content using their API. You can of course use any API or internal file structure you want and apply the same concept.

/**
 * Constant to determine how many blog posts are shown per page.
 */
const POSTS_PER_PAGE = 15;

/**
 * Blog overview page.
 * Posts are still being rendered by [...slug].tsx.
 */
const BlogOverviewPage = ({ blogPosts, pagination }) => {
  return (
    <Layout>
      <>
        {/* This component will render out the collection of blog posts passed as a prop. */}
        <BlogPosts blogPosts={blogPosts} />

        {/* This is our pagination component. */}
        {pagination.totalPages > 1 && <Pagination currentPage={pagination.currentPage} totalPages={pagination.totalPages} />}
      </>
    </Layout>
  );
};

export const getStaticProps: GetStaticProps = async () => {
  // Calculate how many blog posts there are by counting all links starting with 'blog/'.
  const blogPostSlugs = api.getSlugs(...);

  // Total count of blog posts in Storyblok.
  const blogPostTotalCount = Object.keys(blogPostSlugs.links).length - 1; // -1 because the blog overview page is also counted.

  // Total number of /blog/posts pages (including index).
  const totalPages = Math.ceil(blogPostTotalCount / POSTS_PER_PAGE);

  // Retrieve blog posts (without content).
  const blogPosts = api.getBlogPosts(...);

  if (blogPosts.length === 0) {
    return {
      notFound: true,
      revalidate: 5 * 60, // revalidate every 5 minutes.
    };
  }

  return {
    props: {
      blogPosts,
      pagination: {
        currentPage: 1,
        totalPages: totalPages,
      },
    },
    revalidate: 30 * 60, // revalidate every 30 minutes.
  };
};

export default BlogOverviewPage;

Explanation

We have a constant POSTS_PER_PAGE that defines how many posts we want to render per page.

Usually, APIs that support pagination (like in my case Storyblok) have a per_page option or something similar.

Then, we need to pass the current page to the API as well so it can figure out what posts to return.

In Storyblok's case that is the page parameter.

Additionally, we need to calculate the total number of pages for our <Pagination /> component.

You can do so by using the following calculation:

Math.ceil(blogPostTotalCount / POSTS_PER_PAGE);

The dynamic sub-pages

Let's say we render out the 15 latest posts on /blog/posts .

Then we need a /blog/posts/2 page for the next 15, a /blog/posts/3 page for the next 15, and so on...

This is implemented in the dynamic route [page].tsx.

Implementing the [page].tsx pages

/**
 * Constant to determine how many blog posts are shown per page.
 */
const POSTS_PER_PAGE = 15;

/**
 * Paginated blog overview page (eg. /blog/posts/3).
 * Posts are still being rendered by [...slug].tsx.
 */
const PaginatedBlogOverviewPage = ({ blogPosts, pagination }) => {
  return (
    <Layout>
      <>
        <BlogPosts blogPosts={blogPosts} />

        {pagination.totalPages > 1 && <Pagination currentPage={pagination.currentPage} totalPages={pagination.totalPages} />}
      </>
    </Layout>
  );
};

export const getStaticProps: GetStaticProps = async ({ params }) => {
  const page = parseInt(String(params?.page));

  // Calculate how many blog posts there are by counting all links starting with 'blog/'.
  const blogPostSlugs = api.getPostSlugs(...);

  // Total count of blog posts in Storyblok.
  const blogPostTotalCount = Object.keys(blogPostSlugs.links).length - 1; // -1 because the blog overview page is also counted.

  // Total number of /blog/posts pages (including index).
  const totalPages = Math.ceil(blogPostTotalCount / POSTS_PER_PAGE);

  if (page > totalPages) {
    return {
      notFound: true,
      revalidate: 5 * 60, // revalidate every 5 minutes.
    };
  }

  // Retrieve stories for all blog posts (without content).
  const blogPosts = api.getBlogPosts(...);

  if (blogPosts.length === 0) {
    return {
      notFound: true,
      revalidate: 5 * 60, // revalidate every 5 minutes.
    };
  }

  return {
    props: {
      blogPosts,
      pagination: {
        currentPage: storyblokParams['page'],
        totalPages: totalPages,
      },
    },
    revalidate: 30 * 60, // revalidate every 30 minutes.
  };
};

export const getStaticPaths: GetStaticPaths = async () => {
  // Calculate how many blog posts there are by counting all links starting with 'blog/'.
  const blogPostSlugs = api.getPostSlugs(...);

  // Total count of blog posts in Storyblok.
  const blogPostTotalCount = Object.keys(blogPostSlugs.links).length - 1; // -1 because the blog overview page is also counted.

  // Total number of overview pages (including the index page).
  const totalPages = Math.ceil(blogPostTotalCount / Number(POSTS_PER_PAGE));

  // Define array of paths and other options (returned from this function).
  let staticPathsResult: GetStaticPathsResult = {
    paths: [],
    fallback: 'blocking',
  };

  for (let i = 2; i < totalPages + 1; i++) {
    staticPathsResult.paths.push({
      params: {
        page: i.toString(),
      },
    });
  }

  return staticPathsResult;
};

export default PaginatedBlogOverviewPage;

Explanation

The only difference here is that we need a getStaticPaths() method that tells Next.js all the pages it needs to build (during build-time).

See the Next.js documentation for reference:

https://nextjs.org/docs/basic-features/data-fetching/get-static-paths

If you want to use ISR, you can define a fallback , like I did in this example.

Also, because this is a dynamic route and "blueprint" for all sub-pages, we have the parameter page that's contained in the URL that we can pass to the API and pagination as the current page.

Example:

When a user visits /blog/posts/3, params.page is 3 .

Conclusion and things to consider

I hope this gave you a basic idea of how one could go about implementing pagination on static sites in Next.js.

Be careful when implementing paginated content in Next.js using SSG or ISR.

This is the perfect implementation if you only have a couple of pages. It's going to load extremely fast and give the user as well as search engines a great experience! However, please consider that with thousands of pages this could increase the build time a lot and a server-side-rendered approach might be more suitable for that purpose.

In addition to what I've shown here, I would encourage you to also pay attention to SEO. Content behind a pagination is more complicated to figure out for search engines. However, if you get this right, pagination could even improve your SEO ranking as the pages are smaller and load faster.

I actually wrote an article on optimizing SEO for paginated content on my blog:

https://fabiancdng.com/blog/seo-for-developers-pagination

Lastly, it might make sense to take a look at the full, real-world code on GitHub to see everything put together.

Cheers!

📣 This post was originally published on my website on April 8, 2023.

How to Create Virtual Pages in WordPress

Fabian Reinders — Mon, 29 May 2023 17:30:35 +0000

As a WordPress plugin developer, you may need to create custom pages "on the fly" that are not stored in the database. This guide shows you how to programmatically create virtual pages in WordPress that are dynamically generated by your plugin.

Why would I need this?

WordPress is a powerful CMS and therefore offers lots of ways to get content on your site! However, if you are developing complex WordPress plugins those may not always be enough.

Imagine this: You want to build a ticketing system as a WordPress plugin and you want each ticket to have a page within your WordPress site for the customer or staff to view.

The schema for the URL would be something like this: https://example.fabiancdng.com/ticket/{id}

In this case, it might be the best to simply have a PHP template that takes in the id , queries the data from whatever source and dynamically renders the page without having to store anything in the WordPress database.

Step 1: Creating a WordPress plugin

The first step is, of course, creating the WordPress plugin to host our virtual page.

If you already have a plugin, you can skip this step. If not, you can create a new plugin by following these steps:

Create a new folder in the "wp-content/plugins" directory of your WordPress installation.
Create a new PHP file in the folder and give it a unique name.
Open the PHP file and add the plugin header information at the top. This includes the plugin name, version, author, and description.
Save the PHP file and activate the plugin in the WordPress dashboard.

After that the plugin should show up as activated on your dashboard:

Feel free to go through these steps in the WordPress documentation for more detail.

Step 2: Creating a Rewrite rule

WordPress offers a Rewrite API for exactly this purpose.

You can utilize it to programmatically "redirect" a specific slug in your WordPress installation to your plugin that will then render out the content on this page dynamically.

To achieve this, hook up a function to the init hook that calls the add_rewrite_rule() method.

function ticket_plugin_add_rewrite_rules() {
        // Slug of your virtual page (e.g. 'ticket').
        $slug = 'ticket';

        // Add rewrite rule (hook up the virtual page to a slug in WordPress).
        // Do some Regex magic to pass args within the URL for pretty URLs.
        add_rewrite_rule(
            $slug . '/([^/]*)[/]?$',
            'index.php?ticket-id=$matches[1]',
            'top'
        );
}

add_action( 'init', 'ticket_plugin_add_rewrite_rules' );

This example sticks to our example URL schema https://example.fabiancdng.com/ticket/{id} .

First parameter: The URL

The first parameter represents the slug where our virtual page will be mounted (in this example /ticket ). This parameter allows Regex matching. We can use that to allow any variables in the URL as well as GET parameters.

Second parameter: Query variables

The second parameter specifies the query string WordPress receives when the virtual page is loaded.

The query string should contain variables (like in the example). Those so called "query variables" are what WordPress uses under the hood to determine what content to load. WordPress has a lot of built-in ones but plugins can have their own query variables as well (like here).

More on query variables: https://codex.wordpress.org/WordPress_Query_Vars

In this example, that's useful to map the part of the URL that is the ticket ID to a query var ticket-id that we can access on the virtual page to know what specific ticket needs to be rendered.

Step 3: Defining a custom query variable

To tell WordPress about our custom query variable ticket-id we need to register it using the query_vars hook:

function ticket_plugin_add_query_vars( $vars ) {
  $vars[] = 'ticket-id';
  return $vars;
}

add_filter( 'query_vars', 'ticket_plugin_add_query_vars' );

In this example, this is just telling WordPress to recognize our ticket-id query variable.

Step 4: Creating the virtual page's template

Now we need to set up the PHP template that renders the actual content when a user hits our virtual page.

To tell WordPress we want to use a custom template file for this page as opposed to a template from our theme, we can use the template_redirect hook in WordPress.

function ticket_plugin_template_redirect() {
  if ( get_query_var( 'ticket-id' ) ) {
    include_once plugin_dir_path( __FILE__ ) . 'templates/ticket-page-template.php';
    exit;
  }
}

add_action( 'template_redirect', 'ticket_plugin_template_redirect' );

Don't forget to create the template file within your plugin's directory. In this example, I added a dedicated templates folder as well.

Blueprint for /wp-content/plugins/ticket-plugin/templates/ticket-page-template.php:

<?php
/**
 * Template Name: My Virtual Page
 */

// Include WordPress header (if you want to).
get_header();

// Get the ticket ID from our query var.
// You can call a filter/function here to get the data for the ticket.
$ticket_id = get_query_var( 'ticket-id' );

// HTML output here.
// For demonstration purposes, I only output the ticket ID here.
echo $ticket_id;

// Include WordPress footer (if you want to).
get_footer();

Step 5: Flushing the rewrite rules

Flushing rewrite rules is an important step when creating custom routes or virtual pages in a WordPress plugin.

When WordPress loads, it parses the URL and checks it against the rewrite rules to determine what content to display. When you create a new custom route or virtual page in your plugin, you need to flush the rewrite rules to ensure that WordPress recognizes the new route or page.

Flushing the rewrite rules rebuilds the URL structure and updates the internal cache, making the new content available for display. Failure to flush rewrite rules can result in 404 errors or the inability to access the new content. To flush the rewrite rules, you can use the flush_rewrite_rules() function in your plugin code. It's important to note that this function should only be used sparingly, as it can be resource-intensive and slow down your site if used too frequently.

Therefore, I recommend using it in combination with the plugin activation hook (executed when the user activates your plugin on the WordPress dashboard).

function ticket_plugin_activate() {
    // Flush the rewrite rules.
    // Slow and resource heavy, therefore only called on activation and deactivation.
    flush_rewrite_rules();
}

register_activation_hook(
    __DIR__ . '/ticket-plugin.php', // Main plugin file.
    'ticket_plugin_activate'
);

All set! 🥳

You should now be able to reach your virtual page under the slug you specified.

In case you get a 404 error, just head to the WordPress dashboard and deactivate and active the plugin again. This will flush the rewrite rules again, possibly registering your virtual page if it wasn't yet registered.

I created an example WordPress plugin based on this guide that can be found on GitHub. In case you want to see all code pieces brought together, feel free to check it out: https://github.com/fabiancdng/wp-virtual-page-example-plugin

Cheers.

📣 This post was originally published on my website on April 2, 2023.

Running Nextcloud using Docker and Traefik 3

Fabian Reinders — Thu, 18 May 2023 12:05:22 +0000

Nextcloud is an awesome self-hosted cloud-storage service. This is a guide for running Nextcloud using Docker, Traefik, and Let's Encrypt.

Why should you use Docker to deploy Nextcloud?

Well- Have you ever tried setting up a working Nextcloud instance just by using an Apache or NGINX web server? That itself probably isn't that hard but the configuration you have to do after installing Nextcloud is. There's this handy dandy feature under Settings -> [Administration] Overview that shows you what steps you need to take to make your Nextcloud instance secure, fast, and reliable. And if you've just set up Nextcloud- oh boy- there's probably a lot to do.

Since Docker images not only come with the software installed already, but also with a finished and optimized configuration, there's pretty much nothing more to do once you've got your Nextcloud container up and running.

Also, probably because Nextcloud is such complex software, I was never really able to optimize my manual Nextcloud instance as well as the Docker image. I always noticed performance issues or other kinds of things that just didn't work or didn't work as expected.

Why should you run the instance behind Traefik?

Traefik acts as the "reverse proxy" in this configuration. That means we don't have to expose the web server in the container publicly on the web, which has a couple of advantages. One of them being that you don't have to run it on a different port or something when dealing with several services on one server.

An example of that would be my server. I don't just run my blog but also a homepage on that server, which are two completely separate web apps, code-bases, and Docker containers. I don't have to use weird ports behind the web address though, because everything is routed through Traefik.

That enables me to tell Traefik to route a specific subdomain or path, like "blog.fabiancdng.com" or "fabiancdng.com/blog" to the blog container and "fabiancdng.com" to the homepage container.

I'm also able to easily rewrite HTTP headers, implement middlewares, and more.

Why specifically Traefik and not other reverse proxies (like NGINX or Apache)?

Well- that's probably a question for a separate article. One of the reasons is certainly the way it works hand-in-hand with Docker and the fact that it needs almost no configuration (in the form of config files).

But you'll see all of this yourself- now.

Step 1: Setting up Nextcloud, MariaDB, and Redis

Of course, you can also use MySQL instead of MariaDB.

Creating the `docker-compose.yml` for Nextcloud, MariaDB, and Redis:

First, we'll set up a Docker Compose stack for Nextcloud, MariaDB, and Redis:

version: '3.7'
services:
    nextcloud-db:
        image: mariadb:latest
        container_name: nextcloud-db
        command: --transaction-isolation=READ-COMMITTED --log-bin=ROW --skip-innodb-read-only-compressed
        restart: unless-stopped
        volumes:
            - ./mysql-data:/var/lib/mysql
        environment:
            - MYSQL_ROOT_PASSWORD=test # MYSQL ROOT PASSWORD
            - MYSQL_PASSWORD=test # PASSWORD OF MYSQL USER
            - MYSQL_DATABASE=nextcloud # MYSQL DATABASE
            - MYSQL_USER=nextcloud # MYSQL USERNAME
        networks:
            - default

    nextcloud-redis:
        image: redis:alpine
        container_name: nextcloud-redis
        hostname: nextcloud-redis
        restart: unless-stopped
        command: redis-server --requirepass test # REPLACE WITH REDIS PASSWORD
        networks:
            - default

    nextcloud-app:
        image: nextcloud
        container_name: nextcloud-app
        restart: unless-stopped
        depends_on:
            - nextcloud-db
            - nextcloud-redis
        environment:
            - REDIS_HOST=nextcloud-redis
            - REDIS_HOST_PASSWORD=test # REPLACE WITH REDIS PASSWORD
            - MYSQL_HOST=nextcloud-db
            - MYSQL_USER=nextcloud # MYSQL USERNAME
            - MYSQL_PASSWORD=test # PASSWORD OF MYSQL USER
            - MYSQL_DATABASE=nextcloud # MYSQL DATABASE
        volumes:
            - ./nextcloud:/var/www/html
        labels:
            - "traefik.http.routers.nextcloud.entrypoints=http"
            - "traefik.http.routers.nextcloud.rule=Host(`cloud.example.com`)"
            - "traefik.http.middlewares.https-redirect.redirectscheme.scheme=https"
            - "traefik.http.routers.nextcloud.middlewares=nc-header,https-redirect"
            - "traefik.http.routers.nextcloud-secure.entrypoints=https"
            - "traefik.http.routers.nextcloud-secure.rule=Host(`cloud.example.com`)"
            - "traefik.http.middlewares.nc-rep.redirectregex.regex=https://(.*)/.well-known/(card|cal)dav"
            - "traefik.http.middlewares.nc-rep.redirectregex.replacement=https://$$1/remote.php/dav/"
            - "traefik.http.middlewares.nc-rep.redirectregex.permanent=true"
            - "traefik.http.middlewares.nc-header.headers.customFrameOptionsValue=SAMEORIGIN"
            - "traefik.http.middlewares.nc-header.headers.customResponseHeaders.Strict-Transport-Security=15552000"
            - "traefik.http.routers.nextcloud-secure.middlewares=nc-rep,nc-header"
            - "traefik.http.routers.nextcloud-secure.tls=true"
            - "traefik.http.routers.nextcloud-secure.tls.certresolver=letsencrypt"
            - "traefik.http.routers.nextcloud-secure.service=nextcloud"
            - "traefik.http.services.nextcloud.loadbalancer.server.port=80"
            - "traefik.http.services.nextcloud.loadbalancer.passHostHeader=true"
        networks:
            - proxy
            - default

networks:
  proxy:
    external: true

Important: Replace "cloud.example.com" with the (sub)domain you want to run your cloud on and replace the passwords with secure ones (see comments).

I started with the Nextcloud, MariaDB, and Redis Docker Compose stack because some of you may have already set up Traefik and created a network for it. In that case, you can just connect the containers to it by changing "proxy" to your network name. If you haven't created a Docker network for Traefik yet, don't worry, we're going to do that in Step 2.

There's not much to explain here, except maybe what all those Traefik labels mean. Basically, there's a lot to do when a request to your cloud domain comes in.

The first thing you want to do is upgrading the connection from HTTP to HTTPS. This is simply done by creating a middleware using the container labels (yes, that's possible). Eventually, the incoming traffic gets routed to a "service", which in this case is port 80 within the container.

You don't additionally have to expose the port on the host machine. Since the Traefik container connects to the same Docker network as the Nextcloud container, they can communicate on that port (using that network).

Then there's a bunch of middlewares for (over)writing and passing headers of requests (I just followed the instructions on the Nextcloud overview and the docs for optimizing those). See "Hardening and security guidance" for reference.

Step 2: Setting up Traefik

The first thing that's important, as mentioned above, is creating a Docker network that all the containers that you want to run behind Traefik connect to. This is done so we can route the traffic internally as opposed to exposing ports on the host machine.

Creating the network

You can create a new Docker network using:

$ docker network create proxy

You can name it anything you want. For consistency with my example stack above, I call it "proxy".

Creating the docker-compose.yml for Traefik

version: "3.7"

services:
  traefik:
    image: traefik:latest
    container_name: traefik
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./traefik/config/traefik.yml:/traefik.yml
      - ./traefik/certificates/acme.json:/acme.json
      - /var/run/docker.sock:/var/run/docker.sock
    networks:
      - proxy

networks:
  proxy:
    external: true

For Traefik we obviously have to expose the ports 80 and 443 to the host machine to make the HTTP and HTTPS traffic that comes in on the host machine go straight to the Traefik container.

Also, we have to create 2 volumes for a) storing a minimal Traefik config file and b) storing our SSL certificates. We'll later set up Let's encrypt (in the Traefik config file) to obtain free SSL certificates for our Nextcloud, which is recommended if we want to use HTTPS.

Step 3: Configuring Traefik

Last but not least, we have to create our configuration file for Traefik. Technically this is not necessary and we could do everything using labels. But especially for people who want to put more behind Traefik than just one service, this can make things cleaner and a lot easier to read.

Start by creating a folder called traefik in the same directory as the docker-compose.yml (for Traefik) and a subdirectory within that folder called config then create a file called traefik.yml and paste the following:

api:
  dashboard: false
  insecure: false

entryPoints:
  http:
    address: ":80"
  https:
    address: ":443"

providers:
  docker:
    network: proxy

certificatesResolvers:
  letsencrypt:
    acme:
      email: your@email
      storage: acme.json
      httpChallenge:
        entryPoint: http

This just creates our certificate resolver, which is automatically going to obtain and renew the certificates. It also deactivates the internal dashboard (if you want to enable it though, feel free to do so).

If it doesn't work, make sure the certificates folder has the permissions 600. Change the permissions by doing chmod -R 600 certificates/.

Done! 🥳

Both docker-compose.yml files have to be in different folders for Docker Compose to use the correct one. Start both of them (separately) by running docker-compose up -d in both directories.

You can now open up your browser and go to the domain of your Nextcloud. You should be greeted with the initial setup screen.

Cheers.

📣 This post was originally published on my website on July 22, 2021.

I Tried Blogging as a Developer for 7 Days 🧑‍💻

Fabian Reinders — Sun, 14 May 2023 16:22:41 +0000

Here's what I learned in the first 7 days of actively blogging as a developer.

Introduction

Saying I'm new to blogging wouldn't be entirely correct. Before signing up on dev.to, I had already written a handful of blog posts on my own domain.

But even though they've been online for years, they never really reached any audience.

Last week, while reading an article on dev.to, I thought:

"Hmm... Why not try writing an article here to see how much (if any) attention it gets?"

To start things off, I decided to write a helpful, tutorial-ish article about something I came across while working on a side project.

My first post on dev.to

And there it was, my first post (exclusively) on dev.to:

At first, not much was happening.

But 3 days later:

The Twitter account behind dev.to (@ThePracticalDev) gave me a shout-out on Twitter:

// Detect dark theme var iframe = document.getElementById('tweet-1656256770573053953-961'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1656256770573053953&theme=dark" }

I immediately saw people reading my post and following me on the platform.

Cross-posting

I stumbled across an article on "cross-posting" articles on dev.to.

I decided to cross-post one of my previous articles "Automatic Deployment using Docker and GitHub Actions" on dev.to.

The same thing that had happened to my first post, happened to the second one:

// Detect dark theme var iframe = document.getElementById('tweet-1657576971453210624-327'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1657576971453210624&theme=dark" }

3 posts later...

After posting another article exclusively on dev.to, this is how my stats look like, 7 days after creating my first post on dev.to:

1,069 reads
200 followers
9 reactions

Conclusion

Posting or cross-posting on blogging platforms like dev.to, Hashnode or Medium can help your blog reach an audience.

However, keep in mind that blogging is about so much more than just clicks. Blog posts document your projects, personal journey, and growth as a developer.

Your posts don't need to be perfect and even if they're just a digital diary/glossary for yourself, they serve a very important purpose.

But still... There's a chance that your posts can help someone out there. So why not share your projects, research, and experience with others?

I'm curious what you think. Do you have a blog as a developer?
Feel free to share your experience in the comments!

Cheers.

So... Is this PHP's Redemption? 😳

Fabian Reinders — Sat, 13 May 2023 13:27:33 +0000

Is PHP rising from the dead?

Unbelievable yet true... PHP is trending on social media.

// Detect dark theme var iframe = document.getElementById('tweet-1656321343804289032-519'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1656321343804289032&theme=dark" }

Why is this unexpected?

Well... If you're a developer and you've been on the internet the last couple of years, you must have stumbled across at least one meme/article announcing PHP dead for good.

But why is that?

The rise and fall of PHP

The rise of PHP

It's the year 1994. A developer called Rasmus Lerdorf
creates a set of Common Gateway Interface (CGI) scripts, which he uses to maintain his (P)ersonal (H)ome(P)age.
PHP's name later evolved to something more fancy, of course 😅 - "PHP: Hypertext Preprocessor".

It quickly evolved into a full-fledged programming language and became one of the most popular languages for building web applications. 📈📈📈

PHP's early popularity was driven by its simplicity and ease of use, making it accessible to developers of all skill levels.

PHP's architecture

PHP's paradigm is unbelievably simple:

File based routing (in most cases)
The URL/path of a page is made up of the folders and .php files contained in them.

Server-Side-Rendering
The user makes a request to the server and the server generates the HTML for the page dynamically (with the ability of fetching data from a database, for instance, and rendering HTML for that data before sending the HTML back to the user).

PHP's arch-nemesis

However, PHP's dominance began to wane as new languages and frameworks emerged that were better suited for building modern and interactive web applications. ☹️

Front end frameworks such as React, Angular, and Vue.js provided developers with more powerful tools for building complex, interactive user interfaces. 📈📈

A lot of websites began adopting the Single Page Application approach of these frameworks where you don't have to reload the entire page all the time and instead only fetch data from the server and let your front end framework render the HTML for the page on the client side.

"PHP is dying"

As we can see on Google Trends, PHP's relevance is on the decline:

However, according to W3Techs:

PHP is used by 77.5% of all the websites whose server-side programming language we know.

This means PHP still holds a market share like no one else.

So is PHP dying? No. PHP is here to stay for years if not decades to come.

However, its relevance has undeniably been on the decline for quite some time now.

So- Why is PHP trending then?

1. JavaScript frameworks

Even though JavaScript frameworks are probably the biggest reason for PHP's decline in terms of relevance, they are also the biggest reason everyone seems to be talking about PHP again right now.

JavaScript frameworks like React and Vue.js are awesome! But their client-side rendering approach has some drawbacks.

One of the biggest being that the entire page is rendered at runtime in the client's browser.

Not only does it result in more network requests and a longer time until the user can interact with the page (after it loaded up), it also hurts SEO (Search Engine Optimization).

That is because nobody knows how well search engines can run the client-side rendering logic and the initial HTML sent to the client (or web crawler) is just an empty HTML skeleton. 😕

This is why we see JavaScript frameworks like Next.js or Nuxt adopting the concept of Server-Side-Rendering and generally code executed on the server to hydrate pages.

Next.js even adopted a file-based routing system... Does all that sound familiar to you? 🤯

Next.js is also adopting React Server Components - Components entirely rendered on the server, even when updated.

And Next.js recently introduced the concept of "Server Actions" - Functions of code executed on the server and used, for instance, to query data from a database:

import { sql } from '@vercel/postgres';
import { redirect } from 'next/navigation';

async function create(formData: FormData) {
  'use server';
  const { rows } = await sql`
    INSERT INTO products (name)
    VALUES (${formData.get('name')})
  `;
  redirect(`/product/${rows[0].slug}`);
}


export default function Page() {
  return (
    <form action={create}>
      <input type="text" name="name" />
      <button type="submit">Submit</button>
    </form>
  );
}

Source: https://vercel.com/changelog/vercel-postgres

This reminds people a lot of PHP and has caused a flood of memes and comparisons, making people talk about PHP again.

2. PHP 8

PHP, to many developers, is nothing more than a memory. In fact, what many developers remember when they think about PHP is PHP 5, released in 2004.

PHP 5 is ancient and had a lot of issues. However, because it is unfortunately still in use on a lot of websites, a lot of PHP's bad reputation goes back to these older versions of PHP.

However, PHP has had an unbelievable development throughout the recent versions (especially 7 and 8). 🚀

A lot of the bad design choices and security vulnerabilities of the past versions, which unfortunately hurt PHP's reputation a lot, are now gone 💨 And the developer experience is much better which makes PHP a great choice even for modern projects.

Conclusion... Will PHP take over again? 🔮

Good question... I don't know.

But the real question is: Does it matter?

Because in my opinion, what really matters is the developer behind an application and their skills and ideas 👩‍💻🧠

There are developers who build incredible web apps and websites with Laravel or WordPress and then there are developers who build incredible apps with React.

Both worlds are great and every programming language/framework has something unique to offer. I doubt anyone would regret choosing either of them at any point as long as they know how to make the best of it. 🤷‍♀️

But what do you think? Feel free to join the discussion in the comments. I'd love to hear your opinion!

Cheers.

Automatic Deployment using Docker and GitHub Actions

Fabian Reinders — Sat, 13 May 2023 09:15:40 +0000

In this article, I'll show you how I automatically deploy my web apps from GitHub on my server using the new GitHub container registry, Docker, GitHub Actions, and watchtower.

What even is "Automatic Deployment"?

Well- Have you ever been annoyed by rebuilding your code, reuploading the files to your server, restarting your app, and maybe even rebuilding the Docker image?

That's the exact problem CD ("Continuous Deployment") tries to solve. With a proper CD pipeline set up, you don't have to worry about any of these things anymore.

You can have a tool like GitHub Actions (or any other CI/CD tool) automatically build your code when you, for instance, push to a certain branch or create a new release.

Then, some magic ✨ is automatically going to deploy the built code to your server.

You can even make GitHub Actions build your code as a Docker image and push it to a container registry like Docker Hub, GitLab, or GitHub for a continuous build of your application.

The app we'll be deploying

To give you a (more or less) real-world example, I'll go through how the automatic deployment of my homepage (fabiancdng.com) works, which is a Next.js app.

Note that this blog post is from 2021 and my architecture might have changed by now. The concept should remain the same, however.

But you can do this for literally any web app as long as you have a functional Dockerfile for building an image from your code.

You'll have to create that yourself for your app but in this example, my Next.js (standalone mode) Dockerfile looks like this:

# Production image, copy all the files and run next
FROM node:18-alpine AS runner
WORKDIR /app
ENV NODE_ENV production
# Uncomment the following line in case you want to disable telemetry during runtime.
# ENV NEXT_TELEMETRY_DISABLED 1
RUN addgroup --system --gid 1001 nodejs
RUN adduser --system --uid 1001 nextjs
# You only need to copy next.config.js if you are NOT using the default configuration
# COPY --from=builder /app/next.config.js ./
# COPY --from=builder /app/public ./public
# COPY --from=builder /app/package.json ./package.json
# Automatically leverage output traces to reduce image size 
# https://nextjs.org/docs/advanced-features/output-file-tracing
# COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
# COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static
COPY --chown=nextjs:nodejs .next/standalone ./
COPY --chown=nextjs:nodejs .next/static ./.next/static
COPY --chown=nextjs:nodejs public ./public

USER nextjs
EXPOSE 3000
ENV PORT 3000
CMD ["node", "server.js"]

Step 1: Using GitHub Actions to build and push the image

First, we set up a GitHub Actions workflow that is going to build a Docker image from our code, whenever we push to the master branch.

In case you want a different event to trigger your deployment (like a tag or something), you can take a look at the according page in the GitHub Actions docs.

Creating the workflow file

GitHub Actions are stored as YAML files in the repository under the path .github/workflows. So you have to create that folder first.

Then, simply create a new file in the workflows folder (the name can be anything). Just make sure it has the .yml ending.

Alrighty, let's go through the workflow file!

1. Specifying the name of the workflow

Start by giving your workflow a name. Enter the following in your workflow file (you can of course choose anything for the name):

name: Deploy Docker image

2. Specifying the event triggering the workflow

There are multiple options for an event, which you can find in the docs.

In this case, my event is a push to the master branch.

Add the event in the following format to your workflow file (indentation is key ❗ ):

on:
  push:
    branches:
      - master

3. Creating a job

A workflow consists of one or more jobs, which can be something like test, build, deploy.

For the sake of simplicity, I just create one job called "Deploy" that is going to build the code into a Docker image and push it to the registry:

jobs:
  Deploy:
    runs-on: ubuntu-latest

As you can see, the job also has a key runs-on which you can use to specify the OS your GitHub Actions container is supposed to run.

4. Creating the steps for the "Deploy" job

Each job consists of one or more steps. For our deployment job, we want to set up 3 steps:

One for copying the code in the repo
One for logging into the container registry
One for both building and pushing the docker image

We can use a pre-made action for all of these steps that we just have to pass some data to work:

    steps:
      - name: Checkout Code
        uses: actions/checkout@v1
      - name: Login to GitHub Container Registry
        uses: docker/login-action@v1
        with:
          registry: ghcr.io
          username: ${{ github.repository_owner }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - name: Build and Push Docker Image
        uses: docker/build-push-action@v2
        with:
          context: .
          push: true
          tags: |
            ghcr.io/fabiancdng/fabiancdng-homepage:latest

Make sure to change the username and the name of your image down in the "tags" section.

The finished script should then look something like this:

name: Deploy Docker image

on:
  push:
    branches:
      - master

jobs:
  Deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Code
        uses: actions/checkout@v1
      - name: Login to GitHub Container Registry
        uses: docker/login-action@v1
        with:
          registry: ghcr.io
          username: ${{ github.repository_owner }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - name: Build and Push Docker Image
        uses: docker/build-push-action@v2
        with:
          context: .
          push: true
          tags: |
            ghcr.io/fabiancdng/fabiancdng-homepage:latest

5. Creating an access token

Update: You don't need to create an access token yourself anymore.

GitHub Actions automatically provides a secret GITHUB_TOKEN now that contains a token to authorize the push to the registry in the workflow. You can still create a custom access token though to overwrite the scopes/permissions of the default GITHUB_TOKEN .

If you don't need to do that, simply skip this step.

To allow GitHub Actions to push images to the package registry on our behalf, we need to supply it with a GitHub access token that has write access to the package registry.

Go to the Developer settings on GitHub.com and navigate to the option "Personal Access Tokens" in the sidebar.

Then hit "Generate new token" and specify the permissions. I recommend just checking the "packages" settings like this:

6. Putting the access token into the "Repository Secrets"

Update: Only follow this step if you want to overwrite the default GITHUB_TOKEN provided by GitHub Actions (for example to change scopes/permissions).

If you don't need to do that, simply skip this step.

If you don't need to do that, simply skip this step.

I highly recommend putting the token in the repository's secrets section to prevent it from showing up in the logs or even worse in the file tree of your public repository.

To do so, go to your repository's settings and then to "Secrets":

Click "New repository secret" and give it the name of GITHUB_TOKEN and paste your access token as the value.

Step 2: Setting up "watchtower" on your server

Watchtower is an open-source software that automatically recreates your containers with the new version of the image as soon as it is available on the registry.

You can start watchtower without Docker Compose like this:

$ docker run -d \
    --name watchtower \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -v <PATH_TO_HOME_DIR>/.docker/config.json:/config.json \
    containrrr/watchtower

Since it binds to the Docker socket, it's going to update ALL of your running containers, you can use container labeling to exclude or only specifically include containers.

Check the docs if you wish to do so.

You can even set up notifications via Email, Discord, Telegram, etc..

Alternatively, you can create a Docker Compose stack for watchtower:

version: '3'
services:
    watchtower:
        image: containrrr/watchtower
        restart: unless-stopped
        container_name: watchtower
        environment:
            - WATCHTOWER_POLL_INTERVAL=1800
            - WATCHTOWER_CLEANUP=true
        volumes:
            - /var/run/docker.sock:/var/run/docker.sock
            - /root/.docker/config.json:/config.json

The environment variable WATCHTOWER_POLL_INTERVAL defines the interval (in seconds) watchtower is supposed to check for updates.

WATCHTOWER_CLEANUP can automatically delete the old and unused images when set to true.

Step 3: Deploying the image

We need to push to the master branch at least once now in order to kick off the action so there's an image to begin with.

When done so, the image should be showing up in the "Packages" tab of your GitHub profile.

You can also associate the image with a repository here.

Creating a `docker-compose.yml` for your app

Now, create a container running your image either by using the docker run command or, like me, by adding it to a docker-compose.yml file.

version: "3.7"
services:
    homepage:
        image: ghcr.io/fabiancdng/fabiancdng-homepage:latest
        container_name: homepage
        restart: unless-stopped

Note: The name of your image should follow this format (if you use the GitHub Container Registry): ghcr.io/<YOUR USERNAME>/<IMAGE NAME>:<TAG>

Step 4: Lean back and let the magic happen 🧙‍♀

As soon as you've set up GitHub Actions, started your containerized application, and started watchtower, your automatic deployment is set up and ready to go! 🥳

Cheers.

📣 This post was originally published on my website on July 18, 2021.

Redirect HTTP to HTTPS and WWW to Non-WWW with Traefik 3

Fabian Reinders — Sun, 07 May 2023 10:04:18 +0000

Introduction

Traefik is awesome! If you, like me, have moved all your web services to Docker and Docker Compose, there is no better option for a reverse proxy and load balancer than Traefik in my opinion.

You can get things done quickly without having to write massive config files.

However, when you're just starting out with Traefik it might take some getting used to.

Looking at some useful, real-world examples might help in that situation!

Redirecting HTTP to HTTPS

One of the most common things you would want your reverse proxy to handle is automatically redirecting HTTP traffic to HTTPS.

Example: http://fabiancdng.com should automatically be redirected to https://fabiancdng.com to establish a secure connection.

The example web service

To show you how we could go about automatically redirecting HTTP to HTTPS in Traefik, it makes sense to look at an example Docker Compose stack that is already set up to run behind Traefik as a reverse proxy.

version: '3.7'

services:
  fabiancdng-website:
    image: registry/.../my-website-image:latest
    labels:
      - traefik.enable=true
      - traefik.http.routers.my-website-frontend-http.rule=Host(`fabiancdng.com`)
      - traefik.http.routers.my-website-frontend-http.entrypoints=http
      - traefik.http.services.my-website-frontend.loadbalancer.server.port=3000
    networks:
      - proxy

networks:
  proxy:
    external: true

Traefik and this example service can communicate through the external Docker network "proxy". This can differ in your case based on your own configuration.

The above example creates an HTTP router my-website-frontend-http that accepts incoming traffic to http://fabiancdng.com and routes it to port 3000 of the underlying container (that port is not exposed publicly though; only in the Docker network).

Routing HTTPS traffic to the same container

Let's extend the docker-compose.yml to also accept HTTPS traffic at https://fabiancdng.com:

version: '3.7'

services:
  fabiancdng-website:
    image: registry/.../my-website-image:latest
    labels:
      - traefik.enable=true
      - traefik.http.routers.my-website-frontend-http.rule=Host(`fabiancdng.com`)
      - traefik.http.routers.my-website-frontend-http.entrypoints=http
      - traefik.http.routers.my-website-frontend-https.rule=Host(`fabiancdng.com`)
      - traefik.http.routers.my-website-frontend-https.entrypoints=https
      - traefik.http.routers.my-website-frontend-https.tls=true
      - traefik.http.routers.my-website-frontend-https.tls.certresolver=letsencrypt
      - traefik.http.services.my-website-frontend.loadbalancer.server.port=3000
    networks:
      - proxy

networks:
  proxy:
    external: true

In this example configuration, we simply added the router my-website-frontend-https that accepts HTTPS traffic on https://fabiancdng.com.

Additionally, we introduced a certificate resolver letsencrypt.

The certificate resolver is optional but I highly recommend using an SSL certificate on HTTPS routes.

The traefik.yml configuration file

For all of this to work it's important that you configured the basics in Traefik correctly. There need to be corresponding entry points for http and https on the correct ports.

This is how my traefik.yml configuration file handles those:

entryPoints:
  http:
    address: ':80'
  https:
    address: ':443'

providers:
  docker:
    network: proxy

certificatesResolvers:
  letsencrypt:
    acme:
      email: ...
      storage: acme.json
      httpChallenge:
        entryPoint: http

Again, the certificate resolver is optional but if you want to use it, you need a volume to store the acme.json for the certificates persistently. Also, make sure to adjust the Docker network to your existing configuration.

Finally: The redirect from HTTP to HTTPS

Now that we accept incoming traffic both at http://fabiancdng.com and https://fabiancdng.com, we can simply redirect the traffic hitting the my-website-frontend-http router to the my-website-frontend-https router using a RedirectScheme middleware:

version: '3.7'

services:
  fabiancdng-website:
    image: registry/.../my-website-image:latest
    labels:
      - traefik.enable=true
      - traefik.http.routers.my-website-frontend-http.rule=Host(`fabiancdng.com`)
      - traefik.http.routers.my-website-frontend-http.entrypoints=http
      - traefik.http.routers.my-website-frontend-http.middlewares=redirect-to-https
      - traefik.http.routers.my-website-frontend-https.rule=Host(`fabiancdng.com`)
      - traefik.http.routers.my-website-frontend-https.entrypoints=https
      - traefik.http.routers.my-website-frontend-https.tls=true
      - traefik.http.routers.my-website-frontend-https.tls.certresolver=letsencrypt
      - traefik.http.services.my-website-frontend.loadbalancer.server.port=3000
      - traefik.http.middlewares.redirect-to-https.redirectscheme.scheme=https
      - traefik.http.middlewares.redirect-to-https.redirectscheme.permanent=true
    networks:
      - proxy

networks:
  proxy:
    external: true

As you can see in this example, we created a middleware for the http entrypoint that redirects with a 301 to HTTPS:

- traefik.http.middlewares.redirect-to-https.redirectscheme.scheme=https
- traefik.http.middlewares.redirect-to-https.redirectscheme.permanent=true

And we registered the middleware to the my-website-frontend-http router:

- traefik.http.routers.my-website-frontend-http.middlewares=redirect-to-https

Great! That should do it for the HTTPS redirect.

Redirecting WWW to Non-WWW

One thing that might be important as well when deploying a public website is to redirect traffic hitting the www subdomain to the non-www domain (or vice-versa).

When both your main domain and the www subdomain (or even all subdomains) point to your server running Traefik, it makes sense to redirect the traffic to your preferred version.

Why even redirect?

Even though you could use canonicalization to prevent duplicate content SEO issues, it's better to not have duplicate content in the first place and just redirect to your preferred URL for a piece of content.

Regex middleware to redirect www to non-www

As you might have figured, we need another middleware to pull off this redirect as well.

Simply add the following labels to your configuration:

- traefik.http.middlewares.redirect-to-non-www.redirectregex.regex=^https?://www.fabiancdng.com/(.*)
- traefik.http.middlewares.redirect-to-non-www.redirectregex.replacement=https://fabiancdng.com/$${1}
- traefik.http.middlewares.redirect-to-non-www.redirectregex.permanent=true

Also, you need to accept the www subdomain in your router as well. You can simply use || and add another Host to both the my-website-frontend-http and my-website-frontend-https router:

- traefik.http.routers.my-website-frontend-http.rule=Host(`fabiancdng.com`) || Host(`www.fabiancdng.com`)
- traefik.http.routers.my-website-frontend-https.rule=Host(`fabiancdng.com`) || Host(`www.fabiancdng.com`)

Make sure to change the domain to your domain.

The last step now is to hook up the new middleware to your my-website-frontend-https router (that one router should be sufficient as all traffic gets redirected there anyway):

- traefik.http.routers.my-website-frontend-https.middlewares=redirect-to-non-www

Everything put together

The whole configuration should look something like this now:

version: '3.7'

services:
  fabiancdng-website:
    image: registry/.../my-website-image:latest
    labels:
      - traefik.enable=true
      - traefik.http.routers.my-website-frontend-http.rule=Host(`fabiancdng.com`) || Host(`www.fabiancdng.com`)
      - traefik.http.routers.my-website-frontend-http.entrypoints=http
      - traefik.http.routers.my-website-frontend-http.middlewares=redirect-to-https
      - traefik.http.routers.my-website-frontend-https.rule=Host(`fabiancdng.com`) || Host(`www.fabiancdng.com`)
      - traefik.http.routers.my-website-frontend-https.entrypoints=https
      - traefik.http.routers.my-website-frontend-https.tls=true
      - traefik.http.routers.my-website-frontend-https.tls.certresolver=letsencrypt
      - traefik.http.routers.my-website-frontend-https.middlewares=redirect-to-non-www
      - traefik.http.services.my-website-frontend.loadbalancer.server.port=3000
      - traefik.http.middlewares.redirect-to-https.redirectscheme.scheme=https
      - traefik.http.middlewares.redirect-to-https.redirectscheme.permanent=true
      - traefik.http.middlewares.redirect-to-non-www.redirectregex.regex=^https?://www.fabiancdng.com/(.*)
      - traefik.http.middlewares.redirect-to-non-www.redirectregex.replacement=https://fabiancdng.com/$${1}
      - traefik.http.middlewares.redirect-to-non-www.redirectregex.permanent=true
    networks:
      - proxy

networks:
  proxy:
    external: true

Done, both redirects should be working now!

Conclusion and further resources

Once you've gotten used to the way you write configuration and middlewares using the labels in Traefik, it's not that complicated after all (well- except when you need regex 😅; but you can just google that).

And being able to handle all these things properly in your reverse proxy can massively improve the user experience and SEO of your web services.

Lastly, if you want to learn even more about Traefik and how to work with it in more complex scenarios, I can recommend deploying a more complex service like, for instance, Nextcloud (even if it's just for practicing).

A while back, I wrote a blog post going into detail on how Nextcloud can be deployed with Docker and run behind Traefik as a reverse proxy.

Feel free to check that out: https://fabiancdng.com/blog/running-nextcloud-using-docker-and-traefik-3

I even wrote an article on how Traefik can work as a load balancer for Docker containers: https://fabiancdng.com/blog/scaling-next-js-web-apps-with-docker

Traefik is an awesome reverse proxy and I hope this example helped you gain more inside in Traefik's configuration system.

Cheers!

DEV Community: Fabian Reinders

Headless WordPress and Next.js

Why WordPress??

The Gutenberg editor

The ecosystem

Force of habit

My headless WordPress setup

VPS and Docker

WP REST

Webhooks

Part 1: Building the blog

Routing

Exporting paths

Rendering the blog post

Part 2: Building the portfolio

Updating posts and pages

Implementing On-Demand-Revalidation

Implementing webhooks

Conclusion

SEO for Developers: Pagination

Introduction

1. Use a consistent URL structure

2. Implement rel=prev/next tags

3. Canonicalization of links

What is canonicalization?

Canonicalization and pagination

4. Optimize page titles and meta descriptions

Conclusion

Scaling Node.js Web Apps with Docker

Introduction

The problem with Node.js and single-threading

Utilizing multiple CPU cores with Node.js

Multiple Node.js instances with Docker Compose

The docker-compose.yml

Load Balancing

A real-world example: This website

The hosting requirements

The reverse proxy and load balancer

A look ahead: Scaling horizontally across machines

Conclusion

Pagination in Next.js using SSG

What is Pagination?

The URL structure

/blog

/blog/posts

/blog/posts/[page]

The file structure

The Pagination component

The first page

Implementing the index.tsx page

Explanation

The dynamic sub-pages

Implementing the [page].tsx pages

Explanation

Conclusion and things to consider

How to Create Virtual Pages in WordPress

Why would I need this?

Step 1: Creating a WordPress plugin

Step 2: Creating a Rewrite rule

First parameter: The URL

Second parameter: Query variables

Step 3: Defining a custom query variable

Step 4: Creating the virtual page's template

Step 5: Flushing the rewrite rules

All set! 🥳

Running Nextcloud using Docker and Traefik 3

Why should you use Docker to deploy Nextcloud?

Why should you run the instance behind Traefik?

Why specifically Traefik and not other reverse proxies (like NGINX or Apache)?

Step 1: Setting up Nextcloud, MariaDB, and Redis

Creating the docker-compose.yml for Nextcloud, MariaDB, and Redis:

Step 2: Setting up Traefik

Creating the network

Creating the docker-compose.yml for Traefik

Step 3: Configuring Traefik

Done! 🥳

I Tried Blogging as a Developer for 7 Days 🧑‍💻

Introduction

My first post on dev.to

Cross-posting

The `docker-compose.yml`

`/blog`

`/blog/posts`

`/blog/posts/[page]`

Creating the `docker-compose.yml` for Nextcloud, MariaDB, and Redis:

Creating a `docker-compose.yml` for your app