Pretty permalink on search

[markjaquith]

Ryan:

In trunk, with cruft free links, I get stuff like this:

http://foo.blog/page/3/?s=test

That's not right. Maybe we should revert back to pre [5454] to fix the trunk problems.

[5454] was the commit for #3930

If at all possible, I'd like to work with the new code.

[MtDewVirus]

Tested with 7236.

Whenever performing searches, the search results do have URLs in the form of /?s=test.

[DD32]

What would be a suggested fix for this ticket? /search/search-term/page/2 ? /?s=search-term&paged=2 ?

[Denis-de-Bernardy]

+1 for this: /?s=search-term&paged=2

[hakre]

/search/search-term/page/2 with a configureable option in backend for wording of "search" would be pretty nice to fillup serps.

anyway isn't this pretty uninteresting anyway as long as it doesn't lead to a 404?

[janeforshort]

No patch, punting.

[wonderboymusic]

Is this still relevant?

[SergeyBiryukov]

Paged search links still look as described: http://trunk.wordpress/page/2/?s=test.

Before [5454], they used to be http://trunk.wordpress/?s=test&paged=2.

[wonderboymusic]

Makes search links with pretty permalinks on used paged in the query string

[wonderboymusic]

Refreshed patch against trunk - this ticket is like 19,000 tickets old, but the patch works

[wonderboymusic]

#21748 was marked as a duplicate.

[faishal]

New patch

[MikeHansenMe]

Both 4463.diff and 4463_1.diff apply and work as intended. In 4463_1.diff there is a couple addition lines for is_single ! is_home and ! is_front_page. I am not sure if that is necessary as 4463.diff seems to work without it.

[nacin]

Longstanding bug.

[wonderboymusic]

these are all marked 3.7-early

[Mte90]

Just adding a more context focused title to avoid reading all the history in this 16 years ticket.

I don't know if it is something that we want, I mean now it is a standard that on wordpress the only parameter not pretty is s for the search.

The topic was opened because at the time there were some changes on adding as pretty the paged value.

As today, all the search engine doesn't have pretty permalinks for the search string value like Google.

[oglekler]

@joostdevalk can you please give your opinion on this matter. Thank you 🙏

[joostdevalk]

I'd actually prefer us to rip out the clean version of search permalinks from all WordPress sites. Basically get rid of /search/ altogether and redirect all /search/ to ?s= queries.

For search, using a parameterized URL has remained the most common pattern across all big CMSes and big websites. It makes tracking a lot easier, and not having both clean and non-clean modes actually improves cache hit rates and decreases spam attack vectors.

Paginated search URLs should then always use a second parameter, so, back to https://example.com/?s=test&paged=2 or similar.

[jonoaldersonwp]

+1. Using pretty permalinks for search causes all sorts of SEO & performance headaches. Would love to remove this.

[markjaquith]

In the sixteen years since I opened this ticket, my mind has changed. The web has spoken, and searches use query strings. The reason is rather obvious: it’s the only non-JS way to submit a typed search from a form.

I like @joostdevalk’s suggestion.

[oglekler]

@SergeyBiryukov can we plan this for 6.5?

Trac ticket: https://core.trac.wordpress.org/ticket/4463

This PR does the following:

• Removes pretty permalinks for search results
• Redirects old permalinks to the new ones (using ?s=query)

[rajinsharwar]

The patch looks good and seems to resolve the said problem. I believe we will need a Dev Note for this change.

[joostdevalk]

I'm happy to write the dev note.

[jorbin]

Thanks for volunteering Joost!

I really like the direction this is going, but the unit tests seem to be taking a step backwards in the current patch. I noted this on the PR, but it would be good to get those back up to shape or improved before this lands.

[jorbin]

Wanted to note that we are 12 days from beta 1 so if this is going to make it into 6.5, the updates to the unit tests need to be completed.

I've been trying to fix an issue in this PR for days. Unfortunately, so far I have not been able to, so I pushed some additional PHPUnit tests in this one to make the issue more evident.
The problem is that for some reason, if in my browser I go to /search/hello/page/2, it _should_ redirect to /?s=hello&paged=2. Instead, it goes to /page/2/?s=hello. 🤔

@SergeyBiryukov since we worked on this PR together when it first started, do you perhaps have any insights as to what may be happening here?

[audrasjb]

No change since 4 months, let's move this one to 6.7.
Feel free to move it back to 6.6 if there an updated patch is available.

[desrosj]

Looks like @peterwilsoncc weighed in on the attached pull request a few weeks ago. @aristath are you interested and able to take a look at the feedback and bring the branch up to date with trunk?

[chaion07]

Thanks @markjaquith for reporting this. We have reviewed this Ticket during a recent bug-scrub session. Based on the feedback received we are making the following changes:

1. Updating the milestone to Future Release
2. @aristath needs to address review feedback per last comment

Thanks.

Props to @mukesh27

Cheers!