Closed ssoney200 closed 4 years ago
Hi Jamie 👋 hope you're enjoying Gatsby so far! Try this:
wordpressPage(wordpress_id: {eq: 71}) {
title
content
acf {
faculty_title
faculty_text
faculty_selector {
wordpress_id
}
}
}
allWordpressAcfFaculty(filter: {wordpress_id: {eq: 71} }) {
edges {
node {
id
wordpress_id
acf {
faculty_excerpt
faculty_content
}
}
}
}
That will filter that array down; there may also be a wordpressAcfFaculty
node that you can query. If there is let me know and we can simplify that query further
@ssoney200 Instead of using gatsby-source-wordpress
I highly recommend using the new gatsby-source-wordpress-experimental
plugin (https://github.com/gatsbyjs/gatsby-source-wordpress-experimental).
This is the plugin we're supporting long term and will soon fully replace gatsby-source-wordpress
as the v4 release.
The new source plugin does not use the WP REST API to communicate with WordPress, but instead uses WPGraphQL (https:/github.com/wp-graphql/wp-graphql).
You can read more about the new source plugin on the Gatsby Blog and on WPTavern.
The WP REST API, specifically when using extensions such as that for ACF can be pretty problematic because of its inconsistent and unpredictable shape of data. Unpredictability and inconsistency make decoupled applications very difficult to reliably build.
With WPGraphQL and extensions such as WPGraphQL for Advanced Custom Fields the issue of unpredictability and inconsistency go away. This is because the ACF fields are exposed to a Schema so that Gatsby can know what data is possible to be returned by WordPress before any data is returned, and Gatsby can be prepared to handle it.
I believe that by switching to using WPGraphQL and WPGraphQL for Advanced Custom Fields on your WordPress site, and Gatsby Source WordPress Experimental, this specific issue should go away, and we'll be able to better support you with other issues or roadblocks you run into.
Thanks Jason,
Good to hear there might be something that could help ease the pain. The builds and develops have become somewhat problematic.
I've spent the last few hours testing this other route with the plugin you mention.
One thing I am struggling on though, is when using the rest version, I was able to filter pages by template.
Example:
about: allWordpressPage(filter: {template: {eq: "page-templates/about-us.php"}}) {
edges {
node {
id
slug
status
link
wordpress_id
}
}
}
in node js to route any pages that used that template to the correct pages.
Is there a way to manage that on graphql plugin. I was thinking something like the following, but you cannot filter by where on template.
pages(where: {}) {
edges {
node {
title
template{
}
}
}
}
I also have a secondary issue, that when in dev mode, my http://localhost:8000/___graphql shows 'no schema available', even though if you add correct data, such as:
{
allWpPage {
edges {
node {
id
status
link
parentId
content
}
}
}
}
Thanks!
@ssoney200 Instead of using
gatsby-source-wordpress
I highly recommend using the newgatsby-source-wordpress-experimental
plugin (https://github.com/gatsbyjs/gatsby-source-wordpress-experimental).This is the plugin we're supporting long term and will soon fully replace
gatsby-source-wordpress
as the v4 release.The new source plugin does not use the WP REST API to communicate with WordPress, but instead uses WPGraphQL (https:/github.com/wp-graphql/wp-graphql).
You can read more about the new source plugin on the Gatsby Blog and on WPTavern.
The WP REST API, specifically when using extensions such as that for ACF can be pretty problematic because of its inconsistent and unpredictable shape of data. Unpredictability and inconsistency make decoupled applications very difficult to reliably build.
With WPGraphQL and extensions such as WPGraphQL for Advanced Custom Fields the issue of unpredictability and inconsistency go away. This is because the ACF fields are exposed to a Schema so that Gatsby can know what data is possible to be returned by WordPress before any data is returned, and Gatsby can be prepared to handle it.
I believe that by switching to using WPGraphQL and WPGraphQL for Advanced Custom Fields on your WordPress site, and Gatsby Source WordPress Experimental, this specific issue should go away, and we'll be able to better support you with other issues or roadblocks you run into.
Hi Jason,
Just wanted to come back and say, your suggestion to move to Gatsby-source-wordpress-experimental has literally saved my life on this project!
It’s been a really painful weekend converting over, due to nature of graphql camel-casing all acf fields (my site uses a ton), but I finally made it back to where I was yesterday evening.
And you was right, the issue I mentioned above has seemingly gone away, amongst many others!
But, the more important thing is the consistency. The develop or build using the rest api was really painful. But now it’s a breeze! On develop I’m not missing random child image sharps and more importantly I don’t get the almost-always random errors on build that we’re driving me absolutely insane.
So, whilst your suggestion made it difficult this weekend, it’s gonna make this project a lot more enjoyable to work on in the future.
I’ll now be using Gatsby a ton more.
Thanks!
@ssoney200 Thanks for posting back with an update. I'm so happy to hear this!
I look forward to seeing projects you ship with this stack!
@ssoney200 Thanks for posting back with an update. I'm so happy to hear this!
I look forward to seeing projects you ship with this stack!
Hi Jason,
Since switching to this version of gatsby source wordpress experimental I've come across a really strange issue that I hope you might be able to help me solve. I'm due to go live with this project in a little over a week, so I'd really appreciate if you could offer some assistance to what might be causing the following issue.
The problem is I am am running into an issue where my page content seems to be getting muddled up when retrieved by Gatsby using graphql. This is an issue that was not happening with the rest api. The issue seems to be related to when Gatsby retrieves the content and the problem is it seems to mix up the polylang translation.
I have attached two screenshots, one with graphiql in my wordpress dashboard, and then the other in my local environment in gatbsy develop which also gets built on build, so I end up with mixed up content in the same page which obviously I need to resolve as a matter of urgency.
In the first in my graphql playground in wordpress admin the content is correct for the English language version. But on the second screenshot, when it gets retrieved by gatsby you can see that it somehow has appears to be swapped out in parts with the alternate language content. So the bug appears to be only on the Gatsby side.
http://www.bubbleweb.eu/images/wp-side.png
http://www.bubbleweb.eu/images/gatsby-side.png
It's a really strange issue that was not there before switching and is bizarre, but hoping someone else has had a similar issue and can help me to resolve?
Thanks, Jamie
Hi.
I'm fairly new to Gatsby and graphql so apologies if this is a seems a fairly trivial or straight forward request..
A bit about the project - I'm building out a WordPress site using Gatbsy. It's a site containing a fair amount of Advanced Custom Field editable data. It's going really well so far but I'm stuck on one issue.
I have a page on my WordPress site using the Advanced Custom Fields relationship field to pick related post content.
From the rest API however, the WordPress page's relationship data (faculty_selector) does not contain the posts relevant ACF fields, only relationship type data such as the post's wordpress_id.
Here is my current query: