Jason Bahl

We’re still in the process of troubleshooting, determining if it’s another plugin that’s causing the issue. We’ll figure it out.

Hope you get it sorted! I would recommend trying on a vanilla WP install, then adding different plugins one at a time to see if you can identify a conflict with another plugin. Or start on a staging site clone of your site and remove other plugins one at a time.

WPGraphQL definitely doesn’t de-activate on its own, so if something is causing it to de-activate, it’s outside of the WPGraphQL codebase.

Would love to hear what you find out, especially if it’s anything we can help guard against for other users.

I’d be uncomfortable investing time and effort into a plugin where we can’t get reasonably prompt responses (and a thriving community is a key part of that, to take the pressure of the developer).

@jondcruz The WPGraphQL Slack is pretty active (~3,000 users in that slack) than these forums. I’d recommend heading over there if you have general questions, etc.

https://join.slack.com/t/wp-graphql/shared_invite/zt-3vloo60z-PpJV2PFIwEathWDOxCTTLA

You could also check out the Headless WP Discord which is pretty active as well: https://discord.gg/J2khkF9XYK

—-

Is the plugin recommended for Production and Enterprise-level websites?

@markwill It’s been used in production on enterprise sites such as QZ.com as far back as 2017!

WPEngine.com is a headless front-end built on Faust.js and using WPGraphQL.

There’s a ton of examples of headless front-ends powered by WPGraphQL!

—-

When we attempted to use the plugin with 6.3, we had issues with some admin users not being able to see the plugin, or its IDE UI, at all. ?The admin who could actually see the plugin found it deactivated as soon as the other admins tried to view it.

It sounds like someone de-activated the plugin?

Make sure the plugin is active before trying to use it. And also make sure the users trying to use the IDE have manage_options capabilities.

The IDE is limited to folks with manage_options capability (https://github.com/wp-graphql/wp-graphql/blob/4050581ca4be74aaf1fc35c86a7bec2ad3af1c64/src/Admin/GraphiQL/GraphiQL.php#L95).

If you want to open up the IDE for more users, you should be able to override the capability like so: https://wordpress.stackexchange.com/questions/262470/how-to-change-menu-page-capability#answer-410786

Marking this resolved as there’s been no confirmation that this is still an issue since the 1.14 release.

@troyblakelyd could you maybe share a full code snippet?

I’ve never used poet, but I imagine it would work fine with WPGraphQL.

I’m not sure “admin_cols” is the right place to add these fields though. They should be at the root of the post type.

If poet isn’t passing those fields through to the underlying register_post_type() then I would recommend opening an issue with Poet.

@felixh3r the addToCart mutation is added by WPGraphQL for WooCommerce. Please open an issue on that repo: https://github.com/wp-graphql/wp-graphql-woocommerce/issues/new/choose

@lyashko v0.4.0 (https://github.com/wp-graphql/wp-graphql/releases/tag/v0.4.0) is from October 2019 and a LOT has changed since then!

My guess is that there is some custom code in the theme or plugins that are calling functions that no longer exist, or something along those lines.

I would recommend checking your PHP error logs to see what you can find out.

Also, you will almost certainly need to update queries in your client application as the Schema most likely has had many changes since 0.4.0 and your queries will likely not be valid against current versions of WPGraphQL.

Hey Ben!

Thanks for the critical review. I’m so sorry for the inconvenience the bug(s) have caused you.

I just checked the issues and I don’t believe you brought this to our attention. It’s a bit difficult to help correct an issue if the issue isn’t shared with us.

We’ve been pretty good at responding to your issues when you raise them: https://github.com/wp-graphql/wp-graphql/issues?q=is%3Aissue+author%3Abenknight.

Would have loved to have the chance to work with you on this!

My hunch is that you’re referring to a regression that was caused in 1.14 release and we worked with those that raised issues to resolve these regressions in a timely manner (see 1.14.1 – 1.14.3 releases and their corresponding issues raised).

Anyway, we have decent test coverage for a lot of common scenarios, and do our best to prevent regressions, but unfortunately regressions do still occur.

When we are made aware of a regression, we do our best to address them pretty quickly, and then add more tests to help prevent future regressions. The use cases for WordPress + WPGraphQL are quite vast, so we’re always looking to add tests for scenarios that aren’t already well covered.

Multilingual / non-English use-cases could definitely use more testing!

We’d love folks with more experience here to contribute tests / scenarios, etc so the codebase can better support those use cases. It’s certainly something I have limited experience with.

If there’s queries that you rely on, I’d love to work with you to get the core WPGraphQL functionality you’re relying on better tested to ensure future releases don’t break the functionality.

Let us know if you’d be willing to help us get some of these things better tested! ??

@anshulchauhan71 as the error explains, you either need to pass a query or queryId with the request.

The endpoint doesn’t give anything in response if nothing is asked for.

You can read more about Interacting with the WPGraphQL endpoint here: https://www.wpgraphql.com/docs/interacting-with-wpgraphql

@japor42069 I replied to you in Github with a code snippet that might help you accomplish what you’re after.

@japor42069 I think you’ve also opened an issue on the Github repo.

This behavior matches WordPress core behavior.

If you preview a post in non-headless WordPress, the terms associated with the preview will be displayed in the preview template from the parent (published) post, not the preview revision.

For example, I have a published post that’s in the “Uncategorized” category.

If I view the published post (non-headless WordPress) I see that it’s in the “Uncategorized” category

If I go in the editor and click to add new terms:

Then click “preview”, I will still see only the “Uncategorized” category associated with the post.

WPGraphQL is behaving in the same way. If you query a Post using asPreview => true, then query connected terms, it will resolve the connected terms from the parent (published) post.

Based on how core WordPress previews work, what you’re describing is the behavior I would expect from WPGraphQL.

• This reply was modified 1 year, 8 months ago by Jason Bahl.

There’s been several point release updates to 1.13, and 1.14.0 was released today.

Is this still an issue?

If so, I think the best recommendation would be to provide detailed steps to reproduce in a Github Issue and we an look into it more deeply.

It’s definitely possible, but not something WPGraphQL is trying to solve.

WPGraphQL exposes WordPress as a GraphQL API, it doesn’t facilitate (or try to) fetching content from remote APIs for storage in WordPress.

Once you do fetch the content from remote APIs and persist the data in WordPress, you can expose it to the WPGraphQL API using the register_graphql_* functions documented here: https://www.wpgraphql.com/functions

@rgenck the $post that comes through the resolve function is an instance of a WPGraphQL Post Model, not a WP_Post object.

So instead of get_post_meta( $post->ID, ... ) you would want to do get_post_meta( $post->databaseId, ... )

See if that works?

We’ll need more information to be able to help in any way.

Can you provide steps to reproduce the issue? It sounds like you’re having trouble fetching with the GraphiQL IDE, but I’m not sure what steps you took to get to that situation.

I use the GraphiQL IDE daily and it works well, so my guess is there’s a specific way you have WordPress set up that might cause this issue?

If you can provide repeatable steps to get WordPress setup in a way that I can reproduce this issue, that would be helpful.

@genopeppino this sounds like perhaps Toolset is doing something different than standard WordPress post types and you might need to hook into their plugin differently to play nice.

It looks like some folks have explored bridging toolset with WPGraphQL. You might be able to use this plugin, or find inspiration from its code:

https://github.com/zaantar/toolset-wp-graphql