Gatsby-source-wordpress-experimental: Custom hierarchical taxonomy: only first level is returned with no way to get child nodes

Created on 3 Sep 2020 · 6Comments · Source: gatsbyjs/gatsby-source-wordpress-experimental

I'm using custom taxonomy with hierarchical set as true. There seems no way to get the child nodes data.

It appears parent: nullin the generated query is the culprit for not getting the categories in a flat list, but even wpChildren returns an empty array.

query NODE_LIST_QUERY($first: Int!, $after: String) {
  faqsCategory(first: $first, after: $after, where: { parent: null }) {
    nodes {
      ancestors(first: 100) {
        nodes {
          id
        }
      }
      wpChildren: children(first: 100) {
        nodes {
          id
        }
      }
      count
      databaseId
      description
      faqs(first: 100) {
        nodes {
          id
        }
      }
      id
      link
      name
      wpParent: parent {
        node {
          id
        }
      }
      parentDatabaseId
      parentId
      slug
      taxonomy {
        node {
          id
        }
      }
      termGroupId
      termTaxonomyId
      uri
      __typename
    }
    pageInfo {
      hasNextPage
      endCursor
    }
  }
}

This is my config for the custom category

// Register Custom Taxonomy
function custom_tax_faqs_category() {
    $labels = array(
        'name'                       => _x( 'FAQs', 'Taxonomy General Name', 'text_domain' ),
        'singular_name'              => _x( 'FAQ', 'Taxonomy Singular Name', 'text_domain' ),
        'menu_name'                  => __( 'FAQ Categories', 'text_domain' ),
        'all_items'                  => __( 'All Items', 'text_domain' ),
        'parent_item'                => __( 'Parent Item', 'text_domain' ),
        'parent_item_colon'          => __( 'Parent Item:', 'text_domain' ),
        'new_item_name'              => __( 'New Item Name', 'text_domain' ),
        'add_new_item'               => __( 'Add New Item', 'text_domain' ),
        'edit_item'                  => __( 'Edit Item', 'text_domain' ),
        'update_item'                => __( 'Update Item', 'text_domain' ),
        'view_item'                  => __( 'View Item', 'text_domain' ),
        'separate_items_with_commas' => __( 'Separate items with commas', 'text_domain' ),
        'add_or_remove_items'        => __( 'Add or remove items', 'text_domain' ),
        'choose_from_most_used'      => __( 'Choose from the most used', 'text_domain' ),
        'popular_items'              => __( 'Popular Items', 'text_domain' ),
        'search_items'               => __( 'Search items', 'text_domain' ),
        'not_found'                  => __( 'Not Found', 'text_domain' ),
        'no_terms'                   => __( 'No Items', 'text_domain' ),
        'items_list'                 => __( 'Items list', 'text_domain' ),
        'items_list_navigation'      => __( 'Items list navigation', 'text_domain' ),
    );
    $args = array(
        'labels'                     => $labels,
        'hierarchical'               => true,
        'public'                     => true,
        'show_ui'                    => true,
        'show_admin_column'          => true,
        'show_in_nav_menus'          => true,
                 'show_tagcloud'              => false,
                 'show_in_rest'               => true,
        'show_in_graphql'            => true,
                 'graphql_single_name'        => 'faqCategory',
                 'graphql_plural_name'        => 'faqsCategory',
    );
    register_taxonomy( 'faqs', array( 'faqs' ), $args );

}
add_action( 'init', 'custom_tax_faqs_category', 0 );

missing data todo after v4 release

Source

peteluffman

Most helpful comment

Yep, tested this today and it’s all working fine now. Thanks Tyler! :)

peteluffman on 25 Sep 2020

🎉3

All 6 comments

Digging into it further, it appears the standard post category doesn't have the same issue because it has a workaround calling a categoryBeforeChangeNode method in the base config.

I've managed to hack a fix for now by duplicating the compiled category.js found at node_modules/gatsby-source-wordpress-experimental/steps/source-nodes/before-change-node/ into my project root and updating it's graphql references within to match my type.

I've imported the file at the top of my gatsby-config:

const { faqCategoryBeforeChangeNode } = require("./faq-category-child-nodes")

...and updated my config as the following:

{
  resolve: `gatsby-source-wordpress-experimental`,
    options: {
      ...
      type: {
        ...
        FaqCategory: {
          beforeChangeNode: faqCategoryBeforeChangeNode,
        }
      }
    }
  }
}

Hopefully this helps someone else until the bug is resolved!

peteluffman on 3 Sep 2020

👍1

I had same issue.
That really helped me out!

I leave my code because I was worried to rewrite category.js

case_categories_child_nodes.js

"use strict";

exports.__esModule = true;

var _processNode = require("gatsby-source-wordpress-experimental/steps/source-nodes/create-nodes/process-node");
const caseCategoryBeforeChangeNode = async ({
  remoteNode,
  actionType,
  wpStore,
  fetchGraphql,
  helpers,
  actions,
  buildTypeName
}) => {
  var _remoteNode$wpChildre, _remoteNode$wpChildre2;

  if (actionType !== `UPDATE` && actionType !== `CREATE_ALL` && actionType !== `CREATE`) {
    // no need to update children if we're not updating an existing category
    // if we're creating a new category it will be empty initially.
    // so we run this function when updating nodes or when initially
    // creating all nodes
    return null;
  }

  if (!(remoteNode === null || remoteNode === void 0 ? void 0 : (_remoteNode$wpChildre = remoteNode.wpChildren) === null || _remoteNode$wpChildre === void 0 ? void 0 : (_remoteNode$wpChildre2 = _remoteNode$wpChildre.nodes) === null || _remoteNode$wpChildre2 === void 0 ? void 0 : _remoteNode$wpChildre2.length)) {
    // if we don't have any child category items to fetch, skip out
    return null;
  }

  const state = wpStore.getState();
  const {
    selectionSet
  } = state.remoteSchema.nodeQueries.caseCategories;
  const {
    wpUrl
  } = state.remoteSchema;
  const {
    pluginOptions
  } = state.gatsbyApi;
  const query = `
        fragment CASE_CATEGORY_FIELDS on CaseCategory {
          ${selectionSet}
        }

        query {
            ${remoteNode.wpChildren.nodes.map(({
    id
  }, index) => `id__${index}: caseCategory(id: "${id}") { ...CASE_CATEGORY_FIELDS }`).join(` `)}
          }`;
  const {
    data
  } = await fetchGraphql({
    query,
    errorContext: `Error occured while recursively fetching "CaseCategory" nodes in beforeChangeNode API.`
  });
  const remoteChildCategoryNodes = Object.values(data);
  const additionalNodeIds = remoteChildCategoryNodes.map(({
    id
  } = {}) => id);
  await Promise.all(remoteChildCategoryNodes.map(async remoteCategoryNode => {
    var _remoteCategoryNode$w, _remoteCategoryNode$w2;

    if (remoteCategoryNode === null || remoteCategoryNode === void 0 ? void 0 : (_remoteCategoryNode$w = remoteCategoryNode.wpChildren) === null || _remoteCategoryNode$w === void 0 ? void 0 : (_remoteCategoryNode$w2 = _remoteCategoryNode$w.nodes) === null || _remoteCategoryNode$w2 === void 0 ? void 0 : _remoteCategoryNode$w2.length) {
      // recursively fetch child category items
      const {
        additionalNodeIds: childNodeIds
      } = await caseCategoryBeforeChangeNode({
        remoteNode: remoteCategoryNode,
        actionType: `CREATE`,
        wpStore,
        fetchGraphql,
        helpers,
        actions,
        buildTypeName
      });
      childNodeIds.forEach(id => additionalNodeIds.push(id));
    }

    const type = buildTypeName(`CaseCategory`);
    const processedNode = await (0, _processNode.processNode)({
      node: remoteCategoryNode,
      pluginOptions,
      wpUrl,
      helpers
    });
    await actions.createNode(Object.assign({}, processedNode, {
      nodeType: `CaseCategory`,
      type: `CaseCategory`,
      parent: null,
      internal: {
        contentDigest: helpers.createContentDigest(remoteCategoryNode),
        type
      }
    }));
  }));
  return {
    additionalNodeIds
  };
};

exports.caseCategoryBeforeChangeNode = caseCategoryBeforeChangeNode;

RyoheiTomiyama on 17 Sep 2020

Thanks for opening this issue @peteluffman , this is indeed a problem currently. I have some ideas to make it so this workaround isn't needed but haven't gotten around to implementing it yet. Thanks for the reminder and clear description of the problem!