Pouvez-vous préparer le repo de reproduction? Le nombre de messages ne devrait pas être un problème (au moins à cette étape) - la v1 pourrait rencontrer des problèmes de mémoire, mais ce serait dans une étape de construction ultérieure et ne devrait pas rester bloqué

J'étais curieux de savoir s'il s'agissait d'un problème avec Local by Flywheel et capable de créer le site en servant WordPress via MAMP Pro .

Mais, je ne suis même pas encore en train de créer des pages de publication (je construis les pages), et le temps d'exécution pour cette étape problématique est de 636,41 s (un peu moins de 11 minutes).

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,
      //  })
      //})
    })

edit: activez simplement createPage pour les publications et l'exécution de cet élément est passée à 14 minutes. Brutal, mais aussi intéressant que ce ne soit que 3 minutes de plus pour ~ 9000 articles supplémentaires. Il est assis sur ⠁ run graphql queries depuis longtemps actuellement.

edit : qui a duré 419.470 s, soit 7 minutes.

@pieh Oups , j'ai posté ça avant de voir que tu venais de répondre. Je peux essayer d'obtenir ce site à distance demain.

Et destinée à inclure, cette dernière ligne est l'endroit où elle se bloque via Local et prend une éternité 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'a pas confirmé que cela sera construit avec succès (maintenant avec la télécommande WordPress, cela prend des heures), mais cela révèle certainement le problème : https://github.com/dustinhorton/gatsby-issue

Devrait être capable de cloner cela et de construire.

Je viens de courir deux fois pendant plus de 10 heures sans que le site ne finisse de construire. S'il vous plaît laissez-moi savoir ce que je peux fournir d'autre pour l'aide au débogage.

Pourriez-vous essayer de passer à la v2 ? Nous avons apporté une tonne d'améliorations de vitesse à différents sous-systèmes de Gatsby, ce qui devrait considérablement accélérer les grands sites comme celui-ci.

@KyleAMathews Je vais

@KyleAMathews version v2 @ https://github.com/dustinhorton/gatsby-v2-issue. Je construis depuis environ 50 minutes à ce stade.

Le tuer maintenant. Le site n'a toujours pas été construit.

Une autre chose que vous pouvez essayer est d'activer le traçage https://next.gatsbyjs.org/docs/performance-tracing/

Nous n'avons pas encore ajouté la prise en charge du traçage à gatsby-source-wordpress, mais les rapports de traçage pourraient vous aider à comprendre où il cale.

Si quelqu'un d'autre est intéressé à étudier cela, un excellent PR serait d'ajouter un support de traçage à gatsby-source-wordpress. Faites-moi savoir si vous êtes intéressé !

Je vais devoir renflouer malheureusement, car je dois passer tout le temps que j'ai à porter sur un thème traditionnel – un peu écrasé de ne pas pouvoir utiliser Gatsby. Tout le reste semble tellement en arrière.

Désolé, nous n'avons pas eu l'occasion d'examiner cela :-( Sprint en ce moment pour sortir la v2.

Y a-t-il une chance que vous puissiez laisser le site WP fonctionner ? Il semble bien qu'il y ait un bug ici qui devrait être corrigé.

J'ai tweeté pour demander de l'aide, j'espère que quelqu'un va bientôt sauter dessus :-)

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

Wow, c'est génial, merci beaucoup. Le site ne va nulle part pour le moment (et je vais migrer une copie et mettre à jour le référentiel repro si nécessaire).

@dustinhorton pour ce que ça vaut J'ai également remarqué des problèmes pour créer un projet plus important (~ 1 000 messages) sur Local by Flywheel par rapport à notre environnement de production avec un CDN devant lui.

Les réponses REST pour Gatsby sont 10 à 20 fois plus longues en local qu'en production, la construction du site prend donc une éternité. Je n'ai pas encore passé de temps à déboguer le problème dans Local, mais c'est sur ma liste de choses à faire :)

@KyleAMathews Je pourrais jeter un œil à l'ajout du traçage à source-wordpress.

@Khristophor ce serait super !

@dustinhorton Je vois des 404 pour les images sur votre exemple de site (https://dustinhorton.com/gatsby-wp/wp-content/uploads/2018/07/IMG_9906.jpg, par exemple) qui pourraient gonfler la construction temps. Avez-vous la possibilité de rechercher les chemins pour ceux-ci?

Les requêtes WP_MEDIA s'exécutent assez rapidement avec des résultats, alors j'ai pensé que j'étais dans
le clair, mais je peux y jeter un œil plus tard cette semaine si vous le pensez
peut être le cas.

Le mercredi 8 août 2018 à 17h45 Chris Wiseman [email protected]
a écrit:

@dustinhorton https://github.com/dustinhorton Je vois des 404 pour le
images sur votre exemple de site (
https://dustinhorton.com/gatsby-wp/wp-content/uploads/2018/07/IMG_9906.jpg,
par exemple) qui pourrait gonfler le temps de construction. N'importe quelle chance que vous pourriez
chercher dans les chemins pour ceux-ci?

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/gatsbyjs/gatsby/issues/6654#issuecomment-411562589 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAXFNRHTA-vqIwCTtioejUL-Ei3nM0Lbks5uO1vygaJpZM4VZ57n
.

C'est vrai, mais une partie de l'étape de source et de transformation consiste à télécharger tous les éléments multimédias qu'il trouve dans la réponse REST :
https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-source-wordpress/src/normalize.js#L434

Obtenir des 404 sur 7504 images peut causer des problèmes ;)

Croyez que j'ai nettoyé toutes les 404. J'essaierai de construire ce soir. Merci a tous.

Apparemment pas de changement :

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

Et il est resté là pendant environ 8 heures.

@dustinhorton quel type d'hébergement utilisez-vous ? Je pense que cela tue simplement votre boîte de production avec le nombre de demandes. Je crois que je l'ai terminé (après un certain temps, pas huit heures) en définissant les connexions simultanées sur quelque chose de bas, comme 1 ou 2.

C'est un VPS décent sur Linode. Je peux modifier les paramètres si cela peut aider. Mais le problème se produit aussi localement.

https://github.com/gatsbyjs/gatsby/blob/46290c2b0e7894fca036bdcc658a5d1936c4221f/packages/gatsby-source-filesystem/src/create-remote-file-node.js#L133 -L159 cela ne fonctionne parfois pas correctement lorsque nous tirons une plus grande quantité de fichiers - la demande réseau est résolue mais le flux d'écriture de fichier ne se termine jamais (ou des erreurs sont générées). Je pense que ce serait génial d'ajouter une sorte de délai d'attente après la fin de responseStream pour attendre que fsWriteStream se termine, et si ce n'est pas le cas, détruisez toutes les ressources et essayez à nouveau d'écrire le fichier (éventuellement faire quelques tentatives) et en fait des erreurs quand il ne peut pas le faire.

@pieh pouvez-vous s'il vous plaît envoyer le code mis à jour pour ce fichier ?

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

@aman-developer, il n'y a pas encore de correctif pour cela - sinon, il serait publié. Le problème avec ce problème est qu'il n'y a aucun moyen fiable de reproduire cela, donc toutes les corrections sont des suppositions. Le problème est dans certains cas (peut - être matériel et / ou spécifiques du système d'exploitation) système de fichiers WriteStream ne se termine pas et est rester coincé sans jeter erreurs de sorte que toute solution ici est vraiment essayer de problèmes de contournement dans fs package / matériel / os pas fiable :/

Avez-vous eu des problèmes de reprographie avec mon dépôt et mon site ? C'est cohérent pour moi.

J'utilise createRemoteFileNode pour récupérer des images distantes et je rencontre le même problème : le téléchargement se bloque aux alentours de 680/780ish.

Dans createRemoteFileNode, il existe un écouteur pour l'événement downloadProgress qui a été ajouté dans https://github.com/sindresorhus/got/releases/tag/v8.0.0 mais gatsby-source-filesystem utilise got 7.1.0.

J'ai essayé de mettre à niveau vers la dernière version 9.2.2 et je pouvais maintenant télécharger avec succès toutes les images.

Ajoutez ceci dans package.json :

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

Il semble également y avoir des correctifs critiques dans got après 7.1.0, comme des erreurs de flux qui ne sont pas correctement transmises, etc. (https://github.com/sindresorhus/got/releases/tag/v8.0.1)

J'ai essayé de mettre got jour downloadProgress auront besoin d'être désactivés ou d'une sortie plus agréable, car le terminal / la console est spammé avec la progression lors de son utilisation

J'ai pu exécuter gatsby develop après environ 25 minutes, mais j'ai dû réduire la simultanéité dans create-remote-file-node.js de 200 à 20. J'ai eu 22 TimeoutErrors (mais j'ai été retéléchargé lors de l'exécution de gatsby develop à nouveau) après avoir placé les journaux dans cette capture vide dans processRemoteNode.

Je ne sais pas si c'est à cause de got, mais je peux peut-être expérimenter avec d'autres clients 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' }

J'obtiens les mêmes erreurs avec prismic

J'ai mis à niveau vers "got": "^9.2.2" maintenant ça marche houra !

Il faut absolument jeter un œil pour mettre à niveau notre version got . Il s'agit d'un problème d'intermittence, donc cela pourrait être une coïncidence si cela a fonctionné. @RobinHerzog s'il vous plaît laissez-nous savoir si vous rencontrerez des problèmes similaires avec la version mise à niveau de got

La mise got jour de

@dustinhorton quelle partie de la construction tirait des images (ou source and transform data car nous ne montrons pas explicitement combien de temps prend le téléchargement des fichiers) ?

J'ai 150 Mo d'images avec une connexion Internet de 1 Go. Maintenant, il fonctionne. J'ai besoin de 30 secondes pour télécharger et continuer à construire.

J'ai aussi ce problème régulièrement. La mise got niveau de

J'ai essayé de changer concurrentRequests et perPage , ainsi que de mettre à niveau got vers la dernière version, mais rien n'a fonctionné. En ce moment, je peux récupérer categories , posts , pages et tags , mais quand j'inclus users ou media , juste après =END PLUGIN=== , le plugin renvoie une erreur : TypeError: Cannot read property 'id' of undefined .

Si j'inclus toutes les routes et que je mets sur liste noire celles auxquelles je n'ai pas accès, j'obtiens =END PLUGIN=== mais cela ne se termine jamais... Cela vaut pour des tonnes de sites Web que j'ai testés, donc je pense que cela pourrait être mon système d'une manière ou d'une autre . Si quelqu'un veut tester ça, voici la config :

    {
      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 : Une URL que j'ai réussi à récupérer était https://wesbos.com/

BONNE MISE À JOUR : j'ai réussi à le faire fonctionner (_pour les petits sites_) avec includedRoutes , même avec users et/ou media en incluant taxonomies dans la requête . Maintenant, je ne reçois pas l'erreur 'id' of undefined :D

@pieh Je crois que les users et media dépendent de taxonomies , alors ils devraient peut-être venir par défaut chaque fois que la configuration contient l'un de ces types ? Faites-moi savoir si je peux vous aider à résoudre davantage le problème ! En guise de conclusion, ce bogue taxonomies semble pas lié au processus de construction infini. Avec des sites de plus de 500 fichiers multimédias, je n'arrive toujours pas à terminer le processus de création !

MISE À JOUR Numéro 2 : J'ai donc réussi à le faire fonctionner pour queroinvestiragora.com , qui contient 600 fichiers multimédias mais seulement 70 messages, cela prend environ 15 secondes après =END PLUGIN=== , mais ça marche. Cependant, www.clubedospoupadores.com a 702 fichiers multimédias et 336 messages et il ne sera pas compilé.

PS : Ma config dans ces expériences est :

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

Bonjour,

J'ai réussi à ajouter un traçage en suivant les étapes décrites ici https://www.gatsbyjs.org/docs/performance-tracing/ . Malheureusement, il n'a pas fourni beaucoup d'informations car il m'a simplement dit qu'en effet, les nœuds source et de transformation prenaient assez de temps.

J'ai cependant effectué une partie de mon propre débogage sur le problème après avoir eu un comportement non déterministe impliquant des images. Lors de l'exécution du script de développement ou de construction, j'obtiendrais un cas où toutes les images ne seraient pas téléchargées et les nœuds localFile ne se termineraient pas. Après avoir creusé dans le code, j'ai déterminé qu'il semble y avoir un problème ici

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

Pour moi, le nœud createRemoteFile échouait en raison d'erreurs de délai d'attente du serveur et renvoyait par défaut la valeur null. J'ai également dû ajouter une journalisation au nœud createRemoteFile pour le déterminer et obtenir les réponses réelles du serveur. Étant donné que ces nœuds ne se terminent pas et n'ont pas d'ID, ils ne sont pas enregistrés dans le cache. Les fichiers tmp sont supprimés et le système de fichiers gatsby-source était incomplet. Pour une raison quelconque (je n'ai pas encore cherché aussi loin) lors de la réexécution du script de construction, le système de fichiers source a ensuite été supprimé probablement parce que le script détecte que le système de fichiers est invalide ou incomplet. C'est ce processus qui pour moi créait une boucle et provoquait des erreurs sur les futures versions car le système de fichiers ne se termine jamais.

Je travaille sur un correctif qui semble atténuer certains des problèmes, au moins en ce qui concerne les grandes quantités d'images. Lorsque le script de développement ou de construction réussit à télécharger toutes les images la première fois, elles ne sont pas supprimées par la suite, puis le processus de construction se déroule assez rapidement car les images sont correctement mises en cache par gatsby-source-filesystem ! Ma construction est passée de 15 minutes à 1 minute.

Je ne sais pas si cela est lié aux builds qui ont un grand nombre de messages. Mon problème était directement lié au téléchargement de 1,6 Go de données d'image.

C'est la première fois que je travaille avec des plugins sources pour gatsby, donc si quelqu'un a des idées ou des conseils à ce sujet, je l'apprécierais ! Je devrais être en mesure de publier mon dépôt plus tard dans la journée. Je travaille pour qu'il utilise ma version locale de gatsby-source-filesystem sans complications.

Bonjour,

Suite à mon commentaire d'il y a quelques jours. Voici mon dépôt.

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

J'utilise un monorepo dans ce projet, voici donc quelques étapes si vous souhaitez exécuter le référentiel localement.

1. Assurez-vous d'avoir la dernière version de Yarn 1.12.3
2. Cloner la branche du plugin git clone https://github.com/njmyers/byalejandradesign.com.git -b wordpress-plugin
3. Courir yarn && yarn bootstrap
4. Accédez au dossier gatsby pour ne voir que ce dossier cd packages/web
5. Exécutez yarn develop ou yarn build-web . Il devrait se terminer avec succès la première fois et les exécutions suivantes de la même commande entraîneront des builds beaucoup plus rapides ! Les nœuds source et de transformation prennent 222 secondes pour moi, alors que cela prenait 3 fois plus tôt et/ou ne se terminait pas.
6. Si vous voulez voir ce qui se passe réellement pendant la source et la transformation, vous pouvez regarder dans votre navigateur de fichiers à /packages/web/.cache/gatsby-source-filesystem vous verrez que les fichiers y sont créés.

J'ai complètement réécrit la fonction downloadMediaFiles. Vous pouvez voir ce fichier sur ce lien https://github.com/njmyers/byalejandradesign.com/blob/wordpress-plugin/packages/gatsby-source-wordpress/src/download-media-files.js

C'est probablement plus détaillé qu'il n'en faut, mais je devais le faire pour comprendre tout ce qui se passait. La fonctionnalité que j'ai modifiée consiste à ajouter un rejet de promesse lorsque createRemoteFileNode renvoie null. J'utilise ensuite une fonction downloadRunner pour limiter les demandes afin qu'elles n'atteignent pas toutes le serveur en même temps, ainsi qu'une nouvelle tentative sur les refus de promesse. J'ai ajouté une manette de 200 ms entre chaque requête createRemoteFileNode. Je suis sûr que cette valeur pourrait être modifiée et qu'une partie de cela pourrait être mieux adaptée à l'ajout de createRemoteFileNode directement.

Si quelqu'un est curieux, l'installation de WP est une micro-instance EC2 tandis que les images sont derrière une distribution CloudFront. Personnellement, je n'ai jamais eu de problèmes pour obtenir des messages, mon problème était d'obtenir des images et je pense que la plupart des problèmes rencontrés par les gens sont dus à cela.

De plus, si quelqu'un veut tracer ou déboguer son propre site, je suggère de commencer ici...

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

J'ai ajouté la journalisation à la clause catch et j'ai pu déterminer que les nœuds d'image n'étaient pas traités correctement car j'obtenais des erreurs de délai d'attente, puis je retournais null.

@njmyers Je viens de regarder très brièvement cela et je pense que si cela fonctionne, nous devrions utiliser une approche similaire dans createRemoteFileNode directement. Nous utilisons ici queue , donc les consommateurs de cette fonction ( gatsby-source-wordpress dans ce cas) ne devraient pas avoir à s'inquiéter à ce sujet. Une chose qui est potentiellement problématique est cette limitation de 200 ms - nous pourrions peut-être commencer sans elle et lorsque nous commençons à voir des problèmes appliquer automatiquement la limitation (par nom d'hôte)

@pieh Oui, ce serait probablement le lieu d'appliquer cette logique. La limitation était pour moi un moyen d'aborder cela et de diagnostiquer le problème, donc je suis d'accord que le createRemoteFileNode devrait être capable de gérer cela par lui-même.

Cependant, le comportement actuel consistant à échouer silencieusement les erreurs et à renvoyer null est particulièrement problématique. À mon avis, il devrait y avoir une certaine communication sur l'échec ou le succès de l'opération. Je pense que createRemoteFileNode pourrait être rendu plus robuste avec les fonctionnalités suivantes.

1) Créer des liens avec avidité
2) S'il y a des erreurs du serveur, commencez à ralentir et/ou réessayez si nécessaire
3) Définir des valeurs par défaut saines pour la limitation/réessayer
4) Créer un point d'entrée pour ajuster la limitation/réessayer
4) Rejeter une promesse si, pour une raison quelconque, le nœud ne peut pas être traité.

Je peux aussi dire que j'ai joué avec les valeurs de délai d'attente ici https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-source-filesystem/src/create-remote-file-node.js#L135 - L141. Bien que cela augmente la probabilité d'une réponse réussie, je devais quand même ajouter la manipulation afin d' assurer une réponse réussie.

Le point d'entrée correct pour cette logique serait probablement ici.

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

Où si les tâches échouent, elles sont réessayées et/ou échouées, puis finalement rejetées.

Lisez aussi brièvement les queue docs. Je vois ce que vous dites à propos de queue être capable de gérer cela tout seul.

@njmyers beau travail d'enquête ! Je suis tout à fait d'accord pour dire que le téléchargement de fichiers doit être beaucoup plus intelligent !

Il pourrait être intéressant d'extraire l'élément de téléchargement de fichiers dans son propre package qui se concentre sur ce problème de téléchargement et de mise en cache des fichiers distants.

Il y a de fortes chances que nous devions utiliser la fonctionnalité à plusieurs endroits à Gatsby et dans le futur et c'est quelque chose que d'autres internautes voudraient également utiliser.

@KyleAMathews voulez-vous dire extraire createRemoteFileNode dans un package séparé ?

Non seulement la partie téléchargement et mise en cache des fichiers. createRemoteFileNode appellerait alors simplement ce package et récupèrerait une promesse qui se résoudrait lorsque le fichier était téléchargé (ou renvoyé du cache).

J'ai également ce problème avec mon propre plugin de source de cockpit.

Je vois que ce serait vraiment plus comme extraire ces portions de code dans un package séparé ...

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

Cela semble être le code qui traite spécifiquement du téléchargement et de la mise en cache, veuillez me corriger si je me trompe. Heureux de travailler là-dessus ! J'essaie juste de comprendre comment cela fonctionne dans le plus grand écosystème.

Un PR pour réparer uniquement gatsby-source-wordpress serait-il accepté, puis extraire le correctif par la suite ? Avoir du mal à utiliser le plugin @njmyers forked tel

@dustinhorton ne sait pas si cela aide, mais j'ai trouvé que si vous souhaitez utiliser un plugin local, il est préférable de pointer gatsby directement vers le fichier package.json. J'avais du mal à faire en sorte que gatsby trouve mon plugin local jusqu'à ce que je commence à le spécifier explicitement.

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

Je suis toujours heureux de travailler sur ce problème et même sur le nouveau plugin tel que discuté. Je cherche juste un peu de conseils sur la façon d'intégrer cela car cela semble être un changement perturbateur qui pourrait avoir un impact sur beaucoup d'autres choses dont je ne suis pas au courant. @KyleAMathews des pensées? J'ai toujours l'impression que le code ici

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

Est la partie qui doit être extraite dans son propre package. Cela étant dit, c'est l'une des fonctions principales de createRemoteFileNode et je veux m'assurer de m'y prendre correctement afin qu'il puisse être correctement réintégré dans l'écosystème.

@njmyers Vous avez généralement raison avec votre sélection de code - nous voudrions également que notre file d'attente actuelle (dont l'ATM limite à 200 demandes simultanées, ce qui ne semble pas génial pour le développement local et apparemment pour wordpress) déplacée et probablement modifiée.

@dustinhorton Je pense qu'il est raisonnable d'utiliser d'abord ce plugin dans wordpress (principalement parce que c'est pratiquement fait).

@pieh Super merci pour vos éclaircissements ! Je vais commencer à travailler sur un nouveau plugin.

En ce qui concerne un correctif temporaire de wordpress-source, ma seule autre question serait que faire ici

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

Pour le moment, il serait toujours possible d'avoir des erreurs de réseau et il doit y avoir une clause catch pour l'ensemble de la fonction downloadMediaFiles. Quel est le comportement normal pour transmettre des erreurs à gatsby ? Je serais heureux d'ajouter ce code dans le plugin wordpress pour transmettre correctement les erreurs de réseau au gestionnaire approprié. Peut-être pourrions-nous afficher un message d'erreur et une référence à ce problème ? Merci pour votre aide!

@njmyers Merci - oui, je reproduisais votre configuration aussi fidèlement que possible, à part qu'il s'agissait d'un monorepo (y compris en faisant référence à package.json ). L'exécution de develop simplement donné des erreurs comme s'il n'y avait pas de gatsby-source-wordpress . Je vais lui donner un autre essai ici sous peu.

Recréez plus fidèlement votre monorepo, et curieusement, il se trouve juste à source and transform nodes , comme c'était le cas avec le gatsby-source-wordpress non fork avant de rétrograder la dépendance obtenue.

@pieh Capable de répondre à sa demande @ https://github.com/gatsbyjs/gatsby/issues/6654#issuecomment -442536931 ?

@dustinhorton Oui, il devrait rester là pendant un certain temps aussi si vous avez beaucoup d'images. Mon fork lancera unhandled promise rejection si un fichier distant ne parvient pas à se télécharger. C'est pourquoi j'aimerais pouvoir disposer d'un mécanisme pour gérer correctement ce scénario.

Je pense avoir lu sur un autre fil également qu'il était question d'intégrer une sorte de gestionnaire de progrès, car cela fournirait des commentaires sur l'état du plugin.

Si vous regardez dans le système de fichiers de votre système d'exploitation sous project-root/.cache/gatsby-source-filesystem, vous devriez pouvoir voir toutes les images en cours de téléchargement. Dans mon cas, il s'agit de près de 400 images maintenant, donc cela prend un certain temps. Cependant, avant d'utiliser ma version fourchue, le plugin échouait silencieusement sur une erreur, puis ne progressait jamais, provoquant le problème où la source et la transformation prendraient des heures ...

Avez-vous un dépôt? J'aimerais pouvoir l'essayer sur un autre site car pour l'instant je ne l'ai testé qu'en situation réelle sur mon site.

@njmyers C'est la règle - si cela ne vous dérange pas, envoyez-moi un e-mail: [email protected] , ou recherchez simplement une invitation. Je vais préparer quelque chose ce soir.

La mise got jour de

Le problème avec got@9 est qu'il nécessite le nœud 8 (https://github.com/sindresorhus/got/releases/tag/v9.0.0), nous ne pouvons donc pas mettre à niveau ATM :(

Nous devrions pouvoir passer au moins à got@8 , mais je ne sais pas si cela résoudra les problèmes

got@8 semble implémenter la mise en cache HTTP conforme à la RFC 7234, donc gatsby-source-filesystem pourrait fournir son propre adaptateur de cache de système de fichiers. Ce qui devrait au moins réduire le temps passé dans les nœuds source et transformer la deuxième fois étant donné que la ressource est cacheable.

Salut !

Ce problème est devenu silencieux. Effrayant calme. ??

Nous obtenons de nombreux problèmes, nous fermons donc actuellement les problèmes après 30 jours d'inactivité. Cela fait au moins 20 jours depuis la dernière mise à jour ici.

Si nous avons raté ce problème ou si vous souhaitez le garder ouvert, veuillez répondre ici. Vous pouvez également ajouter l'étiquette « not stale » pour garder ce problème ouvert !

Merci de faire partie de la communauté Gatsby ! ??

@gatsbot Toujours un problème.

On m'a demandé de contribuer à un article de blog pour vous tous. Impossible de le faire car il est bloqué sur les nœuds source et de transformation. J'ai vu l'autre problème, mais je ne vois pas où il y a un correctif pour cela. C'est un fork de gatsbyjs, le dernier en amont. Je ne l'ai fait fonctionner qu'une seule fois. Il est toujours bloqué en transformant les nœuds.

Il ne parvient pas à récupérer les captures d'écran de quelques sites lors de la construction. Je rajouterai les sites incriminés dans la matinée.

@ twhite96 Je viens de rencontrer le problème et ce qui a fonctionné pour moi, c'est de supprimer les fichiers temporaires que j'avais encore ouverts (à partir d'emacs), je ne sais pas si cela vous aidera ou non, mais cela a permis à ma construction d'avancer.

Il semble donc que ce soit toujours un problème…

face au même problème lors de l'utilisation de gatsby-source-s3 pour extraire 100 photos et les transformer en netteté. Quelqu'un a trouvé une solution ?

D'une manière ou d'une autre, mon problème a été résolu (au hasard ?). Voici les étapes que j'ai suivies, j'ai créé un nouveau compartiment s3 avec moins d'images (pour les tests), puis j'ai essayé de créer et il a été construit avec succès très rapidement. Ensuite, j'ai décidé de revenir en arrière et d'essayer de sortir du seau d'origine et maintenant, tout d'un coup, il s'est construit avec succès en 49 secondes alors qu'à l'origine, cela durait pendant des heures. Je ne sais pas comment le simple commutateur dans les liens du godet a réparé le décrochage, mais j'espère que cela aidera quelqu'un à le comprendre. peut-être est-ce lié au cache ?

Salut tout le monde. J'ai mis à jour la version de mon plugin local que j'utilisais pour un site qui avait ce problème. Je pense que c'est une meilleure implémentation car elle utilise 'better-queue' avant 'createRemoteNode' et passe le paramètre 'concurrentRequests'. C'est un peu redondant car 'createRemoteNode' utilise déjà une file d'attente, mais quelle que soit cette version, cette version semble bien fonctionner avec les récentes mises à jour de gatsby et donne des informations sur la progression des fichiers. Je vais essayer d'obtenir un PR ensemble pour cela. Désolé pour les retards, je sais que j'ai dit que je travaillerais dessus plus tôt mais j'ai été assez occupé !

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

@njmyers

Merci beaucoup. Votre version a résolu certains problèmes que j'avais. J'ai combiné cela avec une ligne ou deux pour filtrer le téléchargement de 25 Go de mp3, et je suis maintenant prêt !

Certainement toujours un problème.
J'essaie de compiler mon projet depuis 24 heures. Sur environ 12 essais, 3 ont réussi avec des sorties et une connexion WP réelle. Y a-t-il une solution à cela?
BTW, j'ai essayé d'utiliser la version @njmyers du plugin (super travail, en fait !), mais les résultats ont été mitigés. Parfois, il se plaignait de wordpress_parent ou de Date et finissait par planter, mais ne pouvait pas comprendre ce qui se passait réellement avec ces erreurs. Dans d'autres versions, différentes erreurs (mais elles compilent, ce qui est intéressant), ce qui provoque en fait des problèmes sur GraphQL.

@lucassilvagc pouvez-vous publier quelques sorties ? Je suis content que les gens essaient et testent la branche. Faisons en sorte que cela fonctionne mieux afin que nous puissions ouvrir le PR !

@njmyers Bien sûr !

Un aperçu rapide de ce qui se passe:

Mon site Web fonctionne actuellement avec ~1940 fichiers image, peut-être la faute de WordPress en créant plusieurs fichiers image plusieurs fois. Si j'utilise un _gatsby-source-wordpress_ vanille, le problème apparaît comme prévu (il y a une version "vanille" que j'ai faite hier soir sur un autre environnement de construction - qui renvoie le même problème que nous discutons sur ce problème. build fonctionne et compile lorsque tous les fichiers image sont renvoyés). En utilisant votre plugin (en remplaçant tous les fichiers dans node_modules/gatsby-source-wordpress (corrigez-moi si je me trompe)), _gatsby develop_ me renvoie ce qui suit :

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

Après un court instant, il affiche :

'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 : il s'agissait d'une version vanille de gatsby-source-wordpress qui a été _"convertie"_ en la vôtre en remplaçant les fichiers, comme je l'ai dit ci-dessus. Je pense que le fait qu'il ne puisse pas interroger toutes les pages est lié au fait qu'aucun nœud n'est généré. Je tiens également à noter que cette version est égale à ma version vanille qui fonctionne lorsque ce problème n'apparaît pas.

Je tiens également à noter que l'ajout de routes semble causer le même problème initial pour moi (car je voulais éviter différentes pages qui ne sont pas liées ou qui renverront des erreurs en raison de plusieurs couches de protection sur WordPress). Je ne sais tout simplement pas si les itinéraires que j'ai énumérés sont corrects ou s'il me manque quelque chose après.

Je suis très heureux de votre réponse, ce problème est actuellement un énorme revers pour mon projet et je suis heureux que vous soyez toujours au courant de ce problème. Merci beaucoup!

Avoir le même problème avec plus de 400 publications personnalisées avec des champs acf et 4000 images.

J'ai mis à jour et j'ai pu construire en 35 minutes

Impossible de reconstruire après avoir mis got jour

Comme prévu, puisque ce bug existe toujours dans gatsby-wordpress. 35 minutes pour télécharger et traiter toutes les images restent très longs compte tenu de tous les facteurs (vitesse Internet moyenne, puissance de traitement, nombre total de fichiers, etc.).
Vous pouvez essayer d'adapter la version de @njmyers à votre utilisation spécifique, cela fonctionnera comme un charme lors du téléchargement de chaque fichier image que vous avez.

Comme prévu, puisque ce bug existe toujours dans gatsby-wordpress. 35 minutes pour télécharger et traiter toutes les images restent très longs compte tenu de tous les facteurs (vitesse Internet moyenne, puissance de traitement, nombre total de fichiers, etc.).
Vous pouvez essayer d'adapter la version de @njmyers à votre utilisation spécifique, cela fonctionnera comme un charme lors du téléchargement de chaque fichier image que vous avez.

Mon site fonctionnait bien lorsque j'avais un petit nombre d'images, mais lorsque j'ai commencé à en ajouter d'autres, cela se produit également.

@MWalid comment puis-je mettre à jour le got ? Merci.

essayé de construire toute la journée sans succès. ont environ 1450 images.

Nous n'avons pas pu déployer depuis 2 jours maintenant. Quelqu'un peut-il m'aider à m'indiquer où cela se produit dans le code afin que je puisse essayer de trouver une solution ?

Nous n'avons pas pu déployer depuis 2 jours maintenant. Quelqu'un peut-il m'aider à m'indiquer où cela se produit dans le code afin que je puisse essayer de trouver une solution ?

Avez-vous mis à jour votre got dépendance imbriquée du gatsby-source-filesystem pour utiliser au moins la version 9.4.0 ?

Sinon, vous devez ajouter :

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

dans le package.json votre projet Gatsby. Supprimez ensuite node_modules et votre fichier yarn.lock et réinstallez.

Remarque : Cette fonctionnalité resolutions ne fonctionne que pour yarn . npm n'a pas encore implémenté cela.

@anagstef merci beaucoup pour le conseil ! Je vais essayer ça et faire un retour.

Lors de l'exécution de gatsby develop , existe-t-il un moyen de conserver le cache local au lieu de récupérer les données distantes à chaque lancement de la commande ?

@anagstef semble fonctionner beaucoup mieux ! Merci pour le conseil!

La sortie est très détaillée lors de la construction avec cette version de got. Savez-vous s'il existe un moyen de supprimer cela?

@nratter, je suis content que cela ait fonctionné pour vous !

Oui, je sais ça, c'est très verbeux et ça ne peut pas être désactivé. Ruines toutes les sorties de console utiles.

Après quelques recherches que j'ai faites, je pense que cela est causé ici:
https://github.com/gatsbyjs/gatsby/blob/80c7023a8bc23886939205fe52e305277294e6af/packages/gatsby-source-filesystem/src/create-remote-file-node.js#L155

Comme vous pouvez le voir, il appelle un console.log avec la progression du téléchargement de chaque fichier à chaque fois que l'événement downloadProgress émis, ce qui se produit trop de fois par seconde. Ce n'était pas un problème avant, car l'ancienne version got n'implémente pas l'événement downloadProgress .

Peut-être pouvons-nous résoudre le problème avec un PR ? On dirait du débogage du code restant.

J'ai eu le même problème, bloqué sur "nœuds source et de transformation". Après beaucoup de console.logs, mon problème a fini par être un problème de délai d'attente avec la récupération de fichiers multimédias à partir de wordpress. Le problème n'était pas que le serveur ne soit pas en mesure de le gérer, mais plutôt la limitation du taux de cloudflare et le lancement de délais d'attente après environ 350 requêtes.

J'ai contourné cloudflare, je suis allé directement au vps et je ne vois plus de "nœuds source et de transformation", et ma construction se termine.

Ma solution de contournement était d'avoir un wordpress local pour les tests, le site en direct est en netlify, tandis que son déploiement n'a causé aucun problème.

Les gars, j'ai réussi à résoudre ce problème en exécutant des requêtes createRemoteFileNode en série plutôt qu'en parallèle.

Voici la fonction que j'utilise :

/**
 * 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
}

et voici comment je l'utilise :

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

Une fois les images téléchargées, voici à quoi ressemblent mes étapes de source et de transformation

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

J'espère que cela résoudra vos problèmes aussi.
Acclamations

@ancashoria où dois-je mettre ce code ?

@ancahoria oui, je ne sais pas non plus où placer ce code.

Ceci n'a aucun rapport avec le plugin gatsby-source-wordpress . J'ai le code ci-dessus dans mon gatsby-node.js . L'idée est que le fait de lancer toutes ces demandes en parallèle les a fait échouer, j'ai donc écrit cette fonction d'assistance pour les lancer l'une après l'autre.

Je suppose qu'il y a aussi un problème similaire dans gatsby-source-wordpress , mais je ne le connais pas très bien.
Désolé, je ne peux pas être plus utile.

Cela semble être lié à des images massives et à des connexions Internet lentes. Netlify a pu créer le site, mais ma connexion locale ne l'était pas car il ne s'agissait que de 1 Mo/s de téléchargement, ce qui l'a fait expirer après 30 secondes et échouer sur la grande image.

J'ai 1 Go de fibre et pas d'images « massives ».

Je ne transforme pas les images de blog localement après les avoir téléchargées wordpress, j'utilise simplement leur URL. Ce serait bien s'il y avait un paramètre qui désactive le téléchargement de ces images dans ce cas.

Les gars, j'ai réussi à résoudre ce problème en exécutant des requêtes createRemoteFileNode en série au lieu de parallèle.

Oui, le problème est vraiment basé sur le fait que createRemoteFileNode utilise une simultanéité de 200, ce qui est trop pour la plupart des serveurs WP. J'ai mes images sur CloudFront et j'y atteignais des limites de débit.

J'ai essayé de résoudre le problème avec une version ramifiée du plug-in source pendant un certain temps, mais le problème n'est vraiment pas dans gatsby-source-wordpress mais dans gatsby-source-filesystem . Idéalement, les consommateurs de la fonction createRemoteFileNode pourraient y passer en simultané. Ensuite, les plugins pourraient rendre l'option de simultanéité disponible dans leurs configurations. Je voudrais toujours faire un PR pour résoudre ce problème!

La solution que j'ai utilisée n'est qu'un simple script pour modifier le code à l'intérieur de node_modules . Vraiment assez fragile et pas idéal mais c'est un simple bidouillage pour modifier la simultanéité directement. Utilise shelljs , il est donc censé fonctionner également pour les utilisateurs de Windows (je n'ai pas essayé).

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

J'ai eu le même problème, bloqué sur "nœuds source et de transformation". Après beaucoup de console.logs, mon problème a fini par être un problème de délai d'attente avec la récupération de fichiers multimédias à partir de wordpress. Le problème n'était pas que le serveur ne soit pas en mesure de le gérer, mais plutôt la limitation du taux de cloudflare et le lancement de délais d'attente après environ 350 requêtes.

J'ai contourné cloudflare, je suis allé directement au vps et je ne vois plus de "nœuds source et de transformation", et ma construction se termine.

c'était exactement mon problème. Netlify se développait très rapidement - moins de 2 minutes. Seulement environ 30 messages, avec environ 500 images sources. Localement, tout n'était pas terminé, il suffit de décocher le statut CloudFlare pour être DNS uniquement pour résoudre le problème immédiatement

J'ai eu le même problème, bloqué sur "nœuds source et de transformation". Après beaucoup de console.logs, mon problème a fini par être un problème de délai d'attente avec la récupération de fichiers multimédias à partir de wordpress. Le problème n'était pas que le serveur ne soit pas en mesure de le gérer, mais plutôt la limitation du taux de cloudflare et le lancement de délais d'attente après environ 350 requêtes.
J'ai contourné cloudflare, je suis allé directement au vps et je ne vois plus de "nœuds source et de transformation", et ma construction se termine.

c'était exactement mon problème. Netlify se développait très rapidement - moins de 2 minutes. Seulement environ 30 messages, avec environ 500 images sources. Localement, tout n'était pas terminé, il suffit de décocher le statut CloudFlare pour être DNS uniquement pour résoudre le problème immédiatement

J'ai aussi trouvé que c'était le cas. J'avais auparavant une image qui provoquait l'échec de la construction et j'ignorais que Cloudflare était le problème. Depuis, le problème est revenu récemment et comme @amcc a suggéré de ne pas acheminer l'enregistrement A via Cloudflare, le problème a également été résolu immédiatement localement.

Je voulais juste faire écho qu'il ne s'agit pas seulement d'un problème de source WP - je rencontrais le même problème avec gatsby-source-prismic , la réduction de la concurrence du système de fichiers soure avec

Convenez que si rien d'autre, la concurrence du système de fichiers source doit être configurable.

@njmyers Je suis désolé de poser cette question, mais comment exactement ce correctif est-il exécuté. Exécutez simplement le script avant la construction ou ai-je besoin de référencer le script dans le processus de construction, car je me demande actuellement comment appliquer ce correctif localement et également sur netlify, par exemple.

@alexanderwe Pas de soucis, c'est un hack idiot de toute façon. Vous pouvez l'exécuter après avoir installé node_modules . Je ne suis pas sûr à 100% mais je pense que le fichier postinstall de votre projet package.json fonctionnerait.

Pour moi, Gatsby se bloque 50% du temps sur les "nœuds source et de transformation" lorsque j'utilise json avec plus de 500 images incluses. J'utilise gatsby-source-custom-api

Les images sont hébergées sur un serveur rapide et stable.
Ma connexion Internet est également rapide et stable.

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

Que puis-je faire pour déboguer ça ?

Ce problème se produit uniquement avec gatsby-source-custom-api ou source-wordpress ?

Ça m'arrive aussi. J'ai essayé toutes les solutions proposées et rien ne semble fonctionner. Je n'utiliserai certainement plus Wordpress comme backend pour Gatsby, bien que j'entende que des gens rencontrent également des problèmes similaires avec d'autres services.

@alexanderwe La bonne façon de résoudre ce problème est d'implémenter le correctif suggéré par @njmyers
Introduisez ensuite un autre PR à gatsby-source-wordpress et aux autres afin de le rendre réellement configurable à partir de leur référence dans gatsby-config.js

@sebastienfi je viens de tomber sur ce https://github.com/gatsbyjs/gatsby/issues/14819#event -2418874313 et le commit correspondant https://github.com/gatsbyjs/gatsby/commit/90aa24787b32ef9613b6becbfadab6029ec39ddce9#gatsbyjs/gatsby/commit/90aa24787b32ef9613b6becbfadab6029ec39ddce9#gatsbyjs/gatsby/commit/90aa24787b32ef9613b6becbfadab6029ec39ddce9#gatsbyjs/gatsby/commit/90aa24787b32ef9613b6becbfadab6029ec39ddce9#182863bdb64 ajoute une variable d'environnement pour configurer le taux de simultanéité, ce qui a résolu le problème pour moi. Il existe également une discussion en cours sur les variables d'environnement par rapport aux paramètres de configuration : https://github.com/gatsbyjs/gatsby/issues/14636

Avez-vous essayé de définir GATSBY_CONCURRENT_DOWNLOAD sur un nombre inférieur ? Par défaut, il est défini sur 200.

Linux/mac :
GATSBY_CONCURRENT_DOWNLOAD=5 gatsby build

Les fenêtres:
setx GATSBY_CONCURRENT_DOWNLOAD 5; gatsby build

@wardpeet
j'ai essayé, rien n'a changé

Cela a certainement quelque chose à voir avec le système de fichiers source, car les journaux montrent que les images ont été récupérées avec succès... le problème est toujours énorme... nous sommes en retard sur notre échéance, et nous recherchons vraiment un solution à cela...

après avoir configuré le plugin source wordpress pour déboguer, je vois ceci

raccroche toujours entre 470 et 480... mais généralement pas au même endroit.

est-ce que quelqu'un sait où dans le code cela s'exécute?

J'ai fini par le faire fonctionner en basculant un vpn à mi-chemin

Quelqu'un est-il prêt à partager son référentiel avec moi et ses informations d'identification afin que je puisse essayer celui-ci et essayer de trouver le problème ?

N'hésitez pas à m'envoyer un mail privé à [email protected]

mon référentiel n'est pas facilement recréé à ce stade - j'ai une sauvegarde de la base de données telle qu'elle était quelque part, mais pour obtenir la construction du site, j'ai dû réduire chaque mois la valeur des messages en un seul message, pendant des années de contenu.

@wardpeet vous a envoyé mon repo Ward ([email protected]). dis-moi comment ça se passe.

Notre société a changé le wifi et augmenté la bande passante. Aujourd'hui je n'ai eu aucun problème pour télécharger les images... Mais je ne comprends toujours pas, est-ce le réseau ou la simultanéité ?

Cependant, toutes les versions sur Netlify échouent ...

17:13:43 : === [Récupération de wordpress__wp_media] === https://wildkiwi.com/wp-json/wp/v2/media
17:13:43 : Total entités : 1717
17:13:43 : Pages à demander : 344
17:13:45 PM : La demande a échoué avec le code d'erreur "undefined"

le code d'erreur n'est pas défini, donc je ne comprends pas vraiment ce qui se passe...

Lorsque je modifie les requêtes simultanées à 5, cela fonctionne sur Netlify

J'avais ce problème avec un autre plugin (https://github.com/angeloashmore/gatsby-source-prismic) et le réglage GATSBY_CONCURRENT_DOWNLOAD=50 fait l'affaire.

Cela s'est produit à l'improviste (un jour mon site serait construit, le suivant non, sans aucun changement), et sans aucun type de message d'erreur, il est un peu déconcertant de déployer des sites Web pour des clients sans être sûr que cela ne se reproduira plus.

Nous téléchargeons essentiellement 200 images à la fois, mais cela peut être problématique pour certains ordinateurs/connexions Internet. Une bonne solution consiste à faire cuire dans certains mécanismes de nouvelle tentative.

J'avais ces problèmes mais j'ai réussi à faire fonctionner correctement la construction avec une combinaison de setx GATSBY_CONCURRENT_DOWNLOAD 5; gatsby build et de Smushing toutes les images (dont certaines étaient excessivement grandes en dimension et en taille de fichier) en utilisant la version gratuite de https:// en-gb.wordpress.org/plugins/wp-smushit/.

Salut! Je rencontre le même problème avec un plugin source que je crée (sans rapport avec WordPress), et lorsque je télécharge plus de 1000 images, je forme une API. Il se bloque presque toujours à la fin du processus.

Le paramètre GATSBY_CONCURRENT_DOWNLOAD ne l'a pas résolu. J'ai essayé 50 , 20 , 5 , pas de chance.

J'obtiens une collection de tailles de l'API, et j'utilisais la plus grande image, mais je l'ai changée en la plus petite et je ne la répare pas non plus.

Il est difficile d'identifier pourquoi il échoue à ce stade, la seule chose que j'obtiens est source and transform nodes , puis le silence pour toujours.

Ce serait génial d'avoir un mécanisme de débogage pour cela.

Je rencontrais le même problème dans une intégration gatsby + wordress. La construction s'arrêterait pour toujours dans l'API onCreateNode où j'utilisais createRemoteFileNode.

Solution : j'ai mis à jour le système de fichiers gatsby-source de 2.0.4 à 2.1.8 et ajouté GATSBY_CONCURRENT_DOWNLOAD=50 à mes variables d'environnement.

Bonjour

J'ai un problème similaire sur mon projet.

Environnement

  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

J'ai plus de 80000 médias sur mon site WP. Lorsque je lance npx gatsby develop je suis bloqué après "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

J'ai essayé de modifier la valeur GATSBY_CONCURRENT_DOWNLOAD mais rien n'a changé.
Existe-t-il un moyen de limiter l'import de quantité de média ? Par example :

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

Même problème ici, mon WP auto-hébergé a 1690 supports, je suis toujours bloqué à la fin de l'étape Téléchargement des fichiers distants, parfois il ne manque qu'un seul support...

Edit : cette fois, la construction a réussi avec GATSBY_CONCURRENT_DOWNLOAD=5 yarn build ...

@kvalium Merci pour votre commentaire, GATSBY_CONCURRENT_DOWNLOAD=5 yarn build fonctionné pour moi

J'ai eu le même problème et j'arrive à le résoudre en redimensionnant la fenêtre du terminal.

Veuillez vous référer aux derniers commentaires sur #4666.

J'ai également eu le même problème. Je l'ai résolu avec :

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

J'espère que ça peut aider

On dirait que c'est un problème bizarre. Voici mon expérience avec :

• ❌ J'ai vu ce problème sur macOS High Sierra (en utilisant iTerm)
• ✅ J'ai commencé à utiliser GATSBY_CONCURRENT_DOWNLOAD=50 gatsby develop et le problème a disparu (ce fut le cas pendant quelques semaines)
• ❌ J'ai mis à niveau vers Mojave et mis à niveau mon installation globale de Gatsby vers 2.7.47 , puis j'ai recommencé à voir le problème (à l'aide d'iTerm)
• ❌ J'ai essayé de changer GATSBY_CONCURRENT_DOWNLOAD en 5
• ❌ Essayé de souffler .cache et node_modules
• ❌ J'ai essayé de redimensionner la fenêtre iTerm pendant l'exécution de gatsby develop (les deux avec 50 et 5)
• ❌ A couru GATSBY_CONCURRENT_DOWNLOAD=50 gatsby develop dans l'application "Terminal", pas dans iTerm
• ✅ Deux semaines plus tard, j'ai essayé d'utiliser GATSBY_CONCURRENT_DOWNLOAD=50 gatsby develop dans iTerm et j'ai redimensionné la fenêtre plusieurs fois au cours du processus et cela a fonctionné.

J'ai pensé prématurément que je l'avais en cours d'exécution avec ce dernier, mais ensuite il s'est bloqué. Espérons que cela aide les autres. Il semble toujours que ce ne soit pas tout à fait résolu, mais nous y arrivons lentement mais sûrement.

Mise à jour : Aujourd'hui, cela a fonctionné pour moi. Je ne sais pas si c'est parce que j'ai redimensionné la fenêtre iTerm au bon moment du processus ou parce que je l'ai regardée passer de 93% à 100%, mais quelque chose était différent cette fois.

Supplémentaire pour utiliser GATSBY_CONCURRENT_DOWNLOAD = 5, ajoutez le code suivant dans votre fichier gatsby-node.js

// Internationalisation
exports.onPostBuild = () => {
ChildProcess.execSync("ps aux | grep jest | grep -v grep | awk '{print $2}' | xargs kill")
console.log('Copie des paramètres régionaux')
fs.copySync(chemin.join(__dirname, '/src/locales'), path.join(__dirname, '/public/locales))
}

532314892 @bradydowling :

Je ne sais pas si c'est parce que j'ai redimensionné la fenêtre iTerm au bon moment

Alors que je rencontrais le même problème, j'ai redimensionné ma fenêtre iTerm et bam - cela a également continué soudainement. Je ne sais pas si c'est une coïncidence folle, ou...

@bradydowling @davegregg Woah c'est bizarre. Le redimensionnement de ma fenêtre iTerm a fait l'affaire.

@TylerBarnes Quoi que ce soit, je dirais que ce n'est pas spécifique à Wordpress. Je n'utilise rien en rapport avec Wordpress.

@beauhankins Et vous ?

@davegregg @beauhankins @bradydowling est-ce que l'un d'entre vous est en mesure de partager un dépôt où cela se produit ? Cela semble vraiment bizarre que le redimensionnement de la fenêtre de votre terminal résolve le problème.

@TylerBarnes, voici un repo où je le voyais. Je n'y ai pas touché depuis un petit moment.

Remarque : comment gérez-vous une situation où vous clonez un site Gatsby avec une version plus ancienne de Gatsby que celle actuellement installée par la CLI ?

J'exécutais les commendes avec le terminal de code VS (j'utilise bash). Cela prenait une éternité et comme suggéré ci-dessus, j'ai quitté le mode plein écran et cela a fonctionné.

@bradydowling merci d'avoir partagé votre repo ! Pour utiliser des versions plus anciennes de Gatsby que cli, vous pouvez créer un script npm pour le développement et la construction.

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

puis exécuter npm run develop ou yarn develop utilisera la version locale de votre projet.

Nous étudions ce problème, mais en attendant, toute personne ayant le problème peut être en mesure de le contourner en exécutant CI=1 yarn build , car cela devrait utiliser une bibliothèque de reporters différente dans les coulisses. Si vous essayez cela et que cela fonctionne, faites-le nous savoir!

@dustinhorton :

version v2 @ https://github.com/dustinhorton/gatsby-v2-issue. Je construis depuis environ 50 minutes à ce stade.

Fwiw. Je me rends compte que cela a été publié il y a environ un an et que Gatsby a considérablement changé depuis lors. Lorsque vous l'exécutez sur ma machine (et que vous définissez la version de gatsby sur * dans package.json), la construction semble se terminer en 2000 secondes environ (environ 33 minutes).
De plus, lors de la mise à niveau de l'interface de ligne de commande, il y a maintenant une barre de progression, ce qui fait une énorme différence en termes de temps qu'il "se sent", puisque vous obtenez une boucle de rétroaction plus concrète.

L'étape de sourcing prend presque tout ce temps (1968 / 1975 secondes). Le téléchargement de fichiers distants est le plus important (1845 secondes).

Cela ne me surprend pas quand je regarde un seul aller-retour vers ce serveur :

# 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

Chaque requête prend environ 2 à 4 secondes. Les 75 pages qui sont récupérées initialement lors de l'exploration, prennent 18 secondes au total (!). J'ai une connexion rapide et je recan reproduira ce timing avec un simple wget.

Ainsi, l'étape la plus longue tentera de télécharger environ 7500 ressources. Considérant qu'une seule requête prend 2 à 4 secondes, je ne suis pas surpris que cela prenne autant de temps.

Même ainsi, je remarque quelques pauses pendant la période de téléchargement principale de 1845 secondes. Je ne sais pas s'il s'agit uniquement du serveur qui limite les données ou non (j'ai défini la simultanéité sur 5).

J'ai essayé de faire bouger la largeur du terminal (je suis sur xfce linux, fwiw) et bien que cela coïncide parfois avec les progrès, je suis maintenant convaincu que c'est plus une coïncidence qu'une causalité.

Conclusion : bien que je puisse reproduire la lenteur du téléchargement et la progression apparemment "bloquée", tous les signes indiquent actuellement que cela est en grande partie dû à l'attente de la réponse du serveur. De plus, la largeur du terminal ne semble pas affecter cela.

Cela dit : il est possible que la sortie du terminal se bloque d'une manière ou d'une autre lors de la mise à jour de la barre de progression à une largeur très particulière. Bien que cela soit peu probable, ce n'est pas impossible. Par conséquent, nous avons vraiment besoin d'un repro que nous pouvons exécuter nous-mêmes (donc pas d'autorisation). Et de préférence un qui ne dépend _pas_ d'un serveur distant, car je ne veux pas marteler le serveur.

Je vais mettre à jour les étiquettes sur ce problème en conséquence.

La repro publiée dans https://github.com/gatsbyjs/gatsby/issues/6654#issuecomment -438667221 par @njmyers n'existe plus

Le dépôt publié dans https://github.com/gatsbyjs/gatsby/issues/6654#issuecomment -562607399 par @bradydowling nécessite un tas d'autorisations que je n'ai pas et semble avoir des problèmes similaires avec le temps aller-retour

@ 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

Cette étape d'approvisionnement n'affiche pas vraiment d'indicateur de progression, à l'exception du spinner et parfois les étapes sont enregistrées, et prend encore quelques minutes, nous pouvons donc peut-être au moins montrer une sorte d'indicateur de progression si cela a du sens.

De plus, cela pourrait peut-être aider à indiquer le temps moyen pour récupérer une ressource, car c'est une indication de la raison pour laquelle "Gatsby" est lent, alors qu'il est vraiment causé par l'aller-retour.

Dans ce référentiel, même le téléchargement de 589 fichiers distants prenait environ 5 minutes, la barre de progression étant souvent simplement bloquée sans raison apparente.

Après le démarrage, la construction échoue pour moi car des fichiers sont manquants.

@pvdz Je devrai rejouer avec ça (j'ai abandonné pendant un moment) mais il y a certains fichiers qui posent des problèmes d'autorisations même lorsqu'il se construit avec succès, donc j'ai juste pensé que ceux-ci peuvent être ignorés.

Mais pour résumer votre message, dites-vous que certaines étapes (de téléchargement) prennent vraiment beaucoup de temps et que nous devrions attendre plus longtemps pour qu'elles se terminent ?

@bradydowling Eh bien, ça y ressemble, oui. :)

FTR : J'ai suivi un peu la collecte de ressources. Pour faire la lumière sur les horaires ;

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

Ce sont des fichiers de 6 Mo d'ailleurs. Je suis sur une connexion de 250 Mbs, ce qui est bien pour gérer celles qui sont plus rapides que 1 Mbs, mais cela ne m'étonne pas qu'il explose les temps de téléchargement. Aucune quantité de redimensionnement de cli ne va accélérer cela ;)

Intéressant. Il ne s'agit que d'un blog personnel WordPress standard hébergé sur EC2, donc ce n'est pas comme s'il s'agissait d'une installation gigantesque. C'est peut-être parce que toutes ces demandes surchargent l'hôte. Ou, je ne suis pas un expert WordPress, mais peut-être qu'il y a une sorte de limite de taux WP standard sur les appels d'API REST qui peut arriver ? Je part également du principe que ce comportement n'est pas unique à ce site.

C'est peut-être parce que toutes ces demandes surchargent l'hôte.

C'est ma conjecture (ou quelque chose dans ce stade). Mais j'explore un peu notre propre architecture pour vérifier si nous perdons en efficacité à cause des abstractions. Mais étant donné que je peux imiter la plupart des temps rapportés avec des wgets/boucles simples, je doute qu'il y ait beaucoup là-bas.

Donc fwiw j'ai remplacé les bits got.stream() par un téléchargeur brut stupide :

    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

Alors oui, je suis presque sûr que les longs délais (dans ce cas du moins) sont causés par le téléchargement. Alors peut-être que notre meilleur pari est d'améliorer les commentaires en attendant un téléchargement :)

Beaucoup de gens disent que le redimensionnement des fenêtres de terminal (pour une raison étrange) résout le processus de développement bloqué sur les « nœuds source et de transformation ».

Malheureusement, lorsque vous utilisez WSL, ce n'est pas une solution. Coincé avec les « nœuds source et de transformation » localement dans la construction ainsi que dans le développement. Les builds Netlify fonctionnent mais le développement local est devenu impossible.

@Vacilando pouvez-vous déboguer certains liens en cours de téléchargement pour votre site lors du sourcing et tester manuellement s'ils se téléchargent rapidement ? Comme je l'ai mentionné ci-dessus, un gros problème que je vois est que certains hôtes wp sont tout simplement super lents.

Donc, si l'hôte est lent et qu'il y a beaucoup de contenu à télécharger, alors oui, cette étape prendra beaucoup de temps car c'est tout ce qu'il devrait faire dans cette étape ; découvrez le contenu et téléchargez-le :)

Si vous avez confirmé que le contenu lui-même est téléchargé en une fraction de l'étape, veuillez revenir ici. Dans ce cas, une reproduction serait extrêmement utile :)

Peut-être que dans un monde idéal, vous pourriez passer un drapeau à Gatsby qui mettrait en cache
le téléchargement des ressources du site afin que cela n'ait pas à être fait à plusieurs reprises.

Une autre solution optimale serait d'autoriser un indicateur qui définit une sorte de
limitation du débit ou limitation du téléchargement d'actifs afin qu'il n'éclate pas
l'hôte.

Des avis sur ces deux idées ?

Le jeu. 19 décembre 2019, 18:09 Peter van der Zee [email protected]
a écrit:

@Vacilando https://github.com/Vacilando pouvez-vous déboguer certains liens qui
sont en cours de téléchargement pour votre site lors du sourcing et testez manuellement
s'ils téléchargent rapidement ? Comme je l'ai mentionné ci-dessus, un gros problème que je suis
voir, c'est que certains hôtes wp sont tout simplement super lents.

Donc, si l'hôte est lent et qu'il y a beaucoup de contenu à télécharger, alors oui
cette étape prendra beaucoup de temps car c'est tout ce qu'il faut faire dans
cette étape; découvrez le contenu et téléchargez-le :)

Si vous avez confirmé que le contenu lui-même est téléchargé en une fraction du temps
étape entière, veuillez revenir ici. Dans ce cas, une repro serait
extrêmement utile :)

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/gatsbyjs/gatsby/issues/6654?email_source=notifications&email_token=ABS4AU62367MTEWP7LJXWTLQZP5L5A5CNFSM4FLHT3T2YY3PNVWWK3TUL52HS4DFVREXG43VMHJZW63LNMVK56
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/ABS4AU7GCV4YMZQH6R37BSDQZP5L5ANCNFSM4FLHT3TQ
.

@bradydowling une partie de cela existe déjà en fait. Vous pouvez définir une variable d'environnement GATSBY_CONCURRENT_DOWNLOAD pour configurer la limite des requêtes simultanées. La prochaine version majeure de gatsby-source-wordpress https://github.com/gatsbyjs/gatsby/issues/19292 aura plus de contrôle sur la façon dont les fichiers multimédias sont téléchargés. En ce qui concerne la mise en cache, les fichiers téléchargés sont actuellement mis en cache, mais lorsque vous modifiez un fichier gatsby-*.js, il efface actuellement le cache pour éviter qu'un cache obsolète ne provoque des bogues inattendus. C'est donc un problème central plutôt que d'être spécifique à gatsby-source-wordpress , mais du travail est toujours en cours pour améliorer le cache de Gatsby.

Partiellement Jobs Api (#19831) devrait résoudre ce problème de mise en cache.

Oui, j'ai vu le morceau environ GATSBY_CONCURRENT_DOWNLOAD plus près du sommet. D'après mon expérience, cela n'a pas aidé, donc je suppose que ma suggestion était vers un contrôle plus fin comme en mb par s/m/h ou quelque chose comme ça. Peut-être que je dis juste des bêtises.

@bradydowling J'envisage d' ajouter des nouvelles tentatives de demande avec une interruption exponentielle ainsi que d'ajouter un paramètre facultatif pour le nombre maximal de demandes par seconde pour les cas où cela ne fonctionne pas assez bien.

Salut !

Ce problème est devenu silencieux. Effrayant calme. ??

Nous obtenons de nombreux problèmes, nous fermons donc actuellement les problèmes après 30 jours d'inactivité. Cela fait au moins 20 jours depuis la dernière mise à jour ici.
Si nous avons raté ce problème ou si vous souhaitez le garder ouvert, veuillez répondre ici. Vous pouvez également ajouter l'étiquette « not stale » pour garder ce problème ouvert !
Pour rappel amical : la meilleure façon de voir ce problème, ou tout autre, résolu est d'ouvrir une demande de tirage. Consultez gatsby.dev/contribute pour plus d'informations sur l'ouverture des PR, le tri des problèmes et la contribution !

Merci de faire partie de la communauté Gatsby ! ??

Je vais fermer ça maintenant.

Si vous pensez avoir un problème de sourcing wordpress, veuillez d'abord confirmer que vos retards ne sont pas causés par un serveur wordpress lent. Alors s'il vous plaît ouvrez un _nouveau_ problème (mais n'hésitez pas à revenir sur ce problème).

Le nombre élevé de commentaires rend très difficile le suivi de la discussion. Ainsi, l'ouverture d'un nouveau problème est plus susceptible d'aboutir à une réponse à votre problème spécifique.

Moi et d'autres l'avons confirmé au cours de la dernière année et demie. mon problème d'origine était sur un vps bien réglé. @njmyers avait probablement un correctif, ou du moins une amélioration, mais n'a pu obtenir aucune réponse des responsables sur la manière dont ils aimeraient que cela soit fait.

J'ai pensé à me fermer, mais je pense que cela doit être là pour avertir qu'un site wordpress de taille moyenne n'est PAS encore adapté à Gatsby.

@dustinhorton Je comprends ça. Ce problème date de plus d'un an et demi, les choses changent rapidement. Avec le problème qui s'élève à autant de commentaires, il est difficile de comprendre le problème réel.

Fwiw, comme indiqué ci-dessus, j'ai vérifié les dernières reproductions signalées et j'ai déterminé que celles-ci, au moins, étaient causées par des télécommandes lentes. Si vous avez une reproduction d'une version actuelle de Gatsby sur une télécommande rapide, faites-le moi savoir, même si elle est peut-être déjà publiée dans ce fil. Ou peut-être ouvrir un nouveau numéro pour cela (et me taguer) si vous voulez vous concentrer davantage dessus, je vous laisse le soin de décider :)

(_Juste pour être clair, nous avons fermé ce problème car il est devenu un peu obsolète avec trop de messages hors sujet, veuillez ne pas avoir l'impression que nous étouffons la discussion car ce n'est pas l'intention et nous reconnaissons que notre travail n'est pas terminé ici !_)