I have a Wordpress site set up and hosted on Digital Ocean. I’m using Gatsby and gatsby-source-wordpress, a plugin that calls the WordPress API and pulls in blog posts. I’m dynamically assembling pages and deploying a Gatsby site to Netlify.
Problem:
When trying to deploy my site on Netlify, it fails due to errors (build log pasted below). It seems to be that Netlify isn’t able to fetch the data from the Wordpress API but I’m not sure why that is. I have stored the Wordpress API URL (wp.user.com) as an environment variable on Netlify.
My live site is www.user.com which points to user.netlify.app
My Wordpress API URL is wp.user.com which is a subdomain pointing to the Digital Ocean droplet
I’ve tested this on my local by replacing my local Wordpress API URL in my .env file with the Wordpress API I’m using for my live site (user.local → wp.user.com). It fetched all the posts and returned the changes I made so I know that there isn’t an issue with the API. I can’t tell if I have missed an important configuration step on Netlify, if the environment variables are incorrect or if the issue lies elsewhere.
@sao This is just a shot in the dark, but sites that are served via HTTPS cannot fetch assets from sources that are served over HTTP. Have you tried setting up your WordPress instance to be served by HTTPS, and then changing your URL scheme to match?
You’ll need to debug what is failing in that call. That’s a response from some external service (wordpress) and we can’t tell why that would happen, since we have nothing to do with that service. I can tell you we do not change anything about outgoing network requests during build - what you send is what happens. If you use a wrong hostname or call, we’ll happily send it, and you’ll (hopefully) see an error from the remote service, if you contacted them correctly.
ENOTFOUND sounds like your call DID contact some service; that’s a pretty reasonable error code for a request for something that is missing (perhaps you have the call targetting a wrong path or workspace or something?) This is in contracts to contacting a completely typo’d hostname or having a really malformed URL like ttps://something
If it’s a service you subscribe to, their tech support may be able to take the timestamp and see the request and advise as to what’s going wrong, but your better bet will probably be to:
figure out what API call is being made by your code
if the API call looks reasonable to you, ask their support team about that
…since I doubt they will be able to debug your source code directly either
