Gatsby: [gatsby-source-wordpress] - wp_media error

[jasenwyatt]

After success with the example, I'm trying various sites of mine and I'm noticing a common error:

```⠠ source and transform nodes -> wordpress__POST fetched : 88
⠠ source and transform nodes -> wordpress__PAGE fetched : 10
error Plugin gatsby-source-wordpress returned an error

TypeError: Cannot read property 'status' of undefined

• http-exception-handler.js:12 httpExceptionHandler
  [tutorial-part-three]/[gatsby-source-wordpress]/http-exception-handler.js:12:27

• fetch.js:447 _callee4$
  [tutorial-part-three]/[gatsby-source-wordpress]/fetch.js:447:47

• next_tick.js:109 process._tickCallback
  internal/process/next_tick.js:109:7
  ```

Wondering if a common plugin or something could be causing this, or if I'm just overlooking something completely?

[sebastienfi]

@jasenwyatt interesting. Can you please post the gatsby and gatsby-source-wordpress version ?

npm list gatsby gatsby-source-wordpress

[jasenwyatt]

Disabled all plugins (on one site) and getting same result.

@sebastienfi

+-- [email protected]
`-- [email protected]

[KyleAMathews]

This isn't at all surprising. The v2 branch is very new so entirely likely it's not rock solid yet.

From your stack trace, it looks like we're assuming a value is set that's not. Could you debug where this is happening and add a check in a PR?

This page tells you how to setup your dev environment https://www.gatsbyjs.org/docs/how-to-contribute/#contributing

[jasenwyatt]

Looking deeper into the trace today. Will update my findings and a PR as soon as I can.

[flmuel]

I have come across the same error...
my plugins:
"gatsby": "^1.9.45",
"gatsby-link": "^1.6.17",
"gatsby-plugin-less": "^1.0.5",
"gatsby-source-wordpress": "^2.0.10"

success delete html files from previous builds — 0.019 s
success open and validate gatsby-config.js — 0.007 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.036 s
success onPreBootstrap — 0.010 s
.
=START PLUGIN=====================================

Site URL: https://sub.sub.url.net
Site hosted on Wordpress.com: false
Using ACF: true
Using Auth:  
Verbose output: true

Mama Route URL: https://sub.sub.url.net/wp-json

error Plugin gatsby-source-wordpress returned an error


  TypeError: Cannot read property 'status' of undefined

  - http-exception-handler.js:12 httpExceptionHandler
    [360vier]/[gatsby-source-wordpress]/http-exception-handler.js:12:27

  - fetch.js:104 _callee$
    [360vier]/[gatsby-source-wordpress]/fetch.js:104:13

  - next_tick.js:103 process._tickCallback
    internal/process/next_tick.js:103:7


success source and transform nodes — 0.129 s
success building schema — 0.290 s
success createLayouts — 0.038 s
success createPages — 0.011 s
success createPagesStatefully — 0.024 s
success extract queries from components — 0.155 s
success run graphql queries — 0.028 s
success write out page data — 0.006 s
success write out redirect data — 0.001 s
success update schema — 0.268 s
success onPostBootstrap — 0.008 s

info bootstrap finished - 2.996 s

 DONE  Compiled successfully in 4445ms

[flmuel]

could it be possible, that the plugin cannot handle sites with password protection? cause its working on sites without password (at least for the few i tried)...
otherwise it is not logical, because I am in the network and don't need to type in password, so gatsby doesn't need it either...

[brandensilva]

Same issues on "gatsby": "1.9.45" and "gatsby-source-wordpress": ^2.0.12. Effectively this source is broken right now even with a base default starter.

[brandensilva]

@jasenwyatt Were you able to find a version that was stable and working? I'm willing to downgrade Gatsby and the wordpress source plugin to get it working until these bugs get ironed out.

As @KyleAMathews mentioned it sounds like things are in flux right now with the latest release.

@KyleAMathews is there any chance the plugins can be separated from the core gatsby repo? It is a bit of a hunt to get to the right information depending on which plugin you are talking about and it seems easier to file issues against a particular plugin vs core.

[KyleAMathews]

@brandensilva you're having trouble running https://using-wordpress.gatsbyjs.org/ locally as well?

Just a general note on the WordPress source plugin — we need more maintainers of this!

Try following the contributor guide to start running the wordpress source plugin from source. Then trace your error in the source and come up with a potential solution and do a trial PR to see what people think. Would be happy to give feedback.

E.g. looking at this stack trace, the error comes from https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-source-wordpress/src/http-exception-handler.js which means some of the errors being sent there don't have a status.

Anyone want to try investigating the problem and finding either why some errors don't have the status set and either fix that or handle the lack of status in the exception printer.

[flmuel]

For me it was a defective ssl certificate (error: UNABLE_TO_VERIFY_LEAF_SIGNATURE) on our website. console.log(e) in the httpExceptionHandler has helped us...

[KyleAMathews]

@flmuel could you add a PR for the exception handler to not error when status isn't set?

[tw-360vier]

@KyleAMathews
I see the problem not in status but e.response not being defined. This is of course the case when the request fails because of network errors, invalid (or missing intermediate as was the case with UNABLE_TO_VERIFY_LEAF_SIGNATURE) SSL certificates, DNS etc.
Shouldn't the exception handler at least log the error code so one can easier figure these things out?

e.g.:

const colorized = require(`./output-color`)

/**
 * Handles HTTP Exceptions (axios)
 *
 * @param {any} e
 */
function httpExceptionHandler(e) {
  const {response, code} = e
  if(!response){
    console.log(
      colorized.out(
        `The request failed with error code "${code}"`,
        colorized.color.Font.FgRed
      )
    )
    return
  }
  const { status, statusText, data: { message } } = response
  console.log(
    colorized.out(
      `The server response was "${status} ${statusText}"`,
      colorized.color.Font.FgRed
    )
  )
  if (message) {
    console.log(
      colorized.out(
        `Inner exception message : "${message}"`,
        colorized.color.Font.FgRed
      )
    )
  }
}

module.exports = httpExceptionHandler

if thats the way to go i'll see that i put up a pull request for this.

[KyleAMathews]

That looks like a great approach! Go for it!

[flmuel]

@KyleAMathews there was also still a problem with the basic auth... @tw-360vier changed

return axios({
    method: `get`,
    url: url
});

to this on line 90 in fetch.js:

return axios(options);

so now its working fine :)

[brandensilva]

@flmuel Makes sense as the other areas in this file are using await axios(options) to fetch the response. Just above this line the auth is getting set on the options object if it exists.

You still want to persist the async await on this though I imagine.

allRoutes = await axios(options)

Correct me if I'm wrong but I don't think you need to return anything at this point since allRoutes gets passed down to a validator and is returned later.

Are you creating a PR around this?

[flmuel]

@brandensilva I am not that experienced with Github, especially the functionalities like the pull request 😅 Maybe I will look further into this or @tw-360vier will do this...

[KyleAMathews]

@flmuel there's a great free course on making your first contribution! https://egghead.io/courses/how-to-contribute-to-an-open-source-project-on-github

Would love to help you get your first PR in!

[KyleAMathews]

Closing this issue as it's fairly old and we have far too many open issues! If you have additional problems in this area, please open a new issue!