Fix Comma Usage in Blog (#13085)

* docs(gatsby-source-shopify): Add note about API permissions (#13037)

Note which permissions you should enable on the Shopify Storefront API. Without these permissions you'll get a fairly cryptic error message.

* chore(docs): match the Wording Style of Other Tutorial Parts (#13034)

* chore(docs): fix typo in convincing others doc (#13033)

<!--
  Have any questions? Check out the contributing docs at https://gatsby.dev/contribute, or
  ask in this Pull Request and a Gatsby maintainer will be happy to help :)
-->

## Description

Fixes a misspelled word.

* fix(docs): expand guidelist on partnering with gatsby page (#13029)

Following up on #12970. Current https://www.gatsbyjs.org/docs/partnering-with-gatsby/:

![image](https://user-images.githubusercontent.com/21834/55404445-2f445080-5558-11e9-84d8-f75db8dd7297.png)

* fix(starters): update gatsby monorepo (#12925)

This PR contains the following updates:

| Package | Type | Update | Change | References |
|---|---|---|---|---|
| gatsby | dependencies | patch | [`^2.3.3` -> `^2.3.5`](https://diff.intrinsic.com/gatsby/2.3.3/2.3.5) | [source](https://togithub.com/gatsbyjs/gatsby) |
| gatsby-image | dependencies | patch | [`^2.0.35` -> `^2.0.37`](https://diff.intrinsic.com/gatsby-image/2.0.35/2.0.37) | [source](https://togithub.com/gatsbyjs/gatsby) |
| gatsby-plugin-manifest | dependencies | patch | [`^2.0.25` -> `^2.0.26`](https://diff.intrinsic.com/gatsby-plugin-manifest/2.0.25/2.0.26) | [source](https://togithub.com/gatsbyjs/gatsby) |

---

### Release Notes

<details>
<summary>gatsbyjs/gatsby</summary>

### [`v2.3.5`](https://togithub.com/gatsbyjs/gatsby/compare/[email protected]@2.3.5)

[Compare Source](https://togithub.com/gatsbyjs/gatsby/compare/[email protected]@2.3.5)

### [`v2.3.4`](https://togithub.com/gatsbyjs/gatsby/compare/[email protected]@2.3.4)

[Compare Source](https://togithub.com/gatsbyjs/gatsby/compare/[email protected]@2.3.4)

</details>

---

### Renovate configuration

:date: **Schedule**: At any time (no schedule defined).

:vertical_traffic_light: **Automerge**: Disabled by config. Please merge this manually once you are satisfied.

:recycle: **Rebasing**: Whenever PR becomes conflicted, or if you modify the PR title to begin with "`rebase!`".

:ghost: **Immortal**: This PR will be recreated if closed unmerged. Get [config help](https://togithub.com/renovatebot/config-help/issues) if that's undesired.

---

 - [ ] <!-- renovate-rebase -->If you want to rebase/retry this PR, check this box

---

This PR has been generated by [Renovate Bot](https://togithub.com/marketplace/renovate). View repository job log [here](https://renovatebot.com/dashboard#gatsbyjs/gatsby).

* feat(blog): add gatsby is great blog post (#12777)

* chore: add blog post

* chore: keep iterating

* chore: more tweaks

* feat: nearly finish up

* chore: run tinypng

* chore: fix some typos

* chore: fix snippet

* chore: add a gif, it gets the people going

* chore: more

* Update docs/blog/2019-03-25-behind-the-scenes-what-makes-gatsby-great/index.md

Co-Authored-By: DSchau <[email protected]>

* Update docs/blog/2019-03-25-behind-the-scenes-what-makes-gatsby-great/index.md

Co-Authored-By: DSchau <[email protected]>

* Update docs/blog/2019-03-25-behind-the-scenes-what-makes-gatsby-great/index.md

Co-Authored-By: DSchau <[email protected]>

* Update docs/blog/2019-03-25-behind-the-scenes-what-makes-gatsby-great/index.md

Co-Authored-By: DSchau <[email protected]>

* Update docs/blog/2019-03-25-behind-the-scenes-what-makes-gatsby-great/index.md

Co-Authored-By: DSchau <[email protected]>

* Update docs/blog/2019-03-25-behind-the-scenes-what-makes-gatsby-great/index.md

Co-Authored-By: DSchau <[email protected]>

* Update docs/blog/2019-03-25-behind-the-scenes-what-makes-gatsby-great/index.md

Co-Authored-By: DSchau <[email protected]>

* Update docs/blog/2019-03-25-behind-the-scenes-what-makes-gatsby-great/index.md

Co-Authored-By: DSchau <[email protected]>

* Update docs/blog/2019-03-25-behind-the-scenes-what-makes-gatsby-great/index.md

Co-Authored-By: DSchau <[email protected]>

* Update docs/blog/2019-03-25-behind-the-scenes-what-makes-gatsby-great/index.md

Co-Authored-By: DSchau <[email protected]>

* Update docs/blog/2019-03-25-behind-the-scenes-what-makes-gatsby-great/index.md

Co-Authored-By: DSchau <[email protected]>

* chore: change date

* chore: tighten up last section

* chore: change data

* chore: update per feedback

* chore(docs): replace absolute links with relative links (#12949)


<!--
  Have any questions? Check out the contributing docs at https://gatsby.dev/contribute, or
  ask in this Pull Request and a Gatsby maintainer will be happy to help :)
-->

## Description

Suggest a more complete structure to the example gatsby-config.js file

## Related Issues

Along with #12103 this PR fixes #11957

<!--
  Link to the issue that is fixed by this PR (if there is one)
  e.g. Fixes #1234, Addresses #1234, Related to #1234, etc.
-->

* chore(showcase): Add Assortment to site showcase (#13002)

## Description

Adding [assortment.io](https://assortment.io) to site showcase. Assortment is my Web Development blog that I've recently updated to Gatsby, Netlify, Netlify CMS and Emotion. It'd be cool to see it on the showcase 😃

* Fix Comma Usage; Misc Updates

Author: dhurlburtusa

docs/blog/2017-07-19-creating-a-blog-with-gatsby/index.md

@@ -20,7 +20,7 @@ rendering][react-dom-server] at build time. This means that your users get all
 the benefits of a static site such as the ability to work without JavaScript,
 search engine friendliness, speedy load times, etc. without losing the dynamism
 and interactivity that is expected of the modern web. Once rendered to static
-HTML, client-site React/JavaScript _can_ take over (if creating stateful
+HTML, client-side React/JavaScript _can_ take over (if creating stateful
 components or logic in `componentDidMount`) and add dynamism to the statically
 generated content.
 
@@ -36,7 +36,7 @@ these new features by creating a static blog. Let's get on it!
 ### Using the CLI
 
 Gatsby ships with a great CLI (command line interface) that contains the
-functionality of scaffolding out a working site, as well as commands to help
+functionality of scaffolding out a working site as well as commands to help
 develop the site once created.
 
 `gatsby new personal-blog && cd $_`
@@ -47,7 +47,7 @@ developed upon. The CLI generates common development scripts to help you get sta
 For example you can run `npm run build` (build a production, statically generated version of the project) or `npm run develop` (launch a hot-reload enabled web development server),
 etc.
 
-We can now begin the exciting task of _actually_ developing on the site, and
+We can now begin the exciting task of _actually_ developing on the site and
 creating a functional, modern blog. You'll generally want to use `npm run develop` to launch the local development server to validate functionality as we
 progress through the steps.
 
@@ -65,14 +65,14 @@ generating a sitemap, etc.) _or_ they extend Gatsby's webpack configuration
 adding support for TypeScript, Sass, etc.
 
 For this particular blog post, we want a single page app-like feel (without page
-reloads), as well as the ability to dynamically change the `title` tag within
+reloads) as well as the ability to dynamically change the `title` tag within
 the `head` tags. As noted, the Gatsby plugin ecosystem is rich, vibrant, and
 growing, so oftentimes a plugin already exists that solves the particular
 problem you're trying to solve. To address the functionality we want for _this_
 blog, we'll use the following plugins:
 
 - [`gatsby-plugin-catch-links`][gatsby-plugin-catch-links]
-  - implements the history `pushState` API, and does not require a page reload
+  - implements the history `pushState` API and does not require a page reload
     on navigating to a different page in the blog
 - [`gatsby-plugin-react-helmet`][gatsby-plugin-react-helmet]
   - [react-helmet][react-helmet] is a tool that allows for modification of the
@@ -103,8 +103,8 @@ module.exports = {
 ```
 
 Without any additional work besides a `yarn install` and editing a config file,
-we now have the ability to edit our site's head tags, as well as implement a
-single page app feel without reloads. Now let's enhance the base functionality
+we now have the ability to edit our site's head tags as well as implement a
+single page app feel without reloads. Now, let's enhance the base functionality
 by implementing a source plugin which can load blog posts from our local file
 system.
 
@@ -117,7 +117,7 @@ workflow often involves using
 disk--e.g. Markdown files--and then specifying a Markdown transformer to
 transform the Markdown into HTML.
 
-Since the bulk of the blog's content, and each article, will be authored in
+Since the bulk of the blog's content and each article will be authored in
 Markdown, let's add that [`gatsby-source-filesystem`][gatsby-source-filesystem]
 plugin. Similarly to our previous step, we'll install the plugin and then inject
 into our `gatsby-config.js`, like so:
@@ -146,16 +146,16 @@ module.exports = {
 ```
 
 Some explanation will be helpful here! An `options` object can be passed to a
-plugin, and we're passing the filesystem `path` (i.e. where our Markdown files
-will be located), and then a `name` for the source files. Now that Gatsby knows
+plugin, and we're passing the filesystem `path` (which is where our Markdown files
+will be located) and then a `name` for the source files. Now that Gatsby knows
 about our source files, we can begin applying some useful transformers to
 convert those files into usable data!
 
 ### Transformer plugins
 
 As mentioned, a transformer plugin takes some underlying data format that is not
-inherently usable in its current form (e.g. Markdown, json, yaml, etc.), and
-transforms it into a format that Gatsby can understand, and that we can query
+inherently usable in its current form (e.g. Markdown, json, yaml, etc.) and
+transforms it into a format that Gatsby can understand and that we can query
 against with GraphQL. Jointly, the filesystem source plugin will load file nodes
 (as Markdown) off of our filesystem, and then the Markdown transformer will take
 over and convert to usable HTML.
@@ -165,7 +165,7 @@ installed.
 
 - [gatsby-transformer-remark][gatsby-transformer-remark]
   - Uses the [remark][remark] Markdown parser to transform .md files on disk
-    into HTML; additionally this transformer can optionally take plugins to
+    into HTML; additionally, this transformer can optionally take plugins to
     further extend functionality--e.g. add syntax highlighting with
     `gatsby-remark-prismjs`, `gatsby-remark-copy-linked-files` to copy relative
     files specified in markdown, `gatsby-remark-images` to compress images and
@@ -205,8 +205,8 @@ module.exports = {
 ```
 
 Whew! Seems like a lot of set up, but collectively these plugins are going to
-super charge Gatsby, and give us an incredibly powerful (yet relatively simple!)
-development environment. We have one more set up step and it's an easy one.
+super charge Gatsby and give us an incredibly powerful (yet relatively simple!)
+development environment. We have one more setup step and it's an easy one.
 We're simply going to create a Markdown file that will contain the content of
 our first blog post. Let's get to it.
 
@@ -217,8 +217,8 @@ to be in `src/pages`, so that's exactly where we'll put it!
 
 Gatsby is not at all prescriptive in naming conventions, but a typical practice
 for blog posts is to name the folder something like `MM-DD-YYYY-title`, e.g.
-`07-12-2017-hello-world`. Let's do just that, and create the folder
-`src/pages/07-12-2017-getting-started`, and place an `index.md` inside!
+`07-12-2017-hello-world`. Let's do just that. Create the folder
+`src/pages/07-12-2017-getting-started` and place an `index.md` inside!
 
 The content of this Markdown file will be our blog post, authored in Markdown
 (of course!). Here's what it'll look like:
@@ -237,7 +237,7 @@ _Fairly_ typical stuff, except for the block surrounded in dashes. What is that?
 That is what is referred to as [`frontmatter`][frontmatter], and the contents of
 the block can be used to inject React components with the specified data, e.g.
 path, date, title, etc. Any piece of data can be injected here (e.g. tags,
-sub-title,draft, etc.), so feel free to experiment and find what necessary
+sub-title, draft, etc.), so feel free to experiment and find what necessary
 pieces of frontmatter are required to achieve an ideal blogging system for your
 usage. One important note is that `path` will be used when we dynamically create
 our pages to specify the URL/path to render the file (in a later step!). In this
@@ -360,7 +360,7 @@ into the query.
 At this point, we have a bunch of plugins installed to load files off of disk,
 transform Markdown to HTML, and other utilities. We have a single, lonely
 Markdown file that will be rendered as a blog post. Finally, we have a React
-template for blog posts, as well as a wired up GraphQL query to query for a blog
+template for blog posts as well as a wired up GraphQL query to query for a blog
 post and inject the React template with the queried data. Next up:
 programmatically creating the necessary static pages (and injecting the
 templates) with Gatsby's Node API. Let's get down to it.
@@ -512,7 +512,7 @@ frontmatter--the result of which will be our stringified and parsed React
 template injected with the data from our GraphQL query. Whoa, it's actually
 starting to come together!
 
-We can run `yarn develop` at this point, and then navigate to
+We can run `yarn develop` at this point and then navigate to
 `http://localhost:8000/hello-world` to see our first blog post, which should
 look something like below:
 
@@ -524,18 +524,18 @@ isn't a blog! We can't expect our users to guess the path of each post, we need
 to have an index or listing page, where we display each blog post, a short
 snippet, and a link to the full blog post. Wouldn't you know it, we can do this
 incredibly easily with Gatsby, using a similar strategy as we used in our blog
-template, e.g. a React component and a GraphQL query.
+template, i.e. a React component and a GraphQL query.
 
 ## Creating the Blog Listing
 
-I won't go into quite as much detail for this section, because we've already
+I won't go into quite as much detail for this section because we've already
 done something very similar for our blog template! Look at us, we're pro
 Gatsby-ers at this point!
 
 Gatsby has a standard for "listing pages," and they're placed in the root of our
 filesystem we specified in `gatsby-source-filesystem`, e.g.
-`src/pages/index.js`. So create that file if it does not exist, and let's get it
-working! Additionally note that any static JavaScript files (that export a React
+`src/pages/index.js`. So, create that file if it does not exist, and let's get it
+working! Additionally, note that any static JavaScript files (that export a React
 component!) will get a corresponding static HTML file. For instance, if we
 create `src/pages/tags.js`, the path `http://localhost:8000/tags/` will be
 available within the browser and the statically generated site.
@@ -590,19 +590,19 @@ export const pageQuery = graphql`
 OK! So we've followed a similar approach to our blog post template, so this
 should hopefully seem pretty familiar. Once more we're exporting `pageQuery`
 which contains a GraphQL query. Note that we're pulling a slightly different
-data set, specifically we are pulling an `excerpt` of 250 characters rather than
-the full HTML, as well as we are formatting the pulled date with a format
+data set -- specifically, we are pulling an `excerpt` of 250 characters rather than
+the full HTML as we are formatting the pulled date with a format
 string! GraphQL is awesome.
 
 The actual React component is fairly trivial, but one important note should be
-made. It's important that when linking to internal content, i.e. other blog
+made. It's important that when linking to internal content, e.g. other blog
 links, that you should always use `Link` from `gatsby`. Gatsby does not work if pages
 are not routed via this utility. Additionally, this utility also works with
-`pathPrefix`, which allows for a Gatsby site to be deployed a non-root domain.
-This is useful if this blog will be hosted on something like GitHub Pages, or
+`pathPrefix`, which allows for a Gatsby site to be deployed on a non-root domain.
+This is useful if this blog will be hosted on something like GitHub Pages or
 perhaps hosted at `/blog`.
 
-Now this is getting exciting and it feels like we're finally getting somewhere!
+Now, this is getting exciting and it feels like we're finally getting somewhere!
 At this point, we have a fully functional blog generated by Gatsby, with real
 content authored in Markdown, a blog listing, and the ability to navigate around
 in the blog. If you run `yarn develop`, `http://localhost:8000` should display a

docs/blog/2017-11-08-migrate-from-jekyll-to-gatsby/index.md

@@ -23,7 +23,7 @@ mostly develop with Node). I tried to develop my blog inside a Docker container,
 but this was extremely slow.
 
 Some weeks ago, one of my colleagues at work told me about
-[Gatsby](https://www.gatsbyjs.org) Since I was already learning
+[Gatsby](/) Since I was already learning
 [React](https://reactjs.org/) and had started looking at
 [GraphQL](http://graphql.org/) (after attending a talk at
 [Nordic.js](http://nordicjs.com/))—I was very interested in giving it a try.

docs/blog/2018-02-16-bright-future-for-the-web/index.md

@@ -24,7 +24,7 @@ It was for those reasons that I was hesitant to pull the trigger on a static sit
 
 One day after airing my grievances about the current state of static site generators on Slack a fellow developer recommend that I check out Gatsby. Gatsby is yet another static site generator but what really set it apart for me was how it was built with [React](https://reactjs.org/) and emphasized a rich plugin system. This was a big plus for me as I was itching to learn more about React and the plugin system alleviated some initial pain that I would have had dealing with mundane tasks. Out of the box you get a fantastic development environment with live reloading that required almost no configuration. With Gatsby specific plugins and React components it can handle pretty much anything you throw at it.
 
-Next came integrating the statically generated site with data stored in a CMS. Again Gatsby was well suited for this and I was able to easily integrate with Contentful via the [gatsby-source-contentful](https://www.gatsbyjs.org/packages/gatsby-source-contentful/) plugin. Contentful is an example of a headless CMS, meaning that is is not tied to any particular technology or language. Contentful allows you to store content using a pleasant user interface and it can then output the data via an API. Best of all Contentful puts you in the driver seat and lets you define your own content model however you see fit. Think [WordPress Advanced Custom Fields](https://www.advancedcustomfields.com/) on steroids. With the content stored in Contentful Gatsby then uses the Contenful API along with the awesome power of [GraphQL](http://graphql.org/) to query data at build time. Cool stuff!
+Next came integrating the statically generated site with data stored in a CMS. Again Gatsby was well suited for this and I was able to easily integrate with Contentful via the [gatsby-source-contentful](/packages/gatsby-source-contentful/) plugin. Contentful is an example of a headless CMS, meaning that is is not tied to any particular technology or language. Contentful allows you to store content using a pleasant user interface and it can then output the data via an API. Best of all Contentful puts you in the driver seat and lets you define your own content model however you see fit. Think [WordPress Advanced Custom Fields](https://www.advancedcustomfields.com/) on steroids. With the content stored in Contentful Gatsby then uses the Contenful API along with the awesome power of [GraphQL](http://graphql.org/) to query data at build time. Cool stuff!
 
 The final piece of the puzzle was determining where to host the website. I had recently experimented with Netlify on a somewhat [pointless website for my dog](https://www.doggoforhire.com/) and I was impressed by its ease of use and how they offered a fully featured developer tier for free. In no time I was able to get my Gatsby powered website up and running on Netlify. Then with the help of webhooks I was able to have Contentful tell Netlify to “rebuild” the website whenever a new post was published. Finally with Netlify’s form handling functionality I hooked up a contact form all without a single line of backend code or even a database.
 

docs/blog/2018-04-25-how-gatsby-changes-teams-website-development-workflow/index.md

@@ -32,7 +32,7 @@ _Utilize developers to prototype faster_
 
 In order to do user testing, usually user researchers work with designers to construct pixel perfect prototypes of various options, either static or clickable. Constructing and iterating on these artifacts can take days or weeks.
 
-Gatsby makes another option possible. Some Gatsby users report [setting up a production site](https://www.gatsbyjs.org/blog/2018-01-18-how-boston-gov-used-gatsby-to-be-selected-as-an-amazon-hq2-candidate-city/) with live UI that is building and deploying in under an hour.
+Gatsby makes another option possible. Some Gatsby users report [setting up a production site](/blog/2018-01-18-how-boston-gov-used-gatsby-to-be-selected-as-an-amazon-hq2-candidate-city/) with live UI that is building and deploying in under an hour.
 
 Especially if your organization already uses a React or HTML-based component library, your team may consider bringing in a developer to construct live wireframe-level prototypes. This may enable you to accelerate the user research process, start the development process with a working prototype rather than from scratch, and ultimately let you arrive at a better version of your site.
 
@@ -50,7 +50,7 @@ Gatsby's extensible system of API hooks, tight integration with static hosts lik
 
 _Use development pages to communicate project status & collaborate with designers_
 
-One option some teams have found powerful is to create static page components within Gatsby to [handle necessary parts of the development/QA workflow](https://www.gatsbyjs.org/blog/2018-04-11-trying-out-gatsby-at-work-and-co/#1-pre-integration-qa).
+One option some teams have found powerful is to create static page components within Gatsby to [handle necessary parts of the development/QA workflow](/blog/2018-04-11-trying-out-gatsby-at-work-and-co/#1-pre-integration-qa).
 
 This could include:
 
@@ -60,4 +60,4 @@ This could include:
 
 _Use branch and pull request-based artifacts to collaborate on specific pieces of work_
 
-Using the [branch and pull request-based artifacts](https://www.gatsbyjs.org/blog/2018-04-11-trying-out-gatsby-at-work-and-co/#building-staging-urls) automatically created by a service like Netlify for collaboration between developers, designers, and QA. Because generated artifacts are static, pull request collaboration workflows are resilient to underlying content schema changes, such as field deletion, that might break a typical CMS development environment.
+Using the [branch and pull request-based artifacts](/blog/2018-04-11-trying-out-gatsby-at-work-and-co/#building-staging-urls) automatically created by a service like Netlify for collaboration between developers, designers, and QA. Because generated artifacts are static, pull request collaboration workflows are resilient to underlying content schema changes, such as field deletion, that might break a typical CMS development environment.

docs/blog/2018-04-27-building-eviction-free-nyc-with-gatsbyjs-and-contentful/index.md

@@ -70,7 +70,7 @@ perfect fit for a number of reasons:
     could have achieved this level of optimization on our own in this timeframe.
 1.  A growing plugin library that allows for easy integrations that utilize Gatsby’s
     GraphQL data query system. With these we could easily use things like
-    [gatsby-source-contentful](https://www.gatsbyjs.org/packages/gatsby-source-contentful/?=conten)
+    [gatsby-source-contentful](/packages/gatsby-source-contentful/?=conten)
     and [gatsby-plugin-i18n](https://github.com/angeloocana/gatsby-plugin-i18n).
 1.  A growing community of developers sharing resources and best practices. Credit
     is due to [mccrodp](https://github.com/mccrodp) for setting up
@@ -162,7 +162,7 @@ type, you can simply drag-n-drop things in Contentful!
 
 From there, we had to teach GatsbyJS how to properly render each page based on
 pathway. We did this by implementing the `createPages` function in the [Gatsby
-Node API](https://www.gatsbyjs.org/docs/node-apis/). For each Housing Court Page
+Node API](/docs/node-apis/). For each Housing Court Page
 (also per language!), Gatsby creates 6 different pages based on the pathways.
 While our solution had to account for some [limitations in
 GraphQL](https://github.com/facebook/graphql/issues/414), everything wound up

docs/blog/2018-06-07-build-a-gatsby-blog-using-the-cosmic-js-source-plugin/index.md

@@ -356,7 +356,7 @@ export const pageQuery = graphql`
 `
 ```
 
-That looks fine, but at this point, Gatsby does not know when this template should be displayed. Each post needs a specific URL. So, we are going to inform Gatsby about the new URLs we need using the [`createPages` API](https://www.gatsbyjs.org/docs/node-apis/#createPages).
+That looks fine, but at this point, Gatsby does not know when this template should be displayed. Each post needs a specific URL. So, we are going to inform Gatsby about the new URLs we need using the [`createPages` API](/docs/node-apis/#createPages).
 
 Path: `gatsby-node.js`