My WordPress block chain journey: 1

I have been studying up on block chain, and will be meddling more with it to develop a network where content can be distributed, traded, and protected. There are a lot of pieces that I still need to learn, a big one is understanding the theory behind currency, value, and micro/macro economic interactions. Will there be a crypto currency involved in this? In some ways yes, there needs to be some token/currency system tied to interactions. By having a value system in place there are a number of natural benefits that occur.

Why value matters in social interaction

We may not be fully cognizant of it, but collectively we are the most valuable employees to Google, Facebook etc. We are quite literally their money maker. In return for our labor, we get the privilige to use their awesome services. Yay! Wait… that doesn't seem quite right. By purely using their service (not paying for it), we become their revenue source. It seems a bit odd. The data we generate by using Facebook, Google, etc. is very useful and valuable. If the data wasn't these tech behemoths wouldn't be where they are today. Targeted advertising is a good thing, but needs to be revamped a bit. I like Facebook, and Google, they are great, but I question how fair this system seems. We provide them their value, and all we really get in return is a slightly higher level of convenience, I am not sure how well balanced this exchange of value is.

We need to start realizing our own value in our everyday interactions online. Value is exchanged all the time in our searches, page clicks, reading of content, interactions, and messages. We are usually unaware of it though. Without a value system/currency backing these interactions though it is hard to discourage things like harassment, spamming, and other negative behaviors, because ultimately there is no price to be paid. We have high cost infrastructure to help combat these things, but the economics of interaction are a force we are not leveraging. Am I saying you will need to pay to engage? Yes, but not with income we use to buy goods and services. A token system can exist completely aside from a currency, even though they are the same thing pretty much. Remember that our engagement is the real value to companies like Google & Facebook, so why not have some of the value come back our way?

Do I have the perfect plan for all of this? No. A colossal NO. I really have no idea how to approach any of this, but I think the problem is clear enough to start trying to chip away at it.

Choosing a block chain

After reviewing the many many systems in place, Ethereum seems like a pretty safe starting place for the backing blockchain. After reviewing a seemingly endless set of blockchains, tokens, and more, I came to the decision that Ethereum has the best tools, community, and openness to get poking around. I have already begun working on things, (more like stumbling) and am excited to share the progress with everyone and get more people involved. If you have any extra knowledge about developing apps on a blockchain help is appreciated, drop a comment! If you are excited or terrified, also drop a comment, as I would love to hear more thoughts.

Rethinking Meta Boxes with the new WordPress block editor: Part 1

The post has been updated to reflect some code improvements pointed out by Daniel Bachhuber.

I have spoken to a number of agencies, and WordPress developers, and I have come to one conclusion; ACF and Meta Boxes are critical for their deliveries. ACF, particularly the pro version, seems to be used quite a bit. Most of the work I do does not use ACF, but I certainly have used meta boxes a fair bit. We have probably done all sorts of crazy stuff with meta boxes and they have served us well. The new block editor can be somewhat scary as it appears to be replacing meta boxes. In fact, one of the goals of blocks is to replace things like meta boxes. Metadata management is definitely a crucial selling point for WordPress to online businesses. There seems to be the thought that the new block editor will ruin WordPress as a CMS because we are no longer dealing with structured data. I don't think this is the case at all, blocks will bring even more structure than currently exists, hopefully after reading this you will be excited to make the leap to Gutenberg. The tricky part is going to be the transition.

Making the leap to Gutenberg

The new block editor brings a couple major changes to the world of WordPress development. The block API that powers it, seeks to consolidate many elements of WordPress. The editor portion, is a relatively large React/Redux application powered by JavaScript. WordPress development has largely been fragmented across many APIs and I think the new block API, once it is fully fleshed out, will help bring about a better set of standards, and allow developers to create more engaging experiences in less time. You can already ship fast with WordPress, but once the new block editor is running in full gear, I feel it will greatly accelerate the rate at which people create things with WordPress.

The leap will hopefully not have to be painful thanks to the work being done by the Gutenberg team. Part of the goal is to make sure the transition is as smooth as possible. Support for meta boxes, shortcodes, and other features are already included. The meta box support is also continually being improved upon. It is important to not just force every developer to rewrite all of the work they have done in JavaScript. Instead there will be an indefinite period where the block editor will have near complete backwards compatibility, which is really a tremendous feat that should be praised. So big shout out to Riad Benguella and Andrew Duthie who have really been hauling ass on this project! Give them some love. Speaking of Riad, I highly recommend checking out his post about Gutenberg and meta boxes.

If there is backwards compatibility in place though, what is the big deal with blocks and the block editor, why should I rewrite things as a block? Well, it is honestly not fully apparent why blocks matter. Let's quickly compare the two and hopefully I can pique your interest.

A basic meta box implemented in the classic WordPress way


 * Plugin Name: A classic meta block.
 * Version: 0.1.0
 * Author: Edwin Cromley
 * Author URI:
 * License: GPL3+
 * Description: Random meta box.

add_action( 'add_meta_boxes', 'sample_add_metabox' );
add_action( 'save_post', 'sample_save_metabox', 10, 2 );

 * Adds the meta box.
function sample_add_metabox() {
		__( 'Post Notes', 'textdomain' ),

 * Renders the meta box.
function sample_render_metabox( $post ) {
	// Add nonce for security and authentication.
	wp_nonce_field( 'custom_nonce_action', 'custom_nonce' );

	$notes = get_post_meta( $post->ID, 'notes', true );

	<textarea style="width: 100%; height: 200px;" name="notes">
		<?php echo esc_html( $notes ); ?>

 * The code below will not run because my host blocks writing
 * super globals in anyways shape or form. So pretend $POST is
 * the actual superglobal.

 * Handles saving the meta box.
 * @param int     $post_id Post ID.
 * @param WP_Post $post    Post object.
 * @return null
function sample_save_metabox( $post_id, $post ) {
	// Add nonce for security and authentication.
	$nonce_name   = isset( $POST['custom_nonce'] ) ? $POST['custom_nonce'] : '';
	$nonce_action = 'custom_nonce_action';

	// Check if nonce is set.
	if ( ! isset( $nonce_name ) ) {

	// Check if nonce is valid.
	if ( ! wp_verify_nonce( $nonce_name, $nonce_action ) ) {

	// Check if user has permissions to save data.
	if ( ! current_user_can( 'edit_post', $post_id ) ) {

	// Check if not an autosave.
	if ( wp_is_post_autosave( $post_id ) ) {

	// Check if not a revision.
	if ( wp_is_post_revision( $post_id ) ) {

	if ( ! isset( $POST['notes'] ) ) {

	update_post_meta( $post_id, 'notes', wp_unslash( sanitize_text_field( $POST['notes'] ) ) );

To see the actual code that runs checkout this repo. Pretty straight forward classic WordPress meta box registration. Everything is PHP, we create the view in our render function and when the post is saved we do some validation and update the meta value. This meta box will work just fine inside of the Gutenberg editor as well. Let's look at how we could recreate a meta box as a block in Gutenberg.

Meta block:


 * Plugin Name: Sample Meta Block!
 * Version: 0.2.0
 * Author: Edwin Cromley
 * Author URI:
 * License: GPL3+
 * Description: A sample meta block to illustrate how easy using Gutenberg is.

 * Enqueue block assets.
function meta_block_enqueue_block_editor_assets() {
    // Enqueue JS that registers a block.
        plugins_url( 'meta-block.js', __FILE__ ),
        // Here we declare our dependencies for creating the block.
        array( 'wp-blocks', 'wp-element', 'wp-components' )

add_action( 'enqueue_block_editor_assets', 'meta_block_enqueue_block_editor_assets' );

 * The authentication callback for our secrent notes meta key.
 * @param boolean $allowed Whether the user can add the post meta. Default false.
 * @param string $meta_key The meta key.
 * @param int $post_id Post ID.
 * @param int $user_id User ID.
 * @param string $cap Capability name.
 * @param array $caps User capabilities.
 * @return boolean Whether the user has permission or not to
function meta_block_secret_notes_auth_callback( $allowed, $meta_key, $post_id, $user_id, $cap, $caps ) {
    if ( current_user_can( 'edit_post', $post_id ) ) {
        return true;

    return false;

 * Register meta field for the rest API.
function meta_block_init() {
    // Register a post meta
    register_meta( 'post', 'notes', array(
        'show_in_rest'  => true,
        'single'        => true,
        'auth_callback' => 'meta_block_secret_notes_auth_callback',
    ) );

add_action( 'init', 'meta_block_init' );

 * Filters out the notes meta field from rest response for unauthenticated users.
 * @param WP_REST_Response $response The response object.
 * @param WP_Post          $post     Post object.
 * @param WP_REST_Request  $request  Request object.
 * @return WP_REST_Response The modified rest response.
function meta_block_make_secret_notes_secret( $response, $post, $request ) {
    $data = $response->get_data();

    if ( isset( $data['meta']['notes'] ) && ! current_user_can( 'edit_post', $post->ID ) ) {
        unset( $data['meta']['notes'] );
        $response->set_data( $data );

    return $response;

add_filter( 'rest_prepare_post', 'meta_block_make_secret_notes_secret', 10, 3 );

 * Register the block template for the post post type.
 * @param array  $args      Associative array of data used during registration.
 * @param string $post_type The current post type being registered.
 * @return array Associative array of data used during registration.
function meta_block_change_post_block_template( $args, $post_type ) {
    if ( $post_type === 'post' ) {
        // Create a template of our is great block.
        $secret_notes_block = array(
                'template_lock' => 'all',

        // Check if template exists and if not add template.
        if ( ! isset( $args['template'] ) || ! is_array( $args['template'] ) ) {
            $args['template'] = array();

        array_unshift( $args['template'], $secret_notes_block );

    return $args;

add_filter( 'register_post_type_args', 'meta_block_change_post_block_template', 10, 2 );


( function( blocks, element, components ) {
    var el       = element.createElement,
        Editable = blocks.Editable;

    blocks.registerBlockType( 'sample/secret-notes', {
        title: 'Secret Notes',
        category: 'common',
        isPrivate: true,

         * Declare the attributes involved.
         * We declare the notes attribute and one of its properties is a
         * meta key, which will be the corresponding meta key we save on the
         * post meta db.
        attributes: {
            notes: {
                type: 'string',
                source: 'meta',
                meta: 'notes'

        edit: function( props ) {
            var notes = props.attributes.notes;

            function setSecretNotes( notes ) {
                console.log( notes[0] );
                 * This is a tad bit hacky as the value passed in by the
                 * Editable component will be an array of values. In this case,
                 * it will always be an array of one string, which is the value
                 * we want.
                props.setAttributes( { notes: notes[0] } );

            return el(
                    key: 'secret-notes',
                    el( 'h3', {}, 'Secret Notes:' ),
                     * Set the value to the current value being auto loaded in.
                     * Set the onChange handler to set our new attributes, this
                     * will auto save our meta values.
                    el( Editable, { onChange: setSecretNotes, value: notes } )

        save: function() {
             * The save function will represent what is saved into the post's
             * post content, since we are not adding anything to the post
             * content
            return null;
    } );
} )(

If you want to check out the code go to this repository. These are about the same lines of code, and they honestly are not much different. We define how the data should be saved and how it should be rendered in both cases. Different API, same result. So why go through all of the trouble to reimagine meta boxes as blocks?

Benefits of blocks replacing meta boxes

There are a number of benefits of blocks over anything else, however templating, uniformity, and composability are the main benefits.


If you noticed the block template being registered for the post type, this is one of the powers of using blocks instead of the classic method. You can position the meta boxes where they actually need to go. We can provide default values ahead of time as well. When you start to think about the implications for page building and themes it gets very interesting. Being able to structure your content however you want leads to much improved user experiences. The content itself can now be outlined ahead of time, which helps when many content authors are involved and need to adhere to some standard. The template system is not fully fleshed out yet, but when it is, it will be incredibly powerful. Meta boxes fall short in this aspect.


Sometimes meta boxes are not the correct tool for the job and we need to use another one of WordPress's APIs to get the things done. Sometimes the meta boxes I have created will power a shortcode, widget, or custom TinyMCE thing. It always gets awkward though because the experience is so disjointed.

For instance, I do a lot of eLearning projects and often a link to assignments, modules, or the current week's todo items need to be embedded in the content. These are being powered by data somewhere else often controlled by a meta box. I can't just hard code these pieces into the theme templates though, as the instructors want to have control over where these elements are placed. Meta boxes only get you part of the way to where you need to go. Then depending on the case, a TinyMCE button is created and there is a unfulfilling user experience getting this to work. If the author needs to update the list of todos, they need to find the meta box for it somewhere on another page. If they want to change the list of todos for that specific page, they most likely will need to create an entirely new list of todos. It gets tedious quickly.

Now that I am running these systems on Gutenberg, it is effortless for instructors to be onboarded and get up to speed. The block API brings us uniformity, which allows the meta box that is powering something to also be embeddable in the content, or not. It's up to us and there is incredibly flexibility. The uniformity of the experience also makes it easier for the people actually using the editor, because once they have learned how to insert, place, and update the block, they have learned it for everything else. There is no need to go to different pages, and do all sorts of weird workflows. Since blocks will unify meta boxes, content, custom TinyMCE, widgets, shortcodes, and whatever else into one thing, a new property will also arise; composability.


The new block editor does not quite fully deliver on composability yet, but it's getting there. Composability allows us to create something new out of other elements. A web page is basically a composition of various HTML tags. The HTML is parsed into DOM nodes and eventually renders onto our screen after a bunch of other stuff happens. We might create an employee profile by combining, a figure element, with an image element, a figcaption, and maybe some p elements for various information bits. If these pieces did not share a uniform interface, we could not create the employee profile in HTML, we would have to do something else. HTML would not be very useful.

WordPress's current content system for better or worse is a fragmented mess. It kind of makes sense, but as a new comer myself, it was weird learning a lot of the concepts and the WordPress way, as it seemed different for almost every piece. Widgets needed to be created one way, and could only be easily embedded in certain places, which needed to be registered beforehand, unless you wanted to hard code the widget somewhere. Confusing.

If I spent all of my effort creating a widget, well I was out of luck when I wanted to put it inside my content. Instead, I needed to then create a shortcode. If I wanted to do the same exact thing, but slightly different, I would need a new shortcode. I also wanted a widget that did the new thing as well, so I had to create another widget. If I wanted to use the new widget functionality inside the old shortcode it leads to a gigantic mess. The level of reusability is limited, and as a developer we really only have an illusion of reusability when working in WordPress.

Imagine if every time you wrote HTML, you had to keep each element as its own. For instance:

<p>Here is some HTML. Now I </p><a href="">have a link</a><p>inside of the same text.</p>

No tag could ever be a part of another. div and its many incarnations would be unusable. We would be limited to linear ordering of basic elements, slabbing one piece after the other. If we wanted to do something complex, it would need to meticulously be strung together. Nothing could ever be grouped together or composed in a natural way. If we wanted to move a piece we would have to move everything with it. We don't work this way with HTML, so why do we accept it for how we work in WordPress. Again, imagine never using div or even conceiving what div is, that is the world we are working in. Widgets can not be used with shortcodes, or TinyMCE, and vice versa, without a lot of extra work. It is hard to fully see how limited we are by WordPress, because it is great, but when all of the pieces of content can become more easily interchangeable with each other, we will see new experiences emerge.

With the concept of composability, an image slider could potentially also be used to create any kind of slider. It could even be fashioned into a PowerPoint of sorts. The text and images, would be their own unique piece, that fit inside of a slide, and each slide inside of the slide show. Each slide could be powered by a different set of data providing a unique experience for each person. The web browser is already a PowerPoint of sorts that we don't even take into account because the fluidity between each frame is abrupt and we don't fully even know how to even effectively use the medium of the web or computers yet, at least I don't.

The block editor will make WordPress an unparalleled CMS. This is just part one of reimagining meta boxes as blocks, and I hope to show you some of the cool things I have been working on, and get you excited about the future of WordPress! The upcoming articles will be more code oriented and go over how to actually think in blocks and how to actually write the JavaScript and PHP that powers them. If you are interested by the Gutenberg editor, make sure to try it out or check in on the GitHub repository.

WordPress 2018: Growth

WordPress is growing. Growing is good. As WordPress becomes more ubiquitous, respected, cherished, we will all benefit, as long as we do not become complacent in light of our success and we continue to democratize publishing for the world. With the strength of WordPress, the software and the community, it is kind of puzzling that WordPress is not really in the cultural zeitgeist (maybe that is a good thing at the moment).

My family is all about Instagram, I don't use it personally, but they are really into it. Most people know about Instagram, Facebook, Twitter, but not many in my town seem to know about WordPress. WordPress is a much more valuable tool than Instagram, Facebook, Twitter, but it remains hidden in some ways. Many people I talk to are also familiar with Squarespace, Wix and Shopify; just not WordPress. 29.2% of the internet unknown to most. There is tremendous opportunity here, but how do we get the word out?

I read a comment on WP Tavern recently, that said something to the effect of: if you decide to use WordPress, you must also labor over maintaining and publicizing it. This is not true. No one expects anybody to help push the platform forward. The comment was made facetiously, or at least that was my interpretation, but from my experience, I can say the more I put into WordPress the more I get back.

Why? Well it's simple. WordPress the software, not the name, is mine. It is also yours, but it belongs to no one and somehow everyone. It's a weird concept that I still struggle to fully understand, but when you improve WordPress, you will benefit from that improvement.

It is easy to see products like and feel as though they benefit more from WordPress than everyone else, and for some reason this year I have noticed a lot of unwarranted resentment towards Automattic. I am new to the space, so I do not know the full history, but it is really hard for me to see things like as a detriment or vampiric presence to WordPress, quite the contrary in my opinion. Yes, I understand the naming thing between .org and .com. The situation is confusing, but most things in life are pretty confusing. I could easily imagine another scenario where was named XYZOMG. "XYZOMG is basically WordPress, why the fancy name? You aren't promoting your core product! Why should we work on WordPress, when Automattic doesn't even promote it?" This is purely hypothetical, and I don't want to mischaracterize people's opinion, but it often feels like a "Haters are Gonna Hate" scenario. At the end of the day it is just a name. WordPress is just a name. What it embodies is more significant: the powerful software, the passionate community, and the mission of bringing digital publishing to the world.

Although we do not own the name WordPress, we do own WordPress, and when we promote, maintain, and change WordPress, we inevitably change our own personal world too. I very firmly believe that from what I have put into WordPress, I have been given back so much more, and I know I am not the only one. So when I feel that WordPress does not have the recognition it deserves, I am not afraid to try and promote it further, because I believe it will benefit my family, and many others somewhere down the road. I won't feel as though I am cheated out of my time.

I am just a small voice, but collectively we really could help WordPress grow to do more amazing things than it already has. I have been able to help my clients make tens of millions of dollars this year alone, and have been blessed for my efforts. WordPress has helped so many gain economic freedom in a way that I am not sure many other things in this world have done. WordPress is a mission worth hitching your wagon onto. There is a lot work to be done, and a vast amount of opportunity ahead.

Growth Ideas

Calls to action

I really liked Aaron Jorbin's idea of the #GutenbergChallenge. It was a decentralized, yet coordinated way to promote and provide feedback for the new editor. It was a call for people to answer, rather than a post from Make, Post Status, WP Tavern informing us what is happening.

Running some sort of community driven promotional campaign seems like a cool idea that we could potentially leverage to have a more concentrated effort in promoting WordPress itself rather than a small aspect like the editor. I am not sure how successful the #GutenbergChallenge was or how we can even measure success of ventures like this, but it might be interesting to explore how to optimize these challenges, and get the most benefit out of them. I think overall the challenge helped start tipping opinion towards a more positive perception of Gutenberg, which was initially overwhelmingly negative.

The active engagement from the #GutenbergChallenge is the best part. If you participate, you use the new editor, and get to share your thoughts in a clearly written manner. Participating in comment sections, or on GitHub is great, but comments are rarely a good place to fully flesh out your ideas, and they can often degenerate into mixed messages and misunderstandings. So rather than a central post generating discussion via comments, a call to action creates commentary among a diverse collection of experience. The main hurdles to making this effective are collection and curation.

Story Platforms

HeroPress is another great idea. The essays really convey how WordPress has personally impacted the author's life. It covers stories from over the whole globe. The Hallway Chats are also another interesting addition to WordPress focused content. If you haven't checked The Hallway Chats out, they host conversations featuring someone from the WordPress ecosystem.

I like how HeroPress and Hallway Chats showcase individuals rather than organizations and they really add a great personal touch. The individuals may promote the organizations they are associated with, but it is really about the person and how their story has crossed paths with WordPress. It really puts into perspective how all of these people collectively create what WordPress is.

This was about growth though?

Right. Growth. I think there is a lot of room for growth in the WordPress space, especially when we consider trying to make the platform easier to use, and more friendly for new comers ( and current users ). A more difficult prospect is making WordPress more valuable in everyday life. I know many people who run a business that simply do not need a website, or a web presence. Even if they did, they would have to hobble through the nonintuitive portions WP Admin, themes, and plugins. However, almost everyone I know uses some form of messaging, or some form of social interaction via the internet. I wonder if there is space for WordPress to creep into that realm. It kind of is there, but it kind of isn't.

The new block editor will vastly improve the publishing process, and future iterations on that concept will make digital publishing exceptionally powerful and easy, but what about the distribution and discovery mechanisms we have in place for our content? For the most part we are at the whims of the Googles, Facebooks, and Amazons of the world. Don't get me wrong I think all of these companies do groundbreaking work, I just wonder if there is something better that could be created.

With the advent of blockchain, I think there is room to open things up a bit more, and start creating more meaningful connections. I have no idea where blockchain is going to go, nor do I fully understand it, but it seems very interesting, and this year I am going to start a project that will be a network of sorts where people can share their work and ideas with each other over a new distribution mechanism. I have no idea whether it is a good idea, it is probably terrible, but it has captivated my interest.

If the new Gutenberg editor radically improves the digital publishing world, which I hope it does, does it matter if the content we produce has to be distributed through mechanisms that we have minimal control over? The peer to peer nature of blockchain seems very appealing, but I don't know if it will be a good thing or not. I honestly don't know enough about it yet, or its ramifications, but the project will be an interesting project to work on, and hopefully it will be something positive. At the very least, hopefully it inspires similar ideas in others, because I think if we truly want WordPress to grow, we need to empower people to better connect with everyone else.

Social networks have not been figured out yet, or to my knowledge they have not. One of the largest problems in my opinion is something that I believe occurs rather naturally; echo chambers. My own social media interactions are purely web development oriented, with the exception of the incredible C. T. Fletcher. I could find new things, but there is an odd comfort in keeping to what you know, or where you think you belong. I naturally have created my own web development echo chamber without realizing it. One potential solution that I see, that could be very interesting, is to override our natural tendencies, and instead force random connections into our network, even if only temporary, reflecting more of how the real world works. Typically networks encourage you to go after what is already familiar and be highly selective, but I think there is opportunity to shake that up and create more random connections like you would pre-internet. Adding a little chaotic spice to the mix, I think could allow people of different backgrounds to meet connect with each other, even if it is uncomfortable.

Connections as a driver for Growth.

If we really want the ubiquity of WordPress, I think starting to brainstorm on how we can better connect with each other, and how we can bring more value to people's everyday activities will become a crucial piece to the WordPress Growth puzzle.

Gutenberg: A Change of Vue?

If you haven't heard the news already, Matt has decided to move Gutenberg, the new WordPress editor, off of React, over people's reaction to the recent response from Facebook's legal team.

Some parts of Facebook's response seem odd, but I also have no idea what the legal landscape is like for one of the largest most publicly visible companies in the world. I don't think there is malicious intent in React's licensing, but at the same time I think it is a wise decision from Matt to ease growing tension in the WordPress space over the use of React in Gutenberg. Any company, organization, or project that feels wary of taking on the legal uncertainty surrounding React, is a project that would no longer be able to use WordPress; an unfortunate price to pay for using React.

What's next?

It is not clear what will be chosen as the replacement for React, and in many ways I wish React did not need to be replaced, because it is awesome. Vue seems to be the chant ringing through all channels of the WordPress community. I have been meaning to learn Vue. The recent news was the final push. After I finished up my tasks Friday, I jumped straight into Vue. It took me very little time to get Vue running, with Vuex to boot, to create a todo list app. It took about two hours. Vue is great! Magic! I can definitely see why people love it. In many ways Vue is solving the same problems React solves. There are many similarities between Vue and React, but also many differences, and many misconceptions the WordPress community seems to have about that relation.

I did not fully dive into Vue yet, by trying out routing etc., but through a cursory glance, Vue Router seems A LOT better than React Router. However it is important to note that with the way React works, React Router is not a good choice, and instead I would recommend Redux First Router, if you are using Redux. If you are purely using React, godspeed. There are many things I haven't tried out yet in Vue, but I think I have a pretty good grasp of it, and here is my take on its differences with React, and how that could potentially impact Gutenberg and the WordPress ecosystem.

Potential of Vue

Claims about Vue from the WordPress space

1. Vue is easier to learn.

One of the reasons I think Vue is regarded as "easy to learn" is that you can write out UIs with a template syntax similar to HTML and make use of "directives" to accomplish things like conditional rendering, rendering lists, and much more without touching any JavaScript. That is definitely very cool, and could be useful in the WordPress space to help developers ease into front end development using JavaScript.

The template language for Vue is really cool. It is all valid HTML, so you can create a Vue template as HTML, then simply instantiate Vue on the root element. This is really cool and lets you get up and running instantly. Most template languages however, become additional overhead on top of learning a core language, and in the long run are probably not very useful.

All of the templates you create in Vue are transformed into "render functions". This is what I ended up using in my todo list app, as this approach was more familiar to me. From what I can tell in Vue, there are five main ways to create your Vues: html files using vue templates, template strings, .vue files, x-templates, and render functions. All of these break down to just render functions, and you could even write your own template language to compile to these render functions, if you really wanted. Custom compiling is how Vue offers JSX support, same with React.

Here is a quick look at the Vue Syntax vs. Custom Rendering functions.

Vue template syntax, using ES6 template strings: ( the ` ` )

Vue.component( 'my-list', {
  template: `
    <ul v-if="items.length">
      <li v-for="item in items">{{ }}</li>
    <p v-else>No items found.</p>
  props: [ items ]
} )

and now a custom render function:

Vue.component( 'my-list', {
  render: function ( h ) {
    if ( this.items.length ) {
      return h( 'ul', function ( item ) {
        return h( 'li', )
      } ) )
    } else {
      return h( 'p', 'No items found.' )
  props: [ items ]
} )

The Vue template syntax is more concise, but you can only use a limited set of JavaScript in it. To get flexibility out of the template system, directives like v-if and v-for are used. In the render functions approach, much like React, you can use whatever JavaScript you want. Using JSX in Vue, like React, may provide a more condensed "easy" to read template syntax, that won't limit your use of JavaScript.

Once you start using render functions in Vue you might as well be using React. They are very similar at this point, to the point where it is almost staggering. So why would Vue be "easier to learn" at this point if React was already deemed more difficult. I think the argument is that you get a nice ramp up in Vue, whereas React expects you to make the leap from HTML templating right into JSX, and build processes galore.

The reality though is that you will eventually hit the same wall you would have hit while learning React, so it is hard to argue it is truly "easier" to learn it, because there is honestly much, much more to learn in Vue. In fact, because Vue does so much more than React, I would argue Vue is more difficult to learn, because you have so many more options on how you want to configure your use of Vue. React: you learn once and use anywhere ( their slogan ). Vue: learn multiple ways to use Vue and use some of those methods in different contexts for different situations.

2. Vue is simpler than React

I could not disagree more with this after using Vue. Vue's API surface is much larger in comparison to React, but this is not necessarily apparent. React takes a purist approach that only focuses on doing one thing, and doing it really well. React's primary objective is to keep your UI in sync with your data. It accomplishes this with minimal headaches, by using a declarative API, and component based structure. You do not need to worry or care about anything else in React aside from, providing data. Vue takes care of UI sync and then some.

Out of the box Vue offers a lot of really useful tools in addition to the more bare bones approach of React. Vue supports different templating approaches, animations, component slots, and is more loosely based on the upcoming W3C web components spec.

There are some very subtle differences in the Vue API approach vs the approach taken in React. The main export object Vue, is actually a stateful object, whose state ultimately affects the rendering functionality. Where as the approach taken in React, the main export React serves as more of a namespace for all of React's utilities. React's internal state is handled inside a black box we cannot touch, which is a good thing.

Typical Vue:

// Some HTML
<hello-wordpress id="app" />

// Some JS
Vue.component( 'hello-wordpress', {
  template: '<p>Hello WordPress!</p>'
} )

new Vue( {
  el: '#app'
} )

Typical React:

// This would usually be JSX, but not gonna use it.
const helloWordPress = () => React.createElement( 'p', {}, 'Hello WordPress!' )

ReactDOM.render( document.getElementById( 'app' ), helloWordPress )

Vue, once again, is slightly more concise. With the additional conciseness comes additional hidden complexity. Any reference to the root Vue instance could be used to override or goof up whatever Vue is doing. There is even an API used to interact with the main Vue instance after instantiation. In a project like WordPress where people often do whatever they want and write very yolo code ( me ). This unbounded extensibility could be a bad thing. React has only one way to extend itself; through creating and composing more components, which is simply how you use React.

In Vue you can create custom directives, components, mixins, many other customizations, all of these changes will need to happen before Vue instantiates, causing a time dependency. React, at the beginning, did similar things but the React team moved away from mixins etc. and instead started to reduce their API surface, taking a minimalist library approach.

3. React is potentially more flexible and powerful than Vue.

This is something I assumed would be the case. Flexible and powerful have ill-defined meanings in coding, but after taking Vue for a spin, I would have to argue that it is more powerful and flexible than React. However, the ways in which Vue is more flexible, are not necessarily always a good thing, and the ways in which React is more flexible, in the long run are most likely a good thing.

As said before, there is one way to do things in React, and many in Vue. On the surface this seems to be an aspect in favor of Vue. However, what happens if we need to switch off of Vue for some unforeseen reason in the future? Well it will certainly be much more difficult than the switch off of React is going to be. The fragmentation in the way Vue can be used will make an eventual departure away from it very difficult, and even while it is adopted there will probably be multitudes of conflict prone situations in an ecosystem like WordPress. There will certainly be much more technical debt accumulated by using Vue compared to React or Preact, but maybe that is not totally a bad thing.

If a strong commitment was made to Vue, maybe its additional feature set would be ultimately more useful than whatever technical conflicts could potentially arise out of the use of Vue. I got Vue up and running no problem, and someone who is new to the JS world could really do a lot with x-templates in a short amount of time. Vue and React, in my experience, from a purely productivity centric perspective, are major steps up from using jQuery and Backbone, when creating non trivial interfaces. Some of the additional syntax Vue uses in its template language make it really, really quick to get something up and running.

Is Vue the right fit for Gutenberg?

Not that my opinion matters or has much weight to it; I would have to say no. That is not a hard no by any means, and if Vue is chosen I will be happy. Vue is awesome and has many benefits, but for what Gutenberg is trying to achieve, I am not sure Vue is the ideal choice. I really have no idea what the ideal choice is to be honest, so, to wrap up, I will outline what is truly good about Vue, and what is not.

Why Vue could be the best fit

  1. It seems to have a lot of support from people in the WordPress community.
  2. It honestly does have a shorter learning curve for getting started. This is not something to be discarded, as I originally had thought.
  3. Productivity in Vue is great, but I haven't used it enough to know what walls are lurking in more complex uses of it.
  4. The Vue community is not currently larger than React's, but it most likely is larger than Preact's, and most of the other contenders'.

Why Vue might not be the best fit

  1. The vast ways in which Vue can be used, could further fragment WordPress.
  2. Although the initial learning curve is tame, the more advanced uses of Vue appear more complex than using React. There is also a considerable amount more to learn in Vue than React.
  3. Due to the nature of Vue's architecture, integrating with other libraries like TinyMCE ( a fundamental aspect of Gutenberg ), might be more difficult.
  4. Extensibility will probably be more challenging to implement in Vue as it further abstracts away from the core JavaScript language.
  5. Vue's divergence from the pure library approach, makes it a significant amount of extra technical debt to bring into Gutenberg.

That's five to four, Preact clearly wins. Just kidding. I do think Preact would be the most sensible choice though; speaking from a technical perspective. It is important to understand that the library chosen will not impact plugin/theme developers nearly as much as those who are contributing to Gutenberg/WordPress Core.

There are many efforts underway to allow custom blocks for Gutenberg to be written in just about any kind of JS you like. The choice of the library will have implications for WordPress developers though, because it will definitely make sense to use the same library, but it is important to understand that you are not being forced to use whatever library is chosen.


Yeah, this was a long post. Vue is really cool, I am enjoying it a lot, but ultimately I do not believe it is the right fit for Gutenberg, because despite what people assume, it carries more technical debt than a library similar to React does. The funniest part of all this debate is that realistically all of the options are quite good and phenomenal in their own way, so it is really hard to be certain that one option is better than the other.

I hope you stay tuned for more Gutenberg related content. I have some really awesome stuff that I will have ready soonish. I think Gutenberg will open up lots of opportunities beyond what WordPress, or anything for that matter, has really done before. Follow my blog if you want to keep up with Gutenberg related content, and see where the future might lead! I hope the original negativity that clouded this project will begin to fade and people will rally behind this project and support the Gutenberg team, who have been doing truly phenomenal work!

Gutenberg: WordPress needs You!

I have had the fortune of porting Gutenberg into interesting places lately. I am incredibly excited about the progress being made on it, and think the team involved is doing a stellar job! I really can not wait until this is ready for core, and I think it is a much needed improvement of the current WordPress experience. If you haven't tried it out yet head over to the plugin repository and try it out. It is still in early development, and should not be used in production. You may notice a lot of negative reviews and that is what I am going to talk about for a bit.

Negativity around Gutenberg

The project has received a fair amount of negativity honestly. Most of this is stemming from uncertainty around the project, and its implications for WordPress as a whole. The project is far off from a version 1 completion, or core readiness, but it is not as far as some might think.

The negativity in most instances is not necessary, and could easily be framed in more constructive viewpoints, but that should not be expected either. One of the biggest hangups around the project is meta boxes. Gutenberg does not support meta boxes yet, nor does it offer any support really for custom post types. Like was mentioned above, it cannot be stressed enough, Gutenberg is still in early development phase, and is rapidly improving week to week.

Meta Boxes, CPTs. Woe is me!

I see complaints about meta boxes, and custom post types, pretty much everywhere I look for information and critique regarding Gutenberg. It would seem like the meta box problem should be a no-brainer and easy to implement in Gutenberg. The reality of it couldn't be further from that. Gutenberg is more of a client side SPA style application compared to the typical server rendered request response approach that is widely used in WordPress. It runs pretty much entirely in JavaScript, where as typical meta boxes run mostly in PHP.

I could go on further explaining the intricacies and could also explain why we should not trash Gutenberg as some suggest, instead I am going to try to focus my efforts more towards showing people what can be done with Gutenberg.

Gutenberg is the future of WordPress

I had my reservations to begin with, but I am thoroughly convinced that Gutenberg is the future of WordPress, and it is going to be a boon to the WordPress ecosystem. Everywhere we look, we see useful ideas on what to do to improve Gutenberg, but not a lot of people are posting about what can be done with Gutenberg.

I am finding that people are having a hard time wrapping their heads around the "block first" concept, and what that means exactly. I am still wrangling with it myself. On the surface it seems pretty simple, and obvious, a lot like LEGO. LEGO are essentially just a modular building block with a set interface or inputs and outputs. When I look at a box of LEGO, I only see the blocks and their various colors, and need some instructions to help build something cool. Some people see them as a sculpting material and create amazing art.

"Yellow," by U.S. Lego artist Nathan Sawaya

LEGO are just an idea though, and have been reused in truly amazing ways. I think the same will happen with WordPress, we are only on the cusp of the new block based approach.

I hope to focus my efforts on trying to create some unique Gutenberg experiences, and share them with WordPress community, in hopes that people will be able to see how they can do the same in their projects. I want to help show off the incredible sides of Gutenberg, rather than be bogged down by its current shortcomings.

Stay tuned!

If Gutenberg and the discussion around it has piqued some of your interest, or even if it has terrified you, follow my blog and hopefully you can get a taste for what is to come in Gutenberg. I was planning on posting things about Gutenberg that could be better, but instead I want to show the world how amazing it already is!

Gutenberg: A new way to WordPress!

The Gutenberg editor is really shaping up to be something great! The standard editor in wp-admin will most likely be replaced by project Gutenberg in the near future, but Gutenberg is much more than a wp-admin editor replacement. I think it is the future of WordPress, and will open up many new opportunities to bloggers, site owners, agencies, and product businesses. WordPress already powers a large portion of the web, and I think project Gutenberg will increase WordPress’ market share. This could be a victory for the open web, when lately, its obsolescence seems inevitable. Let’s look at some cool things you can do with Gutenberg.

Page Builder Style Editing & More

Below you can see this text being added into the page!

Pretty cool. Not too far off from the current WordPress experience. Let's add in something a little more interesting, that a basic WordPress install cannot do.

Adding A Cover Image!

What we did here is we added in a new cover image block from the inserter. This opened up the media library and we selected our image. We then added text and set the image to full width; oila! Here is what it looked like:

This is just one of the many things that can be done in Gutenberg, quickly, and enjoyably. What you are seeing however is not the standard Gutenberg experience. Instead you are seeing a front-end content building experience powered by Gutenberg. If you haven't checked Gutenberg out yet head over to the WordPress plugin repository and try it out! It does have a fair number of negative reviews, but this is a project in its infancy. There are a number of issues to be resolved with project Gutenberg, but it is largely the effort of a small team over a four month period; impressive.

To see the difference between the regular Gutenberg editor and the one you see running here check out the below image:

The font does not match my theme, nor the layout. This is the standard Gutenberg experience, which is great! As much as I love the standard Gutenberg editor, I would much rather live edit my content as it is going to look when I hit Publish. This has been a boon on some recent projects for me, as my clients are now much more easily able to visualize the final result, because they are creating the final version as they go. The block based building in Gutenberg brings more to the table than a nice user experience.

All hail blocks!

The sleek UI, and interface for Gutenberg will eventually become outdated, but I believe that blocks will remain. The "block first" approach being taken in Gutenberg is the most important aspect of the project. Content blocks have the potential to replace shortcodes, meta boxes, widgets, custom post types and unify them into one self contained entity. The Gutenberg editor can eventually even extend to become a theme builder of sorts. The possibilities are limitless, but I have already started building some practical solutions for my clients as blocks.

For one of my projects, I have created a quiz block. You can build out a quiz, with questions all right inside the editor screen, or use it to insert an already created quiz. In the past this would have required many meta boxes, shortcodes, and would be a jarring user experience. Now it is seamless and effortless.

The Future

I don't know what the future holds, and there is definitely a significant amount of tension surrounding this project, but I am rooting for it and going all in on it. How do you feel about Gutenberg?

Gutenberg: The New WordPress Editor Experience

There seems to be some tension in the air over the new Gutenberg editor for WordPress, which is good. I wish there was more attention and dialog on it. If you haven't tried it out yet head over to the plugin repository and download Gutenberg for your WordPress install. Some think it is utter crap, some think it is amazing. There seems to be very little in between. Some do not see the goal posts or incremental movement, and others realize the plan and understand the significance of Gutenberg.

Why does Gutenberg matter?

Platforms like Squarespace and Wix are offering a very compelling user experience for a very small price. They eliminate a lot of the headache involved in managing self-hosted WordPress. No plugin updates, no core updates, no random breakages between conflicting versions of plugins or core; bliss. The design templates for Squarespace are well crafted. In the hands of a professional designer, any Squarespace site could be molded to look fantastic, without touching any code. The same is not necessarily true for WordPress, unless you are using a tool like Beaver Builder.

If things continue on this path, it is not too unreasonable to imagine a large chunk of WordPress' market share to be taken up by these platforms. This would be a loss, as WordPress is open and serves a gigantic ecosystem, where small businesses and large enterprises can thrive. With a closed platform like Squarespace, outside tech services can only provide little to no benefit for each other. What does any of this have to do with Gutenberg?

WordPress needs to innovate to remain relevant and grow. Now is the time to do so as well, while WordPress still dwarfs any other platform. The Gutenberg project will be the driving force for innovation.

The Goal of Gutenberg as I see it

The goal is to "make adding rich content to WordPress simple and enjoyable". Extrapolating that goal leads one to a front end editing experience similar to Wix, or Squarespace and beyond, but the Gutenberg plugin only currently replaces the editor inside of WP-Admin.

Misunderstanding the goal of Gutenberg

A common question I see is, "If you want to compete with Wix or Squarespace, why not make a page builder?" WordPress could, but it would be missing a huge opportunity in unifying its content experience, and in the process would only try imitating Wix or Squarespace not supersede them. I think things are less about competing with a particular platform and instead are more focused around creating a superior product to any platform. By taking the "block first" approach, widgets, shortcodes, custom meta boxes, post content, et al. can become a block, which can then be added to content anywhere, dynamically, using a uniform interface. Once you can see this clearly, I think it is hard to argue that the direction Gutenberg is headed in is not a superior user, and developer experience.

By unifying the content system into individual blocks first, a page builder would become much more trivial to create. It would also open up other possibilities that other platforms do not have, like collaborative editing (similar to Google Docs). So why the focus on the editor first?

If the front end editing experience was made first, well it would pretty much break the current editor, making it unusable, anyways. If you are editing content as blocks on the front end, then go back to editing in the classic WordPress editor, you will most likely break all of the block content you just created on the front end, because it is no longer there for you to edit in wp-admin. Building the editor first in a new "block first" approach is the correct choice, as opposed to trying to build a page builder on top of WordPress.

This all sounds pretty good, maybe this Mullenweg fellow does understand a thing or two about leading a project forward, so why all the hate on Gutenberg?

Innovation, Fear, Uncertainty, Doubt, and Context

New innovation always will bring about a certain amount of Fear Uncertainty and Doubt, which is totally healthy and good. I have many reservations about the Gutenberg project myself, but I think on the whole it will be a giant net benefit to WordPress. The reviews on the plugin repository are extremely polarized, and although the plugin claims to be in beta, it is really, in my opinion, more like alpha software. It is important to understand that the Gutenberg project is not ready for core yet. It's barely even ready to use on your blog and I would not recommend using it, unless you understand the technical side, but it is also not as far off as some people think.

For developers like myself who have invested countless hours building custom metaboxes and custom TinyMCE buttons etc., it can be somewhat disheartening to see that effort seemingly go to the wayside. You need to get over that feeling quickly. That time spent has hopefully served you well up until this point and now it is time to move on to something that I find is a lot better, and your clients will find a lot better.

My own experience

I have recently started converting a lot of the custom meta boxes and custom TinyMCE buttons for a client into blocks and running Gutenberg ( with tweaks ) in production ( yes, I am crazy ). My client is able to do much more than they ever could, and they have a full front end editing experience already, today, which they are thrilled about. Rather than trying to dig my heels in, I am embracing the future direction, because it seems like in the long run, it will be better for me, my clientele, and WordPress.

Backwards Compatibility

Shortcodes, meta boxes, and widgets aren't necessarily going anywhere, but if you want to come along the journey of where WordPress is going, you should start creating blocks and get involved to help shape them. You might find that the previous experience was a pain to work with. Learning new things can be daunting, but I think the direction of Gutenberg is a good path to follow.


This post has been a part of the GutenbergChallenge, which I will be writing about twice ( failed 😉 ) a week now until the end of the year. If you haven't tried out the Gutenberg editor yet check it out, and share your thoughts on it as well.

Falling Short — WP GraphQL

Hi everyone! I set a ridiculous goal of trying to have WP GraphQL be production ready before the new year. I knew it was not attainable but sometimes when you set something ridiculous you can really motivate yourself to complete it. A lot of progress was made on WP GraphQL, but it is still very far off from production readiness. I think by late June 2017, WP GraphQL will actually be ready, given the same level of work being steadily put into it. The holidays were great and were a necessary refresher for heading into the new year. What’s left to finish off WP GraphQL 1.0.0?

Roadmap, where WP GraphQL is at.

Version 0.1.0 will mark the completion of the initial type system.  What is the type system? The type system in GraphQL defines what can be done in GraphQL. In WP GraphQL there needs to be a type system to support posts, comments, pages, menus, plugins, themes, sites, networks etc… Not only does the type system need to support each basic WordPress type, but fields within each type may have a type themselves. For instance any field that is a url is not just a string but a special url type. Laying the foundation of the type system is the bulk of the work that needs to be done. Currently WP GraphQL almost supports every default type of content laid out in WordPress.

WP GraphQL version 0.2.0 will focus on improving the architecture of serving GraphQL requests. Currently the code to serve a GraphQL request is very ad hoc and sloppy. Improving the design of serving a GraphQL request will enable the ability to start improving the extensibility of WP GraphQL.  Version 0.2.0 will also focus on making WP GraphQL Relay compliant. WP GraphQL version 0.3.0 will focus on locking down the API and making it secure, support authentication, and respect the privilege system of WordPress.

What’s Next?

After this is done WP GraphQL will be production ready. At this point it should be determined whether mutation queries (create, update, delete) should be shipped before or after the 1.0.0 release.  The current goal is to provide a read only GraphQL API as that is where GraphQL really shines.  I think the way REST is structured, makes it alot better suited towards updating, deleting, and creating resources. WP GraphQL, in the future, might just wrap its mutation queries around the WP REST API.

I look forward to seeing how WP GraphQL shapes up over this year, and hopefully more people will want to get involved as well! If you would like to learn more about WP GraphQL head over to the GitHub repository and introduce yourself.



WordPress with GraphQL. Finding a good fit.

Hey everyone!

I am super excited about the progress being made on WP GraphQL; a plugin that enables a GraphQL API for your WordPress install. If you haven’t already checked it out, head over to the WP GraphQL GitHub repository, or the WP GraphQL documentation site.  Let me know if you stumble on anything, or have trouble setting the plugin up. DO NOT SET THIS UP ON A PRODUCTION SITE; it is not production ready and exposes all data without any security checks. The plugin is targeted towards developers. If you want to learn more about GraphQL, check out

Why GraphQL for WordPress, isn’t there a REST API?

The WordPress REST API is very good and has made developing engaging experiences with WordPress a lot more tangible. I deeply appreciate all of the blood sweat & tears put into that project, and have learned an immense amount from it. I have the utmost respect for the team leads of the WP REST API and the many contributors. I will still contribute to the WP REST API when I can. The list of good things to say about it could go on for a very long time. However, in working with the WordPress REST API on some of my projects, I found the experience to fall short of the grand vision laid before me.

The promise of being able to create better user experiences, was met with immense technical hurdles, that I took for granted.  Not that any of these problems are not solvable, but the ever impending reality for me is that GraphQL fits WordPress a lot better.  REST focuses on resources, and I believe firmly that WordPress is not just a collection of siloed resources. WordPress to me is more about relationships.  The relationship between a post and its comments. The authors of those comments, and the author of the post. Think about the impact of our words and the relations that WordPress creates between people who are worlds apart.  WordPress is an ever growing web of relationships in all aspects, the community, the codebase, and most importantly the impact WordPress as a product has, and its reach.

No single aspect of WordPress functions independently. These relationships are key to WordPress itself and should be embraced rather than isolated. GraphQL is all about relationships, REST is about resources.

The power of querying with WP GraphQL!

The name GraphQL stems from Graph Theory. On its basic level, Graph Theory just describes relations between different things. It deals with two concepts; nodes and edges. Nodes are the individual entities, and edges are the relationships between entities. Edges can go one direction or both directions. Let’s think about this in WordPress world.

A single post can be considered a node. The post has various properties like content, title, etc. That post also has an author, which is another node. There is a bi-directional edge/relation between the post and the author; the post has a relation to it’s author and the author a relation to that post. WP GraphQL exposes these relationships.

If you want to grab a post’s title, content and the author’s name, you would use the following query:

  post(id: 2) {
    author {

The response would look like this:

  "data": {
    "post": {
      "content": "Wow this is a really cool post I made.",
      "title": "Insert meme here.",
      "author": {
        "name": "Greg Quincy Love"

I like how concise the queries are in GraphQL and how the response matches the request. There is definitely something to be admired in the simplicity of GraphQL syntax.

I can already do that in WordPress. Who cares?

The above example is basic and does not fully expose the possibilities of GraphQL. Let’s look at this query:

  post(id: 10) {
    author {
      avatar(size: 96) {
      posts(first: 3, not_in: [10]) {
        featured_image {
        comments(first: 1) {
          author {
            avatar(size: 48) {
    comments(first: 20) {
      author {
        avatar(size: 48) {

(disclaimer: WP GraphQL does not fully support all of these capabilities, but is suprisingly close)

Pretty neat right?  This would grab a post with an id of 10. The response will include the title and content for that post. Here is where things get intersting. We will also grab the author of that post, their name, their avatar, and their 3 most recent posts! The three most recent posts of the original post’s author will contain the title, the excerpt, featured image (not yet supported) and the most recent comment. The most recent comment on these recent posts will feature the content, and the author of that comments name and avatar; at a smaller size!

Woah, think about what this opens up for UI/UX design, imagine having a clickable accordion/tab that will toggle featuring the author’s three most recent posts and some nice information about them. GraphQL will liberate our defining of relations from the conventional way.

There was more to that query above, it also fetched the first 20 comments on the original post, each displaying the content date, along with the author’s name and small avatar. Anybody who has designed a UI/UX knows the pain of not having the data you want, and the burden of getting too much data. GraphQL solves both of these issues at once. You get only the data you want and it will follow the relationships you define. WordPress is pretty post centric at this time, what if we could make WordPress more people centric? GraphQL would make this more easily doable.

WordPress multisite installs could become even more network oriented, as GraphQL could become the glue binding each site. Projects like BuddyPress would make an exceptionally great fit for WP GraphQL as well. Social interactions, in something like BuddyPress, can be viewed as relationships between two entities. This is where something very important needs to be considered.

With great power comes great responsibility.

The age old saying fits this perfectly. GraphQL has the ability to expose relations that we currently cannot easily handle or grasp. Anybody who is in tech should understand that each node and edge is much more than data. Each node could be a story, a joke, a human being; each edge a relation, a secret, a friendship. We are here to protect and make the web better. Privacy and taking a sensative approach towards it, will be paramount in the success of WP GraphQL as a project. If you are interested in helping out, head over to the WP GraphQL GitHub repo and introduce yourself!  What are your thoughts!?