Гэтсби с WordPress не находит гибкое поле содержимого ACF, если оно не используется

Question

У меня есть гибкий тип поля содержимого в Wordpress (с ACF), и я получаю ошибки при попытке построить gatsby.

Я использую следующие плагины:

• ACF дляREST api
• ACF to REST api recursive
• Расширенные пользовательские поля PRO

Для Гэтсби я использую gatsby-source-wordpress.

{
  allWordpressPage {
    edges {
      node {
        title
        acf {
          page_builder_page {
            ... on WordPressAcf_hero {
              title
              subtitle
            }
            ... on WordpressAcf_text {
              text
            }
          }
        }
      }
    }
  }
}

Запрос, подобный приведенному выше, работает, только если для блока page_builder на типе page для некоторой страницы используется hero и текст блок.Если я настраиваю эту страницу в первый раз или создаю новый пользовательский тип записи с тем же полем page_builder, мне нужно заполнить по крайней мере одно поле для каждого гибкого типа блока контента, прежде чем будет работать графовый запрос.

В противном случае я получаю ошибки, подобные этим, для каждого неиспользуемого блока (если, например, у типа «герой» есть контент, но нет текстового типа):

GraphQL request: Fragment "TextBlockFragment" cannot be spread here as objects of
type "WordPressAcf_hero" can never be of type "WordPressAcf_text".

Есть ли решение для этого?Я предполагаю, что это не должно быть так.Как и сейчас, мне нужно заполнить всю страницу фиктивным контентом при первой его настройке, прежде чем я смогу создать ее с помощью Gatsby.

Answer 1

Я думаю, что проблема, с которой вы столкнулись, похожа на , довольно распространенную проблему , с которой я также столкнулся при использовании Gatsby + WordPress REST API.

Краткое резюме заключается в том, что API-интерфейс REST WordPress, например, будет возвращать логическое значение при наличии поля галереи ACF без изображений, а не null, чего ожидает запрос GraphQL, когда поле пустое , Я подозреваю, что с вами происходит то же самое: вы запрашиваете не заполненные подполя и получаете ответ, который GraphQL интерпретирует как неправильный тип вместо null. (Полное раскрытие, мой единственный опыт работы с GraphQL через Gatsby.)

К счастью, я думаю, что есть много вариантов, чтобы решить эту проблему.

Новое решение Гэтсби

Команда Gatsby и его участники в последнее время довольно активно работают над этим, и в настоящее время вы можете попробовать предварительную версию нового подхода здесь: https://www.gatsbyjs.org/blog/2019-03-04-new-schema-customization/

Вы можете прочитать больше о проблеме и предыстории здесь, если хотите: https://github.com/gatsbyjs/gatsby/issues/3344

Существующие, быстрые решения WordPress

Два решения, которые обходят это сейчас, если вы не хотите использовать что-то, еще не полностью объединенное с Гэтсби:

1. Установка пустых ответов на null для этого поля ACF, как описано @pieh в команде Gatsby , и в этой проблеме GitHub есть другие примеры для других типов полей
2. Создание «фиктивного» контента, в котором все заполнено, а затем этот пост отфильтровывается перед отображением (например, когда слаг имеет значение placeholder). Подвох в том, что у вас есть эти поддельные сообщения для каждого пользовательского типа сообщений, которые нельзя удалить из WordPress.

Я использовал оба подхода, и оба работают. Я бы сказал, что # 2 был, вероятно, более надежным, поскольку он работает для всех полей, которые вы используете одновременно, но потенциально более запутанно в зависимости от того, кто использует CMS: «Почему эти посты здесь?»

Надеюсь, это полезно!