Clean URLs test needs warning of misleading bug

Additional points:

a) During the testing process I had switched off JavaScript. But I've got it back on now and I can confirm that going to the page via the overlay also produces the false negative.

b) With or without JavaScript turned on, once the clean address has been visited & the checkbox has come up, it persists till the end of the session even if the box is not ticked. (i.e. Drupal continues to "know" that Clean URLs work.) Logging out & in again with Clean URLs off reverts to no box. (consistent with session variable storing the result, which I gather from the other issue threads is what happens.)

c) While Clean URLs are set on (box ticked), behaviour is as intended - even if you log out & in again, it stays with Clean URLs enabled. (which makes sense, because this would be stored in the database wouldn't it...)

I don't think this issue should be closed until something's been added to the page on Clean URLs at http://drupal.org/getting-started/clean-urls. That other issue/thread about the user experience could run for months yet, and IMO this is more urgent than that.

At the moment, the only way people are likely to get any warning that the test may have lied to them is if they read down the first 50+ comments appended to the Clean URLs page. The way that page is written, I suspect most people will try the possible fixes on the page before they read through all those detailed comments, which if your env. is already OK, is a completely unnecessary waste of time. That's a pretty shoddy way to treat the people affected by the bug. So IMO this is important enough to deserve a place in the documentation page itself, until the test works reliably.

Hence changing component to "documentation" and reopening on that basis.

I think there should be a new paragraph in the "Drupal 7.x" and "Drupal 6.x" sections on that page, and it would say something like:
"Occasionally the test gives a false negative result. To double check, navigate to http://www.example.co.uk/admin/settings/clean-urls (note clean URL)."

Or, slightly more informative but also slightly longer:
"Occasionally the test gives a false negative result. See #1178850 [or #881376]. To double check, navigate to http://www.example.co.uk/admin/settings/clean-urls (note clean URL)."

(Actually, if that page is getting an edit anyway, it wouldn't be a bad idea to add a clarification addressing the "page comes back unchanged with re-check button, what does it mean??" confusion from #881376. Happy to work with someone on improving that documentation.)

==

Once there's some such warning, on that page where people are likely to see it fairly early on in their trouble-shooting, then I don't mind the bugfix itself being treated as a duplicate.

I mean, I think there is a valid argument the other way, in that, to quote myself at http://drupal.org/node/881376#comment-4558386, this thread is primarily about the user experience of a "no" test result, not really related to whether the test is accurate. The title of that issue is currently "Run the clean URL test" UX is broken - note "UX broken", not "test broken".

But it's true that there are other people in that UX thread who have had other weird results with the test itself. So maybe that thread should be renamed instead, to explicitly include all misleading test results.

Either way, though, it's not me that's gonna be fixing the test, because I don't have the knowledge to do so. So if the people who are going to fix it want to treat this as a duplicate (documentation aside), then fine by me :-)

==

While I'm here, a bit more on my hosting environment...

Here are two articles about addon domains.
http://support.hostgator.com/articles/cpanel/please-read-before-creating...
http://www.visn.co.uk/cpanel-docs/addon-domains.html

Here is the advertising for the hosting I'm on.
http://www.compila.com/web-hosting/linux-web-site-hosting/commerce-websi...

That's pretty much the limits of my own knowledge, but if someone wants to ask me other questions specific to my hosting, I could put in a support request to Compila to get the answers.

Oh thanks for that, and sorry to have left it in the wrong place - I'd somehow missed that Documentation had a separate queue.

Changing title again, to be slightly more informative.

I'm deferring to your wider-perspective view on priority, although I remain very uneasy with the present situation. Hope something can be done soon to flag this up for people confused by it.

Yes please! I don't think I've got the necessary editing privileges at present (unless there's a link somewhere that I'm not noticing), but happy to use them if granted.

(sorry for delay in replying - hadn't been back on d.o till now.)

a) OK so I did ask on the other thread whether that patch was designed to fix the "false negative" issue I encountered, and it is not; if it gets fixed along the way it'll be by chance. See http://drupal.org/node/881376#comment-4625318 (me asking) and http://drupal.org/node/881376#comment-4664548 (markvangend answering).

b) There already are comments attached to the relevant documentation page. As I've already said, however, it's possible to waste a lot of time before finding those.

I don't think the default policy on bug documentation ought necessarily to be applicable here; most bugs consist of something obviously failing to work, which is a clue to people to look in the issue queue, whereas this one is a lie by the software and therefore more misleading than usual.

Obviously I'm not going to be fooled by this one again! Just thinking of the people about to fall into the same pitfall as I fell into, and of Drupal's reputation.

Therefore I personally still think there ought to be a warning in the text of that page. But I recognise that it's not up to me.