`events` query returns no results
Closed this issue ยท 9 comments
I've just installed the plugin and when I query using events
, I always get an empty array even though I've created a few events all filled out to test. If I use the event
connection and query using the id, it works as expected. Only this connection doesn't seem to work.
Here are my plugins and configurations:
QL Events
Version 0.0.1
The Events Calendar
Version 6.1.3
The Events Calendar Pro
Version 6.1.1
WPGraphQL
Version 1.14.9
PHP
Version 8.1.18
Mysql
Version 5.7
WordPress
Version 6.2.2
I've tried running a simple query like and many like it with no change in returning anything other than an empty array.
events {
nodes {
title
}
}
When I have debugging on and run this query I get this in debug.log
WordPress database error You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'DESC
LIMIT 0, 11' at line 5 for query
SELECT (wp_tec_occurrences.occurrence_id + 10000000) as occurrence_id
FROM wp_posts JOIN wp_tec_occurrences ON wp_posts.ID = wp_tec_occurrences.post_id
WHERE 1=1 AND wp_posts.post_type = 'tribe_events' AND ((wp_posts.post_status = 'publish'))
ORDER BY wp_posts.post_date DESC, wp_posts.ID DESC DESC
LIMIT 0, 11
made by require('index.php'), require('wp-blog-header.php'), wp, WP->main, WP->parse_request, do_action_ref_array('parse_request'), WP_Hook->do_action, WP_Hook->apply_filters, WPGraphQL\Router::resolve_http_request, WPGraphQL\Router::process_http_request, WPGraphQL\Request->execute_http, GraphQL\Server\StandardServer->executeRequest, GraphQL\Server\Helper->executeOperation, GraphQL\Server\Helper->promiseToExecuteOperation, GraphQL\GraphQL::promiseToExecute, GraphQL\Executor\Executor::promiseToExecute, GraphQL\Executor\ReferenceExecutor->doExecute, GraphQL\Executor\ReferenceExecutor->executeOperation, GraphQL\Executor\ReferenceExecutor->executeFields, GraphQL\Executor\ReferenceExecutor->resolveField, GraphQL\Executor\ReferenceExecutor->resolveFieldValueOrError, WPGraphQL\Utils\InstrumentSchema::WPGraphQL\Utils\{closure}, WPGraphQL\Type\WPConnectionType->WPGraphQL\Type\{closure}, WPGraphQL\Type\Connection\PostObjects::WPGraphQL\Type\Connection\{closure}, WPGraphQL\Data\DataSource::resolve_post_objects_connection, WPGraphQL\Data\Connection\AbstractConnectionResolver->get_connection, WPGraphQL\Data\Connection\AbstractConnectionResolver->execute_and_get_ids, WPGraphQL\Data\Connection\PostObjectConnectionResolver->get_query, WP_Query->__construct, WP_Query->query, WP_Query->get_posts, apply_filters_ref_array('posts_pre_query'), WP_Hook->apply_filters, TEC\Events\Custom_Tables\V1\WP_Query\Modifiers\Events_Only_Modifier->filter_posts_pre_query, TEC\Events\Custom_Tables\V1\WP_Query\Custom_Tables_Query->get_posts, WP_Query->get_posts
In the Graphql IDE, I get this message:
{
"errors": {
"message": "Unexpected token '<', \"<div id=\"e\"... is not valid JSON",
"stack": "SyntaxError: Unexpected token '<', \"<div id=\"e\"... is not valid JSON"
}
}
To add to this: This issue starts occurring on TEC version 6.0.4. Previous versions return results on the events
query as expected.
This is dovetailing into an issue with routing to tribe-events_single pages as well. Event posts would return a 404, with the same SQL error that @brittonwalker pointed out in the debug.log
After some digging, this line is the culprit:
ORDER BY wp_posts.post_date DESC, wp_posts.ID DESC DESC
If there are recurring event occurrences being queried, trying to order by the wp_posts table breaks the page from loading. This ORDER BY
line is set in WPGraphQL posts_orderby
hook with a priority set at 10. (wp-graphql/src/Data/Config.php
line 178) We tested increasing the priorities on redirect_posts_orderby
function hooks in the-events-calendar/src/Events/Custom_Tables/V1/WP_Query/Custom_Tables_Query.php
from 200 to 5. That fixed the single event posts, but would cause the Events Calendar API to not get events posts as expected.
I noticed in the PR #58 that you remove the redirect_posts_orderby
filter function, but after pulling down and testing the PR work so far, this still doesn't resolve the SQL error on single event posts.
My suggestion is one of the following, but would need testing:
-Accommodate WPGraphQL and add a graphql_cursor_compare
query argument in the TEC occurrence queries to prevent WPGraphQL from adding the wp_posts table ordering. This may cause issues if the orderby
argument in a custom event query isn't aligned with the graphql_cursor_compare
argument.
-Overriding GraphQL's hook to not run that ORDER BY
statement in wp_post table if a query is running in the wp_tec_occurrences
table. Not ideal as this could potentially cascade into other queries and hooks.
EDIT: Completely scratch that. I took another look. redirect_posts_orderby
is adding an additional 'DESC' to the ORDER BY statement, breaking the query. Removing $order from line 719 in the-events-calendar/src/Events/Custom_Tables/V1/WP_Query/Custom_Tables_Query.php
fixes the single event post issue and the Events Calendar REST API retrieves events as expected. Basically, that function needs to accommodate that GraphQL has already has set 'DESC' in the order by statement.
@kidunot89 do you have any thoughts on what we can do to work around this? As it is, we can't use ql-events without forking the events calendar plugin since the single event routes are broken too now.
@kidunot89 any updates? This breaks both the queries and single event pages, even with ql-events 0.3.1. If we can't get this to work in GraphQL, we're going to have to figure out an alternative to TEC Pro for event management
@hcavanaugh You have to be on at least WPGraphQL v1.16.0 or higher for the QL Events v0.3.1 to work as expected. Can you confirm your on WPGraphQL v1.16.0 or higher?
@kidunot89 I still had to make the modification @hcavanaugh mentioned above to get it to work with WPGraphQL 1.16 last I tried.
@jmotes @kidunot89 I was able to get event queries and event single pages working after updating to wpgraphql 1.16, and updating TEC to 6.2.2.1
@hcavanaugh Nice! TEC v6.2.1 was what I tested against last month. I just updated to today's release (v6.2.3) and it's working great for me as well.
Good to see this is working with v0.3.1