## Introduction
This post is to demonstrate how to create a GraphQL Connection Type between Product Bundles and Bundle Items in [WPGraphQL](https://github.com/wp-graphql/wp-graphql "WPGraphQL GitHub repository") within the context of the [WooGraphQL extension](https://github.com/wp-graphql/wp-graphql-woocommerce "WooGraphQL Github repository").


### tldr
The final implementation is on this gist: https://gist.github.com/jacobarriola/76ba565039c0e32f484be385969d4aca

## Connections in GraphQL

In GraphQL - because we think about our data in a graph - a Connection is a joining of two nodes within our graph.

Caleb Meredith has an awesome [post that explains GraphQL Connections](https://www.apollographql.com/blog/explaining-graphql-connections-c48b7c3d6976/).

In my case, I'm building an extension for [WooCommerce Product Bundles](https://docs.woocommerce.com/document/bundles/) for the WooGraphQL extension, so I needed a way to connect a product bundle to its children (also known as bundle items).

>Really quick, if you're not familiar with Product Bundles, it's basically a parent-child relationship between `product` post types. It gives ecommerce owners the ability to group multiple products together. The parent is the bundle, and the underlying children are their bundle items.

![Product Bundle Architecture](//images.ctfassets.net/4pywjkutx049/4sxy8oTeqiV3H63kbe9T5F/da73bd1a3978fef2530f8e614098c4ef/bundle-large.png)
*High level overview of product bundles and their bundle items*

## Shape of our query

Cool, now that we have a sense of the architecture, let's get down to solving our problem.

Ideally, here's the shape of the query that we'll be shooting for (the `bundleItems` field is where we'll be living):

```graphql
{
  products {
    nodes {
      name
      price
      productId
      ...on BundleProduct {
        bundleItems {
          edges {
            quantityMin
            quantityMax
            node {
              name
              productId
            }
          }
        }
      }
    } 
}

```

Basically, what we're querying is: "go get me the first n products, if a product is a product bundle, go get me its children, along with some data that's relevent to their relationship". 

> Keep an eye on those two `quantityMin` and `quantityMax` edge fields. We'll touch upon those later.

## Steps to create the connection
There will be two steps we'll be taking to create our connection: registering and resolving.

### Step one: register the connection
WPGraphQL has a function called `register_graphql_connection()` that we'll use to create the connection. We can safely call this function as part of a callback during the `graphql_register_types` action.

```php
add_action( 'graphql_register_types', function () {
	register_graphql_connection( [
		'fromType'      => 'BundleProduct',
		'toType'        => 'Product',
		'fromFieldName' => 'bundleItems',
		'resolve'       => function ( $source, $args, $context, $info ) {
			return 'GraphQL is lit!';
		},
	] );
} );
```

The [WPGraphQL docs](https://docs.wpgraphql.com/extending/connections/#config) does a good job of defining the parameters of the the function, so read up on the definitions. But basically, we're defining where the connection is coming from and where it's going to.


### Step two: configure the resolver
The `resolve` function feels like [WordPress pre\_get\_posts-land](https://developer.wordpress.org/reference/hooks/pre_get_posts/ "WordPress pre_get_posts documentation"). In other words, this is an opportunity for us to short-circuit the query before it's run.

In our case, we want to adjust the query variables to only include certain posts (our bundle items).

The resolver essentially needs two things: instantiate a new connection resovler class (either your own or one that's pre-built) and return the `get_connection()` method for that class. The connection resolver class is responsible for setting up the query and connecting to a data loader.

For our case, I ended up using the existing [WooGraphQL Product\_Connection\_Resolver Class](https://github.com/wp-graphql/wp-graphql-woocommerce/blob/develop/includes/data/connection/class-product-connection-resolver.php#L25), since my `$source` is a `product` post type and all I simply need to do is adjust one query parameter (I tried to mess around with creating my own resolver class, but quickly got lost in underlying assumptions that I didn't know about. It works for now, but I'll revisit later).

Here's what the resolver configuration looks like after our update:

```php
add_action( 'graphql_register_types', function () {
	register_graphql_connection( [
		'fromType'      => 'BundleProduct',
		'toType'        => 'Product',
		'fromFieldName' => 'bundleItems',
		'resolve'       => function ( $source, $args, $context, $info ) {
			$resolver = new Product_Connection_Resolver( $source, $args, $context, $info );
			
			return $resolver->get_connection();
		},
	] );
} );
```

Once we update our resolver, the query will now get the first 10 (or whatever your global `per_page` settings is set to) products. This is good, but we still need adjust the query to only retrieve the products that belong/relate to this bundle (ie the bundle items).


#### Figure out how to get the bundle items that belong to the current product bundle
Ok, so in this `resolve` callback, we know that the current `$source` value is a `BundleProduct` Type, which is a `product` post. In the database, the relationships are stored in a custom table called `woocommcere_bundle_items`. Therefore, we'll need to write a query to get all of the bundle items that belong to our current bundle in the `resolve` callback.

Our query can look something like this:

```php
$wpdb->get_results( $wpdb->prepare( "
		SELECT
			product_id
		FROM
			{$wpdb->prefix}woocommerce_bundled_items
		WHERE
			bundle_id = 123456
		LIMIT 10
		"
) );
```

Nothing too crazy here. All we're looking to get back is an array of product IDs that are associated with our Product Bundle.

#### Update the resolver with our bundle item IDs
Now that we have an array of IDs, we can update our resolver (throwing in sample IDs for demo purposes):

```php
add_action( 'graphql_register_types', function () {
	register_graphql_connection( [
		'fromType'      => 'BundleProduct',
		'toType'        => 'Product',
		'fromFieldName' => 'bundleItems',
		'resolve'       => function ( $source, $args, $context, $info ) {
			$resolver = new Product_Connection_Resolver( $source, $args, $context, $info );
			
			$resolver->set_query_arg( 'post__in', [ 123, 456 ] );
			
			return $resolver->get_connection();
		},
	] );
} );
```

The `set_query_arg()` method is the mechanism that allows us to safely set the query arguments before it's run. You can use [any WP_Query parameter](https://developer.wordpress.org/reference/classes/wp_query/#parameters) here. Why? If you explore the `Product_Connection_Resolver` and [look at the get_query() method](https://github.com/wp-graphql/wp-graphql-woocommerce/blob/develop/includes/data/connection/class-product-connection-resolver.php#L319), you'll see that it eventually runs `WP_Query`.

#### `set_query_arg` does not work here
In a perfect world, this would be all we need; however, despite setting the `post__in` query argument, my query was still returning back the first 10 product posts. I have an [issue on GitHub](https://github.com/wp-graphql/wp-graphql-woocommerce/issues/321) that documents this.

##### __Workaround__
Luckily, we can hook into a query args filter that runs really late to safely add our `post__in` argument.

```php
add_filter( 'graphql_product_connection_query_args', function ( $query_args, $source, $args, $context, $info ) {
	
	// Bail if this isn't a bundle. This filter runs on all product types
	if ( 'bundle' !== $source->type ) {
		return $query_args;
	}
	
	$query_args['post__in'] = [ 123, 456 ];
	
	return $query_args;
}, 10, 5 );
```

## Edge fields
Remember our two `productMin` and `productMax` edge fields? I struggled a lot with this concept and how it relates to the problem we're trying to solve.

Edge fields represent __data in the context of the relationship between nodes__. The line between two nodes are called edges; any data that lives on that virutal line is called an edge field.

> 📺 Jason Bahl has a good [explanation of this concepet on YouTube](https://youtu.be/2qYn3VPcTpE?t=826) within the scope of WordPress 

Say you have a property rental application where a node could be a `User` Type and a `Property` Type. A `Property` will have a relationship with a `User` because a user will rent a property. While each of the Types will contain data about itself (`User`: name, DOB, ID, etc; `Property`: address, beds, baths, etc), there is data that is based on *context of the relationship*: rental start date, rental end date, rental ID, etc. This data doesn't really belong to the `User` or the `Property`; it belongs to their relationship. That's edge data!

Back to our case. The `BundleProduct` and `Product` connection have properties of their context. This includes things such as `quantityMin`, `quantityMax`, amongst others. Because it's a property of the relationship, we're delibertaly exposing the data on the edge.

#### How to add edge fields to the bundle items
There's an `edgeFields` property in the `register_graphql_connection` method configuration where we pass in an array a fields we want to expose to the edge schema.

Inside each field we declare, there's a friendly `resolve` property, which we'll use to write our logic for the given field.

```php
register_graphql_connection( [
	'fromType'      => 'BundleProduct',
	'toType'        => 'Product',
	'fromFieldName' => 'bundleItems',
	'resolve'       => function ( $source, $args, $context, $info ) {
		$resolver = new Product_Connection_Resolver( $source, $args, $context, $info );
		
		return $resolver->get_connection();
	},
	'edgeFields'    => [
		'quantityMin' => [
			'type'    => 'Int',
			'resolve' => function () {				
				return 'GraphQL is LIT';
			},
		],
	],
] );
```

The `$source` parameter returns an array with four items:

- cursor - a hash used for pagination
- node - the product itself, an instance `WPGraphQL\WooCommerce\Model\Product`
- source - the product bundle, an instance `WPGraphQL\WooCommerce\Model\Product`
- connection - our connection resolver `Product_Connection_Resolver`

Unfortunately, the data for bundle items isn't stored in `postmeta`, so we can't fire off a quick `get_post_meta( $source['node']->ID, 'quantity_min', true )` and call it a day. Instead, data is stored in a custom meta table, so we need to figure out a way to efficiently get that data.

We don't want to write custom SQL or instantiate classes at each field; rather, we need a way to expose all the data to this resolver beforehand, so that fields can simply pluck the data they need and return it. Filters to the rescue!

The filter we'll be using is `graphql_connection_edges`, which is run at the `Product_Connection_Resolver` level as it's setting all of the data for the edges. What we want to do is instantiate a pre-built `WC_Bundled_Item_Data` class on our given node and expose it to the resolver's `$source` attribute.

This filter runs on all connections, so we need to run some checks to ensure our logic on runs on bundle items.

```php
/**
 * Inject the WC_Bundled_Item_Data Class into the resolver so that fields can access
 * edge data
 */
add_filter( 'graphql_connection_edges', function ( $edges, $resolver ) {
	$source = $resolver->getSource();
	
	// Bail if our $source isn't a bundle
	if ( 'bundle' !== $source->type ) {
		return $edges;
	}
	
	// Get some info about the $resolver
	$resolverInfo = $resolver->getInfo();
	
	// Get the name of the field we are resolving
	$fieldName = $resolverInfo->fieldName;
	
	// Bail if our field isn't bundleItems
	if ( 'bundleItems' !== $fieldName ) {
		return $edges;
	}
	
  // Go get all of the bundle items for this product bundle
	$bundled_data_items = $resolver->getSource()->get_bundled_data_items();
	
	// Go through each edge, find the bundle item id, and set the bundleItem
	foreach ( $edges as $key => $edge ) {
		
		$raw_bundled_data_item = array_filter( $bundled_data_items, function ( WC_Bundled_Item_Data $item ) use ( $edge ) {
			return $item->get_product_id() === $edge['node']->ID;
		} );
		
		if ( empty( $raw_bundled_data_item ) ) {
			$edges[ $key ]['bundledItem'] = [];
			continue;
		}
		
		$bundled_data_item = array_values( $raw_bundled_data_item );
		
		// Expose the bundleItem so that the resolver can get edge data
		$edges[ $key ]['bundledItem'] = WC_PB_DB::get_bundled_item( $bundled_data_item[0]->get_bundled_item_id() );
	}
	
	return $edges;
}, 10, 2 );
```

Lots happening here, but the meat of our logic is happening on the `foreach`, where we find the bundled item, get its id and set the bundle item data so that it's available on the resolver.

Now, our each resolver function has access to the `WC_Bundle_Item_Data` instance for its bundle item, and can properly resolve data. Great success!

```php
'quantityMin' => [
  'type'    => 'Int',
  'resolve' => function ( $source ) {
    /* @var $bundledItem WC_Bundled_Item_Data */
    $bundledItem = $source['bundledItem'];

    return $bundledItem->get_meta( 'quantity_min' );
  },
],
```


## Conclusion
Before I started, I knew nothing about connections, loaders and edges. But with some help with XDEBUG, I was able to open up the source code and get a sense of what was happening behind the scenes.

As always, there's room for improvement. Ideally I'd like to make my own connection resolver (and subsequent data loader) class because running all my logic via filters feels a bit hacky, especially with all of the checks that I have to do. Both WPGraphQL and WooGraphQL write their own classes, so I'll follow their pattern.

Next steps are to see how cart, checkout and orders need to be altered to accomodate product bundles.

The final implementation is on this gist: https://gist.github.com/jacobarriola/76ba565039c0e32f484be385969d4aca


Connect Product Bundle Items in Your WooCommerce GraphQL API

While the docs say to [add WPGraphQL to your WordPress plugin directory](https://docs.wpgraphql.com/getting-started/install-and-activate/#github---download--clone-plugin "WPGraphQL documentation page") (`wp-content/plugins`), here's a quick config if you want to add it to your mu-plugins instead.

This configuration assumes your composer file sits in `wp-content`.

## Why mu-plugins (must-use)?
I like to add core logic in mu-plugins because:

- no one can ever accidentally disable your logic, thereby causing unexpected errors
- all custom app logic is neatly organized in a central place as opposed to mixed in with 3rd party libraries or within a theme
- the code always loads; no need to activate anything


Check out the full WordPress.org docs on mu-plugins: https://wordpress.org/support/article/must-use-plugins/

## tldr - the final composer json config
Here's the final `composer.json` file that you'll want to use.

```json
{
  "name": "wpgrapql",
  "type": "project",
  "license": "proprietary",
  "config": {
    "preferred-install": "dist",
    "vendor-dir": "mu-plugins/app/vendor"
  },
  "extra": {
    "installer-paths": {
      "mu-plugins/{$name}/": [
        "type:wordpress-muplugin",
        "wp-graphql/wp-graphql",
        "wp-graphql/wp-graphiql"
      ]
    }
  },
  "repositories": [
    {
      "type": "github",
      "url": "https://github.com/wp-graphql/wp-graphql"
    },
    {
      "type": "github",
      "url": "https://github.com/wp-graphql/wp-graphiql"
    }
  ],
  "require": {
    "php": ">=7.4",
    "composer/installers": "^1.5",
    "wp-graphql/wp-graphql": "^0.8.0",
    "wp-graphql/wp-graphiql": "^1.0"
  }
}
```

## Let's break down this composer file step-by-step.

### Add the Github repositories in the repositories array
In your `composer.json` file, add the WPGraphQL GitHub repos to the `repositories` array. This tells composer to pull its data from GitHub, as opposed to packagist. Sometimes there's a slight delay on when a version is available in packagist.

```json
 "repositories": [
    {
      "type": "github",
      "url": "https://github.com/wp-graphql/wp-graphql"
    },
    {
      "type": "github",
      "url": "https://github.com/wp-graphql/wp-graphiql"
    }
  ]

```

### Provide the install path
This tells composer _where_ to install the packages.

```json
"extra": {
    "installer-paths": {
      "mu-plugins/{$name}/": [
        "type:wordpress-muplugin",
        "wp-graphql/wp-graphql",
        "wp-graphql/wp-graphiql"
      ]
    }
  },
```

### Install via composer
Now that all of the settings are in place, you can go ahead an run the composer install commands.


```shell
composer require wp-graphql/wp-graphql
composer require wp-graphql/wp-graphiql
```

### Load the files
I usually have a `mu-plugins/load.php` file that simply fires off some requires.

```php
// wp-content/mu-plugins/load.php

require_once __DIR__ . '/wp-graphql/wp-graphql.php';
require_once __DIR__ . '/wp-graphiql/wp-graphiql.php';
```

WPGraphQL should now load on your site as expected! 


Add WPGraphQL as an mu-plugin with composer

## Introduction
This tutorial is to show you how to add the [WooCommerce Product Bundle](https://woocommerce.com/products/product-bundles/ "WooCommerce Product Bundle add on documentation") product type to your WooCommerce GraphQL API. This is definitely a work-in-progress that I'll try and keep updated.

The two plugins in use here are:
1. [WPGraphQL](https://github.com/wp-graphql/wp-graphql "WPGraphQL Github repository"): 0.10.2
2. [WPGraphQL WooCommerce (WooGraphQL)](https://github.com/wp-graphql/wp-graphql-woocommerce "WPGraphQL WooCommerce Github repository"): 0.5.1

### Begin with the end in mind
Ideally, this is the shape of the GraphQL query that we're shooting for:

```graphql
query {
  products {
    name
    shortDescription
    ...on BundleProduct {
      price
      bundledItems {
        node {
          name
          shortDescription
        }
      }
    }
  }
}
```

### TLDR - the final code
Check out the gist for the full implementation: https://gist.github.com/jacobarriola/5d055ba102c001f0c556427a1ae78cd2

### Here are the high level steps that I intend to take:
1. Register the `BundleProduct` ObjectType
2. Register a `RootQuery` field for the new ObjectType
3. Expose the new `BundleProduct` object type to WooCommerce GraphQL's list of product types
4. Expose the new `BundleProduct` to the product types enum values so that query input filters will work
6. Add fields to the `BundleProduct` ObjectType
7. Create a Connection to expose bundleItems to `BundleProduct`

## Product is a GraphQL Interface
An important WooCommerce GraphQL architectural concept to grasp is that a `Product` is an Interface type and all `product_types` (simple, variable, external, grouped) are *implementations* of the `Product` Interface.

> 📕 Say what?! Check out the GraphQL docs on what an Interface is: https://graphql.org/learn/schema/#interfaces


In normal WooCommerce-land, `product_types` (simple, variable, external, grouped) are simply terms for the `product_type` custom taxonomy. The Product Bundle add-on extends this same pattern by creating a term `bundle` for the `product_type` taxonomy.


Therefore, in order to add product bundles to our GraphQL API, we're going to follow the same implementation pattern that the core product types already follow in WooGraphQL and implement and `Product` interface.


## Step one: add the bundle product type to GraphQL product types

This filter allows us to safely add our `bundle` product type. The underlying method uses this list to expose the WooCommerce product types (simple, variable, external, grouped) to the GraphQL schema.

```php
add_filter( 'graphql_woocommerce_product_types', function ( $product_types ) {
	$product_types['bundle'] = 'BundleProduct';
	
	return $product_types;
} );
```

## Step two: add the `BundleProduct` ObjectType to the GraphQL TypeRegistry
This is the meat of our customization. We're bascially declaring our new Type along with all of the fields.

```php{numberLines: true}

add_action( 'graphql_register_types', function () {
	
	/**
   * Register BundleProduct ObjectType
   */
	register_graphql_object_type( 'BundleProduct', [
			'description' => 'A product bundle object',
			'interfaces'  => [ 'Node', 'Product' ], // Following same pattern that other product types declare
			'fields'      =>
				[
					'bundlePriceMin' => [
						'type'    => 'String',
						'resolve' => function ( $source ) {
							return $source->get_bundle_price('min');
						}
					],
					'bundlePriceMax' => [
						'type'    => 'String',
						'resolve' => function ( $source ) {
							return $source->get_bundle_price('max');
						}
					],
					'groupMode'=> [
						'type'    => 'String',
						'resolve' => function ( $source ) {
							return $source->get_group_mode();
						}
					],
					'price' => [
						'type'    => 'String',
						'resolve' => function ( $source ) {
							return $source->get_price();
						},
					],
					'salePrice' => [
						'type'    => 'String',
						'resolve' => function ( $source ) {
							return $source->get_sale_price();
						},
					],
					'regularPrice' => [
						'type'    => 'String',
						'resolve' => function ( $source ) {
							return $source->get_regular_price();
						},
					],
					'bundledItems' => [
						'type'    => 'String',
						'resolve' => function ( $source ) {
							return 'this is still a work-in-progress';
						},
					],
				],
		]
	);
} );
```

### Why are product bundle methods available?
By default, the first parameter in a field resolver is always the latest thing that was queried. In our case, we are querying `Product` types because of the `Product` interface; therefore, the `$source` parameter is an instance of the `WPGraphQL\WooCommerce\Model\Product` class.

But if you explore the class, you won't find any of the Product Bundle methods I'm using (ie `get_bundle_price()`). But why isn't PHP throwing any fatal `cannot find get_bundle_price() method in ...` errors? This is because the presence of a `__call()` [magic PHP method](https://www.php.net/manual/en/language.oop5.magic.php "Documentation on magic methods") in the *parent* class (`WPGraphQL\WooCommerce\Model\Crud_CPT`), which allows us to call dynamic or inaccessible methods that are not definded in the class.

## Step three: register a GraphQL field with our new Type
The Type will not appear on our GraphQL API until we register at least one field.  For now, I'm registering a `RootQuery` so that consumer can query `bundleProduct` directly like the other product types.

```php
add_action( 'graphql_register_types', function () {
  
  register_graphql_field(
      'RootQuery',
      'bundleProduct',
      [
        'type' => TYPE_BUNDLE_PRODUCT,
      ]
  );
});

```

## Step four: add bundle to the product types enum
Doing so will include our new `BundleProduct` to be included in the `where` argument when querying products.

```php

add_filter( 'graphql_product_types_enum_values', function ( $values ) {
	$values['BUNDLE'] = [
		'value'       => 'bundle',
		'description' => 'A bundle product',
	];
	
	return $values;
} );

```


## Step five (TBD): create a new Connection in order to return bundle items
In my query, I'd like to be able to return the actual items that are part of the product bundle. In WooCommerce-land, these are known as `bundleItems`. This is still a work-in-progress.


## Conclusion
Still more work here, but hopefully this will get you started. There's still plenty to be done, such as:
1. add bundle items
2. add bundle to the cart
3. more that I haven't thought of 🤷🏽‍♂️

Add Product Bundles to Your WooCommerce GraphQL API

> Hey! This post is a bit outdated. My site has morphed a few times since this was published. It's currently on Gatsby with Contentful 🚀


---

I have nothing against WordPress; it's wonderful software that solves a lot business problems. In fact, I develop a lot of applications/sites using WordPress. The problem is, for my site, WordPress was no longer a viable solution to my needs.

A static-site generator is a build system that takes in source files and creates all of the HTML for your site. For an in-depth explanation about static-site generators, David Walsh has a great [introduction to static-site generators](https://davidwalsh.name/introduction-static-site-generators "Intro Article About Static Site Generators") on his site. There are a lot of
generators out there such as Jekyll, Metalsmith, and Harp, to name a few.

The focus of this article is to discuss why I decided to move my site from
WordPress to a static-site generator, from the viewpoint of a WordPress developer.

## Why I switched from WordPress to a static site generator

### 1. Databases
I don't write a lot of articles and don't want to have to manage databases,
especially dealing with crazy security threats that I wouldn't know how to
manage/triage if they should occur. Plus, dealing with managing a local db versus a production db was too much to deal with. I'd rather spend the time learning new tools.

### 2. Plugin updates
I ran some core plugins in my old WordPress site. While these plugins do an
amazing job of what they were designed to do, ultimately, I didn't have enough time to keep pace with updating for bug-fixes, security patches and new features.

There would be so many times that I would log into my site and see all kinds of plugin updates. Being a safe developer, I would have to update locally, test, then push up my updated plugin folder onto my repo - too many steps that I was willing to deal with anymore.

WordPress core updates aren't that big of a concern for me lately. Most hosting platforms do a good job of updating core for you automatically. Plus, the core team has been pushing out updates pretty frequently to make the update process less impactful.

### 3. Performance
Static sites are fast. There aren't any SQL queries or PHP processing, or
WordPress creation when a visitor hits your site. The HTML has already been created during the build process.

### 4. Security
Since there isn't anything to login to or a connected database, I don't have to worry as much for any security threats, especially when it comes to things such as comment spamming and site hacking. There were a bunch of times I'd log in to my WordPress site and see hundreds of comments from weird IP addresses. That kind of stuff made me really nervous.

### 5. JavaScript
I wanted a something where I could use JavaScript as part of my build/site creation process (more on this in another post). Most of my time with WordPress dealt with PHP, which is fine; however, I don't have a ton of interest in diving deeper into PHP, and would rather spend time improving my JavaScript.

### 6. No Web Hosting + Deployment with Gulp
I'm hosting my new site via Github Pages, which - for now - is free. So there's no need for me to pay for hosting, although the cost for hosting these days is pretty cheap anyways; nonetheless, who doesn't like free things?!

There's a sweet little Gulp plugin called [gulp-gh-pages](https://www.npmjs.com/package/gulp-gh-pages) that I use to deploy my site on GitHub Pages. I was already using git to deploy my WordPress site anyway; however, this is a nice convenient touch.

Here's the basic setup on my `gulpfile.js`:

```javascript
var gulp = require('gulp');
var ghPages = require('gulp-gh-pages');

gulp.task('deploy', function() {
  return gulp.src('./build/**/*')
    .pipe(ghPages());
});
```


And here's how I deploy:
```bash
$ gulp deploy
[19:37:21] Using gulpfile ~/Documents/Websites/personal-site/gulpfile.js
[19:37:21] Starting 'deploy'...
[19:37:21] [gh-pages] Cloning repo
[19:37:21] [gh-pages] Checkout branch `gh-pages`
[19:37:21] [gh-pages] Updating repository
[19:37:23] [gh-pages] Copying files to repository
[19:37:23] [gh-pages] Adding 4 files.
[19:37:23] [gh-pages] Committing "Update 2016-01-15T03:37:21.748Z"
[19:37:23] [gh-pages] Pushing to remote.
[19:37:25] Finished 'deploy' after 3.39 s
```
Basically, what's happening here is:
1. Gulp clones my `master` branch and checks it out in a new branch named `gh-pages`
2. Gulp makes a commit to `gh-pages` with a timestamp as its message
3. Gulp pushes `gh-pages` to the `origin` repo (on GitHub)


## Road Blocks to Address
For all of the issues I listed with WordPress, there were some possible deal breakers when it came to jumping ship. The following are things I ran into and that a WordPress developer needs to consider before making the change:

### 1. How to deal with SEO
Most SEO WordPress plugins do a lot of stuff that you need to be prepared
to do on your own. You'll have to figure out:

1. How to integrate social (especially things such as Facebook open graph and
custom attributes)
2. How to create your own sitemaps
3. Custom meta tags such as title and description at the post level

My solution? I don't overthink SEO. Write good content/build awesome solutions and people will find you. I've spent too much time going back and forth with SEO experts and reading countless posts about best practices. Spending too much time optimizing your site for SEO is like chasing a moving target. Search engines are always changing how they rank and find you.

### 2. Importing data from WordPress
Luckily, I didn't have any comments on my old site and just a handful of posts, so I didn't have to deal with importing data. However, if you have a lot of data with multiple post types, and custom fields, moving over to a static site generator may not be the ideal option.

One possible project may be to hit the [WP REST API](http://v2.wp-api.org/ "WordPress REST API Docs")and bring in your data via JSON. Once you have the JSON, you can theoretically have your static-site generator fire up the static HTML pages. One road block would be figuring out authentication, but I'm sure there are solutions out there.

Another possible solution is finding a static-site generator that plays nice with WordPress imports. For instance, Jekyll is a popular ruby-based solution that [has an out-of-the-box](http://import.jekyllrb.com/docs/wordpress/ "Jekyll WordPress Import Documentation") WordPress importer.

### 3. No administration UI
For the most part, I was OK with having to deal with the WordPress admin UI, especially since I use [WP-CLI](http://wp-cli.org/), which allows me to use the command line for managing my WordPress site such as plugins, users, and
media.

However, one thing you'll need to keep an eye on is the post/page admin screen.

A static-site generator doesn't have an admin UI, so if you need an interface to manage your posts/pages, that's something you want to consider as a deciding factor. The biggest thing in the management perspective is search. As I write more posts, I feel that searching for a specific post will be harder than using WordPress.

### 4. No WYSIWYG for writing posts/pages
Similar to not having the administration UI, you will lose the content UI where authors write posts. Most static-site generators use markdown as the interface to write your posts. The build process of the generator converts the markdown files into HTML.

### 5. You'll need to learn a templating language
A powerful part of static-sites is the template engines powering your source code.

This introduces programmatic concepts into your HTML such as loops and objects.

I've started off with [Handlebars](http://handlebarsjs.com "Handlebars JavaScript Scripting Language") without any major road blocks. I've also heard good things about [Nunjucks](http://mozilla.github.io/nunjucks "Nunjucks Templating Language") and will probably try them out later on.

If you're a WordPress developer, picking up a templating language shouldn't be too cumbersome, since many of concepts overlap. Either way, it's still a new thing you'll have to learn.

Let's look at a quick example of how a basic WordPress loop differs from Handlebars:

```php
// Our trusty WordPress loop
<ul>
  <?php while ( have_posts() ) : the_post(); ?>
    <li>
      <h2><a href="<?php the_permalink(); ?>"><?php the_title(); ?></a></h2>
      <p><?php the_date(); ?></p>
      <?php the_excerpt(); ?>
    </li>
  <?php endwhile;?>
</ul>
```

```handlebars
// The same loop, written in Handlebars
<ul>
  {{#each collections.posts}}
    <li>
      <h2><a href="{{this.path}}">{{this.title}}</a></h2>
      <p>{{this.date}}</p>
      <p>{{{this.excerpt}}}</p>
    </li>
  {{/each}}
</ul>
```

For the most part, the programmatic concepts are parallel. Each is looking for an object of posts and uses a loop to iterate through them, returning values along the way (title, date, excerpt). Beyond the syntax, it's quite similar and doable for a WordPress developer to take on.

One significant difference is while WordPress uses built-in functions to return values (`the_title()` returns the post title, for instance), Handlebars uses JavaScript's dot notation, `{{ this.title }}`.

Add A Form To a Nuxt or Vue Site With Formspree

The other day I was handed a design for a large navigation menu with images. An image would show when a user hovered over the individual menu item - a pretty common navigation UI.

My biggest concern was how to load these images only when the
visitor required them, especially because they are not visible to the user
unless she engages with the navigation, which may not happen all the time. 

## The plan

**The problem** - the navigation contains a large amount of images, which may impact site load time.

**The solution** - only load a navigation image when user hovers over the associated menu item.

**The technique** - on hover, replace a `span` tag with an `img` tag and copy the attributes over.


## The markup
I've created a `span` element with a custom attribute named `data-original`, which contains the path to my image.

```html
<div class="container">
  <h1 class="trigger">Hover over me to fetch an image</h1>
  <span data-original="http://www.fillmurray.com/200/200">
</div>
```

## The JavaScript
I have an event listener for the `.trigger` class that will do a quick search and replace, copying what I have in the `data-original` to the `src`.

## CodePen demo
I have a red box that is the `span` tag. Once you hover over the box, the JS fires and loads the image.

<p data-height="268" data-theme-id="21239" data-slug-hash="dGGzxK" data-default-tab="result" data-user="jacobarriola" class='codepen'>See the Pen <a href='http://codepen.io/jacobarriola/pen/dGGzxK/'>Lazy Load on hover using span swap</a> by Jacob Arriola (<a href='http://codepen.io/jacobarriola'>@jacobarriola</a>) on <a href='http://codepen.io'>CodePen</a>.</p>
<script async src="//assets.codepen.io/assets/embed/ei.js"></script>

## Progressive Enhancement
Well, the image contains other meta data that I didn't include here such as
the post title and excerpt. Therefore, in the event that JavaScript is not
available, the user will still be able to tell what she is looking at and can still click through - yay!

## What About SEO?
From what I understand, we shouldn't get penalized since the DOM intially reads as a `span` tag. I was orginally going to use an `img` tag and just swap out attributes, but was concerned about search engines penalizing me for having an `img` tag without a `src` attribute.

Lazy Loading Images on Hover

Collection of tools and techonologies discussed in [JAM Stack SF 2019](https://jamstackconf.com/sf/).

## API-Driven CMSs
There were alot of headless/API-centric CMSs at the conference, each with their own unique offering.

- Sanity.io
- Contentful
- Craft CMS
- Forestry.io
- Big Commerce (eCommerce)
- Netlifly


## Static Site Generators

- Gatsby
- 11ty
- Next
- Nuxt

## Image Processing

- Cloudinary
- ImgIX - https://www.imgix.com/

## Tools
- Stackbit Live - edit your static site right from the front end. It's CMS agnostic. https://www.stackbit.com/live/
- OneGraph - https://www.onegraph.com/
- TakeShape - synchorize/combine different sources of data https://www.takeshape.io/



JAMStack SF 2019 Recap


This fall I attended [SassConf](http://sassconf.com/) in Austin, Texas. It was a 3-day event filled with attendees with all kinds of backgrounds: front-end, back-end, and designers. I've been writing Sass for over 2 years now, and felt as though this would be an awesome way for me to meet other Sass developers and level-up my Sass skills.

Here are some quick takeaways from my time in Austin:

## 1. Sass Maps (@get-maps)
Before attending Sass Conf, I thought Sass maps and sourcemaps where the same thing.

Basically, Sass maps are a data-type that give developers a way to structure data, similar to JSON with key/value pairings. Una Kravets has a [excellent article](http://www.sitepoint.com/5-great-uses-sass-maps/) what Sass maps are and some use cases for them.

Slide decks for both talks on Sass maps:

1. [Chris Suave's deck](http://www.slideshare.net/chrismsauve/sassconf-slides-chris-sauve "Slide Deck")
2. [Lourdes Montano's deck](http://www.slideshare.net/loumontano/sassconf-maps "Slide Deck")

## 2. For Loops (@for)
As a WordPress developer, I'm super familiar with how loops work, so getting exposed to them in a Sass perspective was't too difficult for me. In fact,
having programmatic concepts like loops on the CSS side of things blew me away.

I attended [Eva Ferreira's](https://github.com/evaferreira "Eva's GitHub Profile") *Looping For Animation* workshop. We did all kinds of neat things with animations, SVGs and loops. Turns out, animation is an awesome use-case for loops.

Check out the CodePen demo on a simple animation loop she had us do. Super cool.

<p data-height="268" data-theme-id="21239" data-slug-hash="bVQJrp" data-default-tab="result" data-user="jacobarriola" data-preview="true" class='codepen'>See the Pen <a href='http://codepen.io/jacobarriola/pen/bVQJrp/'>Sass Conf Loop animation</a> by Jacob Arriola (<a href='http://codepen.io/jacobarriola'>@jacobarriola</a>) on <a href='http://codepen.io'>CodePen</a>.</p>
<script async src="//assets.codepen.io/assets/embed/ei.js"></script>

## 3. SCSS Linting
Scss linting allows developers to create style rules for Sass. A style rule can be something like "Don't indent more than 3 levels deep" or "No IDs". This can be
really cool for teams or open-source projects. [Check out the project files](https://github.com/sasstools/sass-lint "Sass Lint GitHub Page") for
more info.

## 4. Using VIM
Even though VIM isn't directly associated with Sass, as developers it's a tool we can use in our day-to-day. During the unconf portion of the conference (which
is pretty much a day where everyone meets at a place to discuss their projects
and share knowledge), one of the attendees decided to show us VIM and how he
uses it.

It's super rad and a major time saver. I'm using the Atom VIM wrapper for my
projects, and so far it's helping.

## 5. How to contribute to open source projects
During unconf, I joined Una who shared her [CSSgram](https://github.com/una/CSSgram "CSSgram") open-source project. The
biggest takeaway was how easy it is to contribute to a project. Given that a
project has some clear instructions on how to contribute, Una made contributing
seem very approachable and welcomed by open-source contributors.

Throughout the conference, there were other workshops and talks on open-source
and contributing, so there was definitely a good vibe of contributing during the
conference.

## 6. Contributing to the Sass project isn't that difficult to do
I initially felt that there wasn't anything I could do to contribute to the community since I'm not a Ruby or C developer. However, I met Jina, who maintains the Sass website, and I realized that I could contribute in other ways that match my skill set such as documentation, design and front-end work.

## 7. Take advantage of the Sass functions out there
Roy Tomeij gave a super-informative [talk on built-in Sass functions](http://sassconf.com/speakers/roy-tomeij.html "Roy Tomeij SassConf Page"). In fact, he went of all 80 functions in his talk - a super lighting talk
indeed. All kidding aside, Sass comes with a lot of functions that make our lives
as developers much easier. Check out the docs and get going!