this is breaking a lot of tests, so I converted to a draft. It fixes the problem at hand from what I can tell, but clearly not the "right" solution overall yet.

Code Climate has analyzed commit 5dd69d2 and detected 0 issues on this pull request.

View more on Code Climate.

this is breaking a lot of tests, so I converted to a draft. It fixes the problem at hand from what I can tell, but clearly not the "right" solution overall yet.

I'm not by my desk, but iirc this was part of the impetus for #2749 and might even be working there already. If so we can isolate and cherrypick in a way that isn't b/c.

closing this as I believe there's a way to resolve this without making changes to core WPGraphQL (at least not immediately).

Instead of:

$resolver = new \WPGraphQL\Data\Connection\PostObjectConnectionResolver( $root, $args, $context, $info, 'any' );

			// REPLACE WITH A LIST OF VALID POST IDS.
			// ENOUGH TO PAGINATE AGAINST. IF NONE EXIST, GENERATE SOME.
			// ALSO MAKE SURE THEY ARE NOT STRICTLY ORDERED NUMERICALLY FOR SANITY CHECKING (i.e. 1, 5, 3, 2 instead of 1,2,3,4,5)
			$ids = [17, 105, 106, 15, 16, 18, 19, 30, 20, 21, 22, 23, 24, 7, 25, 26, 27, 28, 29, 31];
			return $resolver
				->set_query_arg( 'post_status', 'any' )
				->set_query_arg( 'post__in', $ids )
				->set_query_arg( 'orderby', 'post__in' )
				->get_connection();

We can do the following:

// override the args that are passed in, as if a user passed them in.
$args['where']['in']  = [17, 105, 106, 15, 16, 18, 19, 30, 20, 21, 22, 23, 24, 7, 25, 26, 27, 28, 29, 31];
$resolver = new \WPGraphQL\Data\Connection\PostObjectConnectionResolver( $root, $args, $context, $info, 'page' );

This will let the internals of the Connection Resolvers do things as if a user were passing in the args.

closing this as I was able to accomplish what was needed by adjusting the $args sent to the PostObjectConnectionResolver as outlined above.

Basically, for better or worse, the *ConnectionResolver classes use the $args passed in as the initial args that are used in mapping input args to query_args.

Then set_query_arg() is used to override any query_args already set.

For arguments like include or in, passing them via set_query_arg is too late for them to be used in mapping for things like pagination. But passing them in as "where" args to the connection resolver maps them as expected.

see: https://github.com/wp-graphql/wpgraphql-acf/pull/167/files