Add get_search_link()

[sirzooro]

WP_Rewrite class provides get_search_permastruct() method, but it is not used. It will be good to add get_search_link() function for completness. I am not sure where it should go (which file), so I post it here:

function get_search_link( $query = null ) {
	global $wp_rewrite;
	$searchlink = $wp_rewrite->get_search_permastruct();

	if ( is_null( $query ) )
		$query = get_search_query();

	$query = rawurlencode( $query );

	if ( empty( $searchlink ) ) {
		$file = trailingslashit( get_option( 'home' ) );
		$searchlink = $file . '?s=' . $query;
	} else {
		$searchlink = str_replace( '%search%', $query, $searchlink );
		$searchlink = trailingslashit( get_option( 'home' ) ) . user_trailingslashit( $searchlink, 'category' );
	}
	return apply_filters( 'search_link', $searchlink, $query );
}

[sirzooro]

Could you reconsider adding this function in 2.9? I had to add the same code to two of my plugins (Meta SEO Pack and Recent Searches Widget), and would like to use built-in function if possible.

[westi]

Replying to sirzooro:

Could you reconsider adding this function in 2.9? I had to add the same code to two of my plugins (Meta SEO Pack and Recent Searches Widget), and would like to use built-in function if possible.

Now that 2.9 has gone to beta we are in feature freeze and want to concentrate on bugs in the new features and regressions against 2.8.6

Unfortunately that means this will have to wait until 3.0

[sirzooro]

OK, I will wait 3.0.

BTW, I think it will be good to perform review of all enhancements before entering feature freeze - as I checked, at this moment 77 enhancements are milestoned for 3.0, and 48 of them has patches.

[jshreve]

I don't want this patch to be forgotten about. It fits in with some of the other search functionality being worked on (#10667) and would be an important addition in my opinion.

I rewrote this a bit to use some of the new 3.0 functions (home_url mainly) and to use get_search_query. I also put it in patch form (instead of a pasted function like above) so it can be tested some more.

[dd32]

needs-patch: $permalink = home_url("?page_id=$search"); I somewhat dont think you meant page_id :)

Seems like its a useful addition to me other than that.

[jshreve]

@dd32 thanks - was testing it with permalinks ON and missed that. updated & everything else should be ok

[dd32]

I'm also not sure if esc_attr() is the right escaping function to use here, If indeed it should be escaped at all. urlencodes are required, but the calling function should escape the link appropriately.

[jshreve]

I based it off of how get_search_feed_link & get_search_comments_feed_link were working. (I assuming there was a reason for doing this). They should already be clean but it looks like it's being used in a few places so if it's ok then those functions could be changed too.

[sirzooro]

There is a problem when someone will include slash in search - you will get url like site.com/search/foo%2Fbar/ . But when you will try to open it in browser, you will get 404. And there is an interesting part - for some reason this url is not handled by WP, but error is returned by Apache itself (at least on my dev machine with Windows).

When you do not encode slahses (url like site.com/search/foo/bar/), you will get 404 served by WP.

[jshreve]

sirzooro: I meant te esc attrs that some of the other functions have.

[dd32]

When you do not encode slahses (url like site.com/search/foo/bar/), you will get 404 served by WP.

This is due to Apache discarding the invalid URL.

/search/test%2Fpost/ is NOT a valid url, however ?s=test%2Fpost IS a valid url. %2F may appear in a URL query string, but not its path.

Valid URL's would be in the form of:

http://localhost/wordpress-commit/search/test/post/
OR
http://localhost/wordpress-commit/search/test%25Fpost/

The problem with the 2nd one however, Is that WordPress doesnt double-urldecode the link.

It seems Apache has a 'AllowEncodedSlashes' option, which transforms %2F to / before its run by the plugins.

one way around this is:

function get_search_link( $query = '' ) {
	global $wp_rewrite;

	if ( empty($query) )
		$search = get_search_query();
	else
		$search = stripslashes($query);

	$permalink = $wp_rewrite->get_search_permastruct();

	if ( empty( $permalink ) ) {
		$permalink = home_url('?s=' . urlencode($search) );
	} else {
		$search = urlencode($search);
		$search = str_replace('%2F', '/', $search); // %2F(/) is not valid within a URL, Pre-encode it so its double-encoded.
		$permalink = str_replace( '%search%', $search, $permalink );
		$permalink = home_url( user_trailingslashit( $permalink, 'search' ) );
	}

	return apply_filters( 'search_link', $permalink, $search );
}

[jshreve]

line-template.2.diff is your above changes.

Tested against r13402. Works like it should.

@dd32: Do you know if there a reason we aren't use the permastructure for the search feeds and search comment feeds? I'll probably write up a small patch to attach here to stay consistent.

[dd32]

: Do you know if there a reason we aren't use the permastructure for the search feeds and search comment feeds?

Honestly, No.
Part of the reason could be that JavaScript is required on the client side to generate that type of URL.

But aside from that, Most people know of the ?s= style for searches...

[dd32]

(In [13483]) Add get_search_link() with Permastruct (/search/) support. Props jshreve. Update get_search_link(), get_search_feed_link() & get_search_comments_feed_link() to use it, as well as supporting Permastructs for those feeds. Fixes #10552