the-events-calendar / ql-events

The Events Calendar binding to WPGraphQL
15 stars 7 forks source link

Problem with Gatsby 5.3.3 and WP-GraphQL 1.13.7 #49

Open therealgilles opened 1 year ago

therealgilles commented 1 year ago

I've upgraded to Gatsby 5 and I'm now getting this WP database error (below) with QL-Events. As you can see, there is a duplicate 'DESC' in the 'ORDER BY' statement. I've tried the QL-Events 0.1.0 version but it breaks the GraphiQL IDE (quickly mentioning that the plugin version number is still at 0.0.1 in ql-events.php). I'm wondering if there is a known fix for this issue. I know TEC v6 has been full of bugs so that could ne another TEC bug. Any insight or help would be appreciated.

WordPress database error You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'DESC
            LIMIT 0, 101' 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_author IN (210)  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, 101
made by 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\Executor\Promise\Adapter\SyncPromiseAdapter->wait, GraphQL\Executor\Promise\Adapter\SyncPromise::runQueue, GraphQL\Executor\Promise\Adapter\SyncPromise->GraphQL\Executor\Promise\Adapter\{closure}, GraphQL\Executor\ReferenceExecutor->GraphQL\Executor\{closure}, GraphQL\Executor\ReferenceExecutor->completeValue, GraphQL\Executor\ReferenceExecutor->completeObjectValue, GraphQL\Executor\ReferenceExecutor->collectAndExecuteSubfields, 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\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
therealgilles commented 1 year ago

I tracked the bug down to this faulty regexp in redirect_posts_orderby, which does not consider there could be blank spaces after ASC/DESC:

// wp-content/plugins/the-events-calendar/src/Events/Custom_Tables/V1/WP_Query/Custom_Tables_Query.php
      // Each `ORDER BY` entry could specify an order (DESC|ASC) or not.
      // if ( preg_match( '~(?<orderby>.*?)\s?(?<order>ASC|DESC)$~i', $orderby_frag, $m ) ) {
      if ( preg_match( '~(?<orderby>.*?)\s?(?<order>ASC|DESC)\s*$~i', $orderby_frag, $m ) ) {
        $orderby = trim( $m['orderby'] );
        $order = trim( $m['order'] );
      } else {
        // Follow the WordPress default and use DESC if no order is specified.
        $orderby = $orderby_frag;
        $order = 'DESC';
      }

so it appears it's another TEC bug.