User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 Instructions in <http://bugzilla.mozilla.org/queryhelp.cgi> are apparently for an older version of the query interface. Reproducible: Always Steps to Reproduce: 1. Enter the query page <http://bugzilla.mozilla.org/query.cgi>, perhaps via the link in the footer of any Bugzilla page 2. Near the bottom of the page, there is a "clue" link which points to <http://bugzilla.mozilla.org/queryhelp.cgi>. Click that 3. Try to follow the instructions on that page with the current query interface Actual Results: Confusion. Expected Results: Especially the sections "People Involved", "Text Search", "Inclusion/Exclusion Options", and "The Rest of the Form" seem to be in need of a rewrite. They are apparently about an older version of the query interface, which was significantly different from what's in the current version. This is a spin-off from bug 251317 -- Dave Miller tried to hijack my problem with old saved queries but I'd like to keep that case focused, and so am submitting a separate case about the outdated documentation. Sorry if this messes up your process.

you don't have the authority to set that to +. please don't. You can set it to ? if you want. (but don't, because this is a dupe - I'll mark it shortly)

*** This bug has been marked as a duplicate of 251317 ***

ARGH. Please don't. Read what it says.

Apoligies... I jumped because you set the + on the flag, and didn't realize you were the same person from the other bug. I think we have it straight now.

While you're on the case, perhaps you want to run a spelling checker on the text, too. I quickly spotted two misspelled "separate" (with the first a replaced with an e -- search for "seper") and the plural of "parenthesis" is "parentheses", not identical to the singular.

There's a bug already open on removing queryhelp.cgi entirely - bug 243549. This is good because queryhelp.cgi isn't localisable, and the content is out of date and poor. I suggest we adopt that approach (and link to the Guide instead) both for trunk and branch. Gerv

(In reply to comment #6) > I suggest we adopt that approach (and link to the Guide instead) both for trunk > and branch. The Guide isn't currently any more localizable than a hard-coded cgi script, and the user section of the Guide is not currently in a state I'd be comfortable linking to. I won't block 2.18rc3 on this because it's essentially documentation, despite being in a cgi, but this definitely needs to be fixed for the final 2.18 release.

> The Guide isn't currently any more localizable than a hard-coded cgi script, It is; for example, you could use MultiViews. And it's much easier to edit HTML/XML than text-interspersed-with-code in queryhelp.cgi. > and the user section of the Guide is not currently in a state I'd be comfortable > linking to. > > I won't block 2.18rc3 on this because it's essentially documentation, despite > being in a cgi, but this definitely needs to be fixed for the final 2.18 > release. If the fix would be to rewrite the queryhelp.cgi text to be more up to date, why don't we just throw it away, and put the effort into fixing the Guide instead? Gerv

I'm not keen on a separate CGI script just for documenting the query form, and linking to the guide initially appealed to me, but don't we want installations to be able to customize this page? After all, installations often modify the query form, subtracting fields they don't use and adding their custom fields. If they use the documentation at all it seems like they'd want it to reflect the set of fields on their installation. Can we make this a page.cgi page?

Myk: we could certainly do that. Maybe that's the best thing to do in the name of getting 2.18 out quickly. Gerv

Given that we aren't making the 2.18 train with any solution, what's the correct thing to do here? I still argue for linking to the Guide. We've now made the docs easier to rebuild, and I can't see the advantage in splitting our documentation between the current docs system and some other location like page.cgi pages. Gerv

The current queryhelp.cgi displays some live keyword, product and component information. Moving to page.cgi or a Guide link, we'd lose this -- do we want that? Personally, I wouldn't miss it much.

One of the right ways to solve this in my opinion is to have the Perl code take that information dynamically out of a .xml docs file: Tagging information with <section id="query-page-help-<name of the field>"> and have in the queryhelp.cgi some perl code that searches this tag in a specific .xml and take the information out of it would be one way of doing things.

Oh, I thought we were talking about query.cgi?help=1 Like travis said in IRC, I think queryhelp.cgi is hardly linked from somewhere these days. In that case, I support ditching it away :)

nuke it. let's work on making the inline help more complete if it's lacking.

Comment on attachment 168282 [details] [diff] [review] v1 So, can someone review this? :-)

(In reply to comment #17) > (From update of attachment 168282 [details] [diff] [review]) > So, can someone review this? :-) > Looks good to me. All queryhelp.cgi references have been catched! (r+ if I could ;) )

Comment on attachment 168282 [details] [diff] [review] v1 We'll want to provide help for the imo very much non-self-explanatory relative dates stuff soon, I think. Goodbye queryhelp.cgi, otherwise.

> We'll want to provide help for the imo very much non-self-explanatory relative > dates stuff soon, I think. That's covered in the hover text that appears on query.cgi?help=1 (not to mention documentation :) ).

Not everybody can access the hover text. And the docs do not mention it. :-/

Well since it's not in the docs, requesting docs on this bug.

Comment on attachment 168282 [details] [diff] [review] v1 r=gerv (rubberstamp :-). Gerv

Removing queryhelp.cgi; /cvsroot/mozilla/webtools/bugzilla/queryhelp.cgi,v <-- queryhelp.cgi new revision: delete; previous revision: 1.23 done Checking in template/en/default/search/boolean-charts.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/search/boolean-charts.html.tmpl,v <-- boolean-charts.html.tmpl new revision: 1.12; previous revision: 1.11 done Checking in template/en/default/search/form.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/search/form.html.tmpl,v <-- form.html.tmpl new revision: 1.27; previous revision: 1.26 done Checking in template/en/default/search/search-advanced.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/search/search-advanced.html.tmpl,v <-- search-advanced.html.tmpl new revision: 1.22; previous revision: 1.21 done Removing queryhelp.cgi; /cvsroot/mozilla/webtools/bugzilla/Attic/queryhelp.cgi,v <-- queryhelp.cgi new revision: delete; previous revision: 1.23 done Checking in template/en/default/search/boolean-charts.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/search/boolean-charts.html.tmpl,v <-- boolean-charts.html.tmpl new revision: 1.8.2.1; previous revision: 1.8 done Checking in template/en/default/search/form.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/search/form.html.tmpl,v <-- form.html.tmpl new revision: 1.24.2.1; previous revision: 1.24 done Checking in template/en/default/search/search-advanced.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/search/search-advanced.html.tmpl,v <-- search-advanced.html.tmpl new revision: 1.18.2.2; previous revision: 1.18.2.1 done

Although I requested documentation here, bug 243549 could be morphed into that.

Simply removing pages is not acceptable. 404 is the wrong error code. All links to that page will simply become dead ends. For removing pages there are appropriate error codes to be generated: 410: The page is removed without any other page taking over its function 301: The page is replaced by another page. Here we clearly need the second with an appropriate redirection address. pi

3.1415926..., this patch has already been checked-in, so this bug should remain close. Please open a new bug about your request and mark it as blocking2.18? if you think we should have it before we release.

Bug 275579 is about the wrong status code sent by the web server. pi

This also caused bug 340154 .

I don't think this needs to be documented. Docs do not mention queryhelp.cgi at all. No need to mention something which disappeared.