-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix non-post indexing #112
Conversation
@pschoffer Do you have any testing steps for reproducing? |
@rebeccahum I added some to the description. Thanks for the prompt. In general, whenever you try to index any non-post in bulk (default) fashion it does not work. That brings me to the idea that using But hopefully we can get this out today. |
*/ | ||
$objects = $wpdb->get_results( $wpdb->prepare( "SELECT SQL_CALC_FOUND_ROWS ID FROM {$wpdb->users} %s LIMIT %d, %d", $orderby, (int) $args['offset'], (int) $args['number'] ) ); | ||
// @codingStandardsIgnoreStart |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could use input on this one. But with the sanitize_order_by above I think this is safe.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems pretty strict on what is allowed. The only alternative would be to provide an allowlist of valid $args['orderby']
columns and ensure it's one of them - but I don't feel like that is necessary here as it's no a top-level user API really.
Can we drop the changes in |
Co-authored-by: Caleb Burks <caleb.burks@automattic.com>
*/ | ||
$objects = $wpdb->get_results( $wpdb->prepare( "SELECT SQL_CALC_FOUND_ROWS ID FROM {$wpdb->users} %s LIMIT %d, %d", $orderby, (int) $args['offset'], (int) $args['number'] ) ); | ||
// @codingStandardsIgnoreStart |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems pretty strict on what is allowed. The only alternative would be to provide an allowlist of valid $args['orderby']
columns and ensure it's one of them - but I don't feel like that is necessary here as it's no a top-level user API really.
Description of the Change
When testing #111 I found that the offset problem is more widespread. This fixes the infinite loop for other indexable.
Introduced in #106
Also, the current version of the users query that was recently changed is not supported with mariadb
mariadb:10.3.27-debian-10-r84
image we use in local dev-env.cc @brettshumaker
Test steps
vip dev-env exec -- wp elasticpress activate-feature users
vip dev-env exec -- wp vip-search index --indexables=user
succeeds