532216 - Distinguish between searches from the text box and via clicks with a URL parameter

Status: VERIFIED FIXED

(support.mozilla.org :: Knowledge Base Software, task, P2)

Description

[[:Cww]]

Now that we have the new start page, the clickable searches dominate searches.  We should distinguish what people search for (typing) vs what they click on by adding a URL parameter so we can track on omniture.

Comment 1

[Paul Craciunoiu [:paulc]]

What's a good target milestone for this?

Comment 2

[James Socol [:jsocol, :james]]

This is essentially the same as bug 532214, and they're both trivial to implement. Adding to 1.5.1 for now.

Comment 3

[James Socol [:jsocol, :james]]

I tried to fix bug 532214 and accidentally started patching this, so -> me. Sorry to step on your toes, Paul.

Comment 4

[James Socol [:jsocol, :james]]

Attachment: extra parameter on searchs

This adds a "qs" parameter, roughly for "query source" that's either 's' for 'search' or 'h' for 'home'. It doesn't add the parameter to the sidebar, but that's easy.

Comment 5

[Paul Craciunoiu [:paulc]]

Comment on attachment 417505 [details] [diff] [review]
extra parameter on searchs

WFM.

Comment 6

[James Socol [:jsocol, :james]]

r57834.

Comment 7

[Stephen Donner [:stephend] Not actively reading bugmail]

Looks good on https://support-stage.mozilla.org/en-US/kb/:

<a class="small" href='/search.php?q=clear+cache&amp;where=all&amp;locale=en&amp;qs=h'>clear cache</a>,

Should I wait for the sidebar to get the parameter added?

Comment 8

[James Socol [:jsocol, :james]]

Changed in the sidebar.

Comment 9

[Stephen Donner [:stephend] Not actively reading bugmail]

If I search from http://support-stage.mozilla.org/en-US/kb/Ask+a+question, I get URLs like:

http://support-stage.mozilla.org/search.php?q=red+panda&locale=en-US&where=all -- no qs=s there.

Comment 10

[Paul Craciunoiu [:paulc]]

I think it's cache, try logging in.

Comment 11

[Paul Craciunoiu [:paulc]]

Attachment: fix for mozgn2

This makes mozgn2 use the sidebar module. Before reviewing, remember assign the sidebar search module to theme=mozgn2.css

Comment 12

[James Socol [:jsocol, :james]]

Comment on attachment 417559 [details] [diff] [review]
fix for mozgn2

This is a big change and rather outside the scope of this bug. Fixing mozcommon/searchbar.tpl is the correct solution here.

Comment 13

[James Socol [:jsocol, :james]]

Attachment: mozcommon/searchbar.tpl patch

Adding the qs=s parameter to the form in mozcommon/searchbar.tpl, which is should take care of this most places.

Comment 14

[Paul Craciunoiu [:paulc]]

Comment on attachment 417808 [details] [diff] [review]
mozcommon/searchbar.tpl patch

Still, we should try and use either the DB or the template to avoid situations like this in the future. What do you think we should do?

Comment 15

[James Socol [:jsocol, :james]]

r57918

(In reply to comment #14)
> Still, we should try and use either the DB or the template to avoid situations
> like this in the future. What do you think we should do?

I disagree. I don't think moving a large, common section of the template into the database is a reasonable solution here.

Comment 16

[Paul Craciunoiu [:paulc]]

What I'm saying is that we currently have the sidebar in the template in some cases and not in others. We should make it consistent, whether it is in the DB or in the template.

Comment 17

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED on http://support-stage.mozilla.org/en-US/kb/Ask+a+question; now results in URLs like http://support-stage.mozilla.org/search.php?where=all&locale=en-US&qs=s&q=firefox+crashes&sa=.

(Tested from the sidebar on that results page, too.)

Comment 18

[James Socol [:jsocol, :james]]

Reopening to commit to branches/1.5.1_temp. Will re-resolve after patches are committed.

Comment 19

[James Socol [:jsocol, :james]]

On branch, r62428

Comment 20

[Vishal Kamdar [:vish_moz]]

Verified, FIXED.