Você pode preparar repo de reprodução? O número de postagens não deve ser um problema (pelo menos nesta etapa) - a v1 pode ter problemas de memória, mas isso seria na etapa de compilação posterior e não deve travar

Estava curioso para saber se era um problema com o Local by Flywheel , e capaz de construir o site ao servir WordPress via MAMP Pro .

Mas, eu nem estou criando páginas de postagem ainda (estou criando as páginas), e o tempo de execução para essa etapa problemática é de 636,41s (apenas 11 minutos).

const path = require('path')

exports.createPages = ({ boundActionCreators, graphql }) => {
  const { createPage } = boundActionCreators

  const postTemplate = path.resolve('./src/templates/Post/Post.js')

  graphql(
    `
      {
        allWordpressPost {
          edges {
            node {
              id
              slug
            }
          }
        }
      }
    `
  )
    .then((result) => {
      console.log('posts')
      // const { data, errors } = result

      // if (errors) console.log(errors)

      // if (!data) return

      //data.allWordpressPost.edges.forEach(({ node }) => {
      //  const { id, slug } = node

      //  createPage({
      //    component: postTemplate,
      //    context: {
      //      id,
      //    },
      //    path: slug,
      //  })
      //})
    })

editar: apenas habilite createPage para postagens e a execução desse item subirá para 14 minutos. Brutal, mas também interessante que dura apenas 3 minutos a mais para ~ 9000 itens a mais. Ele está parado em ⠁ run graphql queries há muito tempo.

editar: que funcionou por 419.470 s, ou 7 minutos.

@pieh Opa, postou antes de ver que você respondeu. Posso tentar ativar este site remotamente amanhã.

E, pretendendo incluir, esta última linha é onde ela trava via Local e leva uma eternidade via MAMP.

$ gatsby develop
success delete html and css files from previous builds — 0.017 s
success open and validate gatsby-config — 0.226 s
info One or more of your plugins have changed since the last time you ran Gatsby. As
a precaution, we're deleting your site's cache to ensure there's not any stale
data
success copy gatsby files — 0.013 s
success onPreBootstrap — 0.159 s
⠁ source and transform nodes -> wordpress__acf_posts fetched : 100
⠁ source and transform nodes -> wordpress__acf_pages fetched : 34
⠂ source and transform nodes -> wordpress__acf_media fetched : 100
⠈ source and transform nodes -> wordpress__acf_categories fetched : 13
⢀ source and transform nodes -> wordpress__acf_tags fetched : 0
⠄ source and transform nodes -> wordpress__acf_users fetched : 11
⢀ source and transform nodes -> wordpress__POST fetched : 9092
⢀ source and transform nodes -> wordpress__PAGE fetched : 34
⠐ source and transform nodes -> wordpress__wp_media fetched : 7483
⡀ source and transform nodes -> wordpress__wp_types fetched : 1
⠁ source and transform nodes -> wordpress__wp_statuses fetched : 1
⢀ source and transform nodes -> wordpress__wp_taxonomies fetched : 1
⠄ source and transform nodes -> wordpress__CATEGORY fetched : 14
⠈ source and transform nodes -> wordpress__TAG fetched : 19
⠐ source and transform nodes -> wordpress__wp_users fetched : 11
⡀ source and transform nodesThe server response was "401 Unauthorized"
Inner exception message : "You are not currently logged in."
⠈ source and transform nodesThe server response was "401 Unauthorized"
Inner exception message : "Sorry, you are not allowed to do that."
⡀ source and transform nodesThe server response was "404 Not Found"
Inner exception message : "No route was found matching the URL and request method"
success source and transform nodes — 636.410 s

@pieh Não confirmou que a construção será bem-sucedida (agora com o controle remoto do WordPress, está demorando horas), mas certamente revela o problema: https://github.com/dustinhorton/gatsby-issue

Deve ser capaz de apenas clonar isso e construir.

Apenas funcionou duas vezes por mais de 10 horas sem a conclusão da construção do local. Informe o que mais posso fornecer para ajudar na depuração.

Você poderia tentar atualizar para a v2? Fizemos muitas melhorias de velocidade em diferentes subsistemas do gatsby, o que deve acelerar drasticamente a velocidade de grandes sites como este.

@KyleAMathews Vou tentar isso hoje à noite - obrigado.

@KyleAMathews versão v2 @ https://github.com/dustinhorton/gatsby-v2-issue. Estou construindo há cerca de 50 minutos neste ponto.

Matando agora. Site ainda não construído.

Outra coisa que você pode tentar é habilitar o rastreamento https://next.gatsbyjs.org/docs/performance-tracing/

Ainda não adicionamos suporte de rastreamento ao gatsby-source-wordpress, mas os relatórios de rastreamento podem ajudá-lo a descobrir onde ele está travando.

Se alguém mais estiver interessado em investigar isso, um ótimo PR seria adicionar suporte de rastreamento ao gatsby-source-wordpress. Deixe-me saber se você está interessado!

Vou precisar me livrar disso, infelizmente, já que preciso gastar todo o tempo que tenho mudando para um tema tradicional - meio arrasado por não poder usar Gatsby. Todo o resto parece tão ao contrário.

Desculpe, não tivemos a chance de investigar isso :-( Correndo agora para lançar a v2.

Existe uma chance de você deixar o site WP funcionando? Definitivamente, parece que há um bug aqui que deve ser corrigido.

Eu twitei pedindo ajuda, então espero que alguém pule sobre isso em breve :-)

https://twitter.com/gatsbyjs/status/1027079401287102465

Uau, isso é demais - muito obrigado. O site não está indo a lugar nenhum por enquanto (e vou migrar uma cópia e atualizar o repro repo, se necessário).

@dustinhorton, pelo que vale a pena, também notei problemas ao construir um projeto maior (cerca de 1.000 postagens) no Local by Flywheel em comparação com nosso ambiente de produção com um CDN na frente dele.

As respostas REST para Gatsby são 10 a 20 vezes mais longas no local do que na produção, portanto, a construção do site leva uma eternidade. Não gastei muito tempo depurando o problema no Local ainda, mas está na minha lista de tarefas :)

@KyleAMathews Eu poderia dar uma olhada na adição de rastreamento ao wordpress de origem.

@Khristophor isso seria ótimo!

@dustinhorton Estou vendo 404 para as imagens em seu site de amostra (https://dustinhorton.com/gatsby-wp/wp-content/uploads/2018/07/IMG_9906.jpg, por exemplo) que podem estar inflando a compilação Tempo. Alguma chance de você olhar para os caminhos para eles?

As solicitações WP_MEDIA são executadas com bastante rapidez com resultados, então percebi que estava
o claro, mas posso dar uma olhada nisso no final desta semana se você acha
pode ser o caso.

Na quarta-feira, 8 de agosto de 2018 às 17:45 Chris Wiseman [email protected]
escreveu:

@dustinhorton https://github.com/dustinhorton Estou vendo 404's para o
imagens em seu site de amostra (
https://dustinhorton.com/gatsby-wp/wp-content/uploads/2018/07/IMG_9906.jpg,
por exemplo) que pode estar aumentando o tempo de construção. Qualquer chance que você pudesse
olhar para os caminhos para aqueles?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/gatsbyjs/gatsby/issues/6654#issuecomment-411562589 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAXFNRHTA-vqIwCTtioejUL-Ei3nM0Lbks5uO1vygaJpZM4VZ57n
.

Isso é verdade, mas parte da origem e da etapa de transformação é fazer o download de todos os itens de mídia encontrados na resposta REST:
https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-source-wordpress/src/normalize.js#L434

Obter 404 em imagens 7504 pode estar causando alguns problemas;)

Acredite que limpei todos os 404s. Vou tentar construir esta noite. Obrigado a todos.

Aparentemente, nenhuma mudança:

~/Sites/gatsby-issue-v2 (master)
→yarn build
yarn run v1.5.1
$ gatsby build
success open and validate gatsby-config — 0.009 s
success load plugins — 0.277 s
success onPreInit — 0.257 s
success delete html and css files from previous builds — 0.008 s
success initialize cache — 0.245 s
success copy gatsby files — 0.079 s
success onPreBootstrap — 0.001 s
⠁
=START PLUGIN=====================================

Site URL: http://dustinhorton.com/gatsby-wp
Site hosted on Wordpress.com: false
Using ACF: true
Using Auth: undefined undefined
Verbose output: true

Mama Route URL: http://dustinhorton.com/gatsby-wp/wp-json

⠁ source and transform nodesRoute discovered : /
Invalid route.
Route discovered : /oembed/1.0
Invalid route.
Route discovered : /oembed/1.0/embed
Invalid route.
Route discovered : /oembed/1.0/proxy
Invalid route.
Route discovered : /yoast/v1
Valid route found. Will try to fetch.
Route discovered : /yoast/v1/configurator
Valid route found. Will try to fetch.
Route discovered : /yoast/v1/reindex_posts
Valid route found. Will try to fetch.
Route discovered : /yoast/v1/ryte
Valid route found. Will try to fetch.
Route discovered : /yoast/v1/indexables/(?P<object_type>.*)/(?P<object_id>\d+)
Invalid route.
Route discovered : /yoast/v1/statistics
Valid route found. Will try to fetch.
Route discovered : /acf/v3
Invalid route.
Route discovered : /acf/v3/posts/(?P<id>[\d]+)/?(?P<field>[\w\-\_]+)?
Invalid route.
Route discovered : /acf/v3/posts
Valid route found. Will try to fetch.
Route discovered : /acf/v3/pages/(?P<id>[\d]+)/?(?P<field>[\w\-\_]+)?
Invalid route.
Route discovered : /acf/v3/pages
Valid route found. Will try to fetch.
Route discovered : /acf/v3/media/(?P<id>[\d]+)/?(?P<field>[\w\-\_]+)?
Invalid route.
Route discovered : /acf/v3/media
Valid route found. Will try to fetch.
Route discovered : /acf/v3/categories/(?P<id>[\d]+)/?(?P<field>[\w\-\_]+)?
Invalid route.
Route discovered : /acf/v3/categories
Valid route found. Will try to fetch.
Route discovered : /acf/v3/tags/(?P<id>[\d]+)/?(?P<field>[\w\-\_]+)?
Invalid route.
Route discovered : /acf/v3/tags
Valid route found. Will try to fetch.
Route discovered : /acf/v3/comments/(?P<id>[\d]+)/?(?P<field>[\w\-\_]+)?
Invalid route.
Route discovered : /acf/v3/comments
Valid route found. Will try to fetch.
Route discovered : /acf/v3/options/(?P<id>[\w\-\_]+)/?(?P<field>[\w\-\_]+)?
Invalid route.
Route discovered : /acf/v3/users/(?P<id>[\d]+)/?(?P<field>[\w\-\_]+)?
Invalid route.
Route discovered : /acf/v3/users
Valid route found. Will try to fetch.
Route discovered : /wp/v2
Invalid route.
Route discovered : /wp/v2/posts
Valid route found. Will try to fetch.
Route discovered : /wp/v2/posts/(?P<id>[\d]+)
Invalid route.
Route discovered : /wp/v2/posts/(?P<parent>[\d]+)/revisions
Invalid route.
Route discovered : /wp/v2/posts/(?P<parent>[\d]+)/revisions/(?P<id>[\d]+)
Invalid route.
Route discovered : /wp/v2/pages
Valid route found. Will try to fetch.
Route discovered : /wp/v2/pages/(?P<id>[\d]+)
Invalid route.
Route discovered : /wp/v2/pages/(?P<parent>[\d]+)/revisions
Invalid route.
Route discovered : /wp/v2/pages/(?P<parent>[\d]+)/revisions/(?P<id>[\d]+)
Invalid route.
Route discovered : /wp/v2/media
Valid route found. Will try to fetch.
Route discovered : /wp/v2/media/(?P<id>[\d]+)
Invalid route.
Route discovered : /wp/v2/types
Valid route found. Will try to fetch.
Route discovered : /wp/v2/types/(?P<type>[\w-]+)
Invalid route.
Route discovered : /wp/v2/statuses
Valid route found. Will try to fetch.
Route discovered : /wp/v2/statuses/(?P<status>[\w-]+)
Invalid route.
Route discovered : /wp/v2/taxonomies
Valid route found. Will try to fetch.
Route discovered : /wp/v2/taxonomies/(?P<taxonomy>[\w-]+)
Invalid route.
Route discovered : /wp/v2/categories
Valid route found. Will try to fetch.
Route discovered : /wp/v2/categories/(?P<id>[\d]+)
Invalid route.
Route discovered : /wp/v2/tags
Valid route found. Will try to fetch.
Route discovered : /wp/v2/tags/(?P<id>[\d]+)
Invalid route.
Route discovered : /wp/v2/users
Valid route found. Will try to fetch.
Route discovered : /wp/v2/users/(?P<id>[\d]+)
Invalid route.
Route discovered : /wp/v2/users/me
Valid route found. Will try to fetch.
Route discovered : /wp/v2/comments
Valid route found. Will try to fetch.
Route discovered : /wp/v2/comments/(?P<id>[\d]+)
Invalid route.
Route discovered : /wp/v2/settings
Valid route found. Will try to fetch.
Added ACF Options route.

Fetching the JSON data from 25 valid API Routes...

=== [ Fetching wordpress__yoast_v1 ] === https://dustinhorton.com/gatsby-wp/wp-json/yoast/v1
⠈ source and transform nodes -> wordpress__yoast_v1 fetched : 1
Fetching the wordpress__yoast_v1 took: 936.166ms

=== [ Fetching wordpress__yoast_configurator ] === https://dustinhorton.com/gatsby-wp/wp-json/yoast/v1/configurator
⢀ source and transform nodesThe server response was "401 Unauthorized"
Inner exception message : "Sorry, you are not allowed to do that."
Fetching the wordpress__yoast_configurator took: 846.014ms

=== [ Fetching wordpress__yoast_reindex_posts ] === https://dustinhorton.com/gatsby-wp/wp-json/yoast/v1/reindex_posts
⢀ source and transform nodesThe server response was "401 Unauthorized"
Inner exception message : "Sorry, you are not allowed to do that."
Fetching the wordpress__yoast_reindex_posts took: 1010.589ms

=== [ Fetching wordpress__yoast_ryte ] === https://dustinhorton.com/gatsby-wp/wp-json/yoast/v1/ryte
⠠ source and transform nodesThe server response was "401 Unauthorized"
Inner exception message : "Sorry, you are not allowed to do that."
Fetching the wordpress__yoast_ryte took: 1022.977ms

=== [ Fetching wordpress__yoast_statistics ] === https://dustinhorton.com/gatsby-wp/wp-json/yoast/v1/statistics
⠄ source and transform nodesThe server response was "401 Unauthorized"
Inner exception message : "Sorry, you are not allowed to do that."
Fetching the wordpress__yoast_statistics took: 820.827ms

=== [ Fetching wordpress__acf_posts ] === https://dustinhorton.com/gatsby-wp/wp-json/acf/v3/posts
⠈ source and transform nodes -> wordpress__acf_posts fetched : 100
Fetching the wordpress__acf_posts took: 6352.670ms

=== [ Fetching wordpress__acf_pages ] === https://dustinhorton.com/gatsby-wp/wp-json/acf/v3/pages
⡀ source and transform nodes -> wordpress__acf_pages fetched : 34
Fetching the wordpress__acf_pages took: 2760.048ms

=== [ Fetching wordpress__acf_media ] === https://dustinhorton.com/gatsby-wp/wp-json/acf/v3/media
⠈ source and transform nodes -> wordpress__acf_media fetched : 100
Fetching the wordpress__acf_media took: 4273.250ms

=== [ Fetching wordpress__acf_categories ] === https://dustinhorton.com/gatsby-wp/wp-json/acf/v3/categories
⠁ source and transform nodes -> wordpress__acf_categories fetched : 13
Fetching the wordpress__acf_categories took: 1029.029ms

=== [ Fetching wordpress__acf_tags ] === https://dustinhorton.com/gatsby-wp/wp-json/acf/v3/tags
⠈ source and transform nodes -> wordpress__acf_tags fetched : 0
Fetching the wordpress__acf_tags took: 941.066ms

=== [ Fetching wordpress__acf_comments ] === https://dustinhorton.com/gatsby-wp/wp-json/acf/v3/comments
⢀ source and transform nodes -> wordpress__acf_comments fetched : 9
Fetching the wordpress__acf_comments took: 2868.036ms

=== [ Fetching wordpress__acf_users ] === https://dustinhorton.com/gatsby-wp/wp-json/acf/v3/users
⠠ source and transform nodes -> wordpress__acf_users fetched : 11
Fetching the wordpress__acf_users took: 2049.181ms

=== [ Fetching wordpress__POST ] === https://dustinhorton.com/gatsby-wp/wp-json/wp/v2/posts
⠁ source and transform nodes
Total entities : 9094
Pages to be requested : 91
⠁ source and transform nodes -> wordpress__POST fetched : 9094
Fetching the wordpress__POST took: 152767.807ms

=== [ Fetching wordpress__PAGE ] === https://dustinhorton.com/gatsby-wp/wp-json/wp/v2/pages
⢀ source and transform nodes -> wordpress__PAGE fetched : 34
Fetching the wordpress__PAGE took: 2194.895ms

=== [ Fetching wordpress__wp_media ] === https://dustinhorton.com/gatsby-wp/wp-json/wp/v2/media
⢀ source and transform nodes
Total entities : 7504
Pages to be requested : 76
⢀ source and transform nodes -> wordpress__wp_media fetched : 7485
Fetching the wordpress__wp_media took: 132029.996ms

=== [ Fetching wordpress__wp_types ] === https://dustinhorton.com/gatsby-wp/wp-json/wp/v2/types
⢀ source and transform nodes -> wordpress__wp_types fetched : 1
Fetching the wordpress__wp_types took: 956.603ms

=== [ Fetching wordpress__wp_statuses ] === https://dustinhorton.com/gatsby-wp/wp-json/wp/v2/statuses
⢀ source and transform nodes -> wordpress__wp_statuses fetched : 1
Fetching the wordpress__wp_statuses took: 1017.845ms

=== [ Fetching wordpress__wp_taxonomies ] === https://dustinhorton.com/gatsby-wp/wp-json/wp/v2/taxonomies
⠠ source and transform nodes -> wordpress__wp_taxonomies fetched : 1
Fetching the wordpress__wp_taxonomies took: 1029.885ms

=== [ Fetching wordpress__CATEGORY ] === https://dustinhorton.com/gatsby-wp/wp-json/wp/v2/categories
⢀ source and transform nodes -> wordpress__CATEGORY fetched : 14
Fetching the wordpress__CATEGORY took: 943.710ms

=== [ Fetching wordpress__TAG ] === https://dustinhorton.com/gatsby-wp/wp-json/wp/v2/tags
⠠ source and transform nodes -> wordpress__TAG fetched : 19
Fetching the wordpress__TAG took: 1104.454ms

=== [ Fetching wordpress__wp_users ] === https://dustinhorton.com/gatsby-wp/wp-json/wp/v2/users
⡀ source and transform nodes -> wordpress__wp_users fetched : 11
Fetching the wordpress__wp_users took: 1325.604ms

=== [ Fetching wordpress__wp_me ] === https://dustinhorton.com/gatsby-wp/wp-json/wp/v2/users/me
⠂ source and transform nodesThe server response was "401 Unauthorized"
Inner exception message : "You are not currently logged in."
Fetching the wordpress__wp_me took: 926.146ms

=== [ Fetching wordpress__wp_comments ] === https://dustinhorton.com/gatsby-wp/wp-json/wp/v2/comments
⠂ source and transform nodes
Total entities : 9410
Pages to be requested : 95
⡀ source and transform nodes -> wordpress__wp_comments fetched : 9397
Fetching the wordpress__wp_comments took: 85370.673ms

=== [ Fetching wordpress__wp_settings ] === https://dustinhorton.com/gatsby-wp/wp-json/wp/v2/settings
⠁ source and transform nodesThe server response was "401 Unauthorized"
Inner exception message : "Sorry, you are not allowed to do that."
Fetching the wordpress__wp_settings took: 808.396ms

=== [ Fetching wordpress__acf_options ] === http://dustinhorton.com/gatsby-wp/wp-json/acf/v2/options
⠂ source and transform nodesThe server response was "404 Not Found"
Inner exception message : "No route was found matching the URL and request method"
Fetching the wordpress__acf_options took: 1059.276ms

=END PLUGIN=====================================: 412457.896ms
⠁ source and transform nodes

E está lá por cerca de 8 horas.

@dustinhorton que tipo de hospedagem você está usando? Acho que está apenas matando sua caixa de produção com a quantidade de solicitações. Eu acredito que consegui terminar (depois de algum tempo, não oito horas) definindo conexões simultâneas para algo baixo, como 1 ou 2.

É um VPS decente no Linode. Posso ajustar as configurações, se isso ajudar. Mas o problema também acontece localmente.

https://github.com/gatsbyjs/gatsby/blob/46290c2b0e7894fca036bdcc658a5d1936c4221f/packages/gatsby-source-filesystem/src/create-remote-file-node.js#L133 -L159 esta quantidade às vezes não está funcionando corretamente de arquivos - a solicitação de rede é resolvida, mas o fluxo de gravação de arquivo nunca termina (ou ocorre o erro). Acho que seria ótimo adicionar algum tipo de tempo limite após responseStream terminar para esperar fsWriteStream terminar e, se isso não acontecer, destrua todos os recursos e tente escrever o arquivo novamente (possivelmente faça algumas tentativas) e, na verdade, erros quando não puder fazer isso.

@pieh, você pode enviar um código atualizado para este arquivo?

/packages/gatsby-source-filesystem/src/create-remote-file-node.js

@ aman-developer ainda não há conserto para isso - caso contrário, seria publicado. O problema com esse problema é que não há uma maneira confiável de reproduzi-lo, portanto, quaisquer correções são suposições. O problema é que, em alguns casos (pode ser específico do hardware e / ou do sistema operacional), o writeStream do sistema de arquivos não termina e está travando sem lançar erros, então qualquer correção aqui realmente está tentando contornar os problemas em fs package / hardware / os não sendo confiável: /

Você teve problemas de reprodução com meu repo e site? É consistente para mim.

Eu uso createRemoteFileNode para buscar imagens remotas e enfrento o mesmo problema: o download para por volta de 680 / 780ish.

Em createRemoteFileNode, há um ouvinte para o evento downloadProgress que foi adicionado em https://github.com/sindresorhus/got/releases/tag/v8.0.0, mas o sistema de arquivos gatsby-source-use obteve 7.1.0.

Tentei atualizar, cheguei à última versão 9.2.2 e agora consegui baixar todas as imagens com sucesso.

Adicione isso em package.json:

  "resolutions": {
    "got": "^9.2.2"
  }

Além disso, parece haver algumas correções críticas obtidas após o 7.1.0, como erros de stream não encaminhados corretamente, etc. (https://github.com/sindresorhus/got/releases/tag/v8.0.1)

Tentei atualizar got , mas às vezes travo, mas vale a pena fazer isso de qualquer maneira. Apenas observe que downloadProgress coisas precisarão ser desativadas ou alguma saída melhor, porque o terminal / console recebe spam com o progresso ao usar isso

Consegui executar gatsby develop após ~ 25 minutos, mas tive que reduzir a simultaneidade em create-remote-file-node.js de 200 para 20. Obtive cerca de 22 TimeoutErrors (mas foram baixados novamente ao executar gatsby Develop novamente) depois de colocar os logs nessa captura vazia em processRemoteNode.

Não tenho certeza se é por causa de got, mas talvez possa experimentar com outros clientes http ...

...
success source and transform nodes — 1407.531 s
success building schema — 3.315 s
success createPages — 0.571 s
success createPagesStatefully — 2.797 s
success onPreExtractQueries — 0.012 s
success update schema — 3.268 s
warning There are conflicting field types in your data. GraphQL schema will omit those fields.
wordpress__wp_media.media_details.width:
 - type: number
   value: 916
 - type: string
   value: '224'
wordpress__wp_media.media_details.height:
 - type: number
   value: 916
 - type: string
   value: '225'
wordpress__wp_media.media_details.sizes.thumbnail.width:
 - type: number
   value: 150
 - type: string
   value: '150'
wordpress__wp_media.media_details.sizes.thumbnail.height:
 - type: number
   value: 150
 - type: string
   value: '150'
wordpress__wp_media.media_details.sizes.medium.width:
 - type: number
   value: 300
 - type: string
   value: '300'
wordpress__wp_media.media_details.sizes.medium.height:
 - type: number
   value: 300
 - type: string
   value: '200'
wordpress__wp_media.media_details.sizes.large.width:
 - type: number
   value: 768
 - type: string
   value: '1024'
wordpress__wp_media.media_details.sizes.large.height:
 - type: number
   value: 1024
 - type: string
   value: '682'
wordpress__wp_media.media_details.image_meta.aperture:
 - type: number
   value: 2.2
 - type: string
   value: '0'
wordpress__wp_media.media_details.image_meta.created_timestamp:
 - type: boolean
   value: false
 - type: number
   value: 1433226914
 - type: string
   value: '0'
wordpress__wp_media.media_details.image_meta.focal_length:
 - type: number
   value: 0
 - type: string
   value: '0'
wordpress__wp_media.media_details.image_meta.iso:
 - type: number
   value: 0
 - type: string
   value: '0'
wordpress__wp_media.media_details.image_meta.shutter_speed:
 - type: number
   value: 0
 - type: string
   value: '0'
wordpress__wp_media.media_details.image_meta.orientation:
 - type: number
   value: 1
 - type: string
   value: '1'
warning Using the global `graphql` tag is deprecated, and will not be supported in v3.
Import it instead like:  import { graphql } from 'gatsby' in file:
/Users/tandingan.wlb/Projects/gatsby/gatsby-issue/src/templates/Post/Post.js
success extract queries from components — 0.120 s
success run graphql queries — 223.335 s — 9121/9121 40.84 queries/second
success write out page data — 0.119 s
success write out redirect data — 0.001 s
success onPostBootstrap — 0.027 s

info bootstrap finished - 1643.854 s

{ TimeoutError: Timeout awaiting 'request' for 30000ms
    at Immediate.timeoutHandler [as _onImmediate] (/Users/tandingan.wlb/Projects/gatsby/gatsby-issue/node_modules/got/source/timed-out.js:39:25)
    at runCallback (timers.js:694:11)
    at tryOnImmediate (timers.js:664:5)
    at processImmediate (timers.js:646:5)
  name: 'TimeoutError',
  code: 'ETIMEDOUT',
  host: 'dustinhorton.com',
  hostname: 'dustinhorton.com',
  method: 'GET',
  path: '/gatsby-wp/wp-content/uploads/2015/05/20150302_061259.jpg',
  socketPath: undefined,
  protocol: 'https:',
  url:
   'https://dustinhorton.com/gatsby-wp/wp-content/uploads/2015/05/20150302_061259.jpg',
  event: 'request' }

Estou recebendo os mesmos erros com prísmico

Eu atualizei para "got": "^ 9.2.2" agora está funcionando houra!

Definitivamente, precisamos dar uma olhada para atualizar nossa versão got . Este é um problema de intermitência, então pode ser coincidência que funcionou. @RobinHerzog , informe-nos se tiver problemas semelhantes com a versão atualizada de got

Atualizar got reduziu significativamente o tempo de compilação do meu repro repo, mas ainda levou quase uma hora da última tentativa.

@dustinhorton que parte da compilação estava puxando imagens (ou source and transform data , pois não mostramos explicitamente quanto tempo o download de arquivos leva)?

Tenho 150 MB de imagens com uma conexão de Internet de 1 GB. Agora está funcionando. Preciso de 30 segundos para fazer o download e continuar construindo.

Também estou tendo esse problema de forma consistente. Atualizar got não resolveu isso para mim. Algum sucesso com a adição de rastreamento adicional ao wordpress de origem para que possamos tentar e depurar qual é o problema?

Tentei alterar concurrentRequests e perPage , bem como atualizar got para a versão mais recente, mas nada funcionou. Agora posso buscar categories , posts , pages e tags , mas quando incluo users ou media , logo após =END PLUGIN=== , o plugin retorna com um erro: TypeError: Cannot read property 'id' of undefined .

Se eu incluir todas as rotas e colocar na lista negra aquelas às quais não tenho acesso, recebo =END PLUGIN=== mas nunca termina ... Isso vale para muitos sites que testei, então acho que pode ser o meu sistema de alguma forma . Se alguém quiser testar isso, aqui está a configuração:

    {
      resolve: 'gatsby-source-wordpress',
      options: {
        // Other URLs I tried:
        // https://clubedovalor.com.br
        // http://rivainvestimentos.com.br
        // http://queroinvestiragora.com/
        // https://www.clubedospoupadores.com/
        baseUrl: "aprenda.guiainvest.com.br",
        protocol: "https",
        hostingWPCOM: false,
        useACF: false,
        concurrentRequests: 10,
        perPage: 50,
        // Going with the excluded routes path
        // excludedRoutes: [
        //   '/*/*/plugins',
        //   '/rock-convert/**',
        //   '/yoast/**',
        //   '/wp-super-cache/**',
        //   '/*/*/users/me',
        //   '/*/*/settings',
        // ],
        verboseOutput: true,
        includedRoutes: [
          "/*/*/categories",
          "/*/*/posts",
          "/*/*/pages",
          "/*/*/tags",
          // You can toggle between media and users (or both)
          // All 3 scenarios will fail with the `'id' of undefined`
          // problem
          // "/*/*/media",
          "/*/*/users",
        ],
      },

PS: Um URL que _dis_ consegui obter foi https://wesbos.com/

FELIZ ATUALIZAÇÃO: Consegui fazer funcionar (_para sites menores_) com includedRoutes , mesmo com users e / ou media incluindo taxonomies na consulta . Agora eu não recebo o erro 'id' of undefined : D

@pieh Acredito que os users e media dependem de taxonomies , então talvez eles devam vir por padrão sempre que a configuração contiver algum desses tipos? Avise-me se puder ajudar na solução de problemas. Como uma nota de fechamento, este bug taxonomies parece não ter relação com o processo de compilação infinito. Com sites com mais de aproximadamente 500 arquivos de mídia, ainda não consigo terminar o processo de construção!

ATUALIZAÇÃO Número 2 : Então, consegui fazer funcionar para queroinvestiragora.com , que tem 600 arquivos de mídia, mas apenas 70 postagens, leva cerca de 15 segundos depois de =END PLUGIN=== , mas funciona. No entanto, www.clubedospoupadores.com tem 702 arquivos de mídia e 336 mensagens e não compila.

PS: Minha configuração nesses experimentos é:

    {
      resolve: 'gatsby-source-wordpress',
      options: {
        baseUrl: "queroinvestiragora.com",
        protocol: "http",
        hostingWPCOM: false,
        useACF: false,
        concurrentRequests: 10, // I've also tried removing it and going with the default, it's the same result
        verboseOutput: true,
        includedRoutes: [
          "/*/*/categories",
          "/*/*/posts",
          "/*/*/pages",
          "/*/*/tags",
          "/*/*/media",
          "/*/*/users",
          "/*/*/taxonomies",
        ],
      },
    },

Olá,

Consegui adicionar rastreamento usando as etapas descritas aqui https://www.gatsbyjs.org/docs/performance-tracing/ . Infelizmente, ele não forneceu muitas informações, pois simplesmente me disse que, de fato, os nós de origem e de transformação estão demorando muito.

No entanto, fiz minha própria depuração no problema depois de ter algum comportamento não determinístico envolvendo imagens. Ao executar o script de desenvolvimento ou construção, eu receberia um caso em que nem todas as imagens seriam baixadas e os nós localFile não seriam concluídos. Depois de me aprofundar no código, concluí que parece haver um problema aqui

https://github.com/gatsbyjs/gatsby/blob/ad142af473fc8dc8555a5cf23a0dfca42fcbbe90/packages/gatsby-source-wordpress/src/normalize.js#L483 -L506

Para mim, o nó createRemoteFile estava falhando devido a erros de tempo limite do servidor e os padrões para retornar nulo. Tive que adicionar algum registro ao nó createRemoteFile também para determinar isso e obter as respostas reais do servidor. Como esses nós não são concluídos e não têm IDs, eles não são registrados no cache. Os arquivos tmp foram excluídos e o sistema de arquivos gatsby-source-file estava incompleto. Por alguma razão (eu não procurei tão longe ainda) ao executar o script de construção novamente, o sistema de arquivos de origem foi então excluído, provavelmente porque o script detectou que o sistema de arquivos é inválido ou incompleto. Foi esse processo que criou um loop e causou erros em compilações futuras, pois o sistema de arquivos nunca é concluído.

Estou trabalhando em uma correção que parece aliviar alguns dos problemas, pelo menos em relação a grandes quantidades de imagens. Quando o script de desenvolvimento ou construção é bem-sucedido no download de todas as imagens pela primeira vez, ele subsequentemente não é excluído e o processo de construção acontece muito rapidamente, pois as imagens são armazenadas em cache corretamente pelo sistema de arquivos gatsby-source-source! Minha construção passou de 15 minutos para 1 minuto.

Não tenho certeza se isso está relacionado a construções que têm uma grande quantidade de postagens. Meu problema estava diretamente relacionado ao download de 1,6 GB de dados de imagem.

Esta é a primeira vez que trabalho com plug-ins de código-fonte para gatsby, então, se alguém tiver alguma opinião ou conselho sobre isso, eu agradeceria! Devo poder postar meu repositório mais tarde hoje. Estou trabalhando para fazê-lo usar minha versão local do gatsby-source-filesystem sem complicações.

Olá,

Seguindo meu comentário de alguns dias atrás. Aqui está meu repo.

https://github.com/njmyers/byalejandradesign.com.git

Estou usando um monorepo neste projeto, então aqui estão algumas etapas se você deseja executar o repositório localmente.

1. Certifique-se de ter a versão mais recente do Yarn 1.12.3
2. Clone o branch do plugin git clone https://github.com/njmyers/byalejandradesign.com.git -b wordpress-plugin
3. Execute yarn && yarn bootstrap
4. Navegue até a pasta gatsby para ver apenas essa pasta cd packages/web
5. Execute yarn develop ou yarn build-web . Ele deve ser concluído com êxito na primeira vez e as execuções subsequentes do mesmo comando resultarão em compilações muito mais rápidas! Os nós de origem e de transformação levam 222s para mim, pois levava 3 vezes mais que antes e / ou não estava concluindo.
6. Se você quiser ver o que realmente está acontecendo durante a origem e a transformação, pode olhar em seu navegador de arquivos em /packages/web/.cache/gatsby-source-filesystem você verá que os arquivos estão sendo criados lá.

Reescrevi a função downloadMediaFiles completamente. Você pode ver esse arquivo neste link https://github.com/njmyers/byalejandradesign.com/blob/wordpress-plugin/packages/gatsby-source-wordpress/src/download-media-files.js

Provavelmente é mais prolixo do que deveria ser, mas eu tive que fazer isso a fim de descobrir tudo o que está acontecendo. A funcionalidade que alterei é adicionar uma rejeição de promessa quando createRemoteFileNode retorna null. Em seguida, uso a função downloadRunner para limitar as solicitações de forma que não cheguem todas ao servidor ao mesmo tempo, bem como uma nova tentativa de rejeições de promessa. Eu adicionei 200ms de aceleração entre cada solicitação createRemoteFileNode. Tenho certeza de que esse valor pode ser ajustado e parte disso pode ser mais adequado para adicionar a createRemoteFileNode diretamente.

Se alguém estiver curioso, a instalação do WP é uma microinstância EC2, enquanto as imagens estão por trás de uma distribuição do CloudFront. Pessoalmente, nunca tive problemas em obter mensagens, o meu problema era em obter imagens e acredito que a maioria dos problemas que as pessoas estão a ter se devem a isso.

Além disso, se alguém quiser rastrear ou depurar seu próprio site, sugiro começar aqui ...

https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-source-filesystem/src/create-remote-file-node.js#L240 -L244

Eu adicionei o log à cláusula catch e fui capaz de determinar que os nós de imagem não estavam sendo processados ​​corretamente porque eu estava recebendo erros de tempo limite e retornando null.

@njmyers Acabei de dar uma olhada rápida nisso e estou pensando que, se funcionar, devemos usar uma abordagem semelhante em createRemoteFileNode diretamente. Estamos usando queue lá, então os consumidores desta função ( gatsby-source-wordpress neste caso) não precisam se preocupar com isso. Uma coisa que é potencialmente problemática é a aceleração de 200ms - talvez pudéssemos começar sem ela e quando começarmos a ver problemas, aplicar a limitação automaticamente (por nome de host)

@pieh Sim, provavelmente seria o lugar para aplicar essa lógica. A limitação para mim foi uma maneira de abordar isso e diagnosticar o problema, então concordo que createRemoteFileNode deve ser capaz de lidar com isso sozinho.

Particularmente problemático, entretanto, é o comportamento atual de falhar silenciosamente os erros e retornar nulo. Em minha opinião, deve haver alguma comunicação sobre o fracasso ou o sucesso da operação. Acho que createRemoteFileNode poderia se tornar mais robusto com a seguinte funcionalidade.

1) Crie conexões avidamente
2) Se houver erros do servidor, comece a acelerar e / ou tente novamente, se necessário
3) Defina alguns padrões lógicos para aceleração / nova tentativa
4) Crie um ponto de entrada para ajustar o estrangulamento / nova tentativa
4) Rejeite uma promessa se por algum motivo o nó não puder ser processado.

Também posso dizer que brinquei com os valores de tempo limite aqui https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-source-filesystem/src/create-remote-file-node.js#L135 - L141. Embora isso tenha aumentado a probabilidade de uma resposta bem-sucedida, ainda tive que adicionar tratamento para garantir uma resposta bem-sucedida.

Provavelmente, o ponto de entrada correto para essa lógica seria aqui.

https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-source-filesystem/src/create-remote-file-node.js#L259 -L269

Onde, se as tarefas estão falhando, elas são repetidas e / ou falham e, finalmente, são rejeitadas.

Também apenas leia brevemente os queue docs. Vejo o que você está dizendo sobre queue ser capaz de gerenciar isso por conta própria.

@njmyers bom trabalho de investigação! Definitivamente, concordo que o download do arquivo precisa ser muito mais inteligente!

Na verdade, poderia ser bom extrair a parte de download do arquivo em seu próprio pacote que foca neste problema de download e armazenamento em cache de arquivos remotos.

Há uma boa chance de precisarmos usar a funcionalidade em vários lugares em Gatsby e no futuro e é algo que outras pessoas na Internet também gostariam de usar.

@KyleAMathews, você quer dizer extrair createRemoteFileNode para um pacote separado?

Não apenas a parte de download e cache de arquivos. createRemoteFileNode então apenas chamaria esse pacote e receberia de volta uma promessa que seria resolvida quando o arquivo fosse baixado (ou retornado do cache).

Também estou tendo esse problema com meu próprio plug-in de origem do cockpit.

Vejo que seria mais como extrair essas partes do código para um pacote separado ...

https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-source-filesystem/src/create-remote-file-node.js#L125 -L244

Este parece ser o código que lida especificamente com download e armazenamento em cache, corrija-me se eu estiver errado. Fico feliz em trabalhar nisso! Só estou tentando descobrir como isso funciona no ecossistema maior.

Um PR para corrigir apenas gatsby-source-wordpress seria aceito e, em seguida, extrairia a correção? Tendo problemas para usar o plugin bifurcado do @njmyers no estado em que se encontra, parece que é uma grande melhoria.

@dustinhorton não tenho certeza se isso ajuda, mas descobri que se você quiser usar um plugin local, é melhor apontar o gatsby diretamente para o arquivo package.json. Eu estava tendo problemas para fazer o gatsby encontrar meu plugin local até que comecei a especificá-lo explicitamente.

https://github.com/njmyers/byalejandradesign.com/blob/d56b1938f6d1bc22c3cf2282bb3198e378fe3561/packages/web/gatsby-config.js#L91 -L94

Ainda estou feliz em trabalhar neste problema e até mesmo no novo plug-in, conforme discutido. Só estou procurando um pouco de orientação sobre como integrar isso, pois parece uma mudança perturbadora que pode impactar muitas outras coisas das quais não estou ciente. @KyleAMathews alguma opinião? Eu ainda sinto como se o código aqui

https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-source-filesystem/src/create-remote-file-node.js#L125 -L244

É a parte que deve ser extraída em seu próprio pacote. Dito isso, é uma das funções principais de createRemoteFileNode e quero ter certeza de que vou fazer isso corretamente para que possa ser integrado de volta ao ecossistema de maneira adequada.

@njmyers Em sua maioria, você está correto com sua seleção de código - também gostaríamos que nossa fila atual (que limita o ATM para 200 solicitações simultâneas, o que não parece ótimo para dev local e aparentemente para wordpress) movida e provavelmente alterada.

@dustinhorton Eu acho que é razoável usar isso no plugin do wordpress primeiro (principalmente porque está praticamente pronto).

@pieh Muito obrigado pelo seu esclarecimento! Vou começar a trabalhar em um novo plugin.

Em relação a uma correção temporária de fonte wordpress, minha única outra pergunta seria o que fazer aqui

https://github.com/njmyers/byalejandradesign.com/blob/d56b1938f6d1bc22c3cf2282bb3198e378fe3561/packages/gatsby-source-wordpress/src/download-media-files.js#L169 -L173

No momento, ainda seria possível ter erros de rede e deve haver uma cláusula catch para toda a função downloadMediaFiles. Qual é o comportamento normal para passar erros para gatsby? Eu ficaria feliz em adicionar esse código ao plug-in wordpress para passar corretamente os erros de rede para o manipulador correto. Talvez pudéssemos exibir uma mensagem de erro e uma referência a esse problema. Obrigado pela ajuda!

@njmyers Obrigado - sim, eu estava replicando sua configuração o mais próximo possível, além de ser um monorepo (incluindo referência a package.json ). Executando develop apenas deu erros como se não houvesse gatsby-source-wordpress . Vou tentar novamente aqui em breve.

Recriei mais fielmente o seu monorepo e, estranhamente, ele está apenas sentado em source and transform nodes , como era com o gatsby-source-wordpress não bifurcado antes de rebaixar a dependência obtida.

@pieh Capaz de responder à sua pergunta @ https://github.com/gatsbyjs/gatsby/issues/6654#issuecomment -442536931?

@dustinhorton Sim, deve ficar aí por um bom tempo também, se você tiver muitas imagens. Meu garfo lançará unhandled promise rejection se o download de um arquivo remoto falhar. É por isso que eu gostaria de poder ter algum mecanismo para lidar adequadamente com esse cenário.

Acho que li em outro tópico também que se falou em integrar algum tipo de gerenciador de progresso, já que isso forneceria feedback sobre o status do plugin.

Se você olhar no sistema de arquivos do seu sistema operacional em project-root / .cache / gatsby-source-filesystem, poderá ver todas as imagens que estão sendo baixadas. No meu caso, são quase 400 imagens agora, então leva algum tempo. No entanto, antes de usar minha versão bifurcada, o plug-in falhava silenciosamente em um erro e nunca avançava, causando o problema em que a origem e a transformação levariam horas ...

Você tem um repo? Eu adoraria poder testá-lo em outro site, pois até agora só testei em uma situação da vida real no meu site.

@njmyers Essa é a regra - se você não se importa, envie-me um e-mail: [email protected] ou apenas procure um convite. Vou preparar algo esta noite.

Atualizar got resolveu todos os problemas para mim também.

O problema com got@9 é que ele requer o Nó 8 (https://github.com/sindresorhus/got/releases/tag/v9.0.0), então não podemos atualizar o ATM :(

Devemos ser capazes de atualizar pelo menos got@8 , mas não tenho certeza se isso resolverá os problemas

got@8 parece implementar cache HTTP compatível com RFC 7234, então gatsby-source-filesystem pode fornecer seu próprio adaptador de cache do sistema de arquivos. O que deve, pelo menos, reduzir o tempo gasto nos nós de origem e transformação na segunda vez, visto que o recurso pode ser armazenado em cache.

Hiya!

Este problema ficou quieto. Silêncio assustador. 👻

Recebemos muitos problemas, então atualmente os fechamos após 30 dias de inatividade. Já se passaram pelo menos 20 dias desde a última atualização aqui.

Se perdemos esse problema ou se você deseja mantê-lo em aberto, responda aqui. Você também pode adicionar o rótulo "não obsoleto" para manter esse problema aberto.

Obrigado por fazer parte da comunidade Gatsby! 💪💜

@gatsbot Ainda é um problema.

Foi convidado a contribuir com uma postagem no blog para vocês. Não posso fazer isso porque está preso nos nós de origem e de transformação. Vi o outro problema, mas não estou vendo onde há uma solução para isso. É um fork do gatsbyjs, o último upstream. Só fiz isso funcionar uma vez. Está sempre travado transformando nós.

Ele não consegue capturar imagens de alguns sites durante a construção. Vou adicionar os sites ofensivos pela manhã.

@ twhite96 Acabei de encontrar o problema e o que funcionou para mim foi remover arquivos temporários que eu ainda tinha abertos (do emacs), não tenho certeza se isso irá ajudá-lo ou não, mas permitiu que minha construção avançasse.

Então, parece que isso ainda é um problema ...

enfrentando o mesmo problema ao usar gatsby-source-s3 para puxar 100 fotos e transformá-las em nítidas. Alguém descobriu uma solução?

De alguma forma, meu problema foi corrigido (aleatoriamente?). Estas são as etapas que eu executei, criei um novo balde s3 com menos fotos (para teste) e, em seguida, tentei construir e construiu com sucesso muito rapidamente. Então eu decidi voltar e tentar puxar do balde original e agora, de repente, ele construiu com sucesso nos anos 49, quando originalmente demoraria horas. Não sei como a mera mudança nos links do balde consertou o estol, mas espero que isso ajude alguém a descobrir. talvez tenha a ver com o cache?

Olá a todos. Atualizei minha versão do plug-in local que estava usando para um site que apresentava esse problema. Acho que é uma implementação melhor, pois usa 'better-queue' antes de 'createRemoteNode' e passa o parâmetro 'concurrentRequests'. É um pouco redundante, pois 'createRemoteNode' já usa uma fila, mas, independentemente, esta versão parece funcionar bem com as atualizações recentes do gatsby e fornece feedback sobre o progresso dos arquivos. Vou tentar conseguir um RP para isso. Desculpe pelos atrasos, eu sei que disse que trabalharia nisso antes, mas estou muito ocupado!

https://github.com/njmyers/byalejandradesign.com/blob/wordpress-plugin/packages/gatsby-source-wordpress/src/download-media-files.js

@njmyers

Muito obrigado. Sua versão resolveu alguns problemas que eu estava tendo. Combinei isso com uma ou duas linhas para filtrar o download de 25 GB de mp3s e estou pronto!

Definitivamente, ainda é um problema.
Tenho tentado compilar meu projeto nas últimas 24 horas. De aproximadamente 12 tentativas, 3 tiveram sucesso com saídas e conexão WP real. Existe alguma solução para isso?
BTW, eu tentei usar a versão @njmyers do plugin (trabalho incrível, na verdade!), Mas os resultados foram mistos. Às vezes, ele reclamava sobre wordpress_parent ou Date e eventualmente travava, mas não conseguia descobrir o que realmente estava acontecendo com esses erros. Em outras compilações, erros diferentes (mas eles compilam, o que é interessante), o que realmente causa problemas no GraphQL.

@lucassilvagc você pode postar algumas saídas? Fico feliz que as pessoas estejam testando e testando o branch. Vamos fazer funcionar melhor para que possamos abrir o PR!

@njmyers Claro!

Uma rápida visão geral do que está acontecendo:

Meu site atualmente funciona com arquivos de imagem de aproximadamente 1940, talvez culpa do WordPress por criar vários arquivos de imagem várias vezes. Se eu usar um _gatsby-source-wordpress_ vanilla, o problema aparece como pretendido (há uma compilação "vanilla" que fiz ontem à noite em outro ambiente de compilação - que retorna o mesmo problema que estamos discutindo neste problema. build funciona e compila quando todos os arquivos de imagem são retornados). Ao usar seu plug-in (substituindo todos os arquivos dentro de node_modules / gatsby-source-wordpress (corrija-me se estiver errado nisso)), _gatsby developers_ retorna o seguinte:

TypeError: Cannot read property 'wordpress_parent' of undefined

  - normalize.js:287 entities.map.e
    [amazingtec]/[gatsby-source-wordpress]/normalize.js:287:11

  - Array.map

  - normalize.js:286 Object.exports.mapElementsToParent.entities [as mapElementsToParent]
    [amazingtec]/[gatsby-source-wordpress]/normalize.js:286:12

  - gatsby-node.js:134 Object.exports.sourceNodes
    [amazingtec]/[gatsby-source-wordpress]/gatsby-node.js:134:24


warning The gatsby-source-wordpress plugin has generated no Gatsby nodes. Do you need it?
success source and transform nodes — 299.757 s
success building schema — 10.192 s

Depois de um tempo rápido, ele produz:

'Cannot query field "allWordpressPage" on type "Query". Did you mean "allSitePage"?',
    locations: [ [Object] ] } ]
error UNHANDLED REJECTION

  TypeError: Cannot read property 'allWordpressPage' of undefined

  - gatsby-node.js:54 graphql.then.result
    C:/Projects/amztec-gtby/amazingtec/gatsby-node.js:54:36

PS: este foi um build baunilha do gatsby-source-wordpress que foi _ "convertido" _ para o seu substituindo os arquivos, como eu disse acima. Eu acho que o fato de que ele não pode consultar todas as páginas está relacionado a nenhum nó sendo gerado. Também quero notar que esta compilação é igual à minha outra que funciona quando esse problema não aparece.

Também quero notar que adicionar rotas parece causar o mesmo problema inicial para mim (já que eu queria evitar páginas diferentes que não estão relacionadas ou retornarão erros devido a várias camadas de proteção sobre o WordPress). Só não sei se as rotas que listei estão corretas ou se estou faltando alguma coisa depois.

Estou muito feliz com sua resposta, este problema está sendo um grande revés para meu projeto e estou feliz que você ainda esteja lidando com esse problema. Muito obrigado!

Tendo o mesmo problema com mais de 400 postagens personalizadas com campos ACF e 4000 imagens.

Eu atualizei, consegui e consegui construir em 35 minutos

Não é possível construir novamente depois de atualizar got

Como esperado, já que esse bug ainda existe no gatsby-wordpress. 35 minutos para baixar e processar todas as imagens continua sendo um tempo muito longo considerando todos os fatores (velocidade média da internet, poder de processamento, total de arquivos e assim por diante).
Você pode tentar adaptar a versão do @njmyers para seu uso específico, ele funcionará

Como esperado, já que esse bug ainda existe no gatsby-wordpress. 35 minutos para baixar e processar todas as imagens continua sendo um tempo muito longo considerando todos os fatores (velocidade média da internet, poder de processamento, total de arquivos e assim por diante).
Você pode tentar adaptar a versão do @njmyers para seu uso específico, ele funcionará

Meu site estava funcionando bem quando eu tinha um pequeno número de imagens, mas quando comecei a adicionar mais, isso também aconteceu.

@MWalid como posso atualizar o got ? Obrigado.

tenho tentado construir o dia todo sem sucesso. tem cerca de 1450 imagens.

Não conseguimos implantar por 2 dias. Alguém pode me ajudar a apontar na direção certa onde isso está ocorrendo no código para que eu possa tentar encontrar uma solução?

Não conseguimos implantar por 2 dias. Alguém pode me ajudar a apontar na direção certa onde isso está ocorrendo no código para que eu possa tentar encontrar uma solução?

Você atualizou sua got dependência aninhada de gatsby-source-filesystem para usar pelo menos a versão 9.4.0 ?

Caso contrário, você deve adicionar:

  "resolutions": {
    "gatsby-source-filesystem/got": "9.4.0"
  }

em package.json seu projeto Gatsby. Em seguida, remova node_modules e seu arquivo yarn.lock e instale novamente.

Nota: Este resolutions recurso só funciona para yarn . npm ainda não implementou isso.

@anagstef muito obrigado pela dica! Vou tentar fazer isso e relatar de volta.

Ao executar gatsby develop , há uma maneira de manter o cache local em vez de buscar dados remotos toda vez que o comando é iniciado?

@anagstef parece estar funcionando muito melhor! Obrigado pela dica!

A saída é muito detalhada ao construir com esta versão do got. Você sabe se há alguma maneira de remover isso?

@nratter , fico feliz que funcionou para você!

Sim, eu sei disso, é muito prolixo e não pode ser desativado. Arruina toda a saída útil do console.

Depois de algumas investigações que fiz, acho que foi causado aqui:
https://github.com/gatsbyjs/gatsby/blob/80c7023a8bc23886939205fe52e305277294e6af/packages/gatsby-source-filesystem/src/create-remote-file-node.js#L155

Como você pode ver ele chama um console.log com o andamento do download de cada arquivo toda vez que o evento downloadProgress emite o que acontece muitas vezes por segundo. Isso não era um problema antes, porque a versão antiga de got não implementa o evento downloadProgress .

Talvez possamos consertar isso com um PR? Parece que está depurando código restante.

Eu tive o mesmo problema, preso em "nós de origem e transformação". Depois de muitos console.logs, meu problema acabou sendo problemas de tempo limite com a recuperação de arquivos de mídia do wordpress. O problema não era o servidor não ser capaz de lidar com isso, mas sim a limitação da taxa de cloudflare e o lançamento de timeouts após cerca de 350 solicitações.

Ignorei o cloudflare, fui direto para o vps e não estou mais vendo "nós de origem e transformação" e minha compilação termina.

Minha solução alternativa foi ter um wordpress local para teste, o site ao vivo está em netlify, embora a implantação não causou nenhum problema.

Pessoal, consegui consertar isso rodando createRemoteFileNode requisições em série ao invés de paralelo.

Esta é a função que estou usando:

/**
 * Map over items array using the fn function but wait for each step to finish before moving to the next one
 */
exports.serialMap = async (items, fn) => {
  const results = []
  for (const item of items) {
    const result = await fn(item)
    results.push(result)
  }
  return results
}

e aqui está como estou usando:

const imageNodes = await serialMap(node.___originalImages, imgUrl => {
  return createRemoteFileNode({
    url: imgUrl,
    parentNodeId: node.id,
    store,
    cache,
    createNode,
    createNodeId,
  })
})

Depois que as imagens são baixadas, é assim que fica minha etapa de origem e transformação

Downloading remote files [==============================] 1063/1063 156.1 secs 100%
Downloading remote files [==============================] 1064/1064 157.2 secs 100%
Downloading remote files [==============================] 1065/1065 158.4 secs 100%
Downloading remote files [==============================] 1066/1066 159.5 secs 100%
Downloading remote files [==============================] 1067/1067 160.5 secs 100%
Downloading remote files [==============================] 1068/1068 161.5 secs 100%
Downloading remote files [==============================] 1069/1069 162.6 secs 100%
Downloading remote files [==============================] 1070/1070 163.7 secs 100%
Downloading remote files [==============================] 1071/1071 164.9 secs 100%
Downloading remote files [==============================] 1072/1072 166.0 secs 100%
Downloading remote files [==============================] 1073/1073 167.5 secs 100%
Downloading remote files [==============================] 1074/1074 169.2 secs 100%
Downloading remote files [==============================] 1075/1075 171.0 secs 100%
success source and transform nodes — 175.271 s

Espero que isso resolva seus problemas também.
Felicidades

@ancashoria onde devo colocar este código?

@ancashoria sim, também não sei onde colocar este código.

Isso não está relacionado ao plug-in gatsby-source-wordpress . Eu tenho o código acima em meu gatsby-node.js . A ideia é que disparar todas essas solicitações em paralelo causou sua falha, então escrevi aquela função auxiliar para dispará-las uma após a outra.

Suponho que também haja um problema semelhante em gatsby-source-wordpress , mas não estou familiarizado com ele.
Desculpe, não posso ajudar mais.

Parece estar relacionado a imagens enormes e conexões lentas de internet. O Netlify foi capaz de construir o site, mas minha conexão local não era, pois o download é de apenas 1 MB / s, o que causou o tempo limite após 30s e falha na imagem grande.

Eu tenho fibra de 1 GB e nenhuma imagem 'massiva'.

Não estou transformando imagens de blog localmente depois de baixá-las no wordpress, simplesmente uso seu url. Seria bom se houvesse uma configuração que desabilitasse o download dessas imagens neste caso.

Pessoal, consegui consertar isso executando as solicitações createRemoteFileNode em série em vez de paralelo.

Sim, o problema é realmente baseado no fato de que createRemoteFileNode usa simultaneidade de 200, o que é demais para a maioria dos servidores WP. Tenho minhas imagens no CloudFront e estava atingindo alguns limites de taxa lá.

Eu tentei consertar o problema com uma versão ramificada do plugin de origem por um tempo, mas o problema realmente não está em gatsby-source-wordpress , está em gatsby-source-filesystem . Idealmente, os consumidores da função createRemoteFileNode seriam capazes de passar em simultaneidade lá. Então, os plug-ins podem disponibilizar a opção de simultaneidade em suas configurações. Eu ainda gostaria de fazer uma RP para resolver esse problema!

A solução que tenho usado é apenas um script simples para modificar o código dentro de node_modules . Realmente muito frágil e não ideal, mas é um hack simples para modificar a simultaneidade diretamente. Usa shelljs portanto, deve funcionar para usuários do Windows também (não tentei).

#!/usr/bin/env node
const path = require('path');
const shell = require('shelljs');

const FILE_PATH = path.resolve(
  __dirname,
  // add path to your root dir here,
  'node_modules',
  'gatsby-source-filesystem/create-remote-file-node.js'
);

shell.sed('-i', 'concurrent: 200', 'concurrent: 20', FILE_PATH);

Eu tive o mesmo problema, preso em "nós de origem e transformação". Depois de muitos console.logs, meu problema acabou sendo problemas de tempo limite com a recuperação de arquivos de mídia do wordpress. O problema não era o servidor não ser capaz de lidar com isso, mas sim a limitação da taxa de cloudflare e o lançamento de timeouts após cerca de 350 solicitações.

Ignorei o cloudflare, fui direto para o vps e não estou mais vendo "nós de origem e transformação" e minha compilação termina.

este era exatamente o meu problema. O Netlify estava construindo muito rápido - menos de 2 minutos. Apenas cerca de 30 postagens, com cerca de 500 imagens de origem. Localmente não era todo completado, simplesmente desmarcar o status do CloudFlare para DNS só resolveu o problema imediatamente

Eu tive o mesmo problema, preso em "nós de origem e transformação". Depois de muitos console.logs, meu problema acabou sendo problemas de tempo limite com a recuperação de arquivos de mídia do wordpress. O problema não era o servidor não ser capaz de lidar com isso, mas sim a limitação da taxa de cloudflare e o lançamento de timeouts após cerca de 350 solicitações.
Ignorei o cloudflare, fui direto para o vps e não estou mais vendo "nós de origem e transformação" e minha compilação termina.

este era exatamente o meu problema. O Netlify estava construindo muito rápido - menos de 2 minutos. Apenas cerca de 30 postagens, com cerca de 500 imagens de origem. Localmente não era todo completado, simplesmente desmarcar o status do CloudFlare para DNS só resolveu o problema imediatamente

Eu também descobri que esse é o caso. Anteriormente, eu tinha uma imagem que estava causando a falha do build e rejeitei o Cloudflare como o problema. O problema voltou recentemente e, como @amcc sugeriu não rotear o registro A através do Cloudflare, resolveu o problema imediatamente localmente também.

Só queria repetir que este não é apenas um problema de origem do WP - estava tendo o mesmo problema com gatsby-source-prismic , reduzindo a simultaneidade do sistema de arquivos soure com

Concorde que, se nada mais, a simultaneidade do sistema de arquivos de origem deve ser configurável.

@njmyers Lamento perguntar isso, mas como exatamente essa correção é executada. Simplesmente execute o script antes da compilação ou preciso referenciar de alguma forma o script no processo de compilação, porque atualmente estou me perguntando como aplicar essa correção localmente e também, por exemplo, no netlify.

@alexanderwe Não se preocupe, é um hack bobo de qualquer maneira. Você pode executá-lo depois de instalar node_modules . Não estou 100% certo, mas acredito que postinstall em seu projeto package.json file funcionaria.

Para mim, Gatsby trava 50% do tempo em "nós de origem e transformação" quando eu uso json com mais de 500 imagens incluídas. Estou usando gatsby-source-custom-api

As imagens são hospedadas em um servidor rápido e estável.
Minha conexão com a Internet também é rápida e estável.

"gatsby": "^2.9.4",
"gatsby-image": "^2.1.4",
"gatsby-plugin-emotion": "^4.0.7",
"gatsby-plugin-sharp": "^2.1.5",
"gatsby-plugin-typography": "^2.2.13",
"gatsby-source-custom-api": "^2.0.4",
"gatsby-transformer-remark": "^2.4.0",
"gatsby-transformer-sharp": "^2.1.21",

O que posso fazer para depurar isso?

Esse problema ocorre apenas com gatsby-source-custom-api ou source-wordpress?

Isso acontece comigo também. Tentei todas as correções sugeridas e nada parece funcionar. Definitivamente, não usarei o Wordpress como back-end do Gatsby novamente, embora eu saiba que as pessoas também estão tendo problemas semelhantes com outros serviços.

@alexanderwe A maneira adequada de corrigir isso é implementar o patch sugerido por @njmyers
Em seguida, introduza outro PR para gatsby-source-wordpress e outros para torná-lo realmente configurável a partir de sua referência em gatsby-config.js

@sebastienfi Eu só tropeçou este https://github.com/gatsbyjs/gatsby/issues/14819#event -2418874313 ea correspondente cometer https://github.com/gatsbyjs/gatsby/commit/90aa24787b32ef9613b6becbfadab6029ec39ce9#diff -1864dd21828754bdbc63f22b895bee8e que adiciona uma variável de ambiente para configurar a taxa de simultaneidade, o que resolveu o problema para mim. Há também uma discussão em andamento sobre variáveis ​​de ambiente vs parâmetros de configuração: https://github.com/gatsbyjs/gatsby/issues/14636

Você já tentou definir GATSBY_CONCURRENT_DOWNLOAD com um número inferior? Por padrão, é definido como 200.

Linux / mac:
GATSBY_CONCURRENT_DOWNLOAD=5 gatsby build

Janelas:
setx GATSBY_CONCURRENT_DOWNLOAD 5; gatsby build

@wardpeet
eu tentei, nada mudou

Definitivamente tem algo a ver com o sistema de arquivos de origem, já que os logs mostram que as imagens foram recuperadas com sucesso ... o problema ainda é enorme ... estamos atrasados ​​em nosso prazo e realmente procuramos um solução para isso ...

depois de definir o plugin de origem do wordpress para depuração, vejo isso

sempre desliga entre 470-480 ... não geralmente no mesmo lugar.

alguém sabe em que parte do código isso está sendo executado?

Acabou fazendo funcionar alternando uma VPN na metade

Alguém está disposto a compartilhar comigo seu repo e credenciais para que eu possa dar uma olhada neste aqui e tentar encontrar o problema?

Sinta-se à vontade para me enviar um e-mail privado para [email protected]

meu repositório não é facilmente recriado neste ponto - eu tenho um backup do banco de dados como estava em algum lugar, mas para conseguir a construção do site, tive que reduzir cada mês de postagens em uma única postagem, por anos de conteúdo.

@wardpeet lhe enviou

Nossa empresa mudou o wi-fi e aumentou a largura de banda. Hoje não tive problema em baixar as imagens .... Mas ainda não entendi, é a rede ou a simultaneidade?

no entanto, todas as compilações no Netlify falham ...

17:13:43: === [Buscando wordpress__wp_media] === https://wildkiwi.com/wp-json/wp/v2/media
17:13:43: Total de entidades: 1.717
17:13:43: Páginas a serem solicitadas: 344
17:13:45: A solicitação falhou com o código de erro "indefinido"

o código de erro é indefinido, então eu realmente não entendo o que está acontecendo ...

Quando eu mudo as solicitações simultâneas para 5, ele funciona no Netlify

Eu estava tendo esse problema com um plugin diferente (https://github.com/angeloashmore/gatsby-source-prismic) e definir GATSBY_CONCURRENT_DOWNLOAD=50 resolveu.

Isso simplesmente aconteceu do nada (um dia meu site iria construir, no outro não, sem alterações), e sem qualquer tipo de mensagem de erro, é um pouco desconcertante estar implantando sites para clientes sem ter certeza de que isso não vai acontecer novamente.

Basicamente, baixamos 200 imagens de uma vez, mas isso pode ser problemático para alguns computadores / conexões com a Internet. Uma boa solução é preparar alguns mecanismos de nova tentativa.

Eu estava tendo esses problemas, mas consegui fazer a compilação funcionar bem com uma combinação de setx GATSBY_CONCURRENT_DOWNLOAD 5; gatsby build e Smushing todas as imagens (algumas das quais eram excessivamente grandes em dimensão e tamanho de arquivo) usando a versão gratuita de https: // en-gb.wordpress.org/plugins/wp-smushit/.

Olá! Estou tendo o mesmo problema com um plugin de origem que estou criando (não relacionado ao WordPress) e ao baixar mais de 1000 imagens de uma API. Ele trava quase sempre no final do processo.

Definir GATSBY_CONCURRENT_DOWNLOAD não resolveu. Tentei 50 , 20 , 5 , sem sorte.

Recebo uma coleção de tamanhos da API e estava usando a imagem maior, mas mudei para a menor e também não consertei.

É difícil identificar por que falha neste ponto, a única coisa que recebo é source and transform nodes e, em seguida, silêncio para sempre.

Seria incrível ter um mecanismo de depuração para isso.

Eu estava tendo o mesmo problema em uma integração gatsby + wordress. A construção iria parar para sempre na API onCreateNode onde eu estava usando createRemoteFileNode.

Solução: Eu atualizei o gatsby-source-filesystem de 2.0.4 para 2.1.8 e adicionei GATSBY_CONCURRENT_DOWNLOAD = 50 às minhas variáveis ​​de ambiente.

Olá 👋

Eu tenho um problema semelhante no meu projeto.

Ambiente

  System:
    OS: macOS 10.14.6
    CPU: (4) x64 Intel(R) Core(TM) i5-7267U CPU @ 3.10GHz
    Shell: 5.3 - /bin/zsh
  Binaries:
    Node: 10.16.0 - ~/.nvm/versions/node/v10.16.0/bin/node
    Yarn: 1.17.3 - ~/.yarn/bin/yarn
    npm: 6.9.0 - ~/.nvm/versions/node/v10.16.0/bin/npm
  Languages:
    Python: 2.7.15 - /usr/local/bin/python
  Browsers:
    Chrome: 76.0.3809.100
    Firefox: 68.0.1
    Safari: 12.1.2
  npmPackages:
    gatsby: ^2.13.42 => 2.13.42
    gatsby-cli: ^2.7.34 => 2.7.34
    gatsby-image: ^2.2.14 => 2.2.14
    gatsby-plugin-glamor: ^2.1.3 => 2.1.3
    gatsby-plugin-manifest: ^2.2.4 => 2.2.4
    gatsby-plugin-offline: ^2.2.4 => 2.2.4
    gatsby-plugin-react-helmet: ^3.1.5 => 3.1.5
    gatsby-plugin-sass: ^2.1.10 => 2.1.10
    gatsby-plugin-sharp: ^2.2.9 => 2.2.9
    gatsby-plugin-svg-sprite: ^2.0.1 => 2.0.1
    gatsby-source-filesystem: ^2.1.18 => 2.1.18
    gatsby-source-wordpress: ^3.1.12 => 3.1.12
    gatsby-transformer-sharp: ^2.2.5 => 2.2.5

Tenho mais de 80000 mídias no meu site WP. Quando executo npx gatsby develop , fico preso depois de "END PLUGIN".

...
=== [ Fetching wordpress__TAG ] === https://[WP_REST_API]/wp-json/wp/v2/tags

Total entities : 8805
Pages to be requested : 89
 -> wordpress__TAG fetched : 8805
Fetching the wordpress__TAG took: 12408.827ms
⠀
=== [ Fetching wordpress__wp_partners ] === https://[WP_REST_API]/wp-json/wp/v2/partners
 -> wordpress__wp_partners fetched : 22
Fetching the wordpress__wp_partners took: 1268.292ms
⠀
=END PLUGIN=====================================: 377120.512ms
⠼ source and transform nodes

Tentei modificar o valor GATSBY_CONCURRENT_DOWNLOAD, mas nada mudou.
Existe uma maneira de limitar a importação de quantidade de mídia? Por exemplo :

{
  resolve: `gatsby-source-filesystem`,
  options: {
    name: `images`,
    path: `${__dirname}/src/images/uploads`,
    limit: 50,
  },
},

O mesmo problema aqui, meu WP auto-hospedado tem 1690 mídias, sempre fico preso no final da etapa de download de arquivos remotos, às vezes falta apenas uma mídia ...

Editar: desta vez, a construção foi bem-sucedida com GATSBY_CONCURRENT_DOWNLOAD=5 yarn build ...

@kvalium Obrigado pelo seu comentário, GATSBY_CONCURRENT_DOWNLOAD=5 yarn build trabalhou para mim

Eu tive o mesmo problema e consigo resolver redimensionando a janela do terminal.

Por favor, consulte os últimos comentários sobre # 4666.

Eu também tive o mesmo problema. Resolvi com:

rm -r node_modules/ 
rm -r .cache
sudo chown -R login:login . 
fuser -k 8000/tcp 
yarn 
gatsby build
gatsby develop

Espero que possa ajudar

Parece que esse é um problema peculiar. Aqui está minha experiência com isso:

• ❌ Vi esse problema no macOS High Sierra (usando o iTerm)
• ✅ Comecei a usar GATSBY_CONCURRENT_DOWNLOAD=50 gatsby develop e o problema foi embora (esse foi o caso por algumas semanas)
• ❌ Eu atualizei para o Mojave e atualizei minha instalação global do Gatsby para 2.7.47 e então comecei a ver o problema novamente (usando o iTerm)
• ❌ Tentei mudar GATSBY_CONCURRENT_DOWNLOAD para 5
• ❌ Tentei soprar .cache e node_modules
• ❌ Tentei redimensionar a janela do iTerm enquanto executava gatsby develop (ambos com 50 e 5)
• ❌ Executou GATSBY_CONCURRENT_DOWNLOAD=50 gatsby develop no aplicativo "Terminal", não no iTerm
• ✅ Duas semanas depois, tentei usar GATSBY_CONCURRENT_DOWNLOAD=50 gatsby develop no iTerm e redimensionei a janela algumas vezes durante o processo e funcionou.

Prematuramente pensei que estava funcionando com aquele último, mas então desligou. Espero que isso ajude outras pessoas. Ainda parece que não está bem definido, mas estamos chegando lá devagar, mas com segurança.

Atualização: Hoje isso funcionou para mim. Não tenho certeza se é porque redimensionei a janela do iTerm no ponto certo do processo ou porque a observei ir de 93% para 100%, mas algo estava diferente desta vez.

Adicional para usar GATSBY_CONCURRENT_DOWNLOAD = 5, adicione o seguinte código em seu arquivo gatsby-node.js

// Internacionalização
exportações.onPostBuild = () => {
ChildProcess.execSync ("ps aux | grep jest | grep -v grep | awk '{print $ 2}' | xargs kill")
console.log ('Copiando localidades')
fs.copySync (path.join (__ dirname, '/ src / locales'), path.join (__ dirname, '/ public / locales))
}

532314892 @bradydowling :

Não tenho certeza se é porque redimensionei a janela do iTerm no ponto certo

Embora tivesse o mesmo problema, redimensionei minha janela do iTerm e bam - de repente, também continuou. Eu não sei se isso é uma coincidência selvagem, ou ...

@bradydowling @davegregg Uau, que bizarro. Redimensionar minha janela do iTerm resolveu o problema.

@TylerBarnes Seja o que for, sugiro que não seja específico do Wordpress. Não estou usando nada relacionado ao Wordpress.

@beauhankins E você?

@davegregg @beauhankins @bradydowling, algum de vocês pode compartilhar um repositório onde isso está acontecendo? Parece muito bizarro que redimensionar a janela do terminal resolva o problema.

@TylerBarnes ya, aqui está um repositório onde eu estava vendo. Eu não toquei nisso por um tempo.

Observação lateral: como você lida com uma situação em que clona um site do Gatsby com uma versão mais antiga do Gatsby do que a que está instalada atualmente pela CLI?

Eu estava executando o commends c / no terminal de código do VS (eu uso o bash). Estava demorando uma eternidade e, como sugerido acima, saí do modo de tela inteira e funcionou.

@bradydowling, obrigado por compartilhar seu repo! Para usar versões mais antigas do Gatsby do que cli, você pode fazer um script npm para desenvolver e construir.

{
  "scripts": {
    "develop": "gatsby develop",
    "build": "gatsby build"
  }
} 

em seguida, executar npm run develop ou yarn develop usará a versão local em seu projeto.

Estamos investigando este problema, mas enquanto isso, qualquer pessoa com o problema pode ser capaz de contorná-lo executando CI=1 yarn build , pois isso deve usar uma biblioteca de repórter diferente nos bastidores. Se você tentar fazer isso e funcionar, por favor nos avise!

@dustinhorton :

versão v2 @ https://github.com/dustinhorton/gatsby-v2-issue. Estou construindo há cerca de 50 minutos neste ponto.

Fwiw. Sei que isso foi postado há cerca de um ano, e Gatsby mudou consideravelmente desde então. Ao executá-lo em minha máquina (e definir a versão gatsby para * em package.json), a compilação parece ser concluída em cerca de 2.000 segundos (~ 33 minutos).
Além disso, ao atualizar o cli, há agora uma barra de progresso, o que faz uma enorme diferença em termos de quanto tempo "parece", já que você obtém um ciclo de feedback mais concreto.

A etapa de sourcing leva quase todo esse tempo (segundos de 1968/1975). O download de arquivos remotos é a maior parte disso (1845 segundos).

Isso não me surpreende quando vejo uma única viagem de ida e volta para este servidor:

# Starting requestInQueue, _concurrentRequests= 10
@ requestInQueue for 75 tasks { concurrent: 10 } { id: 'url' }
@ Fetch http://dustinhorton.com/gatsby-wp/wp-json/wp/v2/media?per_page=100&page=4: 2587.339ms
@ Fetch http://dustinhorton.com/gatsby-wp/wp-json/wp/v2/media?per_page=100&page=10: 2661.584ms
@ Fetch http://dustinhorton.com/gatsby-wp/wp-json/wp/v2/media?per_page=100&page=8: 2695.937ms
@ Fetch http://dustinhorton.com/gatsby-wp/wp-json/wp/v2/media?per_page=100&page=2: 2738.339ms
@ Fetch http://dustinhorton.com/gatsby-wp/wp-json/wp/v2/media?per_page=100&page=6: 2853.199ms

Cada solicitação leva cerca de 2 a 4 segundos. As 75 páginas buscadas inicialmente durante a exploração levam 18 segundos no total (!). Eu tenho uma conexão rápida e posso reproduzir esse tempo com um wget simples.

Portanto, a etapa mais longa tentará baixar cerca de 7.500 recursos. Considerando que uma única solicitação leva de 2 a 4 segundos, não me surpreende que demore tanto.

Mesmo assim, noto algumas pausas durante o trecho principal de download de 1845 segundos. Não tenho certeza se isso é apenas o servidor limitando os dados ou não (eu configurei a simultaneidade para 5).

Tentei mexer na largura do terminal (estou no xfce linux, fwiw) e, embora isso ocasionalmente coincida com o progresso, estou agora convencido de que é mais coincidência do que causalidade.

Resumindo: embora eu possa reproduzir o download lento e o progresso aparentemente "travado", todos os sinais atualmente apontam para que isso seja causado pela espera da resposta do servidor. Além disso, a largura do terminal não parece afetar isso.

Dito isso: existe a possibilidade de que a saída do terminal fique presa de alguma forma ao atualizar a barra de progresso em uma largura muito particular. Embora isso seja improvável, não é impossível. Portanto, realmente precisamos de um repro que possamos executar por conta própria (portanto, sem autenticação). E de preferência um que _não_ dependa de um servidor remoto, pois não quero martelar o servidor.

Vou atualizar os rótulos sobre esse problema de acordo.

A reprodução postada em https://github.com/gatsbyjs/gatsby/issues/6654#issuecomment -438667221 por @njmyers não existe mais

O repo postado em https://github.com/gatsbyjs/gatsby/issues/6654#issuecomment -562607399 por @bradydowling requer um monte de permissões que não tenho e parece ter problemas semelhantes com o tempo de ida e volta

@ Fetch http://topazandsapphire.com/wp-json/wp/v2/media?per_page=100&page=7: 25025.257ms
@ Fetch http://topazandsapphire.com/wp-json/wp/v2/media?per_page=100&page=4: 27791.269ms
@ Fetch http://topazandsapphire.com/wp-json/wp/v2/media?per_page=100&page=2: 37817.874ms
@ Fetch http://topazandsapphire.com/wp-json/wp/v2/media?per_page=100&page=5: 38056.989ms
@ Fetch http://topazandsapphire.com/wp-json/wp/v2/media?per_page=100&page=3: 38446.504ms
@ Fetch http://topazandsapphire.com/wp-json/wp/v2/media?per_page=100&page=6: 43799.842ms

Esta etapa de sourcing não está realmente mostrando nenhum indicador de progresso, exceto para o spinner e as etapas ocasionais estão sendo registradas e ainda levam alguns minutos, então talvez possamos pelo menos mostrar algum tipo de indicador de progresso, se isso fizer sentido.

Além disso, talvez ajude apontar o tempo médio para buscar um recurso, pois isso é uma indicação do porque "Gatsby" é lento, quando na verdade é causado pela viagem de ida e volta.

Nesse repositório, até mesmo o download de 589 arquivos remotos demorava cerca de 5 minutos, com a barra de progresso frequentemente travada sem motivo aparente.

Após o bootstrap, a compilação falha para mim porque os arquivos estão faltando.

@pvdz Terei que brincar com isso de novo (desisti por um tempo), mas há certos arquivos que geram problemas de permissão mesmo quando compilados com sucesso, então percebi que eles podem ser ignorados.

Mas, para resumir sua postagem, você está dizendo que certas etapas (download) demoram muito e devemos esperar mais para que sejam concluídas?

@bradydowling Bem, parece que sim. :)

FTR: Eu acompanhei um pouco a coleta de recursos. Para lançar alguma luz sobre os horários;

Fetch time for http://topazandsapphire.com/wp-content/uploads/2016/01/IMG_6084.jpg: 15605.630ms
Started actually fetching http://topazandsapphire.com/wp-content/uploads/2016/01/IMG_6036.jpg
Fetch time for http://topazandsapphire.com/wp-content/uploads/2016/01/IMG_6051.jpg: 6447.272ms
Started actually fetching http://topazandsapphire.com/wp-content/uploads/2016/01/IMG_6034.jpg
Fetch time for http://topazandsapphire.com/wp-content/uploads/2016/01/IMG_6045.jpg: 6944.355ms
Started actually fetching http://topazandsapphire.com/wp-content/uploads/2016/01/IMG_6029.jpg
Fetch time for http://topazandsapphire.com/wp-content/uploads/2016/01/IMG_6036.jpg: 6401.541ms
Started actually fetching http://topazandsapphire.com/wp-content/uploads/2016/01/IMG_6027.jpg

A propósito, são arquivos de 6 MB. Eu estou em uma conexão de 250Mbs, o que é bom para lidar com aqueles mais rápidos do que 1mbs, mas não me surpreende que o tempo de download aumente. Nenhuma quantidade de redimensionamento cli vai acelerar isso;)

Interessante. Este é apenas um blog pessoal padrão do WordPress hospedado no EC2, então não é como se fosse uma instalação gigantesca. Talvez seja porque todas essas solicitações estão sobrecarregando o host. Ou não sou nenhum especialista em WordPress, mas talvez haja algum tipo de limite de taxa WP padrão em chamadas de API REST que pode acontecer? Também estou presumindo que esse comportamento não é exclusivo deste site.

Talvez seja porque todas essas solicitações estão sobrecarregando o host.

Este é o meu palpite (ou algo parecido). Mas estou explorando um pouco de nossa própria arquitetura para verificar se estamos perdendo eficiência por meio de abstrações. Mas considerando que posso imitar a maioria das vezes relatadas com wgets / curls simples, duvido que haja muito lá.

Então, fwiw, substituí os got.stream() bits por um downloader bruto idiota:

    let r = ""
    require("http").get(url, res =>
      res
        .on("data", m => (r += m))
        .on("end", () => {
          console.timeEnd("$$ Fetch time for " + url)
          resolve(r)
        })
    )

$ Started actually fetching http://topazandsapphire.com/wp-content/uploads/2016/05/IMG_5260.jpg
$$ Fetch time for http://topazandsapphire.com/wp-content/uploads/2016/09/TRAVEL-LEISURE-2-copy.png: 1003.535ms
$ Started actually fetching http://topazandsapphire.com/wp-content/uploads/2016/05/International-Travel-Topaz-Sapphire.png
$$ Fetch time for http://topazandsapphire.com/wp-content/uploads/2016/09/IMG_4606.jpg: 3174.126ms
$ Started actually fetching http://topazandsapphire.com/wp-content/uploads/2016/05/Brunch-Topaz-Sapphire-2.png
$$ Fetch time for http://topazandsapphire.com/wp-content/uploads/2016/09/IMG_4647.jpg: 9521.157ms
$ Started actually fetching http://topazandsapphire.com/wp-content/uploads/2016/05/IMG_6978.jpg
$$ Fetch time for http://topazandsapphire.com/wp-content/uploads/2016/05/International-Travel-Topaz-Sapphire.png: 3611.910ms

Então, sim, tenho quase certeza de que os longos atrasos (pelo menos neste caso) são causados ​​pelo download. Portanto, talvez nossa melhor aposta seja melhorar o feedback enquanto esperamos pelo download :)

Muitas e muitas pessoas dizem que o redimensionamento das janelas de terminal (por qualquer motivo estranho) resolve o processo de desenvolvimento preso nos 'nós de origem e transformação'.

Infelizmente, ao usar WSL, isso não é uma solução. Preso com 'nós de origem e transformação' localmente na construção, bem como no desenvolvimento. As compilações do Netlify funcionam, mas o desenvolvimento local tornou-se impossível.

@Vacilando você pode depurar alguns links que estão sendo baixados para o seu site durante o sourcing e testar manualmente se eles baixam rápido? Como mencionei acima, um grande problema que estou vendo é que certos hosts wp são simplesmente extremamente lentos.

Portanto, se o host for lento e houver muito conteúdo para baixar, então sim, esta etapa levará muito tempo porque é tudo o que deve ser feito nesta etapa; descubra o conteúdo e baixe-o :)

Se você confirmou que o download do conteúdo em si é feito em uma fração de toda a etapa, circule novamente aqui. Nesse caso, uma reprodução seria extremamente útil :)

Talvez em um mundo ideal, você pudesse passar uma bandeira para gatsby que armazenaria
o download do recurso do site para que isso não precise ser feito repetidamente.

Outra solução ideal seria permitir um sinalizador que define algum tipo de
limitação de taxa ou aceleração no download de recursos para que não prejudique
O hospedeiro.

Alguma opinião sobre essas duas ideias?

Na quinta-feira, 19 de dezembro de 2019, às 18h09 Peter van der Zee [email protected]
escreveu:

@Vacilando https://github.com/Vacilando você pode depurar alguns links que
estão sendo baixados para o seu site durante o fornecimento e teste manualmente
se eles baixam rápido? Como mencionei acima, um grande problema que estou
vendo é que certos hosts wp são simplesmente extremamente lentos.

Então, se o host for lento e houver muito conteúdo para baixar, então sim
esta etapa levará muito tempo porque isso é tudo que deve ser feito em
esta etapa; descubra o conteúdo e baixe-o :)

Se você confirmou que o conteúdo em si foi baixado em uma fração do
passo inteiro, por favor circule de volta aqui. Nesse caso, uma reprodução seria
tremendamente útil :)

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/gatsbyjs/gatsby/issues/6654?email_source=notifications&email_token=ABS4AU62367MTEWP7LJXWTLQZP5L5A5CNFSM4FLHT3T2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHLK6DI#issuecomment-567717645 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/ABS4AU7GCV4YMZQH6R37BSDQZP5L5ANCNFSM4FLHT3TQ
.

@bradydowling parte disso já existe na verdade. Você pode definir uma variável env GATSBY_CONCURRENT_DOWNLOAD para configurar o limite de solicitações simultâneas. A próxima versão principal de gatsby-source-wordpress https://github.com/gatsbyjs/gatsby/issues/19292 terá mais controle sobre como os arquivos de mídia são baixados. Quanto ao cache, os arquivos baixados são atualmente armazenados em cache, mas quando você altera um arquivo gatsby - *. Js, ele limpa o cache para evitar que um cache obsoleto cause bugs inesperados. Portanto, esse é um problema central, em vez de ser específico de gatsby-source-wordpress , mas sempre há trabalho sendo feito para melhorar o cache de Gatsby.

Parcialmente Jobs Api (# 19831) deve corrigir este problema de cache.

Sim, eu vi a parte sobre GATSBY_CONCURRENT_DOWNLOAD mais perto do topo. Pela minha experiência, isso não ajudou, então acho que minha sugestão foi em direção a um controle mais refinado, como em mb por s / m / h ou algo parecido. Talvez eu esteja apenas dizendo um disparate.

@bradydowling Estou pensando em adicionar

Hiya!

Este problema ficou quieto. Silêncio assustador. 👻

Recebemos muitos problemas, então atualmente os fechamos após 30 dias de inatividade. Já se passaram pelo menos 20 dias desde a última atualização aqui.
Se perdemos esse problema ou se você deseja mantê-lo em aberto, responda aqui. Você também pode adicionar o rótulo "não obsoleto" para manter esse problema aberto.
Como um lembrete amigável: a melhor maneira de ver esse problema, ou qualquer outro, corrigido é abrir uma solicitação pull. Verifique gatsby.dev/contribute para obter mais informações sobre como abrir PRs, fazer a triagem de problemas e contribuir!

Obrigado por fazer parte da comunidade Gatsby! 💪💜

Eu vou fechar isso agora.

Se você acha que tem um problema de origem do wordpress, primeiro confirme se os atrasos não são causados ​​por um servidor wordpress lento. Em seguida, abra um _novo_ problema (mas sinta-se à vontade para apontar novamente para este problema).

O grande número de comentários torna muito difícil rastrear a discussão. Portanto, é mais provável que abrir um novo problema resulte em uma resposta para o seu problema específico.

Eu e outros confirmamos isso no último ano e meio. meu problema original era em um vps bem ajustado. @njmyers teve uma correção provável, ou pelo menos uma melhoria, mas não conseguiu nenhuma resposta dos mantenedores sobre como eles gostariam que fosse feito.

Pensei em me fechar, mas acho que isso precisa ser divulgado como um aviso de que um site wordpress moderadamente grande NÃO é uma boa opção para o gatsby ainda.

@dustinhorton eu entendo isso. Este problema já existe há mais de um ano e meio, as coisas mudam rapidamente. Com o problema totalizando tantos comentários, é difícil mais descobrir o problema real.

Fwiw, conforme observado acima, verifiquei as últimas repros relatadas e determinei aquelas, pelo menos, causadas por controles remotos lentos. Se você tiver uma reprodução com uma versão atual de Gatsby em um controle remoto rápido, por favor me avise, mesmo que talvez já esteja postado neste tópico. Ou talvez abra um novo problema para ele (e marque-me) se quiser mais foco nisso, vou deixar isso para você :)

(_Só para ficar claro, fechamos este problema porque ele está um pouco obsoleto com muitas mensagens fora do tópico, por favor, não sinta que estamos esmagando a discussão, pois essa não é a intenção e reconhecemos que nosso trabalho não terminou aqui ! _)