Add the block data api plugin

[ingeniumed]

Description

The purpose of this PR is to add the block data api plugin into the bundle. Since the block data api plugin has a rest and graphQL endpoint, this will now enable both of the APIs with this bundle.

The eventual goal would be to replace the bespoke the WPGraphQL Content blocks plugin, in favour of this plugin. The first step is add the plugin in, and then slowly add in any missing features so we can eventually deprecate it.

To review this PR, the changes that have been made:

• Added the plugin using git subtree:

git remote add -f block-data-api-remote git@github.com:Automattic/vip-block-data-api.git
git subtree add --prefix lib/vip-block-data-api block-data-api-remote trunk --squash

The following is how you update it:

git fetch block-data-api-remote trunk
git subtree pull --prefix lib/vip-block-data-api block-data-api-remote trunk --squash

• Added the block data api as a setting that can be turned on and off within the settings.php
• Required the plugin if its enabled within the vip-decoupled.php
• Updated the README with this new plugin with potential deprecation plans.

Steps to Test

• Load up the dev-env or wp-env and enable this plugin
• Ensure the graphQL endpoint can be hit, using the query:

query AllPosts {
  posts {
    nodes {
      id
      title
      contentBlocks {
        blocks {
          attributes {
            name
            value
          }
          name
          innerHTML
        }
        isGutenberg
        version
      }
    }
  }
}

• Ensure the wp-json/vip-block-data-api/v1/posts/1/blocks rest endpoint can be hit

[alecgeatches]

Tested this locally, works great! Used this query to test the Block data WPGraphQL integration as well:

query AllPosts {
  posts {
    nodes {
      id
      title
      blocksData {
        blocks {
          name
          attributes {
            name
            value
          }
        }
      }
    }
  }
}

After setting permalinks, the REST API at wp-json/vip-block-data-api/v1/posts/1/blocks worked properly too. Looks good to me!

[chriszarate]

Is there a chance the Block Data API also lands in mu-plugins? If so, and you want to prefer the mu-plugins version, you might want to proactively add some logic here to determine which version "wins."

[alecgeatches]

Good question! We have that logic built-in. In the plugin itself we verify that we're not double-loading. On the mu-plugins integration side, we also have logic to prefer the customer version of the plugin, if installed.

I spent some time just now testing what happens if the Block Data API plugin is installed, as well as the bundle with the Block Data API feature enabled, as well as the mu-plugins version. The priority goes:

1. Plugin version first
2. Bundle version second, if the plugin is disabled (second alphabetically)
3. The mu-plugins version of the plugin, if everything else is disabled

This fits our original intent to prefer customer code first, and works fine between the bundle and normal Block Data API plugin as well. Everything is working as designed.

[chriszarate]

You might want to put both options next to each other and add a "Which should I choose?" section. That section can even just say, "we already recommend the block data API but here are some caveats"

[ingeniumed]

Great point, thanks for pointing that out. I've added this, and added what I think would be helpful in making this decision. Lemme know what you think.

[alecgeatches]

Note here - we just merged a change into the Block Data API and released version 1.2.0. I've merged those changes into this PR.

[alecgeatches]

Approving for the merge. Thank you @ingeniumed for the integration and documentation!