Seems like if the title doesn't occupy two lines, it sits at the bottom of the footer and is out of sync with the chevron.

At a bare minimum provide the interface and some basic context of what this is. Could be a blog post later on creating our own.

We don't really mention passing Actions to the form. Let's describe this as a concept and add some examples of actions. I've added an example for the delete action.

A pull request in tinacms may require documentation updates.

The following files may need to be updated:

!Breaking!

The referenced PR requires a change to docs describe how to get started with TinaCMS.

yarn add gatsby-plugin-tinacms styled-components

will now need to be

yarn add tinacms gatsby-plugin-tinacms styled-components

We should make sure to update any effected blog posts and notify anyone else who wrote a blog post.

Clicking on the logo currently refreshes the page. It should use a Next Link

For example:

• Warning: Each child in a list should have a unique "key" prop.
• Warning: Invalid DOM property fill-rule. Did you mean fillRule?

Let's cleanup up all these little issues.

I think we can switch to using the Github refs api https://developer.github.com/v3/git/refs/#create-a-reference

There's an "update reference" endpoint that will rebase it off of the base repo (and we can use force=false to let the user handle their own conflicts if they arise?)

We would like to be able to edit content within Zeit's preview deployments with Open Authoring.
E.g https://tinacms-site-next-git-style-reform.tinacms.now.sh/docs/cms/styles

It looks like we can use a custom-url for zeit preview deployments: https://zeit.co/docs/v2/custom-domains

If that's the case, we can send a custom callbackURL to Github to redirect back to our preview deployment url.

If you check the logs of the create_indices job when it throws an error it will log out something like:

(node:3039) UnhandledPromiseRejectionWarning: Error: kill EPERM

However, the job will still pass

Right now if you attempt to signup for the newsletter and you've already signed-up, the alert looks like this. Let's make a custom modal -- In general we should make that alert for newsletter signup more custom and better looking.

Show alert blocking nav when we leave the page with changes:

https://nextjs.org/docs/api-reference/next/router#routerevents

After a PR has been merged, I will be looking at a stale copy of the site. What should happen to the branch? What should happen to the fork?

Some thoughts:
On the next visit, we could alert the user and say that their pr has been merged and ask them if they would like to create a new fork. We could then delete their existing fork and create a new one for them. We could also look into rebasing it.

For now, we could just show an alert and tell them that their changes have been merged and that their fork is out of date.

I setup Tina on my blog and made this form:

const BlogPostForm = {
  label: "Post",
  fields: [
    {
      name: "rawFrontmatter.title",
      component: "text",
      label: "Title",
      required: true,
    },
    {
      name: "description",
      component: "textarea",
      label: "Description",
    },
    {
      name: "date",
      component: "date",
      label: "Last Updated",
    },
    {
      name: "publishDate",
      component: "date",
      label: "Published",
    },

    { name: "rawMarkdownBody", component: "markdown", label: "Body" },
  ],
}

export default remarkForm(BlogPostTemplate, BlogPostForm)

I didn't love the organization in the sidebar though. I rarely care about the descriptions or dates when editing my content. It really lengthens out the form:

I used the group field shove those hide those extra fields. Now the form template looks like this:

const BlogPostForm = {
  label: "Post",
  fields: [
    {
      name: "rawFrontmatter",
      label: "Metadata",
      component: "group",
      fields: [
        {
          name: "date",
          component: "date",
          label: "Last Updated",
        },
        {
          name: "publishDate",
          component: "date",
          label: "Published",
        },
        {
          name: "description",
          component: "textarea",
          label: "Description",
        },
      ]
    },
    {
      name: "rawFrontmatter.title",
      component: "text",
      label: "Title",
      required: true,
    },

    { name: "rawMarkdownBody", component: "markdown", label: "Body" },
  ],
}

And my sidebar looks like this:

With google tag manager, the Scroll Depth event can only reset based on:
Container Load,
Window Load,
or Dom Ready (all of which are only fired upon initial site load). We will have to either manually fire these events on page change, or handle our own scroll tracking.

https://stackoverflow.com/questions/55472262/scroll-depth-gtm-gatsby

Thanks to the ability to dynamically create, add, and remove plugins from Tina, it's incredibly easy to add a button for contextually creating sub-pages!

import { liveRemarkForm, createRemarkButton } from "gatsby-tinacms-remark"
import slugify from "slugify"
import { usePlugin } from "react-tinacms"

function BlogPostTemplate(props) {
  const post = props.data.markdownRemark
  const siteTitle = props.data.site.siteMetadata.title
  const { previous, next } = props.pageContext
  const { setIsEditing, isEditing } = props

  const CreateChildPost = React.useMemo(() => {
    return createRemarkButton({
      label: "Child Post",
      fields: [{ name: "title", label: "Title", component: "text" }],
      filename(form) {
        let currentDir = post.fileRelativePath.replace("index.md", "")
        let sluggifiedTitle = slugify(form.title)

        return `${currentDir}${sluggifiedTitle}/index.md`
      },
      frontmatter(form) {
        return {
          title: form.title,
          date: new Date(),
        }
      },
    })
  }, [post.fileRelativePath])

  usePlugin(CreateChildPost)

  return (
    <Layout location={props.location} title={siteTitle}>
      <SEO
        title={post.frontmatter.title}

Checkout a video in the community slack:

https://tinacms.slack.com/archives/CNMPL8LDT/p1571330174005400?thread_ts=1571329743.004900&cid=CNMPL8LDT

When in edit-mode:
On the docs (or blog page), if you click into the inline Wysiwyg section, if you scroll down, the Wysiwyg menu gets hidden behind the toolbar

tinacms/tinacms#563

As a result of this - tinacms/tinacms#649, we made some changes to the way we pass options to the cms that can be seen here - tinacms/tinacms#723

The component created by createGlobalStyles function in styled-components is extremely inefficient. This will cause sites being edited with TinaCMS to eventually start to crawl.

Any global styles should be memoized:

const GlobalStyle = createGlobalStyle`
  html {
    min-height: 100%;
  }
`
export default React.memo(() => <GlobalStyles />);

We should have a guide/blog post about this.

Website shows Privacy Error

Your connection is not private
Attackers might be trying to steal your information from tinacms.org (for example, passwords, messages, or credit cards). Learn more
NET::ERR_CERT_AUTHORITY_INVALID

Help improve Chrome security by sending URLs of some pages you visit, limited system information, and some page content to Google. Privacy policy

A pull request in tinacms may require documentation updates.

The following files may need to be updated:

We need to document the new loadInitialValues promise and update the Form interface or any examples of initialValues manually getting set.

related issue: tinacms/tinacms#473

Current consumers.json file was copied statically from the Gatsby site. We need to replace this with a dynamically generated version.

When clicking "Edit this site", the GitHub auth flow redirects back to tinacms.org/* instead of:
https://tinacms-site-next-git-branchname.tinacms.now.sh/*

We can't send a custom Github callback because Github returns:

https://tinacms.org/github/authorizing?error=redirect_uri_mismatch&error_description=The+redirect_uri+MUST+match+the+registered+callback+URL+for+this+application....

A few technical/UX challenges to overcome:

• The following actions will be difficult without being about to make commits within git:
  Add/remove image
  Add/remove page

• We will not have the user's auth token, and perform Github requests from the server, so we may run into issues with Github rate limiting
  - We can just read from the filesystem if unauthenticated.

Questions:

• Will we still switch to Edit mode to use Tina?
• What happens if I make changes before logging in (which are saved to local-storage) -> log-in (to an account with an existing fork). Do I see my localstorage changes from base? or my forked changes?

Create an FAQ section on the site.

I've started going through issues (both open & closed) in the tinacms repo to tag potential FAQ items. https://github.com/tinacms/tinacms/issues?utf8=%E2%9C%93&q=label%3Afaq

Need to document the image config options for the Markdown, HTML, & InlineWysiwyg fields.

If you click the submit pull-request button twice, it will try and create the pull request twice (and fail the second time).
https://www.loom.com/share/90603ae016734448a811fde11078489c

In order to be more productive
As an editor
I can learn the current keyboards shortcuts supported in the editor

• See prior work on Forestry (https://github.com/forestryio/admin/blob/95edd6d2438e563cfe27ee017558e9ebc1073493/js/forestry-wysiwyg/CheatSheet/CheatSheet.tsx#L47-L236)
• Test current working shortcuts
• List missing shortcuts that would benefit power users.

Could use some examples and extended docs around tina serve options:
https://github.com/tinacms/tinacms-site/blob/teams-docs/content/docs/teams/cli/commands.md#tina-serve-options--tina-server-options

A pull request in tinacms may require documentation updates.

The following files may need to be updated:

tinacms/tinacms#671

The save button in the toolbar should say:
"Save Draft" before a PR is created
"Update Draft" after PR has been created

@ncphillips mentioned having cms.sidebar.buttons.save take in a component which would allow this to be possible

If we already have a fork_full_name or github_access_token cookie, we can perform a quick validation check instead of going through the full auth flow when toggling edit mode.

Similar to the shortcut keyboard in forestry. Also mention that its commonmark compatible

See the custom field doc. Update to link to the newer styles docs and add a short explanation of how to approach this now with custom fields.

This should make commits to the base repo instead of making a fork.
Also, we likely will want to create branches instead of committing directly to the base branch.
Needs further discussion.

Would it help if we shared when a documentation page was edited for the last time?

Issue
Currently the search is hidden on mobile

Expected
People can search on lower resolutions

Originally posted by @DirtyF in #25 (comment)

Add documentation about the globalRemarkForm HOC to the 'using markdown' in Gatsby file.

https://github.com/tinacms/tinacms/blob/983a4c0ad14808219349b57b11314c98c844bd41/packages/gatsby-tinacms-remark/src/remarkFormHoc.tsx#L64

A pull request in tinacms may require documentation updates.

The following files may need to be updated:

Probable Change

We may want to add a Tip on how to prevent forms from being registered in production

It would be nice to be able to create/edit new docs pages with Tina open-authoring.
There's currently no create button in the Docs pages.
I manually created the page in my fork, but the new page 404'ed (I assume because fallback: false on the docs layouts)

Update post for NextJS 9.3, replace getInitialProps

https://nextjs.org/blog/next-9-3

• https://tinacms.org/blog/simple-markdown-blog-nextjs/ updated
• https://dev.to/tinacms/creating-a-markdown-blog-with-next-js-52hk updated
• reply to https://spectrum.chat/next-js/general/next-9-3-getstaticprops-possible-for-markdown-blog~7e493b45-4868-4a55-b326-9487e2331f2d

Depending on the settings of Firefox or Brave, i.e. how intense the ad-blocking etc. is, the newsletter signup will throw an error and not allow someone to signup. Right now it will at least communicate this to them with an alert.

See benjaminhoffman/gatsby-plugin-mailchimp#45 & benjaminhoffman/gatsby-plugin-mailchimp#34

I reset my firefox browser to factory settings and was able to sign up okay since all my blocker settings were chilled out but this is definitely unfortunate / something we'll want to address.

One thing I didn't try was embedding the entire mailchimp form in like was mentioned in one of the issues...I wasn't sure how that would play with Gatsby. Would be my first step to looking into this.

Our documentation needs to serve a spectrum of users, ranging from those looking for a quick + easy way to get started with Tina, to those interested in wielding parts of the API on their own for highly custom use cases, or building integrations. For simplicity I'll refer to these as lower-investment and higher-investment groups, referring to how much time/energy they want to invest in understanding/implementing Tina.

Trying to serve this entire spectrum from the documentation is challenging and can lead to the docs being confusing/unhelpful.

Proposal

1. Add a new top-level nav item to tinacms.org, titled "Guides"
2. Remove the Tina+Gatsby and Tina+NextJS sections from /docs and repurpose them into Guides as appropriate

Docs

Docs should focus on the APIs and components of Tina, and cater primarily to developers in the medium- and higher-investment part of the spectrum. Naive examples to demonstrate functionality (like what's in the Plugin docs) would be preferred over examples that assume a specific setup.

We should consider a linear path through the documentation. Docs should attempt to present the most common/ubiquitous APIs and components first, leaving more esoteric or uncommonly-needed features for later. This organization should not come at the expense of cohesiveness, however.

Guides

Guides aim to serve the lower- to medium-investment developers, but will likely be useful to everyone.

The attitude of a Guide will be somewhere between documentation and a blog post. Guides should start with an overview of what will be achieved, and may be broken up into multiple logical steps, each in its own markdown file.

| guides
\
  |--nextjs-github-public-repo
  \
    |--overview.md
    |--1-add-github-api.md
    |--2-bootstrap-api-routes.md

We should encourage guides to be as small in scope as seems appropriate, and have guides reference each other. For example, a guide on using the GitHub packages with NextJS should assume you have already bootstrapped Tina into your NextJS site (adding TinaProvider to _app.js,) and should link to a guide on how to do that rather than explaining it all over again.

Discoverability

Guides should be:

1. searchable via algolia
2. discoverable via tags

Guide Layout

something like this

I would like to be able to create new blog posts for tinacms.org within Tina. It would be nice if there was a "create" button in the blog posts list

I'd like to at the least switch between my own branches, and create new branches on my fork.
Also ideally, I could view read-only branches from the base, or other users.

When going through the Next Tinacms Github setup process, it takes a while to verify that you're on the right track. We should document sanity checks that prove that your prior steps have been successful.

E.g, After you add the TinacmsGithubProvider, you should see an authentication modal