Merge branch 'master' into www/docs-workflow-markdown-and-mdx

.github/actions/high-priority-prs/src/process-data.js

@@ -84,6 +84,10 @@ const maintainers = {
     name: "Florian Kissling",
     slackUsername: "@fk",
   },
+  "https://github.com/gillkyle": {
+    name: "Kyle Gill",
+    slackUsername: "@kylegill",
+  }
 }
 
 const ignoreMessages = ["Merge branch 'master'", "Merge remote-tracking branch"]

docs/blog/2018-01-22-getting-started-gatsby-and-wordpress/index.md

@@ -19,7 +19,7 @@ I generated a new site using the [default starter](https://github.com/gatsbyjs/g
 
 That gets us a new site directory with a couple (mostly) empty "gatsby"-prefixed files and a src directory with some basic scaffolding. The configuration and lifecycle hooks for Gatsby get put in those "gatsby"-prefixed files, `gatsby-config.js`, `gatsby-node.js` and `gatsby-browser.js`.
 
-##gatsby-config.js
+## gatsby-config.js
 
 Essentially the Gatsby home base. The two things defined here initially (in the starter) are `siteMetadata` and `plugins`.
 
@@ -38,27 +38,27 @@ For the curious:
 
 - `gatsby-plugin-react-helmet` is a plugin the starter includes. It's a [document head manager for React](/packages/gatsby-plugin-react-helmet/).
 
-##gatsby-node.js
+## gatsby-node.js
 
 We can make use of any of [Gatsby's node APIs](/docs/node-apis/) by exporting a function with the name of that API from this file.
 
 For my purposes, the only one I have interacted with so far to get up and running is the [`createPages`](/docs/node-apis/#createPages) API. This gets called after our data has been fetched and is available to use to dynamically build out our static pages. More on this later.
 
-##gatsby-browser.js
+## gatsby-browser.js
 
 Same as above, we can make use of any of [Gatsby's browser APIs](/docs/browser-apis/) by exporting them from this file.
 
 I haven't needed to make use of any of these yet, but they provide a hook into [client runtime operations](/docs/gatsby-lifecycle-apis/) — for example, replacing the router component, as seen in [this example](https://github.com/gatsbyjs/gatsby/blob/master/examples/using-redux/gatsby-browser.js#L7).
 
-##Plugin: gatsby-source-wordpress
+## Plugin: gatsby-source-wordpress
 
 Having familiarized with the basic structure, my next step was getting my data successfully pulling from WordPress. There's a plugin for that. [`gatsby-source-wordpress`](https://github.com/gatsbyjs/gatsby/tree/master/packages/gatsby-source-wordpress) is Gatsby's plugin for sourcing data from WordPress sites using the WordPress JSON REST API.
 
 (Fun fact: the WordPress REST API is already [included starting with WordPress 4.7](http://v2.wp-api.org/) — no longer requires installing a WordPress plugin. I didn't actually know that, not having used the WordPress REST API for anything before).
 
 I started by reviewing the [code for the plugin's demo site](https://github.com/gatsbyjs/gatsby/tree/master/examples/using-wordpress).
 
-##Configure the plugin to pull your data
+## Configure the plugin to pull your data
 
 In `gatsby-config.js`, add your configuration options, including your WordPress site's baseUrl, protocol, whether it's hosted on [wordpress.com](http://wordpress.com/) or self-hosted, and whether it makes use of the Advanced Custom Fields (ACF) plugin.
 
@@ -83,7 +83,8 @@ module.exports = {
 }
 ```
 
-##Use the data to dynamically construct pages.
+## Use the data to dynamically construct pages
+
 Once your source plugin is pulling data, you can construct your site pages by implementing the `createPages` API in `gatsby-node.js`. When this is called, your data has already been fetched and is available to query with GraphQL. Gatsby uses [GraphQL at build time](/docs/querying-with-graphql/#how-does-graphql-and-gatsby-work-together); Your source plugin (in this case, `gatsby-source-wordpress`) fetches your data, and Gatsby uses that data to "[automatically _infer_ a GraphQL schema](/docs/querying-with-graphql/#how-does-graphql-and-gatsby-work-together)" that you can query against.
 
 The `createPages` API exposes the `graphql` function:
@@ -114,13 +115,13 @@ _.each(result.data.allWordpressPost.edges, edge => {
 
 The [docs define a Gatsby page](/docs/api-specification/#concepts) as "a site page with a pathname, a template component, and optional graphql query and layout component." See the docs on the [createPage bound action creator](/docs/actions/#createPage) and [guide on creating and modifying pages for more detail](/docs/creating-and-modifying-pages/).
 
-##... Take a step back to "templates"
+## ... Take a step back to "templates"
 
 In the step above we dynamically create pages based on our data by passing the absolute path to a defined template to "component". So what's a template?
 
 A template is a page component we can loop over to dynamically create pages based on the content we've pulled in (described above). We pass the post id to "context" to make it available as a GraphQL variable in the template file. The [GraphQL query defined for the template](https://github.com/gatsbyjs/gatsby/blob/master/examples/using-wordpress/src/templates/post.js#L66) then uses that id to query for data specific to that post.
 
-##... Take another step back to "pages"
+## ... Take another step back to "pages"
 
 So a template is a page component that we can use to programmatically create pages. Then what's a page component?
 
@@ -130,11 +131,11 @@ React components living in `src/pages` automatically become pages. The file name
 
 If you include the "optional GraphQL query" noted above, the result of that query is automatically passed to the component on a `data` prop (`this.props.data`). ([Read more on GraphQL queries](/docs/querying-with-graphql/#what-does-a-graphql-query-look-like)).
 
-##Onward
+## Onward
 
 While this isn't a tutorial -- more a guided walkthrough of me familiarizing and stepping through an initial Gatsby setup -- if you're following along with the [demo code](https://github.com/gatsbyjs/gatsby/tree/master/examples/using-wordpress) you're probably close to (or already!) seeing your WordPress data populate your Gatsby dev site if you run `npm run develop`!
 
-##Sidenotes
+## Sidenotes
 
 1.  You [don't need to know GraphQL](https://github.com/gatsbyjs/gatsby/issues/1172#issuecomment-308634739) to get started with Gatsby. I didn't. It's been a good introduction.
 2.  Gatsby makes heavy use of [plugins](/docs/plugins/) — both official and community — for a lot of things, from one that implements [Google Analytics](https://github.com/gatsbyjs/gatsby/tree/master/packages/gatsby-plugin-google-analytics), to one that adds [GitHub's accessibility error scanner](https://github.com/alampros/gatsby-plugin-accessibilityjs) to all pages.

docs/blog/2019-06-08-delicious-simplicity-case-study-part-1/index.md

@@ -8,38 +8,42 @@ tags:
   - enterprise
 ---
 
-When Brian Webster launched his Los Angeles-based development studio he sought a name that would reflect his passion for elegantly simple design. Founded ten years ago, [Delicious SimplicityL](https://delicioussimplicity.com/) has established a reputation for building clean and clever websites for a select clientele of small to mid-sized enterprise and non-profit organizations. The agency, like pretty much every agency in those days, was a Drupal/WordPress shop. As time went on, modern web design embraced bandwidth-hogging elements like hero images and background videos. Clients definitely wanted these -- delivered, of course, at near-instant download speeds and on a plethora of platforms.
+When Brian Webster launched his Los Angeles-based development studio he sought a name that would reflect his passion for elegantly simple design. Founded ten years ago, [Delicious Simplicity](https://www.delicious-simplicity.com/) has established a reputation for building clean and clever websites for a select clientele of small to mid-sized enterprise and non-profit organizations. The agency, like pretty much every agency in those days, was a Drupal/WordPress shop. As time went on, modern web design embraced bandwidth-hogging elements like hero images and background videos. Clients definitely wanted these -- delivered, of course, at near-instant download speeds and on a plethora of platforms.
 
 At the same time, WordPress and Drupal had grown into cumbersome monolithic applications bearing massive core cruft (WP genericons font library, much? Didn’t think so). These platforms were increasingly unsuited to creating the well-honed, fully-featured yet fast websites that Brian envisioned, and that clients demanded. It was time to find a new way of working.
 
 He was drawn to the idea of headless CMS (content management systems) decoupled from Drupal and WordPress, but the immediate question was how. Brian wasn’t sure if what he needed even existed, but he knew he had to search for it anyway. “We really needed an upgrade path from Drupal 7, but WordPress just seemed like it would be more of the same. Once Drupal 8 launched I didn’t want us to go into that, either,” Brian recalls. “I spent time evaluating custom solutions with Django and Python and Rails, tons of different frameworks, tons of heartbreak. Heading down the road with some of these thinking, at first, ‘This could be great, we could standardize on this!’...and then, ‘Ugh. No. This is a mess.’ Then I’d have to go back and keep doing what we were doing until I could find something else to try.”
 
 Brian was especially intrigued by JS and Node and React. “The code samples always gave me such envy—short, succinct, clean and well-organized,” Brian says. “I thought, I would really love to interact with this everyday. Here was the problem, though. I loved JavaScript, but it wasn’t a solution to any of our problems. At least not a complete one.”
 
-> **“I really started to trust that I had found the solution.
-> That Gatsby could be The One.”**
+<Pullquote>
+I really started to trust that I had found the solution.
+That Gatsby could be The One.
+</Pullquote>
 
 So Brian kept trying, and not finding, a better way to develop projects and manage client content. “Eventually, Gatsby came along and I did the same test drive,” Brian says. “But this time I kept going down the road and there was no dead end. It just kept being even better than I had hoped, and I really started to trust that I had found the solution. That Gatsby could be The One.”
 
-#### Swiping Right for Gatsby
+## Swiping Right for Gatsby
 
 There was only one potential hurdle to true romance: convincing the Delicious Simplicity team. They were mainly front end developers used to working with HTML/CSS, maybe a little jQuery. Stepping across the divide into the backend to confront the complexities of a headless CMS was not in their comfort zone. But Brian was confident he could get them there.
 
 “Once I got hands on with Gatsby, I was shocked how quickly I managed to pick things up. The syntax was just so intuitive, which made it easy to digest,” he says. There were definitely some growing pains -- the team had little experience with React or Node, and some of the devs found the new component-based way of thinking overwhelming to grasp at first. But they eventually fell in love with Gatsby and now don’t want to work in anything else.
 
-> **“What we are able to produce with the same people now is of massively higher value thanks to Gatsby’s tech stack.”**
+<Pullquote>
+What we are able to produce with the same people now is of massively higher value thanks to Gatsby’s tech stack.
+</Pullquote>
 
 “The stuff we are doing now! Building functional React components that hook into APIs -- making not just websites, but web apps!” Brian says. “I heard my team saying, ‘I never thought I would do this, I feel like a real developer now, not just a themer!’”
 
 The platform’s logical, streamlined tooling made it possible for the Delicious Simplicity team to give their hearts to Gatsby, fully and confidently, as they leveled up their dev skills. “What we are able to produce with the same people now is of massively higher value thanks to Gatsby’s tech stack,” Brian marvels.
 
-#### Fully Committed
+## Fully Committed
 
 Delicious Simplicity’s team is in fact so enamored that they have gone back and refactored the studio’s existing projects into Gatsby. “Any client projects due for updates, we have moved over to Gatsby, because that is where we want to be working. We’ve done about two dozen, there are maybe four left to go,” Brian says.
 
 Refactoring so much previous work was eased by the amount of reusability from project to project. “Our speed of building with each project is accelerated because we are now building our own library of techniques and components within Gatsby as we find them recurring from project to project,” Brian says. “Each project we do, we find a better way of doing something and then iterate that back to the previous ones. We are truly emerging with a set of tools we take forward with us, and keep applying in new ways.” By comparison, he notes, when working with WordPress and Drupal previously the team would build something specific for each particular solution, starting largely from scratch on each new project.
 
-“Before, if there was something we really liked that we could theoretically pull into another build. But refactoring it to fit was so involved it would rarely be worth the time investment.” Brian says. “Gatsby, on the other hand, enables such seamless reusability between builds that there have been times where it has just been copy, paste, done.”
+“Before, if there was something we really liked we could theoretically pull into another build -- but refactoring it to fit was so involved it would rarely be worth the time investment.” Brian says. “Gatsby, on the other hand, enables such seamless reusability between builds that there have been times where it has just been copy, paste, done.”
 
 "It took serious searching to find the perfect framework I was looking for, and there were times I really thought I would never find the one." he concludes. "But it was totally worth a little heartbreak to finally get to Gatsby."
 

docs/blog/2019-06-10-how-to-recognize-when-gatsby-is-a-good-fit-for-your-client/index.md

@@ -0,0 +1,55 @@
+---
+title: How To Recognize When Gatsby is a Good Fit for Your Client
+date: 2019-06-10
+author: Justin Emond
+excerpt: "If a client is ready to replace their tech stack, addressing their needs and using a use case is key to determining if Gatsby is a good fit as a replacement."
+tags:
+  - developers
+  - tech stack
+  - wordpress
+---
+
+As a bleeding-edge technology, Gatsby can sometimes be a complex concept to explain to clients. Particularly as budgets shift from IT to marketing, and you have to adapt the conversations for an audience with less technical understanding. But the problem isn’t actually Gatsby’s complexity— it’s that you need to start the conversation by addressing clients’ problems first.
+
+## Start with the Use Case
+
+A colleague decided to leave their current job and start his own business. His boss wasn’t pleased to lose him, which is why when he told him that he was quitting the boss said, “To succeed at your own business, you need to be able to sell wool blankets to people at a baseball game on a 90 degree day.” My colleague replied, “I would rather just sell them beer.”
+
+Unlike many technologies, Gatsby is great. But like most technologies, it’s sometimes a great fit, and sometimes not. Before you can sell Gatsby to a client, you need to ask yourself if Gatsby really is the best approach. When the use case resonates, the solution resonates, and it’s much easier to sell.
+
+In November, I began a conversation with a mid-sized retail and digital commerce consumer business in the fashion and beauty space. They were starting to plan the replacement of their aging, over-engineered five year old tech stack and were struggling with two primary challenges.
+
+- First, the content editorial experience for staff was so poor that multiple team members had actually quit because of it (saying as much in their exit interview).
+- Second, development velocity was painfully slow because of the complex implementation.
+
+Once I talked about the value of a microservices approach, the unbeatable fast speed of a React powered front end, preview, and the partial builds feature on the roadmap Gatsby (and was honest about the trade offs), the client enthusiastically wanted to know more, and they are likely proceeding with a Gatsby stack for their replatform.
+
+Here are three smart points of entry to get the conversation focused on use cases. (To learn more about explaining the technicalities of Gatsby, check out Linda’s extensive article on [how to break down Gatsby in a way that will resonate](/blog/2019-03-07-sell-gatsby-to-clients/).
+
+## #1 Developers are the bottleneck
+
+One of the primary drawbacks of a monolithic CMS like WordPress or Drupal is that the front-end theming layer is tightly coupled with the backend data layer. That means that a developer working only in the theme layer must still be comfortable with PHP, a backend programming language. In a headless approach, using JavaScript at the render layer, a themer only needs to know HTML, CSS, and JavaScript, the languages already in their toolkit.
+
+If the client is suffering from slow developer velocity, this benefit will resonate and provide value to their organization.
+
+## #2 The client wants to be on the bleeding edge
+
+There are two things you need to remember about predicting the future. First, don’t do it—it rarely works well. Second, if you absolutely must, then a handy trick is to look at what teenagers and college kids are using obsessively today, and then wait five years. Ask yourself, when was the last time you met a new engineer excited about the Wordpress or Drupal theming system? Yeah, I thought so.
+
+Gatsby is a bleeding-edge approach to solving problems, and it’s pretty different than anything else out there. But being ahead of the curve offers first-mover advantages to organizations that are comfortable dealing with some the inherent uncertainties in exploring new territory. If this is something that your prospect is looking to take advantage of, Gatsby is a good sell.
+
+## #3 They understand site speed is more than page load times
+
+Mobile websites that take [more than 3 seconds to load have a 53% bounce rate](https://www.thinkwithgoogle.com/marketing-resources/data-measurement/mobile-page-speed-new-industry-benchmarks/), meaning that you lose more than half of your visitors because they would rather try to restart their search than continue waiting for your site. In the ecommerce domain, some estimates say you lose up to [1% of revenue for every 100ms delay](https://www.section.io/blog/page-load-time-bounce-rate/) in page load time. When performant technologies like Gatsby become more common, those numbers are going to become more severe.
+
+<Pullquote>
+There is fast (which every site should be) and then there is Gatsby-fast.
+</Pullquote>
+
+Every site needs to be performant. There isn’t a site out there where slow response times won’t negatively impact user engagement, conversion, and often, the bottom line. But remember, there is fast (which every site should be) and then there is Gatsby-fast. Companies that migrate to Gatsby will find their site is [between three and 10 times faster](https://www.gatsbyjs.com/guides/why-are-gatsby-sites-fast/). Indeed, the speed of a Gatsby-powered front end resembles more of the instantaneous feel of native mobile apps.
+
+---
+
+Selling Gatsby is just like selling anything else. Focus the conversation on how using Gatsby will support their organizational and personal goals, not on its cool technical features or its fascinating architecture. Be honest about Gatsby in conversations. If your client points out a challenge with your proposed approach, don’t try to minimize it. Acknowledge it, be honest, explore the concern more deeply, and explain it in the greater context of the overall strategy you are advocating.
+
+Do this and Gatsby will resonate.