Skip to content

clean-commit/gatsby-starter-henlo

Repository files navigation

Henlo Starter

Gatsby Starter Henlo (v1.2.0)

Netlify Status

Official Website / Demo

Gatsby Starter Henlo is the most advanced Decap CMS starter for Gatsby.js. We built it with Page Builder setup in mind. All pages are created out of programmable blocks, aiming to provide the best DX & admin UX possible.

This repo contains an example website that is built with Gatsby, and Decap CMS.

It follows the JAMstack architecture by using Git as a single source of truth, and Netlify for continuous deployment, and CDN distribution.

Features

  • Support for Gatsby v5
  • πŸ’ͺ Battle-tested starting point for small & large web projects
  • πŸ“„ Form Builder that enables Admins to create multiple forms with ease & Netlify Forms integration.
  • πŸŒ— Darkmode support
  • πŸ—Ί Sitemaps using gatsby-plugin-sitemap
  • πŸ”₯ Perfect score on Lighthouse for SEO, Accessibility and Performance
  • πŸ’‡β€β™€οΈ TailwindCSS support with PostCSS & Tailwind Merge
  • πŸ”Œ Support for Gatsby API functions
  • πŸŽ‡ Crazy fast images with gatsby-plugin-image
  • πŸ•΅οΈβ€β™‚οΈ Complete SEO configuration with graphql fragment and reusable components based on Head API
  • Netlify deploy configuration
  • Example pages, collections, CMS configuration with Decap CMS & hooks
  • Readme template for custom projects
  • Easy Decap CMS configuration using Manual Initialization
  • ..and more

Prerequisites

Getting Started (Recommended)

Decap CMS can run in any frontend web environment, but the quickest way to try it out is by running it on a pre-configured starter site with Netlify. Use the button below to build and deploy your own copy of the repository:

Deploy to Netlify

After clicking that button, you’ll authenticate with GitHub and choose a repository name. Netlify will then automatically create a repository in your GitHub account with a copy of the files from the template. Next, it will build and deploy the new site on Netlify, bringing you to the site dashboard when the build is complete. Next, you’ll need to set up Netlify’s Identity service to authorize users to log in to the CMS.

Getting Started (Without Netlify)

$ gatsby new [SITE_DIRECTORY_NAME] https://github.com/clean-commit/gatsby-starter-henlo
$ cd [SITE_DIRECTORY_NAME]
$ yarn dev

Access Locally

Pulldown a local copy of the Github repository Netlify created for you, with the name you specified in the previous step

$ git clone https://github.com/[GITHUB_USERNAME]/[REPO_NAME].git
$ cd [REPO_NAME]
$ yarn && yarn dev

To test the CMS locally, you'll need to start your local development server & run local instance of Decap CMS

$ yarn dev
$ yarn cms
// or
$ npx decap-server

Your admin configuration will be available at http://localhost:8000/admin

Deployment

We've added additional commands for quick deployments with Netlify CLI. To deploy the website to Netlify simply run.

$ yarn deploy:prod

The website will build locally and then deploy to production.

Before deploying to Netlify, you need to:

  • Define GATSBY_APP_URL to your domain
  • Update redirects in netlify.toml to reflect your website (example is set up)

Folder structure

β”œβ”€β”€ cms                      # Decap CMS configuration
β”‚   β”œβ”€β”€ blocks
β”‚   β”œβ”€β”€ collections
β”‚   β”œβ”€β”€ fields
β”‚   β”œβ”€β”€ previews
β”‚   └── cms.js
β”œβ”€β”€ content                  # Your content lives here
β”‚   β”œβ”€β”€ authors
β”‚   β”œβ”€β”€ blog
β”‚   β”œβ”€β”€ forms
β”‚   └── pages
β”œβ”€β”€ public
β”œβ”€β”€ src
β”‚   β”œβ”€β”€ api                  # Gatsby functions should be placed here
β”‚   β”œβ”€β”€ blocks               # Blocks that create sections
β”‚   β”œβ”€β”€ components           # Reusable components
β”‚   β”‚   └── UI               # UI specialized components
β”‚   β”œβ”€β”€ hooks                # Hooks used in the project
β”‚   β”œβ”€β”€ lib                  # misc
β”‚   β”œβ”€β”€ pages
β”‚   β”œβ”€β”€ resolvers
β”‚   β”‚   β”œβ”€β”€ Image.js         # Required for previews
β”‚   β”‚   └── Link.js          # Resolves links to gatsby and outside links
β”‚   β”œβ”€β”€ settings             # Place for theme settings
β”‚   β”œβ”€β”€ styles
β”‚   └── templates            # Templates used to render page types
β”‚       β”œβ”€β”€ page-builder.js
β”‚       └── post.js
β”œβ”€β”€ static
β”œβ”€β”€ _headers
β”œβ”€β”€ .env.example             # Example env -> GATSBY_APP_URL is required to run the app
β”œβ”€β”€ gatsby-config.js         # Config files for gatsby
β”œβ”€β”€ gatsby-node.js           # Page generation setup & types interferrence
└── tailwind.config.js       # Tailwind configuration

Setting up the CMS

Follow the Decap CMS Quick Start Guide to set up authentication, and hosting.

Important This template can be mostly changed by the user within the CMS itself (Settings type). For sitemaps to work correctly, you'll need to provide ENV variable GATSBY_APP_URL which defaults to https://example.com, this url will be used in setting up meta values in the head of the documents and links URL in the CMS.

CMS configuration was placed within cms directory in the root of the project. This allows us to work efficiently on fields and collections without mixing CMS config with Gatsby code.

Henlo uses Manual Initialization to take advantage of componetized approach to managing configuration for Decap CMS. Thanks to that you don't have to control the CMS from centralized YAML file.

To ensure best experience we use 2 custom widgets that are maintained by us -> ID Widget that provides unmutable IDs for content items and Permalink Widget that enables you to create custom permalinks with ease.

import CMS from 'decap-cms-app'
import { Widget as UuidWidget } from 'netlify-cms-widget-id'
import { Widget as PermalinkWidget } from 'netlify-cms-widget-permalink'
import authors from './collections/authors'
import pages from './collections/pages'
import posts from './collections/posts'
import settings from './collections/settings'
import PagePreview from './previews/Page'

// Preview for all PageBuilder based pages

const config = {
  config: {
    load_config_file: false,
    display_url: process.env.GATSBY_APP_URL, // Enables urls based on env variable
    local_backend: true,
    backend: {
      name: 'git-gateway',
    },
    slug: {
      encoding: 'ascii',
      clean_accents: true,
    },
    media_folder: '/static/img',
    public_folder: '/img',
    collections: [pages, posts, authors, settings],
  },
}

CMS.registerPreviewStyle('../commons.css')
CMS.registerPreviewTemplate('pages', PagePreview)

CMS.registerWidget(UuidWidget)
CMS.registerWidget(PermalinkWidget)

CMS.init(config)

Adding blocks

Blocks are defined in cms/blocks/index.js file. We're leveraging use of exported functions and variables from other fields to avoid repetition within the code.

This is extremely important due to the way GraphQL works with Markdown based files. Each field will have to be present on all page queries -> we can't differetiate between different sections.

That's why it's important to reuse names of fields, hence usage of imports.

import { Buttons, Title, Content, SelectField, ImageField } from '../fields';

const Config = {
  label: 'Blocks',
  name: 'blocks',
  widget: 'list',
  types: [
    {
      label: 'Hero',
      name: 'hero',
      widget: 'object',
      fields: [
        Title,
        Content,
        Buttons,
        SelectField('default', ['default', 'centered', 'full']),
      ],
    },
...

To add new block you have tp add new Type to cms/blocks/index.js file, and modify Blocks fragment located in src/components/PageBuilder.js

As you can see below we're adding all fields used by all sections. This causes issues with Gatsby's Schema Inference. Gatsby needs an example of the field to know what type of field it is.

That's why we rely on dont-remove.md this file contains all possible fields used in the starter, so you're never encounter a problem with types inference!

export const query = graphql`
  fragment Blocks on MarkdownRemarkFrontmatter {
    blocks {
      type
      title
      content
      columns {
        title
        content
      }
      photo {
        image {
          childImageSharp {
            gatsbyImageData(
              width: 800
              quality: 72
              placeholder: DOMINANT_COLOR
              formats: [AUTO, WEBP, AVIF]
            )
          }
        }
        alt
      }
      variant
      buttons {
        button {
          content
          url
          variant
        }
      }
    }
  }
`

To keep the GraphQL query small, we opt to reuse the field names across blocks, but if new type is added it has to be defined in graphql using createSchemaCustomization function. Without the definition you may encounter errors during build process.

Adding Favicons

Favicons can be generated using this Favicon Generator After generating the icons, drop the contents of downloaded file into static/img/favicons directory

Preloading fonts

Since 0.4.0 Henlo supports gatsby-plugin-preload-fonts plugin out of the box. To create the preload cache you need to start development server and then run preload-fonts command. This will generate the font-preload-cache.json file in the root of your project. When your projects builds fonts will be added automatically to head of the document.

yarn dev
yarn preload-fonts

Browser support

Gatsby tends to add a lot of polyfills to support older browser versions. In package.json file you can adjust which sites your project should support. As default Henlo will use defaults setting. If you want to learn more about the browser support visit official Gatsby How-To Guide on this subject

CONTRIBUTING

Contributions are always welcome, no matter how large or small. Before contributing, please read the code of conduct.

Additional guides

Here's a list of helpful articles that will help you with your first steps using Henlo!