Conversation
| } | ||
|
|
||
| if ( $wp_current_db_version < 51769 ) { | ||
| upgrade_570(); |
There was a problem hiding this comment.
In this form, it's a one-time only upgrade. Should we make it possible to retry at a later time (e.g. after migrating the site to more recent MySQL version)? If yes, what would be the best approach to do that?
| if ( wp_fulltext_search_enabled() ) { | ||
| $search_orderby .= $wpdb->prepare( "WHEN MATCH({$wpdb->posts}.post_title) AGAINST (%s IN BOOLEAN MODE) THEN 1 ", $q['s'] ); | ||
| } else { | ||
| $search_orderby .= $wpdb->prepare( "WHEN {$wpdb->posts}.post_title LIKE %s THEN 1 ", $like ); |
There was a problem hiding this comment.
This mimics LIKE behavior 1:1 for now. I believe MATCH() relevancy score would be a good fit here, maybe it could even replace WHEN/THEN entirely.
| upgrade_560(); | ||
| } | ||
|
|
||
| if ( $wp_current_db_version < 51769 ) { |
There was a problem hiding this comment.
I chose this number arbitrarily (fulltext ticket id). We should discuss it more before merging.
There was a problem hiding this comment.
It's usually the SVN commit ID but your meaning is clear :) at time of writing it is 49632.
peterwilsoncc
left a comment
peterwilsoncc
left a comment
There was a problem hiding this comment.
I've added a couple of notes to the PR and will catch up on the discussion on the ticket.
| upgrade_560(); | ||
| } | ||
|
|
||
| if ( $wp_current_db_version < 51769 ) { |
There was a problem hiding this comment.
It's usually the SVN commit ID but your meaning is clear :) at time of writing it is 49632.
| * @ignore | ||
| * @since 5.7.0 | ||
| */ | ||
| function upgrade_570() { |
There was a problem hiding this comment.
Excluding the option I think the rest can be done by updating schema.php
| <?php if ( wp_fulltext_search_available() ) : ?> | ||
| <tr class="option-site-visibility"> | ||
| <th scope="row"><?php _e( 'Full-text search' ); ?> </th> | ||
| <td><fieldset><legend class="screen-reader-text"><span><?php _e( 'Full-text search' ); ?> </span></legend> | ||
| <label for="fulltext_search_enabled"><input name="fulltext_search_enabled" type="checkbox" id="fulltext_search_enabled" value="1" <?php echo checked( '1', get_option( 'fulltext_search_enabled' ) ); ?> /> | ||
| <?php _e( 'Use full-text search on this site' ); ?></label> | ||
| </fieldset></td> | ||
| </tr> | ||
| <?php endif ?> | ||
|
|
There was a problem hiding this comment.
My preference would be to go without an option. If the indexes are always created then I am not sure what the gain is in giving admins options they may not understand.
Is there a common reason an owner might want to turn it off if it's available on their server?
There was a problem hiding this comment.
Yeah +1 to not making this a UI option.
| */ | ||
| function wp_fulltext_search_available() { | ||
| $is_available = get_option( 'fulltext_search_available' ) === '1'; | ||
| return apply_filters( 'fulltext_search_available', $is_available ); |
There was a problem hiding this comment.
🔢 Docblock on filters (but can wait as the ticket is discussed, tbh)
| /* | ||
| * Create fulltext indexes for `wp_posts`. | ||
| */ | ||
| $result = $wpdb->query( "ALTER TABLE $wpdb->posts ADD FULLTEXT INDEX `wp_posts_fulltext` (`post_title` ASC, `post_excerpt` ASC, `post_content` ASC);" ); |
There was a problem hiding this comment.
A nicer way of detecting this that can be added to the $wpdb->has_cap() method would be dandy.
|
I'm not pursuing this work anymore so I'm closing this PR. Feel free to take over! |
3 participants
This PR proposes core support for fulltext search with fallback to
LIKEwhen fulltext search isn't available.Sites that would like to keep using
LIKEcould disable thefulltext_search_enabledoption:Trac ticket: https://core.trac.wordpress.org/ticket/51769
This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.