The Final Free Solo Weblog Setup With Ghost And Gatsby

As of late it appears there are an countless variety of instruments and platforms for creating your personal weblog. Nonetheless, a lot of the choices on the market lean in the direction of non-technical customers and summary away all the choices for personalization and really making one thing your personal.

If you’re somebody who is aware of their means round front-end growth, it may be irritating to discover a resolution that provides you the management you need, whereas eradicating the admin from managing your weblog content material.

Enter the Headless Content material Administration System (CMS). With a Headless CMS, you may get all the instruments to create and set up your content material, whereas sustaining 100% management of how it’s delivered to your readers. In different phrases, you get all the backend construction of a CMS whereas not being restricted to its inflexible front-end themes and templates.

In terms of Headless CMS methods, I’m an enormous fan of Ghost. Ghost is open-source and easy to make use of, with a lot of nice APIs that make it versatile to make use of with static web site builders like Gatsby.

On this article, I’ll present you the way you need to use Ghost and Gatsby collectively to get the final word private weblog setup that allows you to maintain full management of your front-end supply, however leaves all of the boring content material administration to Ghost.

Oh, and it’s 100% free to arrange and run. That’s as a result of we might be working our Ghost occasion domestically after which deploying to Netlify, profiting from their beneficiant free tier.

Let’s dive in!

Setting Up Ghost And Gatsby

I’ve written a starter put up on this earlier than that covers the very fundamentals, so I received’t go too in-depth into them right here. As a substitute, I’ll deal with the extra superior points and gotchas that come up when working a headless weblog.

However in brief, right here’s what we have to do to get a primary set-up up and working that we are able to work from:

• Set up an area model of the Gatsby Starter Weblog
• Set up Ghost domestically
• Change the supply knowledge from Markdown to Ghost (swap out gatsby-source-file system for gatsby-source-ghost)
• Modify the GraphQL queries in your gatsby-node, templates, and pages to match the gatsby-source-ghost schema

For extra particulars on any of those steps, you possibly can take a look at my previous article.

Or you possibly can simply begin from the code in this Github repository.

Dealing With Photographs

With the fundamentals out of the way in which, the primary subject we run into with a headless weblog that builds domestically is what to do with photographs.

Ghost by default serves photographs from its personal server. So if you go headless with a static web site, you’ll run right into a state of affairs the place your content material is constructed and served from an edge supplier like Netlify, however your photographs are nonetheless being served by your Ghost server.

This isn’t very best from a efficiency perspective and it makes it unimaginable to construct and deploy your web site domestically (which suggests you would need to pay month-to-month charges for a Digital Ocean droplet, AWS EC2 occasion, or another server to host your Ghost occasion).

However we are able to get round that if we are able to discover one other resolution to host our photographs &mdash, and fortunately, Ghost has storage converters that allow you to retailer photographs within the cloud.

For our functions, we’re going to use an AWS S3 converter, which allows us to host our photographs on AWS S3 together with Cloudfront to provide us an analogous efficiency to the remainder of our content material.

There are two open-source choices out there: ghost-storage-adapter-s3 and ghost-s3-compat. I take advantage of ghost-storage-adapter-s3 since I discover the docs simpler to observe and it was extra not too long ago up to date.

That being stated, if I adopted the docs precisely, I bought some AWS errors, so right here’s the method that I adopted that labored for me:

• Create a brand new S3 Bucket in AWS and choose Disable Static Internet hosting
• Subsequent, create a brand new Cloudfront Distribution and choose the S3 Bucket because the Origin
• When configuring the Cloudfront Distribution, below S3 Bucket Entry:
  • Choose “Sure, use OAI (bucket can prohibit entry to solely Cloudfront)”
  • Create a New OAI
  • And eventually, choose “Sure, replace the bucket coverage”
  • 
  • This creates an AWS S3 Bucket that may solely be accessed by way of the Cloudfront Distribution that you’ve created.

Then, you simply must create an IAM Person for Ghost that may allow it to write down new photographs to your new S3 Bucket. To do that, create a brand new Programmatic IAM Person and connect this coverage to it:

{
    "Model": "2012-10-17",
    "Assertion": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::YOUR-S3-BUCKET-NAME"
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:PutObjectVersionAcl",
                "s3:DeleteObject",
                "s3:PutObjectAcl"
            ],
            "Useful resource": "arn:aws:s3:::YOUR-S3-BUCKET-NAME/*"
        }
    ]
} 


With that, our AWS setup is full, we simply want to inform Ghost to learn and write our photographs there as a substitute of to its native server.

To try this, we have to go to the folder the place our Ghost occasion is put in and open the file: ghost.growth.json orghost.manufacturing.json.(relying on what surroundings you’re at the moment working)

Then we simply want so as to add the next:

{
  "storage": {
  "lively": "s3",
  "s3": {
    "accessKeyId": "[key]",
    "secretAccessKey": "[secret]",
    "area": "[region]",
    "bucket": "[bucket]",
    "assetHost": "https://[subdomain].instance.com", // cloudfront
    "forcePathStyle": true,
    "acl": "non-public"
  }
}


The values for accessKeyId and secretAccessKey may be discovered out of your IAM setup, whereas the area and bucket seek advice from the area and bucket title of your S3 bucket. Lastly, the assetHost is the URL of your Cloudfront distribution.

Now, in case you restart your Ghost occasion, you will notice that any new photographs you save are in your S3 bucket and Ghost is aware of to hyperlink to them there. (Notice: Ghost received’t make updates retroactively, so you should definitely do that very first thing after a recent Ghost set up so that you don’t should re-upload photographs later)

Dealing with Inside Hyperlinks

With Photographs out of the way in which, the subsequent difficult factor we want to consider is inner hyperlinks. As you might be writing content material in Ghost and inserting hyperlinks in Posts and Pages, Ghost will robotically add the positioning’s URL to all inner hyperlinks.

So for instance, in case you put a hyperlink in your weblog put up that goes to /my-post/, Ghost goes to create a hyperlink that goes to https://mysite.com/my-post/.

Usually, this isn’t an enormous deal, however for Headless blogs this causes issues. It’s because your Ghost occasion might be hosted someplace separate out of your front-end and in our case it received’t even be reachable on-line since we might be constructing domestically.

Because of this we might want to undergo every weblog put up and web page to appropriate any inner hyperlinks. Fortunately, this isn’t as arduous because it sounds.

First, we’ll add this HTML parsing script in a brand new file known as replaceLinks.js and put it in a brand new utils folder at src/utils:

const url = require(`url`);
const cheerio = require('cheerio');

const replaceLinks = async (htmlInput, siteUrlString) => {
  const siteUrl = url.parse(siteUrlString);
  const $ = cheerio.load(htmlInput);
  const hyperlinks = $('a');
  hyperlinks.attr('href', operate(i, href){
    if (href) {
      const hrefUrl = url.parse(href);
      if (hrefUrl.protocol === siteUrl.protocol && hrefUrl.host === siteUrl.host) {
        return hrefUrl.path
      }

      return href;
    }

  });
  return $.html();
}

module.exports = replaceLinks;


Then we’ll add the next to our gatsby-node.js file:

exports.onCreateNode = async ({ actions, node, getNodesByType }) => {
  if (node.inner.proprietor !== `gatsby-source-ghost`) {
    return
  }
  if (node.inner.sort === 'GhostPage' || node.inner.sort === 'GhostPost') {
    const settings = getNodesByType(`GhostSettings`);
    actions.createNodeField({
      title: 'html',
      worth: replaceLinks(node.html, settings[0].url),
      node
    })
  }
}


You will notice that we’re including two new packages in replaceLinks.js, so let’s begin by putting in these with NPM:

npm set up --save url cheerio


In our gatsby-node.js file, we’re hooking into Gatsby’s onCreateNode, and particularly into any nodes which might be created from knowledge that comes from gatsby-source-ghost (versus metadata that comes from our config file that we don’t care about for now).

Then we’re checking the node sort, to filter out any nodes that aren’t Ghost Pages or Posts (since these are the one ones that may have hyperlinks inside their content material).

Subsequent, we’re getting the URL of the Ghost web site from the Ghost settings and passing that to our removeLinks operate together with the HTML content material from the Web page/Publish.

In replaceLinks, we’re utilizing cheerio to parse the HTML. Then we are able to then choose all the hyperlinks on this HTML content material and map via their href attributes. We are able to then examine if the href attribute matches the URL of the Ghost Web site — if it does, we’ll exchange the href attribute with simply the URL path, which is the inner hyperlink that we’re searching for (e.g. one thing like /my-post/).

Lastly, we’re making this new HTML content material out there via GraphQL utilizing Gatsby’s createNodeField (Notice: we should do it this manner since Gatsby doesn’t help you overwrite fields at this part within the construct).

Now our new HTML content material might be out there in our blog-post.js template and we are able to entry it by altering our GraphQL question to:

ghostPost(slug: { eq: $slug }) {
  id
  title
  slug
  excerpt
  published_at_pretty: published_at(formatString: "DD MMMM, YYYY")
  html
  meta_title
  fields {
  html
  } 
}


And with that, we simply must tweak this part within the template:

To be:

This makes all of our inner hyperlinks reachable, however we nonetheless have yet one more downside. All of those hyperlinks are anchor tags whereas with Gatsby we needs to be utilizing Gatsby Hyperlink for inner hyperlinks (to keep away from web page refreshes and to offer a extra seamless expertise).

Fortunately, there’s a Gatsby plugin that makes this very easy to resolve. It’s known as gatsby-plugin-catch-links and it seems for any inner hyperlinks and robotically replaces the anchor tags with Gatsby .

All we have to do is set up it utilizing NPM:

npm set up --save gatsby-plugin-catch-links


And add gatsby-plugin-catch-links into our plugins array in our gatsby-config file.

Including Templates And Types

Now the large stuff is technically working, however we’re lacking out on a few of the content material from our Ghost occasion.

The Gatsby Starter Weblog solely has an Index web page and a template for Weblog Posts, whereas Ghost by default has Posts, Pages, in addition to pages for Tags and Authors. So we have to create templates for every of those.

For this, we are able to leverage the Gatsby starter that was created by the Ghost team.

As a place to begin for this mission, we are able to simply copy and paste quite a lot of the recordsdata instantly into our mission. Right here’s what we’ll take:

• Your complete folder src/components/common/meta — we’ll copy this into our src/elements folder (so we’ll now have a folder src/elements/meta)
• The part recordsdata Pagination.js and PostCard.js — we’ll copy these into our src/elements folder
• We are going to create a src/utils folder and add two recordsdata from their src/utils folder: fragments.js and siteConfig.js
• And the next templates from their src/templates folder: tag.js, page.js, author.js, and post.js

The meta recordsdata are including JSON structured knowledge markup to our templates. This can be a nice profit that Ghost provides by default on their platform and so they’ve transposed it into Gatsby as a part of their starter template.

Then we took the Pagination and PostCard.js elements that we are able to drop proper into our mission. And with these elements, we are able to take the template recordsdata and drop them into our mission and they’ll work.

The fragments.js file makes our GraphQL queries rather a lot cleaner for every of our pages and templates — we now simply have a central supply for all of our GraphQL queries. And the siteConfig.js file has a couple of Ghost configuration choices which might be best to place in a separate file.

Now we’ll simply want to put in a couple of npm packages and replace our gatsby-node file to make use of our new templates.

The packages that we might want to set up are gatsby-awesome-pagination, @tryghost/helpers, and @tryghost/helpers-gatsby.

So we’ll do:

npm set up --save gatsby-awesome-pagination @tryghost/helpers @tryghost/helpers-gatsby


Then we have to make some updates to our gatsby-node file.

First, we’ll add the next new imports to the highest of our file:

const { paginate } = require(`gatsby-awesome-pagination`);
const { postsPerPage } = require(`./src/utils/siteConfig`);


Subsequent, in our exports.createPages, we’ll replace our GraphQL question to:

{
  allGhostPost(type: { order: ASC, fields: published_at }) {
      edges {
          node {
              slug
          }
      }
  }
  allGhostTag(type: { order: ASC, fields: title }) {
      edges {
          node {
              slug
              url
              postCount
          }
      }
  }
  allGhostAuthor(type: { order: ASC, fields: title }) {
      edges {
          node {
              slug
              url
              postCount
          }
      }
  }
  allGhostPage(type: { order: ASC, fields: published_at }) {
      edges {
          node {
              slug
              url
          }
      }
  }
}


This can pull all the GraphQL knowledge we want for Gatsby to construct pages primarily based on our new templates.

To try this, we’ll extract all of these queries and assign them to variables:

// Extract question outcomes
  const tags = outcome.knowledge.allGhostTag.edges
  const authors = outcome.knowledge.allGhostAuthor.edges
  const pages = outcome.knowledge.allGhostPage.edges
  const posts = outcome.knowledge.allGhostPost.edges


Then we’ll load all of our templates:

// Load templates
  const tagsTemplate = path.resolve(`./src/templates/tag.js`)
  const authorTemplate = path.resolve(`./src/templates/creator.js`)
  const pageTemplate = path.resolve(`./src/templates/web page.js`)
  const postTemplate = path.resolve(`./src/templates/put up.js`)


Notice right here that we’re changing our outdated blog-post.js template with put up.js, so we are able to go forward and delete blog-post.js from our templates folder.

Lastly, we’ll add this code to construct pages from our templates and GraphQL knowledge:

// Create tag pages
tags.forEach(({ node }) => {
    const totalPosts = node.postCount !== null ? node.postCount : 0

    // This half right here defines, that our tag pages will use
    // a `/tag/:slug/` permalink.
    const url = `/tag/${node.slug}`

    const gadgets = Array.from({size: totalPosts})

    // Create pagination
    paginate({
        createPage,
        gadgets: gadgets,
        itemsPerPage: postsPerPage,
        part: tagsTemplate,
        pathPrefix: ({ pageNumber }) => (pageNumber === 0) ? url : `${url}/web page`,
        context: {
            slug: node.slug
        }
    })
})

// Create creator pages
authors.forEach(({ node }) => {
    const totalPosts = node.postCount !== null ? node.postCount : 0

    // This half right here defines, that our creator pages will use
    // a `/creator/:slug/` permalink.
    const url = `/creator/${node.slug}`

    const gadgets = Array.from({size: totalPosts})

    // Create pagination
    paginate({
        createPage,
        gadgets: gadgets,
        itemsPerPage: postsPerPage,
        part: authorTemplate,
        pathPrefix: ({ pageNumber }) => (pageNumber === 0) ? url : `${url}/web page`,
        context: {
            slug: node.slug
        }
    })
})

// Create pages
pages.forEach(({ node }) => {
  // This half right here defines, that our pages will use
  // a `/:slug/` permalink.
  node.url = `/${node.slug}/`

  createPage({
      path: node.url,
      part: pageTemplate,
      context: {
          // Knowledge handed to context is on the market
          // in web page queries as GraphQL variables.
          slug: node.slug,
      },
  })
})

// Create put up pages
posts.forEach(({ node }) => {
    // This half right here defines, that our posts will use
    // a `/:slug/` permalink.
    node.url = `/${node.slug}/`
    createPage({
        path: node.url,
        part: postTemplate,
        context: {
            // Knowledge handed to context is on the market
            // in web page queries as GraphQL variables.
            slug: node.slug,
        },
    })
})


Right here, we’re looping in flip via our tags, authors, pages, and posts. For our pages and posts, we’re merely creating slugs after which creating a brand new web page utilizing that slug and telling Gatsby what template to make use of.

For the tags and creator pages, we’re additionally including pagination information utilizing gatsby-awesome-pagination that might be handed into the web page’s pageContext.

With that, all of our content material ought to now be efficiently constructed and displayed. However we might use a bit of labor on styling. Since we copied over our templates instantly from the Ghost Starter, we are able to use their kinds as properly.

Not all of those might be relevant, however to maintain issues easy and never get too slowed down in styling, I took all the kinds from Ghost’s src/styles/app.css ranging from the part Format till the top. Then you’ll simply paste these into the top of your src/kinds.css file.

Observe all the kinds beginning with kg — this refers to Koening which is the title of the Ghost editor. These kinds are crucial for the Publish and Web page templates, as they’ve particular kinds that deal with the content material that’s created within the Ghost editor. These kinds make sure that all the content material you might be writing in your editor is translated over and displayed in your weblog accurately.

Lastly, we want our web page.js and put up.js recordsdata to accommodate our inner hyperlink alternative from the earlier step, beginning with the queries:

Web page.js

ghostPage(slug: { eq: $slug } ) {
  ...GhostPageFields
    fields {
      html
     }
}


Publish.js

ghostPost(slug: { eq: $slug } ) {
  ...GhostPostFields
    fields {
      html
    }
}


After which the sections of our templates which might be utilizing the HTML content material. So in our put up.js we’ll change:

To:

And equally, in our web page.js file, we’ll change web page.html to web page.fields.html.

Dynamic Web page Content material

One of many disadvantages of Ghost when used as a conventional CMS, is that it isn’t attainable to edit particular person items of content material on a web page with out going into your precise theme recordsdata and arduous coding it.

Say you may have a bit in your web site that may be a Name-to-Motion or buyer testimonials. If you wish to change the textual content in these packing containers, you’ll have to edit the precise HTML recordsdata.

One of many nice elements of going headless is that we are able to make dynamic content material on our web site that we are able to simply edit utilizing Ghost. We’re going to do that by utilizing Pages that we’ll mark with ‘inner’ tags or tags that begin with a # image.

So for instance, let’s go into our Ghost backend, create a brand new Web page known as Message, sort one thing as content material, and most significantly, we’ll add the tag #message.

Now let’s return to our gatsby-node file. At the moment, we’re constructing pages for all of our tags and pages, but when we modify our GraphQL question in createPages, we are able to exclude every little thing inner:

allGhostTag(type: { order: ASC, fields: title }, **filter: {slug: {regex: "https://smashingmagazine.com/^((?!hash-).)*$/"}}**) {
    edges {
        node {
            slug
            url
            postCount
        }
    }
}
//...
allGhostPage(type: { order: ASC, fields: published_at }, **filter: {tags: {elemMatch: {slug: {regex: "https://smashingmagazine.com/^((?!hash-).)*$/"}}}}**) {
    edges {
        node {
            slug
            url
            html
        }
    }
}


We’re including a filter on tag slugs with the regex expression /^((?!hash-).)*$/. This expression is saying to exclude any tag slugs that embody hash-.

Now, we received’t be creating pages for our inner content material, however we are able to nonetheless entry it from our different GraphQL queries. So let’s add it to our index.js web page by including this to our question:

question GhostIndexQuery($restrict: Int!, $skip: Int!) {
    web site {
      siteMetadata {
        title
      }
    }
    message: ghostPage
      (tags: {elemMatch: {slug: {eq: "hash-message"}}}) {
        fields {
          html
        }
    }
    allGhostPost(
        type: { order: DESC, fields: [published_at] },
        restrict: $restrict,
        skip: $skip
    ) {
      edges {
        node {
          ...GhostPostFields
        }
      }
    }
  }


Right here we’re creating a brand new question known as “message” that’s searching for our inner content material web page by filtering particularly on the tag #message. Then let’s use the content material from our #message web page by including this to our web page:

//...
const BlogIndex = ({ knowledge, location, pageContext }) => {
  const siteTitle = knowledge.web site.siteMetadata?.title || `Title`
  const posts = knowledge.allGhostPost.edges
  const message = knowledge.message;
//...
return (
  

      
  )
}

    

Ending Touches

Now we’ve bought a very nice weblog setup, however we are able to add a couple of closing touches: pagination on our index web page, a sitemap, and RSS feed.

First, so as to add pagination, we might want to convert our index.js web page right into a template. All we have to do is minimize and paste our index.js file from our src/pages folder over to our src/templates folder after which add this to the part the place we load our templates in gatsby-node.js:

// Load templates
 const indexTemplate = path.resolve(`./src/templates/index.js`)


Then we have to inform Gatsby to create our index web page with our index.js template and inform it to create the pagination context.

Altogether we’ll add this code proper after the place we create our put up pages:

// Create Index web page with pagination
  paginate({
      createPage,
      gadgets: posts,
      itemsPerPage: postsPerPage,
      part: indexTemplate,
      pathPrefix: ({ pageNumber }) => {
          if (pageNumber === 0) {
            return `/`
          } else {
              return `/web page`
            }
      },
  })


Now let’s open up our index.js template and import our Pagination part and add it proper beneath the place we map via our posts:

import Pagination from '../elements/pagination'
//...
      

  

  
      
  
//...
  



Then we simply want to vary the hyperlink to our weblog posts from:

to:

This prevents Gatsby Hyperlink from prefixing our hyperlinks on pagination pages — in different phrases, if we didn’t do that, a hyperlink on web page 2 would present as /web page/2/my-post/ as a substitute of simply /my-post/ like we wish.

With that finished, let’s arrange our RSS feed. This can be a fairly easy step, as we are able to use a ready-made script from the Ghost staff’s Gatsby starter. Let’s copy their file generate-feed.js into our src/utils folder.

Then let’s use it in our gatsby-config.js by changing the prevailing gatsby-plugin-feed part with:

{
  resolve: `gatsby-plugin-feed`,
  choices: {
      question: `
      {
          allGhostSettings {
              edges {
                  node {
                      title
                      description
                  }
              }
          }
      }
    `,
      feeds: [
          generateRSSFeed(config),
      ],
  },
}


We might want to import our script together with our siteConfig.js file:

const config = require(`./src/utils/siteConfig`);
const generateRSSFeed = require(`./src/utils/generate-feed`);
//...

Lastly, we have to make one essential addition to our generate-feed.js file. Proper after the GraphQL question and the output subject, we have to add a title subject:

#...
output: `/rss.xml`,
title: "Gatsby Starter Weblog RSS Feed",
#...


With out this title subject, gatsby-plugin-feed will throw an error on the construct.

Then for our final of entirety, let’s add our sitemap by putting in the package deal gatsby-plugin-advanced-sitemap:

npm set up --save gatsby-plugin-advanced-sitemap


And including it to our gatsby-config.js file:

{
  resolve: `gatsby-plugin-advanced-sitemap`,
  choices: {
      question: `
        {
            allGhostPost {
                edges {
                    node {
                        id
                        slug
                        updated_at
                        created_at
                        feature_image
                    }
                }
            }
            allGhostPage {
                edges {
                    node {
                        id
                        slug
                        updated_at
                        created_at
                        feature_image
                    }
                }
            }
            allGhostTag {
                edges {
                    node {
                        id
                        slug
                        feature_image
                    }
                }
            }
            allGhostAuthor {
                edges {
                    node {
                        id
                        slug
                        profile_image
                    }
                }
            }
        }`,
        mapping: {
            allGhostPost: {
                sitemap: `posts`,
            },
            allGhostTag: {
                sitemap: `tags`,
            },
            allGhostAuthor: {
                sitemap: `authors`,
            },
            allGhostPage: {
                sitemap: `pages`,
            },
        },
        exclude: [
            `/dev-404-page`,
            `/404`,
            `/404.html`,
            `/offline-plugin-app-shell-fallback`,
        ],
        createLinkInHead: true,
        addUncaughtPages: true,
    }
}
}


The question, which additionally comes from the Ghost team’s Gatsby starter, creates particular person sitemaps for our pages and posts in addition to our creator and tag pages.

Now, we simply should make one small change to this question to exclude our inner content material. Identical as we did within the prior step, we have to replace these queries to filter out tag slugs that comprise ‘hash-’:

allGhostPage(filter: {tags: {elemMatch: {slug: {regex: "https://smashingmagazine.com/^((?!hash-).)*$/"}}}}) {
    edges {
        node {
            id
            slug
            updated_at
            created_at
            feature_image
        }
    }
}
allGhostTag(filter: {slug: {regex: "https://smashingmagazine.com/^((?!hash-).)*$/"}}) {
    edges {
        node {
            id
            slug
            feature_image
        }
    }
}


Wrapping Up

With that, you now have a totally functioning Ghost weblog working on Gatsby that you would be able to customise from right here. You possibly can create your entire content material by working Ghost in your localhost after which if you end up able to deploy, you merely run:

gatsby construct


After which you possibly can deploy to Netlify utilizing their command-line instrument:

netlify deploy -p


Since your content material solely lives in your native machine, additionally it is a good suggestion to make occasional backups, which you are able to do utilizing Ghost’s export characteristic.

This exports your entire content material to a json file. Notice, it doesn’t embody your photographs, however these might be saved on the cloud anyway so that you don’t want to fret as a lot about backing these up.

I hope you loved this tutorial the place we lined:

• Establishing Ghost and Gatsby;
• Dealing with Ghost Photographs utilizing a storage converter;
• Changing Ghost inner hyperlinks to Gatsby Hyperlink;
• Including templates and kinds for all Ghost content material sorts;
• Utilizing dynamic content material created in Ghost;
• Establishing RSS feeds, sitemaps, and pagination.

If you’re inquisitive about exploring additional what’s attainable with a headless CMS, take a look at my work at Epilocal, the place I’m utilizing an analogous tech stack to construct instruments for native information and different unbiased, on-line publishers.

Notice: You will discover the full code for this project on Github here, and you too can see a working demo here.

Additional Studying on Smashing Journal

• “Building Gatsby Themes For WordPress-Powered Websites,” Paulina Hetman
• “Building An API With Gatsby Functions,” Paul Scanlon
• “Advanced GraphQL Usage In Gatsby Websites,” Aleem Isiaka
• “Gatsby Serverless Functions And The International Space Station,” Paul Scanlon