Updating your Gatsby site when WordPress posts are published

During the last few weeks, I’ve covered most steps I took when moving from WordPress to a headless WordPress setup with Gatsby. One of the questions I often see is, “how do I update my Gatsby site when a post is published or updated?”. In this tutorial, I’ll cover what you need to know.

Continue reading “Updating your Gatsby site when WordPress posts are published”

Why I’m no longer contributing to Stack Overflow

Over the last seven years, I’ve been answering questions on Stack Overflow. I’ve answered more than 700 questions which helped 2 million developers. Additionally, I’ve flagged, reviewed and edited a few thousand posts, in order to maintain the site’s quality.

Maintaining the site is not an easy task, as interests between maintainers and the rest of the community are not always aligned. This has always been the case, but I loved participating in it, and it was appreciated by the people who manage Stack Overflow.

Sadly, the latter doesn’t feel true any longer. Over the last two years, it became clear that Stack Overflow does not seem to care about their community, nor their employees.

Why I think that way? Let’s rewind to about a year and a half ago. In October 2018, a discussion about one of Stack Overflow’s feature arose on Twitter. This feature, allowed questions that gained some popularity, to be visible within the sidebar. However, since this was all automated, questions that are not friendly towards other people aren’t filtered from it.

One of the problems of discussing it on Twitter, is that the limitation in amount of characters lead to heated discussion. In addition, a Stack Overflow employee joined the discussion, and rather than trying to mitigate, the employee added more fuel to the discussion. In the Twitter thread, the employee accused the moderators for being obnoxious trolls, and for sealioning.

The result was that this feature was (temporarily) removed. In addition, many community moderators were frustrated with how this was handled.

If one thing was clear, it’s that Stack Overflow had to put more effort into making everyone feel welcome. And so, great initiatives like the new Code of Conduct, the Welcome Wagon and the lifeboat badge were introduced. Fast forward one year later, and one of these initiatives, a Code of Conduct change about using preferred pronouns, was discussed amongst community moderators.

One of these community moderators argued that they prefer to write in a gender-neutral form. And again, in stead of mitigating, a Stack Overflow employee decided to fire the community moderator, and accuse the community moderator for misgendering. This discussion also got the attention of the press, in which the Stack Overflow employee discussed the matter with the press.

Regardless of which side was right or wrong, Stack Overflow should NEVER have dragged the name of one of their community moderators through the mud. Since then, the news article is the number one hit when searching for the community moderator their name. This means that they didn’t only harm the community moderator, but continue to do so in the future, as anyone (potential employers, new people they meet, …) searching for their name will end up with that article.

Rather than apologizing or retracting the statements Stack Overflow made, it took three months, a GoFundMe page and legal actions to get this rectified. Even then, a proper apology is still absent.

The conclusion is that there’s a lot of bad communication happening lately. Stack Overflow matured, and had to evolve their way of communicating. Sadly, by doing so, they burnt several bridges with the community.

Not only that, but they also decided to fire two of their community managers. This especially hurts because one of them was known exactly for building bridges with the community, and now that’s gone.

This leads me to the conclusion that Stack Overflow is not interested in rebuilding these bridges with the community.

You may think… why don’t you just continue answering questions and leave the whole moderation part? Well, I tried that as well. The last few months, I’ve been actively hiding all moderator- and meta-related questions from Stack Overflow using an Ad blocker.

This certainly made it easier for me. However, it doesn’t mean that even though I’m not seeing the problems there are, that there aren’t any.

In addition, Stack Overflow decided to unilaterally change the license of all posts (both past, present and future posts) from Creative Commons 3 to Creative Commons 4. While this change itself is not spectacular, it means that Stack Overflow isn’t hesitant in applying these changes any longer without consulting the community.

It also means that they could change the license to anything they like, and put everything behind a paywall.

So, here I am, January 2020, noticing that Stack Overflow is no longer about the community, nor about being open. Since I really cared about these two things, there isn’t really a reason for me to stay. As a solution, I decided to copy over my popular answers and rewrite them into blogposts. Writing dynamic queries with JPA and Loading initial data with Spring are examples of that.

And at last, I clicked that Logout link for the first time in seven years.

Adding syntax highlighting with WordPress and Gatsby

If you’re looking for syntax highlighting with Gatsby, chances are you’ve encountered an example using Prism.js. Sadly, the plugins that are available to do syntax highlighting, only work for Markdown, and not for WordPress.

In this tutorial I’ll explore the options we have to get syntax highlighting to work with WordPress.

Continue reading “Adding syntax highlighting with WordPress and Gatsby”

Optimize loading images with WordPress and Gatsby

In my previous tutorials, we’ve explored how to use WordPress with Gatsby. One issue we haven’t covered yet is to lazy-load embedded images within our WordPress posts. This isn’t easily done with gatsby-source-wordpress or other plugins.

In this tutorial, I’ll hack my way around it to show lazy images with Gatsby.

Continue reading “Optimize loading images with WordPress and Gatsby”

Working with Gatsby and pagination

A while back, I decided to use Gatsby for my WordPress blog, and continue with WordPress as a headless CMS. So far, I’ve also written two tutorials about setting up Gatsby with WordPress, and how to create detail pages for your content. In this tutorial, we’ll explore how we can use pagination with Gatsby.

Continue reading “Working with Gatsby and pagination”

Creating pages with Gatsby

In my latest tutorial, I’ve explored the possibilities with Gatsby and WordPress. While we built a proper index-page, our WordPress-powered Gatsby blog is far from done.

In this tutorial, I’ll pick up where we left off and start with creating detail-pages.

Using the Node API

Last time, I used the <Link> component to add a link for each blogpost to its detail page. However, clicking it right now points us to a 404 page, since we haven’t told Gatsby yet that we want to serve a page there.

To add pages during build-time, we have to use the gatsby-node.js API. Within this file, we can export certain hooks, and one of them is the createPages function.

This function passes two arguments, a graphql parameter to execute GraphQL queries, and the other is an actions object, which contains a function to create new pages.

Since we need both these parameters, we can initialize our code like this:

exports.createPages = ({graphql, actions}) => {
  const {createPage} = actions;
};

The next step is to find out which query we want to execute. In this case, I want to create a detail-page for every blog post, so I need to use a query like last time, to fetch allWordpressPost. This time, I won’t have to add a limit though:

const allPostsQuery = `{
  allWordpressPost {
    edges {
      node {
        id
        slug
      }
    }
  }
}`;

I also don’t need all the details of a post, only:

  • The slug, so I can tell Gatsby which page to generate.
  • And the id, which we can use to retrieve the post when we load the page.

Creating detail pages

Now that we have our query, we can execute it using the graphql parameter. When executing, this returns a promise, which we have to return within the createPages hook:

exports.createPages = ({graphql, actions}) => {
  const {createPage} = actions;
  return graphql(allPostsQuery).then(({errors, data}) => {
    if (errors) return Promise.reject(errors);
  });
};

Using the data, we can call the createPage function for every post like this:

return data.allWordpressPost.edges.map(({node}) => createPage({
  path: node.slug,
  component: path.resolve('./src/templates/post.js'),
  context: {id: node.id}
});

As you can see, the createPage function requires a parameter containing three fields:

  • The path to serve the page.
  • Additionally, we have to provide which component we should use to render the page.
  • Optionally, we can also pass parameters as the context of the page.

The component should contain an absolute path to the component that we want to use. To do this, we use path.resolve() which we can only use if we properly import it:

const path = require('path');

Creating a page component

While we’ve set up Gatsby to create new pages for every WordPress post, we’re not ready yet. The next step is to implement the src/templates/post.js page component.

For the structure of this component, we can look at src/pages/index.js and copy the same structure over:

const PostPage = () => (
  <Layout>
    <SEO title="Home"/>
  </Layout>
);

export default PostPage;

Now, like before, we have to execute a GraphQL query to retrieve the data. However, we can’t use the useStaticQuery hook, since our query will be parameterized.

An alternative method to execute a GraphQL query is to export it:

export const query = graphql`
  query ($id: String!) {
    wordpressPost(id: {eq: $id}) {
      date(formatString: "MMMM Do, YYYY")
      title
      content
      slug
      tags {
        name
      }
    }
  }
`;

The nice part about Gatsby is that it automatically recognizes that your GraphQL query uses variables ($id), and will automatically pass context parameters as variables.

Additionally, we can retrieve the data in our component like this:

const Post = ({data}) => {
  return (
    <Layout>
      <SEO title={data.wordpressPost.title}/>
      <PostTitle
        title={data.wordpressPost.title}
        slug={data.wordpressPost.slug}
        tags={data.wordpressPost.tags}
        date={data.wordpressPost.date}/>
      <div dangerouslySetInnerHTML={{__html: data.wordpressPost.content}}/>
    </Layout>
  );
};

In this example, we’re using the PostTitle component from last time. Additionally, we’re using dangerouslySetInnerHTML to add the content of the post. This is necessary because our WordPress content contains HTML tags we want to render.

To take effect, we have to re-run the Gatsby application. This will create the new pages, and now you should be able to view them in action.

Gatsby detail page

With that, we’ve created our first example of custom pages with Gatsby. Next time we’ll explore how we can achieve pagination. If you’re interested in the code, you can check out the source of my blog on GitHub.