DEV Community: scottgallant

Markdown Bot - An AI friend who improves your content

scottgallant — Fri, 21 Jul 2023 17:19:30 +0000

With TinaCMS, all your content changes are committed directly to Git. This enables your team to create a variety of workflows for reviewing and merging content updates. By leaning on GitHub, you can integrate CI/CD into your content workflow.

To illustrate the potential of this combination, we're excited to introduce Markdown Bot, an AI friend who improves your content by making suggestions to your Pull Requests.

Want to skip the reading and jump straight to the code? Check out the open source repo.

A Useful Aid, Not a Replacement

AI can be a valuable tool for assisting with writing and editing content. We've designed this bot not to replace content editors, but rather to augment their capabilities. The bot offers content suggestions directly in your pull requests. If you find the suggestions helpful, you can commit them with a click. If not, they're just as easily dismissed.

Markdown Bot Works On Your PRs

There are many AI writing tools out there but if you use them with markdown content it often involved copying and pasting from AI outputs. We wanted something that could interact with our Content in GitHub. That's why we developed a GitHub bot that allows us to receive these suggestions right within a GitHub pull request.

Working with the GitHub Bot

After you've integrated the bot into your repository, you can command it to make suggestions by commenting ai fix: <path to file>. A custom prompt can be added by using prompt: <Custom Prompt> underneath. The bot will then offer commit suggestions in the form of a pull request review.

To get started check out the open source repo.

Looking Ahead: AI and Git-based Content

Our GitHub bot works hand in hand with TinaCMS to enhance the content creation process. No longer do you need to manually copy and paste suggestions. The bot brings suggestions right to your pull requests for a smooth, efficient experience.

We can envision some impressive custom workflows being built with AI and Git-based content. For instance, you could build off of this bot to:

Trigger the AI bot with custom events, such as opening a PR.
Utilize analytics to suggest recommendations based on your top/bottom performing pages.
Integrate this bot with your feedback widget, to open PRs based on user feedback.
Catch insensitive, inconsiderate writing with tools like alex

These are just a few of the many possibilities we see for integrating AI with Git-based content. We're excited about the potential here and look forward to seeing the creative workflows that the community will build.

Visual Open Authoring with Next.js & TinaCMS

scottgallant — Tue, 10 Mar 2020 19:19:52 +0000

We're focused on improving the independent web as a whole. We want to craft tools that help people build better sites and create better content.

In line with this mission, we sought to create something we call Visual Open Authoring ✍️. The open authoring concept was originally pioneered by Netlify CMS this past summer and involves opening up your website's CMS to accept content-related contributions from anyone. Using Tina, we were able to take this a step further, establishing the editing context on the page itself.

Add an "Edit Mode" to Your Site

Picture this: on your website, there's an "Edit this page on GitHub" link — familiar enough. But imagine that when you click it, instead of kicking you over to GitHub, the site itself becomes editable, like a Google Doc.

The experience should feel familiar for anyone that has used a word processor or site builder. You navigate to the page you want to change, click “Edit”, make updates in a WYSIWYG, and then submit your changes. That’s it 🧞‍♂️.

What's under the hood?

The scaffolding underneath Visual Open Authoring is a Git-based workflow. Triggering "Edit Mode" creates a new fork to track and commit changes on. When content updates are ready, the editor can make a pull request. The site owner can then review the work before making it live.

Currently, this requires a GitHub account and some knowledge of Git workflows, making Open Authoring ideal for developer-centric sites (docs, wikis, etc). Soon, we will be opening up Tina Teams so people without GitHub accounts can easily edit in real-time too.

We are currently prototyping this on our own site. In the coming weeks, the APIs for integrating Visual Open Authoring with Tina will become available. In the meantime, go to tinacms.org/blog/introducing-visual-open-authoring and click the edit button at the top of the page to try it out. Feel free to reference this site’s source code to see how it works.

Using Next.js to Enable "Edit-mode"

A new feature announced in Next.js 9.3 has been instrumental to providing the ideal experience for Visual Open Authoring. The preview mode capability allows us to host a website that is fully static by default, but switches to a dynamic mode that runs server code for users that have a special "preview" cookie set. What we refer to as "Edit Mode" for Visual Open Authoring is the same as this Next.js "Preview Mode".

The ability for a website to run statically by default, and then "wake up" into a dynamic web application in response to specific user actions, is revolutionary. It significantly simplifies the concerns of operating an editing environment with Tina. With this workflow, we don't have to host a separate Cloud Editing Environment — the live site is the editing environment! And thanks to Git and our fork-based workflow, we can edit content from the production website worry-free.

Crowdsourcing your content

Visual Open Authoring is a unique, low-friction approach to website editing. Thanks to the clever Next.js preview mode, Tina's content flexibility, and the seamless Inline Editing experience, we're ready for a digital content revolution.

What if it were effortless to fix a spelling error on the New York Times? Imagine contributing to the ReactJS documentation in an instant.

The web is all about community, crowdsourcing, and the power of many perspectives. The easier it is to make content contributions, the more viewpoints we incorporate. The less context switching, the more space for creative expression of ideas.

Let's democratize content and strengthen the independent web.

Creating Markdown Drafts with Gatsby and TinaCMS

scottgallant — Wed, 30 Oct 2019 12:33:58 +0000

One of the core features of an editorial workflow is to provide writers & editors a safe space for creating and iterating on content without these in-process posts publishing to production — draft-mode.

This post will outline how to add a draft-state to your markdown files in a Gatsby site using TinaCMS. Based on the environment and the file’s draft state, they will be selectively ‘published’ or not published. In development, we will ‘publish’ all files so we can view and edit drafts and completed posts alike; whereas in production we are going to filter out draft posts in our graphQL queries.

The code examples are based on the gatsby-starter-tinacms. Feel free to reference that as you go along.

Step 1: Add the published field to MarkdownRemark nodes

First off, we need to create a way to tell Gatsby what files to include (or not include) in the build process depending on the environment. To do this, we will add a published field to every MarkdownRemark node. The published field is the faucet from which files get included in the build process. In development mode, the faucet is fully open, and all posts, regardless of their draft state, will be ‘published’ or sent through the build process. In production mode, the faucet filters out anything in draft state. So think of the published as a sort-of misnomer for includedInBuild.

The first file we need to touch to do this is the gatsby-node.js file, which typically lives in the root of a site. This is a special gatsby file where we can access all of Gatsby’s Node-API’s, or access points to the GraphQL layer that processes all the data in a Gatsby site. The API we will use is called setFieldsOnGraphQLNodeType:

const { GraphQLBoolean } = require('gatsby/graphql')

exports.setFieldsOnGraphQLNodeType = ({ type }) => {
  // if the node is a markdown file, add the `published` field
  if ("MarkdownRemark" === type.name) {
    return {
      published: {
        type: GraphQLBoolean,
        resolve: ({ frontmatter }) => {
          /*
          `published` is always true in development
              so both drafts and finished posts are built
          */
          if (process.env.NODE_ENV !== "production") {
            return true
          }
          /*
          return the opposite of the `draft` value,
          i.e. if draft = true : published = false
          */
          return !frontmatter.draft
        },
      },
    }
  }
  return {}
}

Step 2: Create only published pages

While we’re in the gatsby-node.js file, we need to prevent files in a draft state from being created as pages by Gatsby. We need to query for all the MarkdownRemark files, specifically with the published field data, so we can only create pages if they are published or set to be included in the build.

Let’s loop through all the posts and only call createPage for published content. This example code is using the createPages API, which is where you manipulate or handle the creation of pages in Gatsby.

exports.createPages = async ({ graphql, actions, reporter }) => {
 const { createPage } = actions
 // Query for markdown nodes to use in creating pages.
 const result = await graphql(
   `
     {
       allMarkdownRemark(sort: { fields: [frontmatter___date], order: DESC } limit: 1000) {
         edges {
           node {
             published
             fields {
               slug
                }
             frontmatter {
               title
               }
           }
         }
       }
     }
   `
 )
 // Handle errors
 if (result.errors) {
   reporter.panicOnBuild(`Error while running GraphQL query.`)
   return
 }
 // Create pages for each markdown file.
 const blogPostTemplate = path.resolve(`src/templates/blog-post.js`)
 result.data.allMarkdownRemark.edges.forEach(({ node }) => {
   // if unpublished return, to prevent the page from being created
   if (!node.published) return
   // otherwise, create the `published` page
   createPage({
      path: node.fields.slug,
      component: blogPostTemplate,
      context: {
        slug: node.fields.slug
     },
   })
  }
}

Step 3: Filter unpublished pages at the query level

Now that we have our published field controlling the flow of whether or not posts get included in the build, we need to adjust the queries in our templates and index list files so that we only query for published data.

Go to the component or page file that renders a ‘list’ of all posts — this could be an index file on a simple blog, or a list page file on a more complicated site. In that file, let’s add a filter parameter to the allMarkdownRemark query:

src/pages/index.js

export const pageQuery = graphql`
  query {
    // Only query for published markdown files
    allMarkdownRemark(filter: { published: { eq: true } }, sort: { fields: [frontmatter___date], order: DESC }) {
      edges {
        node {
          excerpt
          fields {
            slug
          }
          frontmatter {
            date(formatString: "MMMM DD, YYYY")
            title
            description
          }
        }
      }
    }
  }
`

Same goes for the query in the blog-post template.

src/templates/blog-post.js

export const pageQuery = graphql`
  query BlogPostBySlug($slug: String!) {
    //  Unpublished pages will 404
    markdownRemark(published: { eq: true }, fields: { slug: { eq: $slug } }) {
      // ...
    }
  }
`

Now our templates and components dealing with any blog post data will conditionally handle published content depending on the build environment.

Step 4: Add a “draft” indicator in development

Since you’re already in your blog-post.js template file and you have added the filter parameter, we now need to add the ‘draft’ field to our query so we can conditionally render some indication of the post status in the component. You may need to restart the Gatsby dev server after adjusting this query.

Add the draft to your blog-post.js query:

export const pageQuery = graphql`
  query BlogPostBySlug($slug: String!) {
    markdownRemark(published: { eq: true }, fields: { slug: { eq: $slug } }) {
      frontmatter {
        title
        date(formatString: "MMMM DD, YYYY")
        description
        // The new field
        draft
      }
    }
  }
`

There’s lots of ways you can incorporate the ‘draft’ indicator status into your component. One way would be to conditionally render draft status instead of the date, based on the value of frontmatter.draft, as shown in the example below:

<p
  style={{
    ...scale(-1 / 5),
    display: `block`,
    marginBottom: rhythm(1),
  }}
>
  {post.frontmatter.draft ? (
    <DraftIndicator />
  ) : (
    post.frontmatter.date
  )}
</p>

Step 5: Add the Draft Toggle to your Form

Finally, let’s add this draft toggle field to the form, where we edit our blog posts with TinaCMS. Simply add this field to each page’s form definition.


     {
       name: "frontmatter.draft",
       component: "toggle",
       label: "Draft",
     },

Note:
Tina will only add the draft frontmatter value to files after it’s been edited. If the draft frontmatter value is not set on a file, it will be null (falsy)and will get published in all environments.

That’s it!

We successfully added ‘draft-mode’ to a simple blog. Now this configuration might look slightly different depending on your site, but feel free to reference the TinaCMS-site repo, specifically the blog template, to see this feature in action on a more complicated site.

Announcing TinaCMS

scottgallant — Mon, 21 Oct 2019 17:01:51 +0000

We’re excited to announce TinaCMS: an open-source site editing toolkit for React-based sites, especially Next.js). See the announcement video at Jamstack Conf SF (the demo starts at 3:45).

Tina is not a CMS, in the traditional sense. As in, it’s not a separate system for managing content. Instead, Tina adds editing functionality to your site when running in dev mode locally, or when using TinaCloud...
In fact, I'm writing this post with Tina right now:

When you install Tina, your site gets a floating edit icon in the corner that toggles an editing pane to expose the CMS fields. This gives your content editors a contextual editing experience that’s super intuitive. When you click "Save" Tina writes your content to external data sources, such as Markdown or JSON files.

Where does Tina store my content?

Currently, Tina writes to Markdown and data files and commits to Git but it can be extended to write to other data sources (another headless CMS like Strapi or Contentful, or any API-based service like Google Sheets or Airtable). When running locally, Tina writes to the file system and if you're using Tina Cloud, it commits to your GitHub repository.

Why Tina?

I’ve been setting up content management systems for people since the early 2000’s. In the beginning, CMSs like WordPress and Drupal gave our non-developer colleagues website editing powers. But we’ve seen very little innovation on the editing experience in the past 10+ years. Meanwhile, the editing experience of site builders like Squarespace, Wix and Webflow have become very sophisticated.

When I watch people use a traditional CMS, I often see them struggle because the input (the CMS) lacks the context of the output (their site) and using a CMS feels more like filing your taxes than editing a website. Now that we’ve moved to headless CMSs and the Jamstack, editors often lose the ability to preview, leaving them in the dark as they create content.

We developers have hot-reloading, and Tina is hot-reloading for content editors.

Get Started

We're coming out of a monolithic CMS era and we believe next-gen sites need a next-gen CMS. Checkout Tina and let us know what you think!