Added block and content resolver for CoreFootnotes

[colinmurphy]

Summary

This PR adds a content block for CoreFootnotes and also adds a post content resolver to load the post meta data for footnotes and also parse the HTML.

Example

Query

fragment CoreFootnotesBlockFragment on CoreFootnotes {
  innerBlocks {
    renderedHtml
  }
}

query Post($id: ID!) {
  post(id: $id, idType: DATABASE_ID) {
    databaseId
    editorBlocks {
      ...CoreFootnotesBlockFragment
    }
  }
}

Example Response

{
  "data": {
    "post": {
      "databaseId": 16,
      "editorBlocks": [
        {},
        {
          "innerBlocks": [
            {
              "renderedHtml": "<ol class=\"footnotes\"><li id=\"d4051e5e-1547-49ff-ab6d-bec1caa6aabc\"><a href=\"https://wpengine.com/about-us/\">https://wpengine.com/about-us/</a></li><li id=\"2e79de23-68a8-42eb-87ab-1f2467a21752\"><a href=\"https://wpengine.com/support/\">https://wpengine.com/support/</a></li></ol>"
            }
          ]
        },
        {}
      ]
    }
  },
  "extensions": {
    "debug": [],
    "queryAnalyzer": {
      "keys": "262c7066ca9adad309e85fa6e74f44cbba09adbaf24eba42ac58b418899a687f graphql:Query operation:Post cG9zdDoxNg==",
      "keysLength": 106,
      "keysCount": 4,
      "skippedKeys": "",
      "skippedKeysSize": 0,
      "skippedKeysCount": 0,
      "skippedTypes": []
    }
  }
}

[changeset-bot]

🦋 Changeset detected

Latest commit: d1ce72c

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@wpengine/wp-graphql-content-blocks	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[justlevine]

But core/footnotes doesn't have inner blocks...
https://github.com/WordPress/gutenberg/blob/be5ce8aefa49b394a57aa540d9c9b091510ed8f1/packages/block-library/src/footnotes/index.php#L19
https://github.com/WordPress/gutenberg/blob/be5ce8aefa49b394a57aa540d9c9b091510ed8f1/packages/block-library/src/footnotes/edit.js#L49 ...

[theodesp]

I was actually able to render the footnotes HTML without checking out this branch. This is on the main branch:

{
  posts {
    nodes {
      editorBlocks {
        ...on CoreFootnotes {
          type
          renderedHtml
        }
      }
    }
  }
}

{
  "data": {
    "posts": {
      "nodes": [
        {
          "editorBlocks": [
            {
              "type": "CoreFootnotes",
              "renderedHtml": "<ol class=\"wp-block-footnotes\"><li id=\"183aa597-72fa-49da-8ea2-73aff3387d88\">Another footnote <a href=\"#183aa597-72fa-49da-8ea2-73aff3387d88-link\" aria-label=\"Jump to footnote reference 1\">↩︎</a></li><li id=\"d6700ca9-32d4-4f18-ad7d-0f6b00d99137\">footnote 1 <a href=\"#d6700ca9-32d4-4f18-ad7d-0f6b00d99137-link\" aria-label=\"Jump to footnote reference 2\">↩︎</a></li></ol>"
            },

          ]
        },
       }
}

Do we really need to expose the individual footnote items from this list? I'm not sure.

[colinmurphy]

@theodesp @justlevine I think if we can get the data (as per @theodesp GQL query) then is there any need for this? I don't think we should add any new blocks/logic if we can already get the data? The other thing is footnotes are directly correlated with content so not sure if adding a new block for footnotes is needed on reflection.

[justlevine]

agree there's no need, and personally don't see the value, especially versus the cost of maintaining this (and any other manual deviation that we cant auto-infer from WP core in our schema generation)

Unit tests are always nice to alert us if renderedHtml or something else changes in the future, but I don't see that in this diff anyway.

[colinmurphy]

Thanks @justlevine

I don't see any point either if we can just query the data. I will close this PR out. Thanks for the really good feedback aswell.

[colinmurphy]

Closing as not needed.