Integration of Search API into core

[jshreve]

The Search API plugin (​http://wordpress.org/extend/plugins/search/) should be converted to a patch for the next release. The MySQL fulltext plugin should also be included in the distro to replace the default search.

[jshreve]

Makes the neccessary changes to convert the WPSearchAPI plugin to a working part of the core

[jshreve]

SearchAPI Core file. (to be placed in wp-includes/)

[jshreve]

MySQL FullText Search Plugin (wp-plugins/). Changes to be compatible with the SearchAPI Core.

[jshreve]

The schema is included in the installer code but I'm providing it for reference

[andy]

Excellent first draft!

What happens in WP_Query::get_posts when is_search? It looks like it will waste a database query and ignore the incorrect results. There are also some problems with execution order. Populating $wp_query->posts during template_redirect will expose any number of plugins to the incorrect results from above.

I think the search query should actually happen during WP_Query::get_posts, populate the appropriate object vars, run the appropriate filters on the result set, and skip everything else in that method. If possible, run the usual filters (for caching, etc.) on the query parts and then let the query happen as usual.

I expect some search plugins will return nothing more than an array of post_id's. The posts query would then look like SELECT * FROM $wpdb->posts WHERE ID IN(78,8,26).

[hakre]

Can you compile a single patchfile so that it can be tested and reviewed better?

[hakre]

​FULLTEXT is not supported on all storage layers within MySQL, some restrictions apply additionally.

Related: #11685

[andy]

Minimalistic approach to making search pluggable.

[ryan]

(In [13037]) posts_search filter. Props skeltoac. see #10667

[andy]

Allow core classes WP_Query and WP to be replaced before instantiating.

[filosofo]

plug-objects.diff really needs its own ticket.

But while it's here, wouldn't it be better handled by a filter?

$WP_Query = apply_filters('wp_query_class', 'WP_Query');
$wp_the_query =& new $WP_Query()

That way you have a decent chance through priority of deciding among competing plugins.

And don't forget about the half-dozen or so other instantiations of WP_Query in core.

[ryan]

If the intent is to replace the class only for The Query, the filter could be called the_wp_query_class.

[filosofo]

Replying to ryan:

If the intent is to replace the class only for The Query, the filter could be called the_wp_query_class.

Or maybe pass the context as the second argument to the filter?

I don't know why you'd want to replace the class in only one place, particularly since many themes call query_posts() directly.

[andy]

I think I like it better as a filter. I wrote it that way first but I'm not sure why I didn't keep it that way.

Replying to filosofo:

I don't know why you'd want to replace the class in only one place, particularly since many themes call query_posts() directly.

For example, a search plugin could use this. That would probably only want to replace/extend the core instance and only when isset($_GETs?).

Sometimes you're going to want to ignore the core posts query results so you might as well bypass all of WP_Query::get_posts. Heck, why not just stub it out in WP::main. That's why I showed up wanting to be able to replace or extend these classes.

While I'm at it, I'm thinking of how to fix wpdb so it can be extended. HyperDB is a PITA to keep synced with wpdb. It would be better if it extended wpdb.

So this should be two new tickets then.

[andy]

Twenty Ten uses "Older posts" and "Newer posts" labels for pagination links in search.php. The labels are only appropriate for chronological lists of posts and they are not filtered. A search plugin that supplies results in non-chronological order has easy way to correct the labels.

There should be $label filters in get_(next|previous)_posts_link(). Also, "Older posts" and "Newer posts" are unfortunate pagination labels for search.php. "Next page" or, better, "Next results" makes more sense here.

The Next and Previous links should be reversed on search result pages. It's going to become more common to see search results sorted other than reverse-chronological, and to include things other than posts.

Current (okay for browsing chronological archives):

<-- Older ..... Newer -->

Better for search results in general:

<-- Previous ... Next -->

Eventually I'd like to move all pagination into an abstract and filterable template tag. For now, let's set a better example for search results and apply filters to the the labels.

Attaching a patch, search-pagination-1.diff:

• Reverses direction of search pagination links

• Changes labels of same

• Adds filters for pagination link labels

[nacin]

Related to your thoughts on abstracting that: #10219 - "Older Entries" and "Newer Entries" links are wrong when entries displayed in ascending order.

[westi]

Replying to ryan:

(In [13037]) posts_search filter. Props skeltoac. see #10667

Is this PHP4 compatible?

Should we not be passing by reference so we don't end up with a copy - is this another reason we need an apply_filters_ref_array()? = #9886

[westi]

Replying to westi:

Replying to ryan:

(In [13037]) posts_search filter. Props skeltoac. see #10667

Is this PHP4 compatible?

Should we not be passing by reference so we don't end up with a copy - is this another reason we need an apply_filters_ref_array()? = #9886

This was done when we introduced apply_filters_ref_array()

[brentes]

I've reopened this as the 'posts_search' filter is being applied on every query, rather than only those queries where a search pattern is specified.

I'm guessing that's a bug and not by design?

If it is a bug, it's easily fixed, the filter just needs to moved up one line above the curly brace. :)

[scribu]

I'm not so sure about that. A plugin could want to do some searching even when there isn't a search pattern defined.

Anyway, I don't really see the problem. Just bail if the search pattern is empty.

[brentes]

Yeah that's fair enough and as you say, it's not a problem to test within the hooked function if a search pattern is defined.

I guess the hook's documentation will just need to show it's not actually called only on searches, as the name implies, to avoid that trap for young players (like myself).

[westi]

(In [14603]) Add commentary about the posts_search filter. See #10667.

[sussane]

[spam comment removed by dd32]

[dmitrihughes]

[spam comment removed by dd32]

[sussane]

(spam removed, WP.org account banned)

[Testuser1]

Nothing.