¿Se puede preparar un repositorio de reproducción? La cantidad de publicaciones no debería ser un problema (al menos en este paso): la v1 podría tener problemas de memoria, pero esto sería en un paso de compilación posterior y no debería atascarse

Tenía curiosidad por saber si era un problema con Local by Flywheel y poder construir el sitio al servir WordPress a través de MAMP Pro .

Pero, ni siquiera estoy construyendo páginas de publicaciones todavía (estoy construyendo las páginas), y el tiempo de ejecución para ese paso problemático es 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: solo habilite createPage para publicaciones y la ejecución de ese elemento aumentó a 14 minutos. Brutal, pero también interesante, es solo 3 minutos más para ~ 9000 elementos más. Está sentado en ⠁ run graphql queries durante mucho tiempo actualmente.

editar: que duró 419.470 s, o 7 minutos.

@pieh Vaya, acababas de responder. Puedo intentar instalar este sitio de forma remota mañana.

Y destinado a incluir, esta última línea es donde se cuelga a través de Local, y tarda una eternidad a través de 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 No he confirmado que esto se construirá con éxito (ahora con el control remoto de WordPress, está tomando horas), pero ciertamente revela el problema: https://github.com/dustinhorton/gatsby-issue

Debería poder simplemente clonar eso y construir.

Solo se ejecutó dos veces durante más de 10 horas sin que el sitio terminara la construcción. Hágame saber qué más puedo proporcionar para ayudar con la depuración.

¿Podría intentar actualizar a v2? Hemos realizado un montón de mejoras de velocidad en diferentes subsistemas de gatsby que deberían acelerar drásticamente los sitios grandes como este.

@KyleAMathews Le daré una oportunidad esta noche, gracias.

@KyleAMathews versión v2 @ https://github.com/dustinhorton/gatsby-v2-issue. He estado construyendo durante unos 50 minutos en este punto.

Matarlo ahora. El sitio aún no se ha construido.

Otra cosa que puede intentar es habilitar el seguimiento https://next.gatsbyjs.org/docs/performance-tracing/

Todavía no hemos agregado soporte de rastreo a gatsby-source-wordpress, pero los informes de rastreo pueden ayudarlo a descubrir dónde se está estancando.

Si alguien más está interesado en investigar esto, un gran PR sería agregar soporte de rastreo a gatsby-source-wordpress. ¡Déjame saber si estás interesado!

Lamentablemente, voy a necesitar rescatarme de esto, ya que necesito pasar todo el tiempo que tengo transfiriéndome a un tema tradicional, un poco aplastado por no poder usar Gatsby. Todo lo demás se siente tan al revés.

Lo sentimos, no hemos tenido la oportunidad de investigar esto :-( Sprint ahora para sacar v2.

¿Existe la posibilidad de que pueda dejar el sitio de WP funcionando? Definitivamente parece que hay un error aquí que debería corregirse.

Twitteé pidiendo ayuda, así que espero que alguien salte pronto sobre esto :-)

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

Vaya, eso es genial, muchas gracias. El sitio no va a ninguna parte por el momento (y migraré una copia y actualizaré el repositorio de reproducción si es necesario).

@dustinhorton, por lo que vale, también he notado problemas para construir un proyecto más grande (~ 1,000 publicaciones) en Local by Flywheel en comparación con nuestro entorno de producción con un CDN al frente.

Las respuestas de REST para Gatsby son 10-20 veces más largas de Local que de producción, por lo que el sitio tarda una eternidad en construirse. Todavía no he dedicado tiempo a depurar el problema en Local, pero está en mi lista de tareas pendientes :)

@KyleAMathews Podría echar un vistazo a agregar rastreo a source-wordpress.

@Khristophor ¡Eso sería genial!

@dustinhorton Estoy viendo 404 para las imágenes en su sitio de muestra (https://dustinhorton.com/gatsby-wp/wp-content/uploads/2018/07/IMG_9906.jpg, por ejemplo) que podrían estar inflando la compilación hora. ¿Alguna posibilidad de que puedas buscarlos en los caminos?

Las solicitudes WP_MEDIA se ejecutan bastante rápido con resultados, así que pensé que estaba en
claro, pero puedo echarle un vistazo más adelante esta semana si lo crees
puede ser el caso.

El miércoles 8 de agosto de 2018 a las 5:45 p.m. Chris Wiseman [email protected]
escribió:

@dustinhorton https://github.com/dustinhorton Estoy viendo 404 para el
imágenes en su sitio de muestra (
https://dustinhorton.com/gatsby-wp/wp-content/uploads/2018/07/IMG_9906.jpg,
por ejemplo) que podría estar inflando el tiempo de construcción. Cualquier oportunidad que pudieras
buscar en los caminos para esos?

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/gatsbyjs/gatsby/issues/6654#issuecomment-411562589 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAXFNRHTA-vqIwCTtioejUL-Ei3nM0Lbks5uO1vygaJpZM4VZ57n
.

Eso es cierto, pero parte del paso de fuente y transformación es descargar todos los elementos multimedia que encuentra en la respuesta REST:
https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-source-wordpress/src/normalize.js#L434

Obtener 404 en imágenes 7504 puede estar causando algunos problemas;)

Creo que he limpiado todos los 404. Intentaré construir esta noche. Gracias a todos.

Aparentemente sin cambios:

~/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

Y ha estado ahí durante unas 8 horas.

@dustinhorton ¿qué tipo de hosting estás usando? Creo que está acabando con su caja de producción con la cantidad de solicitudes. Creo que logré terminar (después de bastante tiempo, no ocho horas) configurando las conexiones simultáneas en algo bajo, como 1 o 2.

Es un VPS decente en Linode. Puedo modificar la configuración si eso ayuda. Pero el problema también ocurre a nivel local.

https://github.com/gatsbyjs/gatsby/blob/46290c2b0e7894fca036bdcc658a5d1936c4221f/packages/gatsby-source-filesystem/src/create-remote-file-node.js#L133 -L159 cuando esto a veces no funciona correctamente de archivos: la solicitud de red se resuelve, pero la secuencia de escritura del archivo nunca termina (o fallan los errores). Creo que sería genial agregar algún tipo de tiempo de espera después de que responseStream termine para esperar a que fsWriteStream termine, y si no lo hace, destruya todos los recursos e intente escribir el archivo nuevamente (posiblemente hacer algunos reintentos) y, de hecho, se producen errores cuando en realidad no puede hacer eso.

@pieh , ¿puede enviar un código actualizado para este archivo?

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

@ aman-developer, todavía no hay solución para esto; de lo contrario, se publicaría. El problema con este problema es que no hay una forma confiable de reproducirlo, por lo que cualquier solución es conjetura. El problema es que en algunos casos (puede ser un hardware y / o un sistema operativo específico) el sistema de archivos writeStream no termina y se atasca sin arrojar errores, por lo que cualquier solución aquí realmente está tratando de solucionar problemas en fs paquete / hardware / sistema operativo no ser confiable: /

¿Ha tenido problemas para reprogramar con mi repositorio y sitio? Es consistente para mí.

Utilizo createRemoteFileNode para buscar imágenes remotas y experimento el mismo problema: la descarga se atasca en alrededor de 680 / 780ish.

En createRemoteFileNode, hay un detector del evento downloadProgress que se agregó en https://github.com/sindresorhus/got/releases/tag/v8.0.0 pero los usos de gatsby-source-filesystem obtuvieron 7.1.0.

Intenté actualizar a la última versión 9.2.2 y ahora pude descargar todas las imágenes con éxito.

Agregue esto en package.json:

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

También parece haber algunas correcciones críticas en la versión posterior a 7.1.0, como errores de transmisión que no se reenvían correctamente, etc. (https://github.com/sindresorhus/got/releases/tag/v8.0.1)

Intenté actualizar got , pero a veces me quedo atascado, pero vale la pena hacerlo de todos modos. Solo tenga en cuenta que las cosas de downloadProgress necesitarán deshabilitarse o alguna salida más agradable, porque la terminal / consola se llena de spam con el progreso al usar eso

Pude ejecutar gatsby develop después de ~ 25 minutos, pero tuve que reducir la concurrencia en create-remote-file-node.js de 200 a 20. Obtuve algunos 22 TimeoutErrors (pero se volvieron a descargar al ejecutar gatsby development nuevamente) después de poner registros en esa captura vacía en processRemoteNode.

No estoy seguro de si es por got, pero tal vez pueda experimentar con otros 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' }

Obtengo los mismos errores con prismic

Actualicé a "got": "^ 9.2.2" ¡ahora está funcionando!

Definitivamente necesito echar un vistazo para actualizar nuestra versión got . Este es un problema de intermitencia, por lo que podría ser una coincidencia que haya funcionado. @RobinHerzog , háganos saber si tendrá problemas similares con la versión mejorada de got

La actualización de got redujo significativamente el tiempo de compilación de mi repositorio de reproducción, pero aún así, la última vez que lo intenté me llevó casi una hora.

@dustinhorton, ¿qué parte de la compilación estaba extrayendo imágenes (o source and transform data ya que no mostramos explícitamente cuánto tiempo toma la descarga de archivos)?

Tengo imágenes de 150 MB con una conexión a Internet de 1 GB. Ahora está funcionando. Necesito 30 segundos para descargar y continuar construyendo.

También tengo este problema constantemente. Actualizar got no resolvió esto por mí. ¿Algún éxito al agregar seguimiento adicional a source-wordpress para que podamos intentar depurar cuál es el problema?

Intenté cambiar concurrentRequests y perPage , así como actualizar got a la última versión, pero ninguno funcionó. Ahora mismo puedo buscar categories , posts , pages y tags , pero cuando incluyo users o media , justo después de =END PLUGIN=== , el complemento regresa con un error: TypeError: Cannot read property 'id' of undefined .

Si incluyo todas las rutas y pongo en lista negra las a las que no tengo acceso, obtengo =END PLUGIN=== pero nunca termina ... Esto se aplica a toneladas de sitios web que probé, así que supongo que podría ser mi sistema de alguna manera . Si alguien quiere probar esto, aquí está la configuración:

    {
      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",
        ],
      },

PD: Una URL que _ logré recuperar fue https://wesbos.com/

FELIZ ACTUALIZACIÓN: Logré que funcionara (_para sitios más pequeños_) con includedRoutes , incluso con users y / o media al incluir taxonomies en la consulta . Ahora no obtengo el error 'id' of undefined : D

@pieh Creo que los users y media dependen de taxonomies , por lo que tal vez deberían venir por defecto siempre que la configuración contenga alguno de estos tipos. ¡Avíseme si puedo ayudar con la resolución de problemas! Como nota final, este error taxonomies parece no estar relacionado con el proceso de construcción infinito. Con sitios de más de ~ 500 archivos multimedia, ¡todavía no puedo terminar el proceso de compilación!

ACTUALIZACIÓN Número 2 : Me las arreglé para que funcione por queroinvestiragora.com , que tiene 600 archivos multimedia pero solo 70 publicaciones, toma aproximadamente 15 segundos después de =END PLUGIN=== , pero funciona. Sin embargo, www.clubedospoupadores.com tiene 702 archivos multimedia y 336 publicaciones y no se compilará.

PD: Mi configuración en estos experimentos es:

    {
      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",
        ],
      },
    },

Hola,

Logré agregar el rastreo siguiendo los pasos descritos aquí https://www.gatsbyjs.org/docs/performance-tracing/ . Desafortunadamente, no proporcionó mucha información, ya que simplemente me dijo que, de hecho, los nodos de origen y transformación están demorando bastante.

Sin embargo, he realizado algunas de mis propias depuraciones sobre el problema después de tener un comportamiento no determinista que involucra imágenes. Al ejecutar el script de desarrollo o compilación, obtendría un caso en el que no se descargarían todas las imágenes y los nodos de localFile no se completarían. Después de profundizar en el código, he determinado que parece haber un problema aquí.

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

Para mí, el nodo createRemoteFile estaba fallando debido a errores de tiempo de espera del servidor y los valores predeterminados para devolver nulo. Tuve que agregar algunos registros para crear el nodo createRemoteFile también para determinar esto y obtener las respuestas reales del servidor. Dado que estos nodos no se completan y no tienen ID, no se registran en la caché. Los archivos tmp se eliminan y el sistema de archivos gatsby-source-file estaba incompleto. Por alguna razón (no he mirado tan lejos todavía) al ejecutar el script de compilación nuevamente, el sistema de archivos de origen se eliminó probablemente porque el script detecta que el sistema de archivos no es válido o está incompleto. Para mí, fue este proceso el que creó un bucle y provocó errores en compilaciones futuras, ya que el sistema de archivos nunca se completa.

Estoy trabajando en una solución que parece aliviar algunos de los problemas, al menos con respecto a grandes cantidades de imágenes. Cuando el script de desarrollo o compilación tiene éxito en la descarga de todas las imágenes la primera vez, posteriormente no se elimina y luego el proceso de compilación ocurre con bastante rapidez, ya que las imágenes se almacenan en caché correctamente mediante gatsby-source-filesystem. Mi construcción pasó de 15 minutos a 1 minuto.

No estoy seguro de si esto está relacionado con compilaciones que tienen una gran cantidad de publicaciones. Mi problema estaba directamente relacionado con la descarga de 1,6 GB de datos de imagen.

Esta es la primera vez que trabajo con complementos de origen para gatsby, por lo que si alguien tiene alguna idea o consejo al respecto, ¡se lo agradecería! Debería poder publicar mi repositorio más tarde hoy. Estoy trabajando para que use mi versión local de gatsby-source-filesystem sin complicaciones.

Hola,

Continuando con mi comentario de hace unos días. Aquí está mi repositorio.

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

Estoy usando un monorepo en este proyecto, así que aquí hay algunos pasos si desea ejecutar el repositorio localmente.

1. Asegúrese de tener la última versión de Yarn 1.12.3
2. Clonar la rama del complemento git clone https://github.com/njmyers/byalejandradesign.com.git -b wordpress-plugin
3. Ejecutar yarn && yarn bootstrap
4. Navega a la carpeta gatsby para que puedas mirar solo esa carpeta cd packages/web
5. Ejecute yarn develop o yarn build-web . ¡Debería completarse correctamente la primera vez y las ejecuciones posteriores del mismo comando darán como resultado compilaciones mucho más rápidas! Los nodos de origen y transformación toman 222 segundos para mí, ya que me tomaban 3 veces más antes y / o no se completaban.
6. Si desea ver lo que está sucediendo realmente durante la fuente y la transformación, puede buscar en su explorador de archivos en /packages/web/.cache/gatsby-source-filesystem y verá que los archivos se están creando allí.

Reescribí la función downloadMediaFiles por completo. Puede ver ese archivo en este enlace https://github.com/njmyers/byalejandradesign.com/blob/wordpress-plugin/packages/gatsby-source-wordpress/src/download-media-files.js

Probablemente sea más detallado de lo que debe ser, pero tuve que hacer esto para descubrir todo lo que está sucediendo. La funcionalidad que cambié es agregar un rechazo de promesa cuando createRemoteFileNode devuelve nulo. Luego uso una función downloadRunner para acelerar las solicitudes de modo que no lleguen todas al servidor a la vez, así como un reintento en el rechazo de promesas. Agregué un acelerador de 200 ms entre cada solicitud createRemoteFileNode. Estoy seguro de que este valor podría modificarse y algo de esto podría ser más adecuado para agregar a createRemoteFileNode directamente.

Si alguien tiene curiosidad, la instalación de WP es una microinstancia EC2 mientras que las imágenes están detrás de una distribución de CloudFront. Personalmente, nunca tuve ningún problema con la obtención de publicaciones, mi problema fue con la obtención de imágenes y creo que la mayoría de los problemas que tiene la gente se deben a esto.

Además, si alguien quiere rastrear o depurar su propio sitio, sugiero comenzar aquí ...

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

Agregué el registro a la cláusula de captura y pude determinar que los nodos de la imagen no se estaban procesando correctamente ya que recibía errores de tiempo de espera y luego devolvía un valor nulo.

@njmyers Acabo de verlo brevemente y estoy pensando que si esto funciona, deberíamos usar un enfoque similar en createRemoteFileNode directamente. Estamos usando queue allí, por lo que los consumidores de esta función ( gatsby-source-wordpress en este caso) no deberían tener que preocuparse por esto. Una cosa que es potencialmente problemática es que el acelerador de 200 ms; tal vez podríamos comenzar sin él y cuando empecemos a ver problemas, aplicar el acelerador automáticamente (por nombre de host)

@pieh Sí, ese probablemente sería el lugar para aplicar esta lógica. Para mí, la limitación fue una forma de abordar esto y diagnosticar el problema, así que estoy de acuerdo en que createRemoteFileNode debería poder manejar esto por sí solo.

Sin embargo, es particularmente problemático el comportamiento actual de fallar silenciosamente los errores y devolver nulo. En mi opinión, debería haber alguna comunicación sobre el fracaso o el éxito de la operación. Creo que createRemoteFileNode podría hacerse más robusto con la siguiente funcionalidad.

1) Crea conexiones con entusiasmo
2) Si hay errores del servidor, comience a acelerar y / o vuelva a intentarlo si es necesario
3) Establezca algunos valores predeterminados razonables para la limitación / reintento
4) Cree un punto de entrada para ajustar la limitación / reintento
4) Rechace una promesa si por alguna razón el nodo no puede ser procesado.

También puedo decir que jugué con los valores de tiempo de espera aquí https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-source-filesystem/src/create-remote-file-node.js#L135 - L141. Aunque eso aumentó la probabilidad de una respuesta exitosa, todavía tenía que agregar manejo para asegurar una respuesta exitosa.

Lo más probable es que el punto de entrada correcto para esta lógica esté aquí.

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

Donde, si las tareas fallan, se reintentan y / o fallan y finalmente se rechazan.

También lea brevemente los documentos queue . Veo lo que estás diciendo acerca de que queue puede administrar esto por sí mismo.

@njmyers buen trabajo de investigación! ¡Definitivamente estoy de acuerdo en que la descarga de archivos debe ser mucho más inteligente!

De hecho, podría ser bueno extraer la parte de descarga del archivo en su propio paquete que se enfoca en este problema de descargar y almacenar en caché archivos remotos.

Existe una buena posibilidad de que necesitemos usar la funcionalidad en varios lugares en Gatsby y en el futuro, y es algo que otras personas en Internet también querrían usar.

@KyleAMathews, ¿ te refieres a extraer createRemoteFileNode a un paquete separado?

No solo la parte de descarga de archivos y almacenamiento en caché. createRemoteFileNode simplemente llamaría a este paquete y obtendría una promesa que se resolvería cuando el archivo se descargara (o se devolviera del caché).

También tengo este problema con mi propio complemento fuente de cabina.

Veo que realmente sería más como extraer estas porciones de código en un paquete separado ...

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

Este parece ser el código que se ocupa específicamente de la descarga y el almacenamiento en caché, corríjame si me equivoco. ¡Feliz de trabajar en esto! Solo estoy tratando de averiguar cómo funciona en el ecosistema en general.

¿Se aceptaría un RP para corregir solo gatsby-source-wordpress y luego extraer la corrección? Tengo problemas para usar el @njmyers tal como está, y parece que es una gran mejora.

@dustinhorton no estoy seguro de si esto ayuda, pero descubrí que si desea usar un complemento local, es mejor apuntar a gatsby directamente al archivo package.json. Estaba teniendo problemas para que gatsby encontrara mi complemento local hasta que comencé a especificarlo explícitamente.

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

Todavía estoy feliz de trabajar en este problema e incluso en el nuevo complemento como se discutió. Solo busco una pequeña guía sobre cómo integrar esto, ya que parece un cambio disruptivo que podría afectar muchas otras cosas que no conozco. @KyleAMathews ¿

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

Es la parte que debe extraerse en su propio paquete. Dicho esto, es una de las funciones principales de createRemoteFileNode y quiero asegurarme de hacerlo correctamente para que pueda integrarse de nuevo en el ecosistema correctamente.

@njmyers En general, está en lo correcto con la selección de su código; también

@dustinhorton Creo que es razonable usar esto en el complemento de wordpress primero (principalmente porque está prácticamente hecho).

@pieh ¡Muchas gracias por tu aclaración! Empezaré a trabajar en un nuevo complemento.

Con respecto a una solución temporal de wordpress-source, mi única otra pregunta sería qué hacer aquí

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

Por el momento, todavía sería posible tener errores de red y es necesario que haya una cláusula de captura para toda la función downloadMediaFiles. ¿Cuál es el comportamiento normal para pasar errores a gatsby? Me complacería agregar ese código en el complemento de wordpress para pasar correctamente los errores de red al controlador correcto. ¿Quizás podríamos mostrar un mensaje de error y una referencia a este problema? ¡Gracias por su ayuda!

@njmyers Gracias, sí, estaba replicando su configuración lo más fielmente posible, aparte de que es un monorepo (incluida la referencia a package.json ). Ejecutar develop solo dio errores como si no hubiera gatsby-source-wordpress . Lo intentaré de nuevo aquí en breve.

Recreó más fielmente su monorepo, y curiosamente está sentado en source and transform nodes , como estaba con el gatsby-source-wordpress no bifurcado antes de degradar la dependencia got.

@pieh Capaz de responder a su consulta @ https://github.com/gatsbyjs/gatsby/issues/6654#issuecomment -442536931?

@dustinhorton Sí, debería estar ahí durante bastante tiempo también si tienes muchas imágenes. Mi bifurcación arrojará unhandled promise rejection si un archivo remoto no se descarga. Es por eso que me gustaría poder tener algún mecanismo para manejar adecuadamente este escenario.

Creo que también leí en otro hilo que se habló de integrar también algún tipo de administrador de progreso, ya que esto proporcionaría comentarios sobre el estado del complemento.

Si busca en el sistema de archivos de su sistema operativo en project-root / .cache / gatsby-source-filesystem, debería poder ver todas las imágenes que se están descargando. En mi caso, ahora son casi 400 imágenes, por lo que lleva bastante tiempo. Sin embargo, antes de usar mi versión bifurcada, el complemento fallaría silenciosamente en un error y luego nunca progresaría causando el problema donde la fuente y la transformación tomarían horas ...

¿Tienes un repositorio? Me encantaría poder probarlo en otro sitio ya que hasta ahora solo lo he probado en una situación de la vida real en mi sitio.

@njmyers Eso es una regla. Si no le importa, envíeme un correo electrónico: [email protected] , o simplemente busque una invitación. Prepararé algo esta noche.

Actualizar got resolvió todos los problemas.

El problema con got@9 es que requiere el Nodo 8 (https://github.com/sindresorhus/got/releases/tag/v9.0.0), por lo que no podemos actualizar el cajero automático :(

Deberíamos poder actualizar al menos a got@8 , pero no estoy seguro de si esto solucionará los problemas

got@8 parece implementar el almacenamiento en caché HTTP compatible con RFC 7234, por lo que gatsby-source-filesystem podría proporcionar su propio adaptador de caché del sistema de archivos. Lo que al menos debería reducir el tiempo dedicado a la fuente y transformar los nodos la segunda vez, dado que el recurso se puede almacenar en caché.

Hola!

Este tema se ha silenciado. Silencio espeluznante. 👻

Tenemos muchos problemas, por lo que actualmente cerramos los problemas después de 30 días de inactividad. Han pasado al menos 20 días desde la última actualización aquí.

Si no detectamos este problema o si desea mantenerlo abierto, responda aquí. ¡También puede agregar la etiqueta "no obsoleto" para mantener este problema abierto!

¡Gracias por ser parte de la comunidad de Gatsby! 💪💜

@gatsbot Sigue siendo un problema.

Se le pidió que contribuyera con una publicación de blog para todos ustedes. No puedo hacerlo porque está atascado en los nodos de origen y transformación. Vi el otro problema, pero no veo dónde hay una solución para esto. Es una bifurcación de gatsbyjs, último upstream. Solo pude ejecutar esto una vez. Siempre está atascado transformando nodos.

No es posible tomar capturas de pantalla de algunos sitios durante la construcción. Agregaré los sitios ofensivos por la mañana.

@ twhite96 Me encontré con el problema y lo que funcionó para mí fue eliminar los archivos temporales que todavía tenía abiertos (de emacs), no estoy seguro de si eso te ayudará o no, pero permitió que mi compilación avanzara.

Parece que esto sigue siendo un problema ...

enfrenta el mismo problema al usar gatsby-source-s3 para sacar 100 fotos y transformarlas en nítidas. ¿Alguien ha descubierto una solución?

De alguna manera, mi problema se solucionó (¿al azar?). Estos son los pasos que tomé, creé un nuevo bucket de s3 con menos imágenes (para probar) y luego intenté construir y se construyó con éxito de manera muy rápida. Luego decidí regresar e intentar sacar del cubo original y ahora, de repente, se construyó con éxito en 49 segundos cuando originalmente duraba horas. No sé cómo el simple cambio en los enlaces del cubo solucionó el problema, pero espero que esto ayude a alguien a resolverlo. tal vez tenga que ver con el caché?

Hola a todos. Actualicé la versión de mi complemento local que estaba usando para un sitio que tenía este problema. Creo que es una mejor implementación ya que usa 'better-queue' antes de 'createRemoteNode' y pasa el parámetro 'concurrentRequests'. Es un poco redundante ya que 'createRemoteNode' ya usa una cola, pero independientemente de que esta versión parezca funcionar bien con las actualizaciones recientes de gatsby y brinda retroalimentación sobre el progreso de los archivos. Intentaré conseguir un PR para esto. Perdón por las demoras. Sé que dije que trabajaría en esto antes, ¡pero he estado bastante ocupado!

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

@njmyers

Muchas gracias. Tu versión resolvió algunos problemas que estaba teniendo. Combiné eso con una línea o dos para filtrar la descarga de 25 GB de mp3, ¡y ahora estoy listo!

Definitivamente sigue siendo un problema.
He intentado compilar mi proyecto durante las últimas 24 horas. De aproximadamente 12 intentos, 3 tuvieron éxito con salidas y conexión WP real. ¿Hay alguna solución para esto?
Por cierto, he intentado usar la versión @njmyers del complemento (¡trabajo increíble, en realidad!), Pero los resultados fueron mixtos. A veces, se quejaba de wordpress_parent o Date y, finalmente, se bloqueaba, pero no podía averiguar qué estaba pasando realmente con estos errores. En otras compilaciones, diferentes errores (pero compilan, lo cual es interesante), lo que en realidad causa problemas en GraphQL.

@lucassilvagc ¿puedes publicar algunos resultados? Me alegro de que la gente esté probando y probando la rama. ¡Hagamos que funcione mejor para que podamos abrir el PR!

@njmyers ¡Seguro!

Una descripción general rápida de lo que está sucediendo:

Mi sitio web actualmente funciona con archivos de imagen de ~ 1940, tal vez por culpa de WordPress al crear varios archivos de imagen varias veces. Si utilizo un _gatsby-source-wordpress_ vainilla, el problema aparece según lo previsto (hay una compilación "vainilla" que hice ayer por la noche en otro entorno de compilación, que devuelve el mismo problema que estamos discutiendo sobre este tema. build funciona y compila cuando se devuelven todos los archivos de imagen). Al usar su complemento (reemplazando todos los archivos dentro de node_modules / gatsby-source-wordpress (corríjame si me equivoco en esto)), _gatsby Develop_ me devuelve lo siguiente:

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

Después de un rato, da como resultado:

'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

PD: esta fue una compilación básica de gatsby-source-wordpress que fue _ "convertida" _ a la suya reemplazando los archivos, como dije anteriormente. Creo que el hecho de que no pueda consultar todas las páginas está relacionado con que no se generen nodos. También quiero notar que esta compilación es igual a mi versión básica que funciona cuando este problema no aparece.

También quiero notar que agregar rutas parece causarme el mismo problema inicial (ya que quería evitar diferentes páginas que no están relacionadas o que devolverán errores debido a múltiples capas de protección sobre WordPress). Simplemente no sé si las rutas que he enumerado son correctas o si me falta algo después.

Estoy muy contento con su respuesta, este problema actualmente está siendo un gran revés para mi proyecto y me alegra que todavía esté al tanto de este problema. ¡Muchas gracias!

Tener el mismo problema con más de 400 publicaciones personalizadas con campos acf y 4000 imágenes.

Actualicé, obtuve y pude compilar en 35 minutos.

No se puede volver a compilar después de actualizar got

Como era de esperar, dado que este error todavía existe en gatsby-wordpress. 35 minutos para descargar y procesar todas las imágenes sigue siendo un tiempo muy largo considerando todos los factores (velocidad promedio de Internet, potencia de procesamiento, total de archivos, etc.).
Puede intentar adaptar la versión de @njmyers a su uso específico, funcionará como un encanto al descargar cada archivo de imagen que tenga.

Como era de esperar, dado que este error todavía existe en gatsby-wordpress. 35 minutos para descargar y procesar todas las imágenes sigue siendo un tiempo muy largo considerando todos los factores (velocidad promedio de Internet, potencia de procesamiento, total de archivos, etc.).
Puede intentar adaptar la versión de @njmyers a su uso específico, funcionará como un encanto al descargar cada archivo de imagen que tenga.

Mi sitio funcionaba bien cuando tenía una pequeña cantidad de imágenes, pero cuando comencé a agregar más, esto también sucede.

@MWalid ¿cómo puedo actualizar el got ? Gracias.

He intentado construir todo el día sin éxito. tiene alrededor de 1450 imágenes.

No hemos podido implementar durante 2 días. ¿Alguien puede ayudarme a indicarme la dirección correcta en cuanto a dónde está ocurriendo esto en el código para que pueda intentar encontrar una solución?

No hemos podido implementar durante 2 días. ¿Alguien puede ayudarme a indicarme la dirección correcta en cuanto a dónde está ocurriendo esto en el código para que pueda intentar encontrar una solución?

¿Ha actualizado su got dependencia anidada de gatsby-source-filesystem para usar al menos la versión 9.4.0 ?

Si no es así, debe agregar:

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

en el package.json su proyecto Gatsby. Luego elimine node_modules y su archivo yarn.lock e instálelo nuevamente.

Nota: Esta función resolutions solo funciona para yarn . npm aún no lo ha implementado.

@anagstef ¡muchas gracias por el

Al ejecutar gatsby develop , ¿hay alguna manera de mantener la caché local en lugar de obtener datos remotos cada vez que se lanza el comando?

¡@anagstef parece estar funcionando mucho mejor! ¡Gracias por el consejo!

La salida es muy detallada al compilar con esta versión de got. ¿Sabes si hay alguna forma de eliminar esto?

@nratter ¡Me alegro de que te haya funcionado!

Sí, lo sé, es muy detallado y no se puede apagar. Arruina toda la salida útil de la consola.

Después de algunas investigaciones que he hecho, creo que se debe aquí:
https://github.com/gatsbyjs/gatsby/blob/80c7023a8bc23886939205fe52e305277294e6af/packages/gatsby-source-filesystem/src/create-remote-file-node.js#L155

Como puede ver, llama a console.log con el progreso de la descarga de cada archivo cada vez que se emite el evento downloadProgress , lo que ocurre demasiadas veces por segundo. Esto no era un problema antes, porque la antigua versión got no implementa el evento downloadProgress .

¿Quizás podamos arreglarlo con un PR? Parece depurar el código sobrante.

Tuve el mismo problema, atascado en "nodos de origen y transformación". Después de un montón de console.logs, mi problema terminó siendo problemas de tiempo de espera con la recuperación de archivos multimedia de wordpress. El problema no era que el servidor no pudiera manejarlo, sino que limitaba la tasa de destello de la nube y generaba tiempos de espera después de unas 350 solicitudes.

Pasé por alto cloudflare, fui directamente al vps y ya no veo "nodos de origen y transformación", y mi compilación finaliza.

Mi solución fue tener un wordpress local para probar, el sitio en vivo está en netlify, mientras que implementarlo no causó ningún problema.

Chicos, me las arreglé para solucionar esto ejecutando solicitudes createRemoteFileNode en serie en lugar de en paralelo.

Aquí está la función que estoy 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
}

y así es como lo estoy usando:

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

Después de descargar las imágenes, así es como se ve mi fuente y paso de transformación

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 también resuelva tus problemas.
Salud

@ancashoria ¿ dónde debería poner este código?

@ancashoria sí, tampoco tengo claro dónde colocar este código.

Esto no tiene nada que ver con el complemento gatsby-source-wordpress . Tengo el código de arriba en mi gatsby-node.js . La idea es que disparar todas esas solicitudes en paralelo provocó que fallaran, así que escribí esa función auxiliar para dispararlas una tras otra.

Supongo que también hay un problema similar en gatsby-source-wordpress , pero no estoy tan familiarizado con él.
Lo siento, no puedo ser de más ayuda.

Parece estar relacionado con imágenes masivas y conexiones lentas a Internet. Netlify pudo construir el sitio, pero mi conexión local no lo fue, ya que solo es una descarga de 1 MB / s, lo que provocó que se agotara el tiempo de espera después de 30 segundos y fallara en la imagen grande.

Tengo 1 GB de fibra y no tengo imágenes "masivas".

No estoy transformando imágenes de blogs localmente después de descargarlas en wordpress, simplemente uso su URL. Sería bueno si hubiera una configuración que deshabilita la descarga de estas imágenes en este caso.

Chicos, me las arreglé para solucionar esto ejecutando solicitudes createRemoteFileNode en serie en lugar de en paralelo.

Sí, el problema se basa realmente en el hecho de que createRemoteFileNode usa una concurrencia de 200, que es demasiado para la mayoría de los servidores WP. Tengo mis imágenes en CloudFront y estaba alcanzando algunos límites de velocidad allí.

Intenté solucionar el problema con una versión ramificada del complemento de origen durante un tiempo, pero el problema realmente no está en gatsby-source-wordpress sino en gatsby-source-filesystem . Idealmente, los consumidores de la función createRemoteFileNode podrían pasar la concurrencia allí. Luego, los complementos podrían hacer que la opción de concurrencia esté disponible en sus configuraciones. ¡Todavía me gustaría hacer un PR para abordar este problema!

La solución que he estado usando es solo un script simple para modificar el código dentro de node_modules . Realmente bastante frágil y no ideal, pero es un truco simple para modificar la concurrencia directamente. Usa shelljs por lo que se supone que también funciona para usuarios de Windows (no lo he probado).

#!/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);

Tuve el mismo problema, atascado en "nodos de origen y transformación". Después de un montón de console.logs, mi problema terminó siendo problemas de tiempo de espera con la recuperación de archivos multimedia de wordpress. El problema no era que el servidor no pudiera manejarlo, sino que limitaba la tasa de destello de la nube y generaba tiempos de espera después de unas 350 solicitudes.

Pasé por alto cloudflare, fui directamente al vps y ya no veo "nodos de origen y transformación", y mi compilación finaliza.

este era exactamente mi problema. Netlify se estaba construyendo muy rápido, menos de 2 minutos. Solo alrededor de 30 publicaciones, con alrededor de 500 imágenes fuente. Localmente no se completó todo, simplemente desmarcar el estado de CloudFlare para que fuera DNS solo resolvió el problema de inmediato

Tuve el mismo problema, atascado en "nodos de origen y transformación". Después de un montón de console.logs, mi problema terminó siendo problemas de tiempo de espera con la recuperación de archivos multimedia de wordpress. El problema no era que el servidor no pudiera manejarlo, sino que limitaba la tasa de destello de la nube y generaba tiempos de espera después de unas 350 solicitudes.
Pasé por alto cloudflare, fui directamente al vps y ya no veo "nodos de origen y transformación", y mi compilación finaliza.

este era exactamente mi problema. Netlify se estaba construyendo muy rápido, menos de 2 minutos. Solo alrededor de 30 publicaciones, con alrededor de 500 imágenes fuente. Localmente no se completó todo, simplemente desmarcar el estado de CloudFlare para que fuera DNS solo resolvió el problema de inmediato

También encontré que este es el caso. Anteriormente tenía una imagen que estaba causando que la compilación fallara y descarté que Cloudflare fuera el problema. Desde entonces, el problema volvió recientemente y, como @amcc sugirió, no enrutar el registro A a través de Cloudflare, también resolvió el problema de manera local de inmediato.

Solo quería hacerme eco de que esto no es solo un problema de fuente de WP: estaba teniendo el mismo problema con gatsby-source-prismic , reduciendo la concurrencia del sistema de archivos soure con

Acepte que, como mínimo, la concurrencia del sistema de archivos fuente debería ser configurable.

@njmyers Lamento preguntar esto, pero ¿cómo se ejecuta exactamente esta solución? Simplemente ejecute el script antes de la compilación o necesito hacer referencia de alguna manera al script en el proceso de compilación, porque actualmente me pregunto cómo aplicar esta solución localmente y también, por ejemplo, en netlify.

@alexanderwe No te preocupes, es un truco tonto de todos modos. Puede ejecutarlo después de instalar node_modules . No estoy 100% seguro, pero creo que postinstall en su proyecto package.json archivo funcionaría.

Para mí, Gatsby se cuelga el 50% del tiempo en "generar y transformar nodos" cuando uso json con más de 500 imágenes incluidas. Estoy usando gatsby-source-custom-api

Las imágenes se alojan en un servidor rápido y estable.
Mi conexión a internet también es rápida y estable.

"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",

¿Qué puedo hacer para depurar eso?

¿Este problema ocurre solo con gatsby-source-custom-api o source-wordpress?

A mí también me pasa. Probé todas las soluciones sugeridas y nada parece funcionar. Definitivamente no volveré a usar Wordpress como backend para Gatsby, aunque escuché que la gente también está teniendo problemas similares con otros servicios.

@alexanderwe La forma correcta de solucionar esto es implementar el parche sugerido por @njmyers
Luego, introduzca otro RP en gatsby-source-wordpress y otros para que esto sea realmente configurable a partir de su referencia en gatsby-config.js

@sebastienfi Me acabo de encontrar con este https://github.com/gatsbyjs/gatsby/issues/14819#event -2418874313 y el correspondiente compromiso https://github.com/gatsbyjs/gatsby/commit/90aa24787b32ef9613b6becbfadab6029ec39ce648#d18828 -75 agrega una variable de entorno para configurar la tasa de concurrencia, lo que me resolvió el problema. También hay una discusión en curso sobre las variables de entorno frente a los parámetros de configuración: https://github.com/gatsbyjs/gatsby/issues/14636

¿Ha intentado configurar GATSBY_CONCURRENT_DOWNLOAD en un número más bajo? De forma predeterminada, está configurado en 200.

Linux / mac:
GATSBY_CONCURRENT_DOWNLOAD=5 gatsby build

Ventanas:
setx GATSBY_CONCURRENT_DOWNLOAD 5; gatsby build

@wardpeet
lo intenté, nada ha cambiado

Definitivamente tiene algo que ver con el sistema de archivos de origen, ya que los registros muestran que las imágenes se han recuperado con éxito ... el problema sigue siendo enorme ... estamos llegando tarde a nuestra fecha límite, y realmente buscamos un solución a esto ...

después de configurar el complemento de origen de wordpress para depurar, veo esto

siempre cuelga entre 470-480 ... aunque no suele estar en el mismo lugar.

¿Alguien sabe en qué parte del código se está ejecutando?

Terminé haciendo que funcione alternando una VPN a la mitad

¿Alguien está dispuesto a compartir conmigo su repositorio y sus credenciales para que pueda darle una vuelta e intentar encontrar el problema?

No dude en enviarme un correo privado a [email protected]

mi repositorio no es fácil de volver a crear en este momento; tengo una copia de seguridad de la base de datos como estaba en alguna parte, pero para poder construir el sitio tuve que reducir cada mes las publicaciones en una sola publicación, durante años de contenido.

@wardpeet le envió un correo electrónico a mi repo Ward ([email protected]). Déjame saber como va.

Nuestra empresa cambió el wifi y aumentó el ancho de banda. Hoy no tuve ningún problema para descargar las imágenes ... Pero todavía no entiendo, ¿es la red o la concurrencia?

sin embargo, todas las compilaciones de Netlify fallan ...

5:13:43 PM: === [Obteniendo wordpress__wp_media] === https://wildkiwi.com/wp-json/wp/v2/media
5:13:43 PM: Total de entidades: 1717
5:13:43 PM: Páginas a solicitar: 344
5:13:45 p.m.: la solicitud falló con el código de error "indefinido"

el código de error no está definido, por lo que realmente no entiendo lo que está sucediendo ...

Cuando cambio las solicitudes simultáneas a 5, funciona en Netlify

Estaba teniendo este problema con un complemento diferente (https://github.com/angeloashmore/gatsby-source-prismic) y configurar GATSBY_CONCURRENT_DOWNLOAD=50 hizo el truco.

Esto sucedió de la nada (un día mi sitio se construiría, al siguiente no, sin cambios), y sin ningún tipo de mensaje de error, es un poco desconcertante estar implementando sitios web para clientes sin estar seguro de que esto no volverá a suceder.

Básicamente, descargamos 200 imágenes a la vez, pero esto podría ser problemático para algunas computadoras / conexiones a Internet. Una buena solución es hornear algunos mecanismos de reintento.

Estaba teniendo estos problemas, pero logré que la compilación funcionara bien con una combinación de setx GATSBY_CONCURRENT_DOWNLOAD 5; gatsby build y Smushing de todas las imágenes (algunas de las cuales eran excesivamente grandes en dimensión y) usando la versión gratuita de https: // en-gb.wordpress.org/plugins/wp-smushit/.

¡Hola! Estoy experimentando el mismo problema con un complemento de origen que estoy creando (no relacionado con WordPress), y cuando descargo más de 1000 imágenes forman una API. Casi siempre se cuelga al final del proceso.

Configurar GATSBY_CONCURRENT_DOWNLOAD no lo resolvió. Intenté 50 , 20 , 5 , sin suerte.

Obtengo una colección de tamaños de la API, y estaba usando la imagen más grande, pero la cambié a la más pequeña y tampoco la soluciona.

Es difícil identificar por qué falla en este punto, lo único que obtengo es source and transform nodes y luego silencio para siempre.

Sería fantástico tener un mecanismo de depuración para esto.

Estaba experimentando el mismo problema en una integración de gatsby + wordress. La compilación se detendría para siempre en la API onCreateNode donde estaba usando createRemoteFileNode.

Solución: Actualicé el sistema de archivos gatsby-source-files de 2.0.4 a 2.1.8 y agregué GATSBY_CONCURRENT_DOWNLOAD = 50 a mis variables de entorno.

Hola 👋

Tengo un problema similar en mi proyecto.

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

Tengo más de 80000 medios en mi sitio WP. Cuando ejecuto npx gatsby develop me quedo atascado después 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

Intenté modificar el valor GATSBY_CONCURRENT_DOWNLOAD pero nada ha cambiado.
¿Hay alguna forma de limitar la importación de cantidad de medios? Por ejemplo :

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

El mismo problema aquí, mi WP autohospedado tiene 1690 medios, siempre estoy atascado al final del paso Descarga de archivos remotos, a veces solo falta un medio ...

Editar: esta vez la compilación fue exitosa con GATSBY_CONCURRENT_DOWNLOAD=5 yarn build ...

@kvalium Gracias por tu comentario, GATSBY_CONCURRENT_DOWNLOAD=5 yarn build funcionó para mí

Tuve el mismo problema y me las arreglé para resolverlo cambiando el tamaño de la ventana de la terminal.

Consulte los últimos comentarios sobre el número 4666.

También tuve el mismo problema. Lo resolví con:

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

Espero que pueda ayudar

Parece que este es un problema peculiar. Aquí está mi experiencia con eso:

• ❌ Vi este problema en macOS High Sierra (usando iTerm)
• ✅ Empecé a usar GATSBY_CONCURRENT_DOWNLOAD=50 gatsby develop y el problema desapareció (este fue el caso durante un par de semanas)
• ❌ Actualicé a Mojave y actualicé mi instalación global de Gatsby a 2.7.47 y luego comencé a ver el problema nuevamente (usando iTerm)
• ❌ Intenté cambiar GATSBY_CONCURRENT_DOWNLOAD a 5
• ❌ Intenté volar .cache y node_modules
• ❌ Intenté cambiar el tamaño de la ventana de iTerm mientras ejecutaba gatsby develop (ambos con 50 y 5)
• ❌ Ejecutó GATSBY_CONCURRENT_DOWNLOAD=50 gatsby develop en la aplicación "Terminal", no en iTerm
• ✅ Dos semanas después intenté usar GATSBY_CONCURRENT_DOWNLOAD=50 gatsby develop en iTerm y cambié el tamaño de la ventana un par de veces durante el proceso y funcionó.

Pensé prematuramente que lo tenía funcionando con ese último, pero luego se colgó. Ojalá esto ayude a otros. Todavía parece que esto no está del todo definido, pero estamos llegando de manera lenta pero segura.

Actualización: hoy esto funcionó para mí. No estoy seguro de si es porque cambié el tamaño de la ventana de iTerm en el punto correcto del proceso o porque lo vi pasar del 93% al 100%, pero algo fue diferente esta vez.

Adicional para usar GATSBY_CONCURRENT_DOWNLOAD = 5, agregue el siguiente código en su archivo gatsby-node.js

// Internacionalización
exportaciones.onPostBuild = () => {
ChildProcess.execSync ("ps aux | grep jest | grep -v grep | awk '{print $ 2}' | xargs kill")
console.log ('Copiando configuraciones regionales')
fs.copySync (path.join (__ dirname, '/ src / locales'), path.join (__ dirname, '/ public / locales))
}

532314892 @bradydowling :

No estoy seguro si es porque cambié el tamaño de la ventana de iTerm en el punto correcto

Mientras experimentaba el mismo problema, cambié el tamaño de mi ventana de iTerm y bam; de repente, también continuó. No sé si esto es una coincidencia salvaje, o ...

@bradydowling @davegregg Woah, eso es extraño. Cambiar el tamaño de mi ventana de iTerm funcionó.

@TylerBarnes Sea lo que sea, sugiero que no sea específico de Wordpress. No estoy usando nada relacionado con Wordpress en absoluto.

@beauhankins ¿Y tú?

@davegregg @beauhankins @bradydowling ¿ Alguno de ustedes puede compartir un repositorio donde está sucediendo esto? Parece realmente extraño que cambiar el tamaño de la ventana de su terminal solucione el problema.

@TylerBarnes ya aquí hay un repositorio donde lo estaba viendo. No lo he tocado en un poquito.

Nota al margen: ¿Cómo maneja una situación en la que clona un sitio de Gatsby con una versión anterior de Gatsby que la que está instalada actualmente por la CLI?

Estaba ejecutando los elogios con el terminal de código VS (uso bash). Me estaba tomando una eternidad y, como se sugirió anteriormente, salí del modo de pantalla completa y funcionó.

@bradydowling ¡ gracias por compartir su repositorio! Para usar versiones anteriores de Gatsby que cli, puede crear un script npm para desarrollar y compilar.

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

luego ejecutando npm run develop o yarn develop usará la versión local en su proyecto.

Estamos investigando este problema, pero mientras tanto, cualquiera que tenga el problema puede solucionarlo ejecutando CI=1 yarn build , ya que eso debería usar una biblioteca de reporteros diferente detrás de escena. Si lo intentas y funciona, ¡avísanos!

@dustinhorton :

versión v2 @ https://github.com/dustinhorton/gatsby-v2-issue. He estado construyendo durante unos 50 minutos en este punto.

Fwiw. Me doy cuenta de que se publicó hace aproximadamente un año, y Gatsby ha cambiado considerablemente desde entonces. Al ejecutarlo en mi máquina (y configurar la versión de gatsby en * en package.json), la compilación parece completarse en aproximadamente 2000 segundos (~ 33 minutos).
Además, al actualizar el cli, ahora hay una barra de progreso, lo que marca una gran diferencia en términos de cuánto tiempo "se siente", ya que obtienes un ciclo de retroalimentación más concreto.

El paso de abastecimiento toma casi todo este tiempo (1968/1975 segundos). La descarga de archivos remotos es la mayor parte de eso (1845 segundos).

Esto no me sorprende cuando miro un solo viaje de ida y vuelta a 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 solicitud toma aproximadamente de 2 a 4 segundos. Las 75 páginas que se recuperan inicialmente mientras se explora, toman 18 segundos en total (!). Tengo una conexión rápida y puedo volver a reproducir esa sincronización con un wget simple.

Entonces, el paso más largo intentará descargar unos 7500 recursos. Teniendo en cuenta que una sola solicitud tarda de 2 a 4 segundos, no me sorprende que tarde tanto.

Aun así, noto algunas pausas durante el tramo de descarga principal de 1845 segundos. No estoy seguro de si esto es solo el servidor que limita los datos o no (configuré la concurrencia en 5).

Intenté mover el ancho de la terminal (estoy en xfce linux, fwiw) y, aunque en ocasiones coincidió con el progreso hacia adelante, estoy convencido de que ahora es más una coincidencia que una causalidad.

En pocas palabras: si bien puedo reproducir la descarga lenta y el progreso aparentemente "atascado", todas las señales apuntan a que eso se debe en gran parte a la espera de la respuesta del servidor. Además, el ancho del terminal no parece afectar esto.

Dicho esto: existe la posibilidad de que la salida del terminal se atasque de alguna manera mientras se actualiza la barra de progreso en un ancho muy particular. Si bien esto es poco probable, no es imposible. Por lo tanto, realmente necesitamos una reproducción que podamos ejecutar nosotros mismos (por lo que no hay autenticación). Y preferiblemente uno que _no_ dependa de un servidor remoto, ya que no quiero estar martillando el servidor.

Actualizaré las etiquetas sobre este tema en consecuencia.

La repro publicada en https://github.com/gatsbyjs/gatsby/issues/6654#issuecomment -438667221 por @njmyers ya no existe

El repositorio publicado en https://github.com/gatsbyjs/gatsby/issues/6654#issuecomment -562607399 por @bradydowling requiere un montón de permisos que no tengo y parece tener problemas similares con el tiempo de ida y vuelta

@ 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

Este paso de abastecimiento no muestra realmente ningún indicador de progreso, excepto el indicador giratorio y ocasionalmente se están registrando los pasos, y aún toma unos minutos, por lo que tal vez podamos al menos mostrar algún tipo de indicador de progreso si eso tiene sentido.

Además, tal vez podría ayudar señalar el tiempo promedio para buscar un recurso, ya que eso es una indicación de por qué "Gatsby" es lento, cuando en realidad es causado por el viaje de ida y vuelta.

En este repositorio, incluso descargar 589 archivos remotos tomó aproximadamente 5 minutos, y la barra de progreso a menudo se atasca sin razón aparente.

Después del bootstrap, la compilación falla porque faltan archivos.

@pvdz Tendré que jugar con esto de nuevo (lo dejé por un tiempo) pero hay ciertos archivos que arrojan problemas de permisos incluso cuando se compila con éxito, así que pensé que se pueden ignorar.

Pero para resumir tu publicación, ¿estás diciendo que ciertos pasos (de descarga) toman mucho tiempo y deberíamos esperar más para que se completen?

@bradydowling Bueno, lo parece, sí. :)

FTR: He seguido un poco la recopilación de recursos. Para arrojar algo de luz sobre los tiempos;

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

Estos son archivos de 6 MB por cierto. Estoy en una conexión de 250 Mbs que está bien para manejar esos más rápidos que 1mbs, pero no me sorprende que explote los tiempos de descarga. Ninguna cantidad de cambio de tamaño de cli va a acelerar eso;)

Interesante. Este es solo un blog personal estándar de WordPress alojado en EC2, por lo que no es como una instalación gigantesca. Quizás esto se deba a que todas estas solicitudes sobrecargan el host. O bien, no soy un experto en WordPress, pero tal vez haya algún tipo de límite de tasa de WP estándar en las llamadas a la API REST que puede suceder. También voy con la suposición de que este comportamiento no es exclusivo de este sitio.

Quizás esto se deba a que todas estas solicitudes sobrecargan el host.

Esta es mi suposición (o algo en este estadio). Pero estoy explorando un poco de nuestra propia arquitectura para comprobar si estamos perdiendo eficiencia a través de abstracciones. Pero considerando que puedo imitar la mayoría de las veces reportadas con wgets / rizos simples, dudo que haya mucho allí.

Entonces, reemplacé los got.stream() bits con un descargador sin formato tonto:

    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

Así que sí, estoy bastante seguro de que los retrasos prolongados (al menos en este caso) se deben a la descarga. Entonces, quizás nuestra mejor opción sea mejorar los comentarios mientras esperamos una descarga :)

Mucha, y mucha gente dice que el cambio de tamaño de las ventanas de la terminal (por alguna extraña razón) resuelve el proceso de desarrollo atascado en los "nodos de origen y transformación".

Lamentablemente, cuando se usa WSL, esta no es una solución. Atascado con 'generar y transformar nodos' localmente tanto en compilación como en desarrollo. Las compilaciones de Netlify funcionan, pero el desarrollo local se ha vuelto imposible.

@Vacilando ¿puedes depurar algunos enlaces que se están descargando para tu sitio durante el abastecimiento y probar manualmente si se descargan rápido? Como mencioné anteriormente, un gran problema que estoy viendo es que ciertos hosts de wp son simplemente súper lentos.

Entonces, si el host es lento y hay mucho contenido para descargar, entonces sí, este paso tomará mucho tiempo porque eso es todo lo que debería hacer en este paso; descubre contenido y descárgalo :)

Si ha confirmado que el contenido en sí se descargó en una fracción del paso completo, vuelva a hacer un círculo aquí. En ese caso, una reproducción sería tremendamente útil :)

Quizás en un mundo ideal podrías pasarle una bandera a Gatsby que guardaría
la descarga de activos del sitio para que esto no tenga que hacerse repetidamente.

Otra solución óptima sería permitir una bandera que establezca algún tipo de
tasa de limitación o estrangulamiento en la descarga de activos para que no se rompa
el anfitrión.

¿Alguna idea sobre esas dos ideas?

El jueves 19 de diciembre de 2019 a las 6:09 p.m. Peter van der Zee [email protected]
escribió:

@Vacilando https://github.com/Vacilando puedes depurar algunos enlaces que
se descargan para su sitio durante el abastecimiento y se prueban manualmente
si se descargan rápido? Como mencioné anteriormente, un gran problema soy
ver es que ciertos hosts de wp son simplemente súper lentos.

Entonces, si el host es lento y hay mucho contenido para descargar, entonces sí.
este paso llevará mucho tiempo porque eso es todo lo que debería hacer en
Este paso; descubre contenido y descárgalo :)

Si ha confirmado que el contenido en sí se descarga en una fracción del
paso completo, por favor, vuelva a circular aquí. En ese caso, una réplica sería
tremendamente útil :)

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/gatsbyjs/gatsby/issues/6654?email_source=notifications&email_token=ABS4AU62367MTEWP7LJXWTLQZP5L5A5CNFSM4FLHT3T2YY3PNVWWK3TUL52HS4DFVVREXWWK3TUL52HS4DFVVREXWG43 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/ABS4AU7GCV4YMZQH6R37BSDQZP5L5ANCNFSM4FLHT3TQ
.

@bradydowling parte de eso ya existe en realidad. Puede establecer una variable env GATSBY_CONCURRENT_DOWNLOAD para configurar el límite de solicitudes simultáneas. La próxima versión principal de gatsby-source-wordpress https://github.com/gatsbyjs/gatsby/issues/19292 tendrá más control sobre cómo se descargan los archivos multimedia. En cuanto al almacenamiento en caché, los archivos descargados se almacenan actualmente en caché, pero cuando cambia un archivo gatsby - *. Js, actualmente borra el caché para evitar que un caché obsoleto cause errores inesperados. Así que ese es un problema central en lugar de ser gatsby-source-wordpress específico, pero siempre se está trabajando para mejorar la caché de Gatsby.

Parcialmente Jobs Api (# 19831) debería solucionar este problema de almacenamiento en caché.

Ya vi el bit sobre GATSBY_CONCURRENT_DOWNLOAD más cerca de la parte superior. Desde mi experiencia, eso no ayudó, así que supongo que mi sugerencia fue hacia un control más detallado, como en mb por s / m / ho algo así. Quizás solo estoy diciendo tonterías.

@bradydowling Estoy buscando agregar reintentos de solicitud con retroceso exponencial, así como agregar una configuración opcional para solicitudes máximas por segundo para los casos en que eso no funciona lo suficientemente bien.

Hola!

Este tema se ha silenciado. Silencio espeluznante. 👻

Tenemos muchos problemas, por lo que actualmente cerramos los problemas después de 30 días de inactividad. Han pasado al menos 20 días desde la última actualización aquí.
Si no detectamos este problema o si desea mantenerlo abierto, responda aquí. ¡También puede agregar la etiqueta "no obsoleto" para mantener este problema abierto!
Como recordatorio amistoso: la mejor manera de ver este problema, o cualquier otro, solucionado es abrir una solicitud de extracción. ¡Visite gatsby.dev/contribute para obtener más información sobre la apertura de relaciones públicas, la clasificación de problemas y la contribución!

¡Gracias por ser parte de la comunidad de Gatsby! 💪💜

Voy a cerrar esto ahora.

Si cree que tiene un problema de abastecimiento de wordpress, primero confirme que sus retrasos no son causados ​​por un servidor de wordpress lento. Luego, abra un problema _nuevo_ (pero no dude en señalar este problema).

La gran cantidad de comentarios dificulta mucho el seguimiento de la discusión. Por lo tanto, es más probable que la apertura de un nuevo problema dé como resultado que su problema específico obtenga una respuesta.

Otros y yo lo confirmamos durante el último año y medio. mi problema original estaba en un vps bien ajustado. @njmyers tuvo una solución probable, o al menos una mejora, pero no pudo obtener ninguna respuesta de los mantenedores sobre cómo les gustaría que se hiciera.

Pensé en cerrarme, pero creo que debe estar ahí como una advertencia de que un sitio de wordpress moderadamente grande NO es adecuado para gatsby hasta el momento.

@dustinhorton, lo entiendo. Este número tiene más de un año y medio, las cosas cambian rápidamente. Con el problema que asciende a tantos comentarios, ya es difícil descubrir el problema real.

Fwiw, como se señaló anteriormente, verifiqué los últimos repros informados y determiné que, al menos, fueron causados ​​por controles remotos lentos. Si tiene una reproducción con una versión actual de Gatsby en un control remoto rápido, hágamelo saber, incluso si tal vez ya esté publicado en este hilo. O tal vez abra un nuevo número para él (y etiquéteme) si desea centrarse más en él, lo dejo en sus manos :)

(_ Para ser claros, cerramos este problema porque se ha vuelto un poco obsoleto con demasiados mensajes fuera del tema, no sienta que estamos aplastando la discusión ya que esa no es la intención y reconocemos que nuestro trabajo no ha terminado aquí. ! _)