I performed a fresh installation of D7 from today's CVS snapshot tarball. After the base configuration I went to "Home » Dashboard » Configuration » Search and metadata » Clean URLs" and pressed the "Run the clean URL test" button. The page is being reloaded, but nothing else changes, I still only see the test button. I would have expected either an error message if clean URLs can't be enabled, or additional configuration options in case the test succeeds.

Files: 
CommentFileSizeAuthor
#161 881376-161-clean_urls_ux.patch4.64 KBmarcvangend
PASSED: [[SimpleTest]]: [MySQL] 35,991 pass(es).
[ View ]
#149 881376-149-clean_urls_ux.patch4.65 KBmarcvangend
PASSED: [[SimpleTest]]: [MySQL] 32,932 pass(es).
[ View ]
#134 881376-134-clean_urls_ux.patch4.65 KBmarcvangend
PASSED: [[SimpleTest]]: [MySQL] 32,857 pass(es).
[ View ]
#130 881376-130-clean_urls_ux.patch4.93 KBmarcvangend
PASSED: [[SimpleTest]]: [MySQL] 33,233 pass(es).
[ View ]
#91 clean-urls-flow.png83.58 KBmarcvangend
#87 881376-87-clean_urls_ux.patch4.53 KBmarcvangend
PASSED: [[SimpleTest]]: [MySQL] 31,498 pass(es).
[ View ]
#78 CleanURLsEnabledButTestFailed.png53.83 KBTor Arne Thune
#78 CleanURLsCannotBeEnabled.png55.02 KBTor Arne Thune
#78 CleanURLsTestFailed.png57.19 KBTor Arne Thune
#78 CleanURLsTestPassed.png54.65 KBTor Arne Thune
#78 CleanURLsEnabled.png52.67 KBTor Arne Thune
#78 CleanURLsDisabled.png52.75 KBTor Arne Thune
#74 system_clean_url_settings.txt2.95 KBmarcvangend
#67 881376-67-clean_urls_ux.patch4.03 KBmarcvangend
PASSED: [[SimpleTest]]: [MySQL] 30,449 pass(es).
[ View ]
#62 881376-62-clean_urls_ux.patch3.92 KBmarcvangend
PASSED: [[SimpleTest]]: [MySQL] 30,402 pass(es).
[ View ]
#18 clean-urls-page.png20.94 KBmarcvangend

Comments

Update: It turned out that I still had an "AllowOverride None" in my Apache configuration file that prohibited the usage of the rewriting rules in .htaccess. Setting it to "All" enabled a checkbox that allowed me to activate Clean URLs. However, the test for clean URLs should have failed in the case above instead of just reloading the same page without any further information.

From what I can see if you get the test button it means you failed. I think perhaps that page should be written with some more information so the user understands that it is failing though. Perhaps change

"Use URLs like example.com/user instead of example.com/?q=user. If you are directed to a Page not found (404) error after testing for clean URLs, see the online handbook."

to

"Currently your system does not support clean URLs. You can use the button below to reload this page and test your system again.

Clean URLs allows you to use URLs like example.com/user instead of example.com/?q=user. If you are directed to a Page not found (404) error after testing for clean URLs, see the online handbook."

I'd be happy to put it into a patch if this will solve the issue?

Not sure if changing the error message helps here.

The problem is that pressing the "Run the clean URL test" does not actually redirect me to a 404 error. It simply reloads the same page and I'm back at the "Run the clean URL test" page, without providing any feedback if the test passed or failed...

That's what I'm saying. If someone could correct me if I'm wrong but when you load that page it does the test. If it passes you don't see that error message and the button. Instead you get clean url options. If you see the button then it failed the tests. Clicking the button reloads the page so it redoes the tests. That's why I'm saying I think it's more an error with the text's wording.

Even if that is correct ... if simply loading the page runs the test, then why show the button at all?

Because, and this is my assumption on the thought process behind it, the non techie person will prefer just clicking a button to rerun the test rather than hitting f5.

Title:"Run the clean URL test" does nothing"Run the clean URL test" does not work like it says it does

It is correct, loading the page does run the test, except if it has been run before during this PHP session. We should change the text so it explains what's happening. The button can remain for re-running the test, AFAIC.

Assigned:Unassigned» marcvangend

By the way, I just found a small edge-case bug.
Situation: Clean URLs are disabled, but the server is configured properly, so the checkbox is available.
Action: Disable mod_rewrite (or mis-configure the server in another way) and reload admin/config/search/clean-urls.
Result: The checkbox is still available, so Clean URLs can still be enabled while that should not be possible.
This happens because the $available variable is stored in $_SESSION and the test is not run again when the page is reloaded.

I'm working on a patch to improve the text and fix this bug.

Component:base system» user interface text
Assigned:marcvangend» Unassigned

No patch yet. Reading through #423196: Clean up clean URLs settings page (especially #33), it seems that there can be cases where indeed a 404 is returned. The same issue also shows that the bug from #9 was already known, and explains why the result of the test is stored as session variable.

Still, I'm not happy with the current confusing text and I think we should change it. Clean URLs is an important feature and configuring your server is already confusing enough for many users.

Hello. Just want to say that i am having this exact same issue.

I'm using nginx with php-fpm, and on d6 clean urls work fine.

Storing the result of the test in the session is by design, to prevent unnecessary requests to test if clean URLs work. If you want to mess with your server configuration after you've installed Drupal, then that's your problem, not Drupal's.

If you click the button and clean URLs aren't available, you should see a 404. If they *are* available, you should see the checkbox that allows you to enable clean URLs. In no case should you be redirected to exactly the same page.

But thats exactly what happened to me. A clean install, same page. I had to change it directly in the database to get it working.

I understand that this is a choice that has been made in another issue when I was not around... but personally, I don't care about unnecessary requests if they are needed to guarantee accurate results. Performance is really not important for this page because it's rarely visited.

The 404 behavior you describe is definitely broken. Steps to reproduce:
- Get a clean Drupal install with clean URLs enabled (to be sure your server supports it)
- Disable clean URLs
- Disable mod_rewrite and restart Apache (to break clean URLs)
- Go to ?q=admin/config/search/clean-urls and click the button
Result: the exact same page appears. No 404 or any other kind of feedback.

Xano, you say "If you want to mess with your server configuration after you've installed Drupal, then that's your problem, not Drupal's", but that's inconsistent. If clean URLs do not work right away, the "Run the clean URL test" button actually encourages messing with the server configuration after Drupal has been installed.

So what do we do next? If we agree that all behavior is by design, we should at least improve the messages. However, if you ask me, we should change the behavior and choose accurate test results over performance.

The 404 behaviour is actually the only way to do an accurate check. We test for clean URLs by checking if we can load a page using a clean URL. The PHP check may fail because PHP can't execute HTTP request. The JS request may fail because JS isn't executed. That leaves us with a manual solution (the button), but unfortunately there is no way to perform a request without actually redirecting the user this way, so we can't catch the 404 and show the user something different, which we can and do when the PHP or JS check is used.

This behaviour is by design and we haven't been able to do better last year. We might be able to do better now, but please realise a lot of time has gone into that issue and that everything has been thought through very thoroughly, so don't assume people messed up then.

As far as I can see the messages are no the problem. They clearly state that if the user clicks the button and he gets a 404, he should consult the handbook (because his server doesn't support clean URLs with its current configuration).

The supposed problem here is that the manual check doesn't result in a 404. Is that because the server configuration has been changed during the user's session? So:
1) We should decide if storing the test result in the session has been such a good idea. Like I said, we thought about this thoroughly last year, so please post any pros and cons you can think of, before we undo something we later realise was important.
2) You can force a recheck by using non-clean URLs. Should we add a link to do this?

The nicely thought out logic behind it is irrelevant if the user is confused. If clean urls are not working then people go to that page and click the button to test it. If all they keep getting is the same page they were on with no warnings or error messages then something has to change, particularly if we are going ahead with the "drupal for dummies" plan and turning it into joomla. This page confuses the hell out of non technical people. It had me confused for a short while myself.

We know it doesn't work as it should. Now we should find a proper solution. There's nothing wrong with the logic behind the actual checks, although the session variable might not have been such a good idea, as I mentioned in #15. There *is* a bug in how the last check works (no 404), which we should fix.

StatusFileSize
new20.94 KB

This is not about creating "drupal for dummies" or turning it into joomla. This is about making a page do what the user expects it to do. Every user deserves that, not just dummies and joomla users.

Let's first agree on what the behavior should be. I drew a quick diagram of how I thing it should work:

The most important thing is: what happens when you click the button? I think it should either return a 404 or the same page with a clear message.

Clicking the button can't directly result in the same page with a message, unless clean URLs are available. That's a technical requirement, because it checks for clean URLs by actually redirecting the user to a page that uses it.

Now I'm thinking of it... If clean URLs are disabled, we can link to any actual file on the system. So what if we redirect the user to an HTML page, that is also a URL path, but *only* if clean URLs are available?
File: /modules/system/clean-urls.php
URL path: /modules/system/clean-urls.php, but without clean URLs it's not accessible directly, but only through /?q=modules/system/clean-urls.php.
This means that if clean URLs are not available, the user would see the actual PHP page telling him "Dude, I'm sorry, but this ain't gonna work.". If clean URLs *are* available, the request will be caught by the rewrites in .htaccess and redirected to the page callback, which redirect back to /admin/config/search/clean-urls and show the configuration form.

We'd just trick the system :)

Clicking the button can't directly result in the same page with a message, unless clean URLs are available.

Why not? Currently, if I install D7 on a server with mod_rewrite disabled, I get the "Run the clean URL test" button. When I click it, I am returned to the same page. If I enable mod_rewrite and click the button again, I see the checkbox. This can only mean that the clean URL test is run and a 404 is not necessary. This being the situation, I don't see why we would not be able to display a message.

As soon as I have the time, I'll have a better look at the internals of the clean URL test, and hopefully submit a patch. If needed, I'll use Xano's idea of tricking the system.

Why not? Currently, if I install D7 on a server with mod_rewrite disabled, I get the "Run the clean URL test" button. When I click it, I am returned to the same page.

That's a bug. The page should redirect to the same page, but using the clean URL, which in browser terms actually means it's a different page. If clean URLs are disabled, you should see a 404 (because that's what happens if you go to a URL that doesn't exist), otherwise you should see the checkbox.

Is that really a bug? I think it's great that obviously we are able to run the test without showing a 404. We just need to communicate about it (and, IMO, make sure that what we communicate is always correct).

Well, yeah. The page redirects to a URL that should give a 404, because without clean URLs that page simply doesn't exist. It doesn't point to a physical file.

Isn't it possible to do an ajax call to a clean url or a file_get_contents to a specific page and see if the page is returned and contains some specific thing that we expect?

That's what we already do. Please read this issue and #423196: Clean up clean URLs settings page before saying commenting anything.

I installed the latest snapshot today(27-sep). The installation did seem to think clean URL's were possible. Clean URL's clearly worked if typed by hand (http://example.com/about-us), but they were not being generated. When I ran the clean URL checker it did not get a 404, but no checkbox appeared.

Eventually I figured out that this was because the clean URL checker page was in an overlay. The URL was ...#overlay=... . I reentered the URL manually without the overlay. I then got a successful test, checked the box, and clean URL's were both generated and usable.

I cannot now revert to the original erroneous no-checkbox-state to duplicate this problem.

I looked for but have not found other mentions of the overlay mechanism breaking the clean URL checker, so I am mentioning it here.

Aaaah. When we made this, Overlay.module didn't exist yet, so there may be conflicts with the JS clean URL check, because IIRC it uses window.location. At this time I can't think of a reason why a manual check in the overlay shouldn't work, but I haven't tested it, so I may be terribly wrong about it.

Issue tags:+overlay

hoping to catch ksenzee's attention

I ran into the same problem when I clicked the ' Run the Clean URL Test ' button - it returned neither the 404 error page or the the ' Enable URL check ' box. I disabled the overlay module , still the same. I then commented out the ' rewrite_module modules/mod_rewrite.so ' from my httpd.conf apache file , restarted the server and the URL check box has appeared and the Clean URL is working

(reply to #27) As I mentioned, I could not revert back to the no-checkbox condition in the overlay once the checkbox actually showed up on the check page. So this may need to be tested on an absolutely clean install. It was as if there was no entry in some config file or the database, and then once it showed up, it did not disappear again. Maybe a three state problem: missing, true, false. But I am just hypothesizing.

Major wtf from me - I noticed this problem on a shared host to which I had to manually upload the core files.

If you forget to upload the .htaccess file along with all the other configuration files, then the 'Enable clean URLs' checkbox will not appear on the Clean URLs configuration page. The 'Test for Clean URLs' button (whatever it says) appeared, and seemed to do something... but didn't show any results.

Once I uploaded that file, the checkbox appeared.

Marked as duplicates (issue queue cleanup):

Title:"Run the clean URL test" does not work like it says it does"Run the clean URL test" button and "Enable clean URLs" checkbox broken
Priority:Normal» Major

This is a major ux wtf, in my opinion. I'm upping the priority to major (I think it's definitely above normal, as a lot of people who forget an .htaccess file or have a slightly broken Apache installation will run into issues on this configuration page).

If you forget to upload the .htaccess file along with all the other configuration files, then the 'Enable clean URLs' checkbox will not appear on the Clean URLs configuration page. The 'Test for Clean URLs' button (whatever it says) appeared, and seemed to do something... but didn't show any results.

Very interesting. Thanks for the info. Does this happen when JavaScript is not enabled as well? (To rule out conflicts with the Overlay JS).

Title:"Run the clean URL test" button and "Enable clean URLs" checkbox broken"Run the clean URL test" UX is broken
Issue tags:+Needs usability review

Correcting the title. The "Run the clean URL test" button does work, but it doesn't provide the promised feedback (a 404) or any other kind of feedback. The "Enable clean URLs" checkbox does exactly what it should do (although, as mentioned in #9, it sometimes shows while it shouldn't). In other words: the functionality is fine, but the UX is badly broken.

Does this happen when JavaScript is not enabled as well?

Hmm... I moved the .htaccess file, and turned off JavaScript, and now the 'Enable Clean URLs' checkbox stays up no matter what, even if it's impossible to use Clean URLs. The checkbox is not even greyed out.

That's probably because you already tried and the test results are cached.

I have installed fresh drupal, but due to pecularities of my hoster was unable to upload .htaccess file and haven't noticed it; as a result, clean urls were turned off and checkbox "Enable clean URLs" wasn't showing. "Run the clean URL test" was simply reloading the page with no 404 error, which was highly frustrating.

After I've noticed that .htaccess file is missing and re-uploaded it, checkbox "Enable clean URLs" did not appear; the behavior of button "Run the clean URL test" did not change.

After I've cleared caches on "Performance" page, nothing has changed, checkbox "Enable clean URLs" did not appeared and behavior of "Run the clean URL test" remained the same.

Only after I've manually entered the address http:// xxx .com/admin/config/search/clean-urls into address bar of a browser, I was able to see the checkbox "Enable clean URLs" and turn clean URLs on.

Certainly something doesn't work as designed, in my opinion.

I fancy myself a tech-savvy person and was working with Drupal for more 2 years (as themer, mostly), and it was very frustrating 30 minutes for me. If Drupal is meant to be for non-specialists (which it should be) then at least the presentation of this part of the configuration have to be seriously changed.

Only after I've manually entered the address http:// xxx .com/admin/config/search/clean-urls into address bar of a browser, I was able to see the checkbox "Enable clean URLs" and turn clean URLs on.

... This tells me that the clean-urls admin page was probably cached locally by your browser. In FF for example you can hit ctrl+shift+r (or cmnd+shift+r on mac to do a hard refresh). If I'm correct there isn't too much we could do about that...

bleen18: if that really is a problem, we can do something about it. Drupal already contains the mechanism of adding a query string to css files to prevent browser caching. If needed, we could do the same with admin/config/search/clean-urls.

marcvangend: but in that case, Drupal knows there is a change because Drupal is responsible for creating those aggregate css/js files. In the scenario described in #37, Drupal is unaware of a change (the change being the sudden appearance of a .htaccess file) ... and since the page is locally cached (again, assuming I'm right about that) then there isnt even an opportunity for Drupal to check

If I turn off cleanURLs and disable them in apache, the admin page still shows me the checkbox, thus allowing me to kill the site...

I think part of the problem is that once $_SESSION['clean_url'] is TRUE, it can't be unset!

Re #41: see comments #9 and #10.

Thanks @dchalbert @grahor. #26 #37 I experienced exactly the same issue in D7 Beta3. Trying to enable Clean Urls simply would not happen from the Admin UI, I was simply presented with the test button repeatedly - even though the server was capable of Clean Urls. Overlays were definitely part of the problem... by entering the direct clean url to the Clean url page I was able to get a check box and enable Clean Urls. ( /admin/config/search/clean-urls ).

This would be a bad experience for anyone, new users would be very frustrated. The reality is that most users will attempt to enable clean urls through the admin interface with overlays and will experience the same difficulties as I and many others have experienced. I know a great deal of work and effort has gone into resolving these issues; but D7 is likely to go to RC1 by the end of the month (Nov 30th) and there is a serious danger that these issues could end up unresolved in the release version of D7.

In my view this is such important and widely used functionality that it simply must work correctly before release.

I'm experiencing the same issue with a new site being set up using drupal-7.0-rc1, where mod_rewrite has not yet been enabled.

All I see is the "Run the clean URL test" button, whether I'm viewing the page as an overlay or directly accessing the page. After hitting the button, I just end up back at ?q=admin/config/search/clean-urls -- hitting the test button does not send me to a 404 page. I only get to a 404 page if I manually type in a clean URL and try to access it.

I agree with above comments that the way the page currently works is confusing -- I hit the "Run the clean URL test" button repeatedly, expecting some type of message telling me the results of the test. In particular, I recall with a drupal6 installation (on a different server) being explicitly told that clean URLs could not be enabled and being given information that allowed me to quickly identify what needed to be done.

At the least, the message on the clean-urls page needs to be changed to say something like "If you do not see a checkbox on this page, then clean URLs can not be enabled on your site." Ideally, the message would instead say "The clean URL test failed because mod_rewrite is not enabled on your server." I understand the technical difficulties discussed above with generating such a message, but from the end-user perspective, that's what is most useful and it's what new users would naively expect to see after running a clean URL test.

Sidenote: mod_rewrite is not the only way clean URLs can be achieved. It is Apache-only, but IIS supports clean URLs as well.

Xano: thanks for the reminder, we tend to forget about IIS too easily.
Anyway, we've seen enough me-too's now, it's about time we get this fixed. I will try to spend some more time on this in the coming days. If anyone wants to help, let's meet in IRC.

Sidenote: mod_rewrite is not the only way clean URLs can be achieved. It is Apache-only, but IIS supports clean URLs as well.

And pretty much all webservers around.

Nginx, Lighthttpd, Cherokee and some others.

@post nr. 37

Thanks. Problem solved here.

I am having the same problem. I have a fresh installation of rc1 on a server that correctly shows clean urls on D6 sites, so I know it is nothing amiss in the server.

Just the run test button over and over.

#37, How did you get to http://xxx .com/admin/config/search/clean-urls ? That's a clean URL and gives a 404 for me.

A thought: I have installed on a subdirectory, i.e. in public_html/d7test. Then my full address of the D7 site is

xxx.com/myusername/d7test

I don't know if it would work if I pointed a TLD directly at the D7 site, but surely it should go in this situation also?

@RTH

Check the .htaccess file inside the drupal 7 rc1 directory. Does it allow clean urls, i.e. rewrite ?

#29: "I then commented out the ' rewrite_module modules/mod_rewrite.so ' from my httpd.conf apache file , restarted the server and the URL check box has appeared and the Clean URL is working"

How does disabling mod_rewrite make rewrites work? What made you think of trying that, and how can it possibly work?

@Geir19

Thanks for the suggestion. "diff" with the official rc1 download .htaccess shows no differences.

That files contains rewrite rules, but I am not a sufficient expert in apache to say whether they are correct.

RTH, this issue is not meant for support to get your clean url's working. The problem discussed here is not that clean url's don't work in a certain situation. This issue is about providing proper feedback after clicking the test button. Please read http://drupal.org/getting-started/clean-urls if you need help enabling clean url's on your machine.

#53, I am well aware of that. That is precisely what I am discussing. But I was asked a question (Does the .htaccess file have the rewrite rules) and so I answered it.

I made a clean installation of D7 rc1 on a machine that correctly does clean URLs under D6, and it doesn't work. That indicates a bug above and beyond the user interface issue, not that "I need help" getting clean URLs to work. The entire point is that the advice in the page you helpfully point me to doesn't work, period.

I have tried to assist by contributing the information that the workaround others have succeeded with doesn't work for me, and I have contributed (I hope useful) fact that my installation is in a subdirectory of the main site, just in case that is relevant to finding the problem.

I was also discussing the strange fact that the workaround others have found doesn't seem to be logical at all. That, in my 30 years' experience as a computer scientist, is almost always a good clue, if one thinks hard enough, of where the problem lies.

I don't see how any of my comments here are not appropriate.

And let me add, yes, this issue is a show-stopper. D7 should absolutely not go live until it is fixed. I have recently taken over maintenance of a contributed module, and I do not see that I can usefully test a D7 version with such a big failure at the heart of the system. That is quite apart from the appalling impression that lay people would get from a system that falls over upon writing the first page in a virgin installation.

And BTW, @marcvangend, I notice you are the person who changed the title of the thread in #34 to indicate only a UX problem. If a clean installation on a machine that has been proven to be able to do clean URLs cannot show a button to enable them to be enabled, that is a bug in the functionality, not merely a problematic user interface.

I hope that doesn't indicate that the seriousness of this is being underestimated.

@RTH I completely concur. As I pointed out in #43. The clean urls page showed no check button, even though the server WAS capable of clean urls. I was able to enable them with a work-around. The interface INCORRECTLY reported that the server was not capable of clean urls. This is a serious bug in functionality - not just a UX issue. It will bite hard if D7 gets released with this bug still there.

@indigoblue, your getting it to work with a workaround is the significant point here, and proves there is a bug as well as a UX issue.

This is so central to getting a site up and running that I can predict a publicity debacle if D7 is introduced with this malfunction remaining.

I believe this is a 7.x blocker. Should we not mark this as critical?

OK - I decided to make a clean install and test with the latest version D7-RC2. This time there was no difficulty - The checkbox was visible... and therefore I guess something has changed/been fixed in RC2. yay!

So before escalating this further - I think the best approach would be for everyone who has experienced this problem - to reconfirm with a clean install using D7-RC2 and report back if there is still a problem with steps on how to replicate.

I have now installed rc2 and I cannot replicate the failure to produce a checkbox on a system with clean url capacity.

I have, however, still found that the "Run the clean URL test" button merely recycles back to itself without a 404 nor a sensible error message. It seems that this is now only a UX issue, but it is still, imho, a show-stopping one because that is such a critical feature for beginners to be wrongly informed about. (It seems as if the button is simply not working.)

Here's (probably) how to replicate the problem. I installed RC2 by copying the files over from a directory to my root. I did NOT get my .htaccess file in the process. I ran install and everything went fine and dandy. I noticed clean URLs weren't working, checked my htaccess and realized I didn't get it when I copied files over. After inserting it, I get a page with just a test button and no option to enable/disable clean URLs when visiting the clean URL config page. When I try various clean URLs they are functioning so I know the server is capable. All D7 UI elements use non-clean URLs. As it looks there's no way to actually turn them on, just "test" for them with the button which does nothing.

I'm not going to try the Apache method. I know my .htaccess is being read because I inserted some junk into it and got a server error. I'll try a clean install I suppose, but this probably needs to be fixed...

Component:user interface text» system.module
Status:Active» Needs review
Issue tags:-overlay
StatusFileSize
new3.92 KB
PASSED: [[SimpleTest]]: [MySQL] 30,402 pass(es).
[ View ]

Well, I finally found the time to dive into this. I have found that there are three problems in the code for the clean URLs form:
1) There is no proper feedback after running the test;
2) The session-based caching mechanism is unreliable;
3) The inline documentation says "make sure clean URLs can be disabled at all times", but the code doesn't allow that at all.
My patch solves those three problems.

Problem 1) is solved by returning system messages when the "Run the clean URL test" has been clicked. I also altered the default text that you see when clean URLs are not available. I realize that we're WAY past string freeze, but I think this is the only way to really fix the problem.

Problem 2), which caused the behavior described in #9, is solved by removing the $_SESSION['clean_url'] variable, which means that the test is always run. The clean URL settings page is not visited often, so the performance impact will be minimal. When a user does visit the page, he should never be confused with stale test results.

Problem 3) was solved by comparing the test result with the clean_url variable. If there is a conflict, a message is shown and the user gets access to the form so he can disable it if needed. Also, $form_state['redirect'] is set to a non-clean URL to make sure the form is submitted correctly and the user is redirected to the correct page.

This patch works on my system (Ubuntu 10.10, PHP 5.3.3, Apache 2.2.16) but needs to be tested thoroughly on all kinds of platforms. Please give it a spin, be creative, try to break it, and report your results. Thanks!

PS. I'm not completely sure if $form_state['input']['op'] == t('Run the clean URL test') is the cleanest way to check if the "Run the clean URL test" button was clicked. It feels a bit dirty... feedback appreciated.

Status:Needs review» Needs work
Issue tags:-Needs usability review

The last submitted patch, 881376-62-clean_urls_ux.patch, failed testing.

Status:Needs work» Needs review
Issue tags:+Needs usability review

#62: 881376-62-clean_urls_ux.patch queued for re-testing.

Test pass locally and I don't see why this patch would break batch processing. Re-testing.

Use $form_state['values']['op'] instead.

I'll try to review the patch tonight. Don't hesitate to poke me on IRC if I forget.

Xano: $form_state['values'] is not available at that point, so that's why I used $form_state['input']. I think $form_state['values'] only exists in _validate and _submit functions, but IMO it would be overhead to add a submit handler if we're not really processing data, but merely checking if a certain message needs to be displayed.

This is an edge case, but it bothers me is that an if-statement like
if (isset($form_state['input']['op']) && $form_state['input']['op'] == t('Run the clean URL test')) {
will break if someone decides to change $form['clean_url_test']['#value'] with a hook_form_alter.

StatusFileSize
new4.03 KB
PASSED: [[SimpleTest]]: [MySQL] 30,449 pass(es).
[ View ]

New patch. I added a hidden field 'clean_url_test_executed' to the form running the clean url test, so instead of if (isset($form_state['input']['op']) && $form_state['input']['op'] == t('Run the clean URL test')) we can now check for if (isset($form_state['input']['clean_url_test_executed'])). This means that the button text can now be altered without breaking the messages.

This patch also fixes a minor coding style mistake.

You're using drupal_set_message() in the form builder?

drupal_set_message() should be used after user actions. Building the form does not constitute as a user action.

Instead of using $_SESSION, I would keep the test results in a system variable (variable_set()) and as soon as a clean URL test completes, compare its result to result from the test before that (which was saved using the system variable). If it differs, show a message. If it doesn't, nothing has changed, so don't show a message at all.

Just to be clear: the system variable shouldn't be used to cache the data, but to determine whether to show a message that tells the user something has changed in his server setup.

Xano, thanks for reviewing.

drupal_set_message() should be used after user actions. Building the form does not constitute as a user action.

AFAIK, drupal_set_message is not limited to user actions. For instance, it's also used to tell a user that security updates are available. Check out "▸ 251 functions call drupal_set_message()" on http://api.drupal.org/api/drupal/includes--bootstrap.inc/function/drupal..., there are about a dozen form builders on that list.
That said, the message about the test result is only displayed after the user clicks the "Run the clean URL test" button, so that certainly qualifies as a user action. (Did you actually test the patch? I get the impression that you're only reacting to what you see in code.) The only message that is not the result of a user action, is the warning when clean URLs are enabled, but not functioning. In that case, the drupal_set_message does not react to a user action, but to a change in the server environment.
I don't think that your proposal with a system variable is a solution to the UX problem. It would still mean that a user can click the "Run the clean URL test" button and return to the same page without any kind of feedback. IMO that is a no-go.

On a more abstract level I do agree with you that a form builder is not the ideal place to process test results and display messages. If you ask me, system_clean_url_settings() is a strange creature: it's two form builders mashed one, with some testing and submit handling on top. If I would have to write it from scratch, those drupal_set_message calls would probably be in a proper submit handler. However, given the current state of D7, I think there is no room for that kind of rewrites.

Thank you for working on this issue. I've got 7-RC3 running on a Windows Vista system with WAMP.

As a newbie, I was totally confused by the messaging with this issue. The message as it is now tells me that if the test doesn't work, I should recieve a 404 error, but I didn't. I just assumed it was a bug that still needed to be fixed.

There should be something in the messaging that tells a newbie that if there is not a check box for enabling clean URLs present that I should consult the handbook. As the messaging is now, it only tells me to check the handbook if I get a 404 error.

Just a newbie's perspective on the usability of the Clean URL configuration.

Thank you for listening.

BalRob

Thanks for your input, BalRob. Did you already apply the patch from #67? It really needs to be tested, so we would appreciate if you can apply the test and tell us if it takes away your confusion.

I'd be happy to test it--I'll need to read up on how to apply the patch in a Windows environment, but once I do, I'll let everyone know how it works.

I still haven't figured out how to apply the patch in Windows yet, but I'm getting there.

Interesting thing, though--in WAMP, I commented out the loading of the mod_rewrite module in the Apache httpd.conf file. (I had figured out how to enable that to get clean URLs before you asked me to check the patch), then restarted Apache so I could be ready to test the patch once I figured out how to apply it.

When I went back to the Clean URL settings page it still had the checkbox for enabling Clean URLs, even though mod_rewrite wasn't loaded. I then clicked on the 'save changes' button and the overlay (transparency) of the admin page turned into an opaque white page. Any admin page I went to thereafter was opaque white with no trasparency overlay.

When I re-enabled mod-rewrite, the opaque page issue went away.

I hope that all makes sense.

BalRob

StatusFileSize
new2.95 KB

BalRob, if you're still struggling with applying patches in windows, here is my current version of function system_clean_url_settings(). In modules/system/system.admin.inc, around line 2176, you can replace the current system_clean_url_settings() function with this code. The result should be the same as with the patch applied. This is by no means the preferred method to test patches, but it will work for now because there is only one file and function involved. Thanks for testing.

I have RC4 installed if you want me to test. I'm assuming this patch has not been integrated into the installation, because when I ran the page, I received no indication of anything.

And my Apache2 is set up correctly.

Shelly, all testing is very welcome, thanks. As long as the status of this issue is not "fixed" or "closed (fixed)" no patch has been committed to any version of Drupal 7.

Issue tags:+#d7ux, +d7wtf

Tagging... hoping to draw some attention before D7 is final.

Took some screenshots of the patch in #67 in action.

  1. I already had Clean URLs enabled, so I disabled the rewrite module in Apache. I pointed my browser to ...?q=admin/config/search/clean-urls. See CleanURLsEnabledButTestFailed.png for the result.
  2. I clicked on 'Save configuration' with the checkbox 'Enable clean URLs' still checked. The result can be seen in CleanURLsCannotBeEnabled.png.
  3. I clicked on 'Run the clean URL test'. The result can be seen in CleanURLsTestFailed.png.
  4. I re-enabled the rewrite module in Apache, then clicked on 'Run the clean URL test'. The result can be seen in CleanURLsTestPassed.png.
  5. I checked the checkbox 'Enable clean URLs' and clicked on 'Save configuration'. The result can be seen in CleanURLsEnabled.png.
  6. I unchecked the checkbox 'Enable clean URLs' and clicked on 'Save configuration'. The result can be seen in CleanURLsDisabled.png.

To me there was nothing confusing about this process, so in my opinion it is good to go. It fixes the reported bug, and would probably avoid some bug reports being filed after Drupal 7 is released. Clean URLs can be frustrating to enable in the web server configuration for many, so this patch would avoid adding more salt to the "wound".

marcvangend--thank you for making this easier for me. I, too, was able to apply the patch with the txt file you supplied, and got the same results as 1V.

I think it's a fantastic patch, and as a newbie, I wouldn't be left with a doubt about what to do to enable CleanURLs. Thanks for the great work!

Status:Needs review» Reviewed & tested by the community

This patch is much better than what is already in Drupal 7. It has been reviewed (code and UI) and tested, so marking it RTBC. Correct me if I'm wrong.

I'd like to see at least one Form API maintainer approve this patch.

Status:Reviewed & tested by the community» Needs work

This definitely seems worth fixing before release, but I can't make heads or tails of the discussion here. Could someone prepare an issue summary? (Thanks for the great testing though, 1V!)

Also, on IRC sun mentions some coding standards violations and other stuff in addition to a FAPI mantianer approval, so marking "needs work" for now.

1V and BalRob, thanks for testing and creating screenshots.

Webchick, I think the issue summary you're looking for is in #62. It describes exactly which three problems I have found and how the patch attempts to solve them:

I have found that there are three problems in the code for the clean URLs form:
1) There is no proper feedback after running the test;
2) The session-based caching mechanism is unreliable;
3) The inline documentation says "make sure clean URLs can be disabled at all times", but the code doesn't allow that at all.
My patch solves those three problems.

Problem 1) is solved by returning system messages when the "Run the clean URL test" has been clicked. I also altered the default text that you see when clean URLs are not available. I realize that we're WAY past string freeze, but I think this is the only way to really fix the problem.

Problem 2), which caused the behavior described in #9, is solved by removing the $_SESSION['clean_url'] variable, which means that the test is always run. The clean URL settings page is not visited often, so the performance impact will be minimal. When a user does visit the page, he should never be confused with stale test results.

Problem 3) was solved by comparing the test result with the clean_url variable. If there is a conflict, a message is shown and the user gets access to the form so he can disable it if needed. Also, $form_state['redirect'] is set to a non-clean URL to make sure the form is submitted correctly and the user is redirected to the correct page.

Sun, I completely agree, I would like a FAPI maintainer's feedback too. Also, I would be happy to fix any coding standards violation I failed to notice.

I want to make clear that I'm not really thrilled with the code in system_clean_url_settings(). As I said before: it's two form builders mashed into one, with some testing and submit handling on top. The reason why my patch looks the way it does, is that 1) I don't know why the code is what it is now, and 2) I wanted to create the smallest possible patch, to make it more likely that it gets committed before D7 stable. Maybe I'm missing something, but I think that the proper solution would be to have a separate menu callback function that runs the test and then calls drupal_get_form to load one of the two forms. As Xano mentioned, a submit handler would be the most appropriate place to generate the messages about the test result. However I think all that is D8 stuff; right now, the patch from #67 is a huge improvment.

Issue tags:+string freeze

Adding string freeze tag

+++ modules/system/system.admin.inc 28 Dec 2010 09:31:17 -0000
@@ -2182,22 +2182,43 @@ function system_site_maintenance_mode()
+  // If the request uri is a clean URL, clean URLs must be available.

URI always uppercase.

+++ modules/system/system.admin.inc 28 Dec 2010 09:31:17 -0000
@@ -2182,22 +2182,43 @@ function system_site_maintenance_mode()
+      // If the user started the clean URL test, provide explicit feedback.
+      if (isset($form_state['input']['clean_url_test_executed'])) {

Present form (clean_url_test_execute) would be more appropriate, less mind-boggling.

+++ modules/system/system.admin.inc 28 Dec 2010 09:31:17 -0000
@@ -2182,22 +2182,43 @@ function system_site_maintenance_mode()
+      else if (isset($form_state['input']['clean_url_test_executed'])) {

elseif

+++ modules/system/system.admin.inc 28 Dec 2010 09:31:17 -0000
@@ -2205,6 +2226,9 @@ function system_clean_url_settings($form
+    if ($conflict) {
+      $form_state['redirect'] = $base_url . '?q=/admin/config/search/clean-urls';
+    }

I think you meant to set $form['#action'] instead of $form_state['redirect'], perhaps? A code comment would help.

Additionally, I'm not sure whether these changes take the additional AJAX behavior in system.js into account?

Upon rendering of this form, an AJAX request is performed to the /check path and if that is successful, the browser redirects to the same path as clean URL.

Also note that this AJAX request currently does not send any additional form data...

It indeed looks like we should convert that current JS behavior into a proper AJAX-driven form submit, so as to achieve consistency in JS and no-JS situations.

+++ modules/system/system.admin.inc 28 Dec 2010 09:31:17 -0000
@@ -2212,12 +2236,20 @@ function system_clean_url_settings($form
+    $form['clean_url_test_result'] = array(
+      '#type' => 'markup',
+      '#markup' => '<p>' . t('Clean URLs cannot be enabled. If you are directed to this page or to a <em>Page not found (404)</em> error after testing for clean URLs, see the <a href="@handbook">online handbook</a>.', array('@handbook' => 'http://drupal.org/node/15365')) . '</p>',
     );

Can we prepend a code comment that explains why we are outputting this failure notice on the page upfront? Actually looks like a bug to me, but perhaps I'm missing a key part in the logic (which should be explained in the comment).

+++ modules/system/system.admin.inc 28 Dec 2010 09:31:17 -0000
@@ -2212,12 +2236,20 @@ function system_clean_url_settings($form
     $form['clean_url_test'] = array(
       '#type' => 'submit',
       '#value' => t('Run the clean URL test'),
     );

This submit button should totally be wrapped in a #type 'actions' parent element.

+++ modules/system/system.admin.inc 28 Dec 2010 09:31:17 -0000
@@ -2212,12 +2236,20 @@ function system_clean_url_settings($form
+      '#value' => true,

Should be 1

Powered by Dreditor.

I had the same problem with a shared host but in the .htaccess file in row 107 i uncomment that line ( RewriteBase / ) and now the checkbox and that UX came up.

Status:Needs work» Needs review
StatusFileSize
new4.53 KB
PASSED: [[SimpleTest]]: [MySQL] 31,498 pass(es).
[ View ]

Sun, thanks for the review.

URI always uppercase.
Present form (clean_url_test_execute) would be more appropriate, less mind-boggling.
elseif

All done.

+      $form_state['redirect'] = $base_url . '?q=/admin/config/search/clean-urls';

I think you meant to set $form['#action'] instead of $form_state['redirect'], perhaps? A code comment would help.

No, it really needs to be $form_state['redirect']. In case clean URLs are enabled, but the test fails, this page can only be reached at example.com/?q=/admin/config/search/clean-urls, so the form's action is the same by default. However, for some reason, the setting is not saved to the db (so clean URLs cannot be disabled) without setting $form_state['redirect'] to the non-clean URL. I added a comment.

+      '#markup' => '<p>' . t('Clean URLs cannot be enabled. If you are directed to this page or to a <em>Page not found (404)</em> error after testing for clean URLs, see the <a href="@handbook">online handbook</a>.', array('@handbook' => 'http://drupal.org/node/15365')) . '</p>',
     );

Can we prepend a code comment that explains why we are outputting this failure notice on the page upfront? Actually looks like a bug to me, but perhaps I'm missing a key part in the logic (which should be explained in the comment).

That notice is presented only if $available and $conflict are both false, ie. the test has failed and clean URLs are disabled. If the user sees this page, it needs to be explained why he is seeing it and what he can expect after clicking the button. I added a comment to clarify that.

This submit button should totally be wrapped in a #type 'actions' parent element.

OK, done. (I didn't know that, I guess it needs to be documented at http://api.drupal.org/api/drupal/developer--topics--forms_api_reference.....)

+      '#value' => true,

Should be 1

Done.

Regarding JS and AJAX: I didn't do anything about it. While investigating this problem, I didn't see any AJAX activity going on, so I ignored the js file and focused on fixing the errors before D7 goes stable. Looking at the code, I see that the jQuery selector is broken. It looks like the AJAX functionality on this page has been broken since #423196: Clean up clean URLs settings page was committed on May 29, 2009, because that's when the id attribute changed. Ouch!

I did a quick test and it seems that the AJAX functionality comes back when you replace $('#edit-clean-url') with $('#edit-clean-url-test') at line 35 of system.js. That said, given the way the php logic works right now (after my patch), I really don't see the added value of checking this with AJAX.

Another thought... the possibility of a 404 is still mentioned:

Clean URLs cannot be enabled. If you are directed to this page or to a Page not found (404) error after testing for clean URLs, see the online handbook.

However on my test installation I never get a 404. With the current code, is it even possible on certain platforms that a user gets a 404? If not, let's take out the 404 part.

However, for some reason, the setting is not saved to the db (so clean URLs cannot be disabled) without setting $form_state['redirect'] to the non-clean URL.

This sounds very odd. We cannot commit a change that relies on a uncertain/unknown behavior. The applied code logic needs to know why it exists.

the jQuery selector is broken. It looks like the AJAX functionality on this page has been broken since #423196: Clean up clean URLs settings page was committed on May 29, 2009, because that's when the id attribute changed.

The intended UX behavior of this settings page is that a user should not have to click or do something in order to perform the clean URL test. Thus, when visiting this page with a non-clean URL, a JavaScript HTTP GET request is performed to the check callback, and if that callback returns 200/success, the browser redirects to the same page using the clean URL. The resulting page merely contains a confirmation that clean URLs can be enabled, and a checkbox to ultimately enable them. In other words: the intended UX is a one-click action.

But you're right that the ID of the triggering form element was unintentionally changed, so the JavaScript behavior is not executed at all anymore. Fixing that should be part of this patch.

sun,

Quoting from your comment#89:
""However, for some reason, the setting is not saved to the db (so clean URLs cannot be disabled) without setting $form_state['redirect'] to the non-clean URL."

This sounds very odd. We cannot commit a change that relies on a uncertain/unknown behavior. The applied code logic needs to know why it exists."

I believe what marcvangard is describing here is what I ran into in comment#73. When I was trying to apply his patch, I commented out the loading of the mod_rewrite module in the Apache httpd.conf file (in my WAMP setup), then restarted Apache so I could be ready to test the patch once I figured out how to apply it.

When I went back to the Clean URL settings page it still had the checkbox for enabling Clean URLs, even though mod_rewrite wasn't loaded. I then clicked on the 'save changes' button and the overlay (transparency) of the admin page turned into an opaque white page. Any admin page I went to thereafter was opaque white with no trasparency overlay.

When I re-enabled mod-rewrite, the opaque page issue went away.

Being a newbie, I may be way off-base in this discussion, but thought you might want to know what happened to me in relation to not being able to disable clean URLs.

I hope that all makes sense.

BalRob

StatusFileSize
new83.58 KB

This sounds very odd. We cannot commit a change that relies on a uncertain/unknown behavior. The applied code logic needs to know why it exists.

You're right. I merely reused the trick of setting $form_state['redirect']; it was already in the code of system_clean_url_settings(). If no one knows why it works, we need to find out.

The intended UX behavior of this settings page is that a user should not have to click or do something in order to perform the clean URL test. Thus, when visiting this page with a non-clean URL, a JavaScript HTTP GET request is performed to the check callback, and if that callback returns 200/success, the browser redirects to the same page using the clean URL. The resulting page merely contains a confirmation that clean URLs can be enabled, and a checkbox to ultimately enable them. In other words: the intended UX is a one-click action.

Even without my patch applied and with the broken jQuery selector, the behavior is exactly the one-click action you describe above. (The only difference is that there is no redirection going on.) No javascript is needed because the test is performed in php with drupal_http_request() before the appropriate form is built. Clicking the button is not a necessary step, it simply re-runs the test, which is useful when you're trying to make clean URLs work. I put together a flow chart to clarify what happens in system_clean_url_settings() after applying the patch. I hope that helps.
flow chart of system_clean_url_settings()

Everything the javascript does (once we fix the selector) is already happening in php. The only difference is that the js redirects to the clean URL, whereas the php code simply displays the appropriate form on the requested URL, clean or non-clean. Looking at the js code comments, even that redirection behavior seems to be a hack to force the correct form:

// Check was successful. Redirect using a "clean URL". This will force the form that allows enabling clean URLs.
The more I look at the javascript side of this, the more I think that not of fixing it, but removing it should be part of this patch.

BalRob: I think your situation was caused by the $_SESSION-based caching of the test result, not by the absence of $form_state['redirect'].

An issue describing the problems of a victim of this UX, posted today: #1018346: clean-urls can't be activated.

Hm, very disappointing that this wasn't fixed before the release of Drupal 7. The reason it matters a lot to me is that I'm going to explain clean URLs to 50 students in a couple of weeks, and it doesn't help if the clean URL test doesn't work. Can I help testing a patch?

This has probably been reported above: I'm not able to make Drupal forget the result of the clean URL test - even if I flush the cache. (I even deleted the "clean_url" variable using the Variable editor in the Devel module, and then flushed the cache again.) And this is when I have removed the RewriteBase settting so clean URLs don't work ...

hansfn: sure, you can help testing the patch. Just apply it and see if the page behaves the way you would expect it to.

In fact, having a class with 50 students offers a lot of possibilities. You can hook them up with a patched version and see if they are able to complete the task without asking questions about the interface and the clean URLs test. You could also give the patched version to only half of your class and compare the results between the two groups. You could even let them apply the patch themselves and teach a lesson about contributing to open source software... Sorry, I got carried away there :-)

You are right about the caching, currently there is no way from the UI to make Drupal forget about a successful test. The test result is stored in your $_SESSION variable, so you can make Drupal forget about it by deleting the session cookie from your browser and logging in again. This problem (amongst others) is fixed by the patch.

I have the same problem, because nothing happens whe the botton is pressed.

Uncommenting RewriteBase fixed the problem for me, thanks #86. I have shared Apache hosting w/ 1&1, if that makes any difference.

Version:7.x-dev» 7.0

The clean urls button is missing from my site and I need to actually click it off!! Here's the problem with the clean url button and I didn't see this exact case mentioned:

I built a test site on a local server in MAMP with clean urls enabled. I transfered the site to live on a server that doesn't support clean urls (I didn't realize until it was too late).

Now all the links on my site are broken (they are missing the q?=) I have to manually retype them in the browser with the q?=. When I go to the admin panel to click button for disabling clean urls the button is missing! All I get is an option to run the clean url test.

The only way to fix it was to go back to original test site and disable clean urls before exporting the database

Version:7.0» 7.x-dev

X1-Bot: thanks, your story illustrates why this patch is important. If you can, please re-create the exact same situation with the patch applied and try to solve the problem again. After that, please let us know if the patch made it easier for you to solve the problem.

PS. If you change the 'version' value when commenting in an issue queue, you're changing it for the entire issue, not just for your comment. I'm setting it back to 7.x-dev because that is where the bugfixing happens.

Thanks juahoo:

That solve the problem, the thing is. If the installation is made in a /home/user/public_html/drupal7/
It is necesary to change in the file .htaccess the line RewriteBase as Juahoo said:

In my case works like this:

RewriteBase /~user/drupal7/

Before applying the patch, I have experienced some anomalous behavior in AJAX on other pages. Prior to enabling Clean URLs AJAX was working correctly. After enabling Clean URLs, all working ajax started returning 404 errors.

I will apply the patch and see if it rectifies this issue also.

After applying the patch, I can no longer disable Clean URL's. Turning off the check box and clicking save will return me to the same page with the check box still clicked.

It appears to "get even better". After logging out with Clean URL's turned on (and no way to turn them off it appears), I can no longer log in. Guess I will need to re-install...

I applied the patch from comment #87 above. It fixed the initial issue, in the sense that the test started returning results. However, the response I got back was "The clean URL test failed." But I've been able to use clean URLs on the same server, using Drupal 6.

One thing that may be throwing off the test results is that I'm running Drupal in a subdirectory (using "RewriteBase /~example/sitename"). But the Drupal 6 sites on the same account are configured the same way.

UPDATE: Oddly, I went back a few days later and clean URLs were working. When I went to the admin/config/search/clean-urls page though, the check box wasn't enabled. To be consistent, I checked it and they continued working. I don't know if my hosting company changed something in their configuration or what. Sorry if this just confuses things, but I'm baffled too.

Clean URL's still cause AJAX 404 issues - any updates?

Ping...

Category:bug» support

Hi, everyone.

I'd like to ask for some help...

I'm new to drupal and I simply cant make clean urls work.
I installed drupal in Mac OS X 10.6 and I tried lots of thinks:

1) edit /etc/apache2/httpd.conf (FolowSymLinks, AllowOveride, etc)

2) edit /etc/apache2/users/username.conf (FolowSymLinks, AllowOveride, etc)

3) edit .htaccess (RewriteBase /drupal)

I'm a little frustrated because it took me about 2 hours and I cant make it work.
But I know my computer can use clean urls because I also use wordpress and permalinks are working fine.

Does anyone can help me?
Thanks a lot!

Category:support» bug

Thanks #37 Grahor
it's work for me

Should I post the AJAX 404 issue associated with Clean URL's in a different area? The system works fine if do not enable clean URL's. Once enabled, AJAX gives 404 errors for everything.

Did a clean install of 7, checked AJAX was working by creating new user. Turned on Clean URL's, 404 error when setting password on new user. Turned off Clean URL's problem remained. Reinstalled Drupal, problem gone.

Running on Centos 5.5, PHP 5.3.6-01, MySQL 5.5.9, Apache 2.2.17.

Thanks,
Tim

Version:7.x-dev» 8.x-dev
Issue tags:-#d7ux, -d7wtf+#d8ux

Issue tags:+#d7ux, +d7wtf

I know it must be committed to the D8 branch first, but it's still a huge UX WTF in D7 and it needs to be backported. I'm not giving up on D7 yet! (/me remembers Sun assuring me on IRC that this will surely get committed before 7.1...)

#37 worked for me, too. (hosted on MediaTemple (dv) box). Thanks!

The removal of the issue tags was a mistake I suspect. Re-adding them.

I understand that the community has moved on to Drupal 8, but is there any timeframe on this for those of us wanting to stay with a "stable" release for our clients?

Exactly as described #37 - the same problem solved by #37's solution. Thanks!
BTW: running D7 on Gigaserver.cz's servers.

Not sure if this is stated or experienced by anybody else, but before trying any solution, Clean URLs were functioning for me if I manually typed the URL. Drupal was just refusing to generate clean URLs.

#37 allowed me to see the checkbox when browsing the the admin page, when the overlay would not, however the checkbox would not save and the form reloaded unchecked.

#86 allowed me to see the checkbox on both the page and the overlay, however ONLY the overlay would save the clean urls setting.

#86 ultimately has fixed this for me.

EDIT: Since applying #86 and then enabling Clean URLs, I started having problems with Nodereference Fields and AJAX. I'm now no longer able to use Overlay as it keeps redirecting me to the admin page in order to disable Clean URLs, which still does not allow me to modify the Clean URL's setting, just submits a reset, this time always enabled.

Also, undoing the change in #86 (commenting the Rewrite Base in .htaccess) has failed to allow me to modify Clean URLs

Tried resetting the Clean URLs setting in the variable table in DB, didn't seem to have any effect.

Tried logging out, then had a crazy ordeal that almost sent me crazy where by I couldn't login. I appear to have been saved by clearing cache with Drush and finally being able to log back in, at which point Clean URLs have disabled themselves and I'm able to use Nodereference AJAX again.

I should mention, the Nodereference is now part of the References module for D7

Hello all

Glad to have found this thread. I'm in the middle of struggling with Clean URLs on D7 myself (http://drupal.org/node/116769) and I have some thoughts about the user experience.

Like others here, I have been clicking the button and getting the same page back again with nothing different, and wishing the result was a bit more verbose and helpful.

I'm not sure if I should be trying to apply the patch from up-thread - whether that will actually help me or if it's more designed for future people who haven't even got this far. Should I?

Anyway, meanwhile bear in mind that what I'm commenting on here is D7, not D7-dev or the patch.

1) OK, from this thread I get that there are technical limits on how much information can be returned on the spot after running the test. Details of the "type of fail" would certainly be on my wishlist, but if that's not possible at the moment, fair enough.

2) I.m.o. the existing D7 instruction is definitely a bit broken. ("If you are directed to a Page not found (404) error after testing for clean URLs, see the online handbook.") At first it didn't even occur to me to click on the handbook page link, because I haven't had a 404! and wrongly expected the handbook link to be talking about something specific to that case!

It should at least say "If you are directed to a Page not found (404) error after testing for clean URLs, or you simply get this page back again unchanged, see the online handbook." (bolding here to indicate suggested amendment, not that it would really be bold in the amended version) - though in fact I think we can do better than that.

(As an aside, I am puzzled about the absence of 404s, because Xano said at #15
The 404 behaviour is actually the only way to do an accurate check. We test for clean URLs by checking if we can load a page using a clean URL. The PHP check may fail because PHP can't execute HTTP request. The JS request may fail because JS isn't executed. That leaves us with a manual solution (the button), but unfortunately there is no way to perform a request without actually redirecting the user this way, so we can't catch the 404 and show the user something different, which we can and do when the PHP or JS check is used.

Shouldn't that mean that if JavaScript is off and I click the button, I get a 404? But I don't. I've never had a 404 yet whatever I do, only the same page again. http://www.example.co.uk/?q=admin/config/search/clean-urls)

3) I note the exchange between Dries & Xano at #26 & #29 of the earlier discussion at http://drupal.org/node/423196. To paraphrase, Dries said "users need more info than this", Xano replied "yeah, but no way can we tell them everything here, look at the handbook page which is long". I agree with both of these comments.

Stepping back from my own situation and thinking also of users even less experienced than me, I think what might be good is something like:

===
If clicking the button gives you this page again, or a Page Not Found (404) error, it means Drupal could not yet confirm that Clean URLs would work here.

Clean URLs depend partly on Apache, or your web host's equivalent server software - not only on Drupal. If they don't work straight away, you may need to change something yourself (e.g. change a line in Drupal's .htaccess file), or you may need help from your hosting company. The answer is different for different hosting environments, so please _see the handbook_ [= link].

After making changes, click the button again to re-test. If Drupal succeeds in confirming that Clean URLs can work here, it will show a tick-box to switch them on.

Alternatively, you can choose to launch your site without Clean URLs. The site itself will still work.
===

(not claiming that all details of that are correct or best put, but suggesting something of approx that level of informativeness. It would e.g. clarify things for some of the people in http://drupal.org/node/1018346.)

4) For myself, something I would like to see included in the handbook (and indeed now!) is a step by step walk-through of the test mechanism. From this thread, I understand now that the test tries to call a clean-URL page. But I still have only a fairly vague idea of the stages that Drupal goes through to serve a page, and what role mod_rewrite and .htaccess (or httpd.conf) would be playing in a passed test. I feel sure that if such an explanation was spelt out "in little words", I would be able to understand it.

At present what I have "instead" is a list of things that might make the test pass (e.g. changing the RewriteBase line). Better than nothing, but really I don't just want to be told "you can try this list of various things and, hey, one of them might work"... especially bearing in mind that two or more of the different possible fixes might need to happen at once. I know there are people who have spent many hours on similar experiments. My heart sinks! It's not an attractive path!

I'm craving some kind of mental model for what the test actually DOES, what ingredients have to be in place for the stages to succeed, and hence the various ways in which it could be failing. And then I could mesh that model with the actual hosting situation I'm dealing with, and get a sense of which fix is most likely to be applicable and why.

Maybe that explanation does exist somewhere and I haven't found it? I've found http://drupal.org/node/423196 comments #9, #33 and #48, but none of those is really aimed at people at my lower level of the learning curve - not enough background explanation (and I'm not even 100% sure which of them describes the current functioning).

I would be happy to contribute to the writing of such a page, right now while I want to try to understand it for my own reasons anyway. For obvious chicken-&-egg reasons I can't write it by myself, but if anyone who does understand the mechanics wants to be quizzed & let me draft a write-up of their answers, let me know.

5) Couple of questions arising from earlier comments on this thread:

a) About the session-variable cacheing: I'm unclear on this now. Does clicking the button clear the cache? Or not?

b) Is the scenario described at #26 above the only kind of false negative known to exist? so that in D7, if I go directly to http://www.example.co.uk/?q=admin/config/search/clean-urls (no overlay), and get a fail, it definitely means a fail?

Thanks & h.t.h.

Answering my own question from 5b just above... No, there is another kind of false negative, and it was the cause of my problem.

See http://drupal.org/getting-started/clean-urls#comment-2526658
and http://drupal.org/getting-started/clean-urls#comment-4511508.

After testing various alterations to .htaccess, I discovered those two comments. Went to http://www.example.co.uk/admin/settings/clean-urls (note clean URL) and straight away there was the tickbox! I then (to double-check what was happening) copied an original D7 default .htaccess file into place. Still works. There was nothing wrong with the hosting environment in the first place!

I.e. it's not only the user experience which is a bit broken. The test is broken... under some presumably not too common circumstances.

I've created a separate bug report for that, because this thread is primarily about the user experience of a "no" test result, not really related to whether the test is accurate. I've linked to this thread and the "Clean up clean URLs settings page" one. See http://drupal.org/node/1178850.

Version:8.x-dev» 7.2
Assigned:Unassigned» parksan

One way to solve this problem:

my problem is 'CLEAN URLS' check-box disappeared, just leaves the buttom of RUN CLEAN URLS in the page of (http://***/admin/config/search/clean-urls).
I modified the '# RewriteBase /' in .htaccess to ' RewriteBase /'. (my d7 set in my site root).
Ok, fresh your site, you can find the ‘Enable clean URLs’ check-box. and then be working.

Version:7.2» 8.x-dev
Assigned:parksan» Unassigned

parksan, please leave the issue settings as they are unless you have an important reason to change them. They are applied to the whole issue, not just your comment.

I've got a question.

#26, #27, #43, #55, #56, #116 and mine at #118 are talking about the test actually giving wrong results (false negatives), possibly/seemingly related to the overlay function.

The issue title doesn't currently acknowledge that, and it doesn't seem to be included in marcvangend's summary at #83 of what's being addressed by the current patch. (though maybe I've misunderstood?)

By far the majority of comments here are genuinely about the user experience (in particular the "same button again and again" thing), so it's a reasonable title for the thread. And that certainly does need addressing. But I don't want the "false negative results" thing to get lost.

So I started http://drupal.org/node/1178850 specifically to address that (see #118 above). But I'm being told at the other issue that it's a duplicate of this one.

@marcvangend, is your patch at #87 designed to fix the "false negative" issue, or not? My impression was that it wasn't (and indeed that no-one really understands yet exactly what was happening to create the false negatives)... but that might just be me getting the wrong end of the stick :-)

Thanks in advance for clarification.

Version:8.x-dev» 7.x-dev

This worked for me: to get the checkbox to display, in /drupal/.htaccess modify the RewriteBase to reflect your site's root.

@fishbowl:
I'm glad you solved your problem, but let's say this one more time:
This issue is not about the correct server/htaccess setup to make clean url's work. This issue is about how Drupal communicates with the end user about the current configuration.

@Jennifer_M:
Thanks for your elaborate comments, I'm sorry I didn't have time to respond sooner. Regarding your question in #121: My patch fixes a false test result as described in #9 of this issue. I would call that a false positive: the clean URL checkbox is there, but when you enable clean URL's, they don't work. Personally I have not been able to reproduce false negatives. My patch may accidentally fix them, but I'm not sure. False negatives can also be the result of browser cache, as mentioned in #38.

I hope to do some more work on this issue in the coming weeks. With so many people involved in this thread, we should be able to wrap this up and get it committed.

Version:7.x-dev» 8.x-dev

Tagging issues not yet using summary template.

nothing reviewable

Status:Needs review» Needs work

It should be possible to build

+      $form_state['redirect'] = $base_url . '?q=/admin/config/search/clean-urls';

with url() and the 'external' => TRUE option.

There are a lot of new strings added here, are they all necessary?

Apart from that the patch looks sane to me, did not test it or anything.

Hi,

So I understand that you made a patch to say it failed better. However, I just did a fresh 7.7 install, changed .htaccess, made sure mod_rewrite was loaded, added the rewrite rules in the installation...no checkbox. Tried different permutations of what I was able to glean from this thread...no checkbox.

Does your patch bring back the checkbox? Do I need to apply this patch to 7.7?

Thanks

Re #127: I think you're completely right about url(). I'll give it a try to be sure and check if all lines are absolutely necessary.

Re #128: At the risk of repeating myself: I have not yet seen a situation where the test returns a false negative. If there is no checkbox, the test failed for a reason and you need to check your server configuration. The patch does not fix that.

StatusFileSize
new4.93 KB
PASSED: [[SimpleTest]]: [MySQL] 33,233 pass(es).
[ View ]

Re #127: Some more thoughts about url()... First of all, I think you can't use 'external' => TRUE because that would ignore the drupal base path. You could use the query property:

      $form_state['redirect'] = url('', array('query' => array('q' => '/admin/config/search/clean-urls')));
That's what I did in the patch attached.

I also made a small improvement to the form that is shown in the conflicted state (ie. clean URLs are enabled but the server does not support it): There is now a single button you can click, the checkbox has been replaced by a hidden field.

Status:Needs work» Needs review

Re #129, If there is no checkbox, the test failed for a reason and you need to check your server configuration.

I think that statement is a bit misleading, given that other people have seen false negatives. I think anyone reporting a perplexing negative should be advised to read http://drupal.org/node/1178850 before concluding it's for real.

(@timebinder @#128: I don't know if you already did read that other issue, but I recommend you do if you didn't already.)

The code in #130 doesn't appear to actually be in the patch.

StatusFileSize
new4.65 KB
PASSED: [[SimpleTest]]: [MySQL] 32,857 pass(es).
[ View ]

Re #133: you're right, my mistake, I attached the wrong patch.

Re #132: The one-click-disabling button I introduced in #130 does not really harm those with a false negative, because it's still your own decision to click it or not. It only takes away the need to uncheck the box before submitting the form.
That said, I decided to take out the one-click-disabling for now. I think this issue should only focus on what's really broken. The less we change now, the greater the chance it can be backported to D7. Other improvements should be done in a D8-only follow-up after this issue is fixed.

Priority:Major» Normal
Issue tags:-string freeze, -#d7ux, -d7wtf, -#d8ux, -needs backport to D7+Usability

Sorry, but I have to demote this - after 1 year in the queue, we are still not very close to a fix and its effecting only a very small usecase.

Priority:Normal» Major

This functionality is seriously broken; the "usability" part is actually secondary here, we're primarily talking about a major bug in code logic. And yes, this is broken for ages already, but didn't popup for everyone, since the Standard install profile enables clean URLs by default, if I'm not mistaken.

Ok, how do we move this forward? There is no use in getting marc to put forward more patches, when there are no reviews.

@sun / @Bojhan.core - The problem is worst if you upload the Drupal codebase files to your server/directory without the provided .htaccess file (like most people who upload via FTP often do). If this happens, the UX and functionality of the clean URL system is completely borked, and there is no helpful warning or requirement showing the actual problem (the .htaccess file is missing).

That's why it's major; I would imagine many a beginning Drupal developer will be / has been frustrated when they can't get clean URLs working, and have to resort to looking around online for an answer (not a good first impression).

#134 looks fine to me. I did not test manually.

Is http://drupal.org/node/881376#comment-3890264 still accurate for screenshots?

Re #139: Yes, those screenshots are still correct.

Status:Needs review» Reviewed & tested by the community

OK, let's get this in then, Bojhan confirmed he's still happy from a UX point of view in irc as well.

There are some string changes/additions here, we might want to review those for 7.x, but this an extremely rarely visited page so breaking translations seems OK to fix the bug.

Definitely agree with RTBC. This page is probably only visited when the site is originally installed, so I don't see a problem with string changes.

Re #142: That's not completely true, the page may also be visited when a site is moved to another server or after the server configuration has been changed. Anyway, these added strings are essential to fixing the UX. Without them, it remains broken.

Here are the results of my testing...

I deleted my .htaccess file in order to force clean URLs off. I then manually went to the URL http://localhost/core/?q=admin/config/search/clean-urls.

Without the patch I get this:

Button + link to handbook.

I am indeed directed to a 404 page when clicking the link, which forces me to have to hit the back button and then manually click http://drupal.org/node/15365. Ugh. There's also no way to shut this off without basically Devel module, since I can't even toggle it in the database in PHPMyAdmin or something, since those value fields are BLOBs.

With the patch, i get this instead:

Description of problem, checkbox to shut it off

MUCH better. I'm told what the problem is before clicking the button, I'm given a checkbox to turn off the setting that no longer works, etc. And now if I switch off that checkbox and re-press the button, instead of being taken to an Apache 404 page, I instead get this:

notice that clean URL test failed

So in every conceivable way, the patch vastly improves the situation.

The big question is whether this is D7 material or not, and if so to what extent. Obviously, this will invalidate existing documentation that talks about how to turn on/off clean URLs. But it will probably also remove 500 paragraphs from said documentation and render it unnecessary.

So I'm leaning toward committing to D7 even though it's both a UI and string breakage. I'll revisit shortly after 7.8 is rolled this week, to see what other opinions there are.

Thanks for your review, Angie. Glad to see that you're satisfied with the improvements ;-)

Issue tags:+needs backport to D7

Adding backport tag. Breaking UI/strings seems fine in this case, since they're the cause of the bug here.

Status:Reviewed & tested by the community» Needs work

+++ b/modules/system/system.admin.inc
@@ -2181,24 +2181,45 @@ function system_site_maintenance_mode() {
+        if (!isset($form_state['input']['op'])) {
+          drupal_set_message(t('Clean URLs are enabled, but the clean URL test failed. If needed, you can disable clean URLs now.'), 'warning');
+        }

I'm not really sure I understand this message. Especially the last sentence is confusing. How does the end-user know if it is 'needed to disable clean URLs now'? I'm hoping we can make this a bit more clear before we commit it.

I skimmed, so apologies if I missed the answer to this somewhere. Is there a reason not to do one of:

  1. Instruct the user to disable clean URLs?

    Clean URLs are enabled, but the clean URL test failed. Uncheck the box below to disable clean URLs.

  2. Or even possibly disable clean URLs automatically when the test fails?

    Clean URLs have been disabled because the clean URL test failed.

As I recall, clean URLs cannot be enabled at all if the test fails on install, so #2 isn't actually too ridiculous. In any case, can someone clarify?

StatusFileSize
new4.65 KB
PASSED: [[SimpleTest]]: [MySQL] 32,932 pass(es).
[ View ]

Re #147, #148:

A user sees that message in one of the following situations:
1) Clean URLs used to work, but they are not working anymore because the server environment changed. (The user must have navigated to the page by manually typing the non-clean url in his browser. He is probably busy fixing the problem.)
2) Clean URLs are enabled and working, but the test returns a false negative. (False negatives have been reported above, but I have not been able to reproduce it.)

I don't think it's a good idea to disable clean URLs automatically in a conflicting situation. Mainly because I never like settings that automatically change themselves (it makes me feel out of control), but also because a user may just want to solve the problem without disabling clean URLs first, and because of situation 2).

The current patch says "if needed" because I think admins should be able to decide for themselves if they really want to disable clean URLs. However, I like xjm's suggestion "Uncheck the box below to disable clean URLs" because it provides more guidance for users who don't have a clue what to do. New patch attached.

Status:Needs work» Needs review

Following our interface text guidelines, the "if needed" part is not needed (the irony). We do not tell or advise users what to do with their websites. We only present them the possibilities.

Status:Needs review» Reviewed & tested by the community

I think that's a good improvement, it's a hard condition to explain (although Marc did a good job!) and it was already an improvement on the existing UI which didn't really handle this case at all. Moving back to RTBC.

Version:8.x-dev» 7.x-dev

Great. The updated status/help message is much better and it is no longer confusing to me. I committed to the patch to 8.x.

I'll leave it up to webchick to decide if this patch should go in 7.x. Technically it is a UI change but personally I think it is worthwhile to backport this patch.

The clean URL setting (and test) has been tweaked and tuned for many years, however, it feels like we are finally getting it right now. Great job!

OK, so any advice/direction for a Druupal newbie here who wants clean URL's? I'm getting the same page returned as spoken about above. I get no check box nor a message saying the URL test failed. So, apparently my server is not set up for clean URL's? I'm running a pretty new install of Drupal 7.7.

Any and all advice would be greatly appreciated! (I'm wondering if I should stick with WordPress)

WebDi, welcome to the community. This thread is a bug report in the issue queue, so this is where the community solves problems. This is not a support forum - but maybe you weren't aware of the difference.

Please see the documentation (http://drupal.org/getting-started/clean-urls) to learn how you can enable Clean URLs on your system. If that doesn't help, you can start a new forum topic (http://drupal.org/node/add/forum), open a support request issue (http://drupal.org/node/add/project-issue/drupal) or use another support channel such as IRC (see http://drupal.org/irc).

PS. Should you stick with Wordpress? I think not. Server configuration can be a bit puzzling sometimes, but if Drupal is the right tool for the site you need to build, don't let the server stop you.

+1 , tested the patch from #149 on current D7 stable and also fixes my problem of the form_state['redirect'] going to a clean url, would be REALLY nice to see this in D7 as I'm sure a lot of non-clean-url enabled admin's out there are now saying "Huh? I enabled a module now my site is broken" when their browser gives them 404 because it's sitting on 'http://site.com/admin/modules'

Status:Reviewed & tested by the community» Needs work

+++ b/modules/system/system.admin.inc
@@ -2206,18 +2227,37 @@ function system_clean_url_settings($form, &$form_state) {
+    // Explain why the user is seeing this page and tell him what to expect
+    // after clicking the 'Run the clean URL test' button.

don't assume that drupal users are male.

Is there an official policy for English language usage of the third person in Drupal docs and informational pieces? It seems that there are different standards in different places in the documentation, and I've never seen any guidelines for it...

Should it be changed to 'she' (flip the coin the other way)? 'They' (grammatically incorrect, but gender neutral)? Some form that avoids the third person? In written language, I've gone many different directions, usually whatever the professor, organization, publication, etc. requires.

There's no reason to use a gendered pronoun at all. I would simply repeat "the user" or a use passive construction:

Explain why this page is shown and tell the user what to expect after clicking the 'Run the clean URL test' button.

Or we could remove the comment entirely. I'm not sure that it's that helpful.

This has already been committed to 8.x, so we can open a separate issue to de-gender-ify the comment there. (Novice issue!!)

Status:Needs work» Needs review
StatusFileSize
new4.64 KB
PASSED: [[SimpleTest]]: [MySQL] 35,991 pass(es).
[ View ]

To me, the his/her thing is a complete non-issue. I merely used the word "his" to refer to the gender-neutral "the user"; Wikipedia calls this the universal he. However, if people find this offensive, let's change it. I really don't want to get into a gender discussion here.

Similar problems have been solved before (eg. #75594: Removal of gender-specific pronouns from core) and I agree with the majority there that a construction like "tell him/her" is ugly and breaks the flow of the text. That's why I propose the following solution:

+    // Explain why the user is seeing this page and what to expect after
+    // clicking the 'Run the clean URL test' button.

Status:Needs review» Reviewed & tested by the community

That seems perfectly fine to me.

Opened a followup in #1284436: Make comment text gender-neutral in system_clean_url_settings() to change the 8.x comment.

Category:bug» task
Priority:Major» Critical
Status:Reviewed & tested by the community» Active
Issue tags:+Needs change record

I tested this out and it works slick. I think it's definitely worth committing to D7.

So! Committed and pushed to D7. :) This could use a change notification about the before/after UX change for the benefit of the documentation team.

OMG! Whooo :D Finally!

Title:"Run the clean URL test" UX is brokenChange notification for "Run the clean URL test" UX is broken

Issue tags:+Novice

And since adding that summary is relatively easy, tagging as Novice.

Title:Change notification for "Run the clean URL test" UX is broken"Run the clean URL test" UX is broken
Status:Active» Fixed

I have created a change record: http://drupal.org/node/1294434.

I'm reverting the title, otherwise the link to this issue in the change record looks silly.

Shouldn't the "Introduced in version" be set to 7.9, the upcoming version? (if 7.9 won't be the security release.)

Re #168: I asked in IRC about that and Webchick and Catch told me to use 7.8. Quote:

(09:37:20 AM) marcvangend: catch: So if I create a change record now for something that was added to 8.x first and backported to 7.x, I just enter 7.8?
(09:37:40 AM) catch: marcvangend: yeah I think so.
(09:38:42 AM) webchick: marcvangend: I think that's how others have been doing it. It's a little awkward but kinda works. We should probably ask jhodgdon what she'd prefer there in the future.

Fair enough :)

Actually I think we were wrong saying 7.8, it should probably be 7.9 although if that did end up being a security release it'd still be wrong.

I know the problem is solved, I had the same problem but for me the following worked out:

Look at you root folder and see if there is an .htaccess file drupal needs this to rewrite the url's. Show hidden files needs to be on visible, this is platform specific. For mac type the following instruction in the terminal: defaults write com.apple.finder AppleShowAllFiles TRUE to turn this of again run the same instruction with FALSE .htaccess isn't copied if show hidden files is off.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

In my case the problem occurred when I tried to install drupal in a subdirectory...

in which case I had to find these lines in .htaccess

# Modify the RewriteBase if you are using Drupal in a subdirectory or in a
# VirtualDocumentRoot and the rewrite rules are not working properly.
# For example if your site is at http://example.com/drupal uncomment and
# modify the following line:
# RewriteBase /path/to/subfolder/directory

agree with OP... very confusing for the button to do nothing when you click it... needs an error other than 404... maybe a read write error? since that seems relevant...

fireflydesign, welcome to the community. This issue has already been closed and the fix is implemented in the latest version of Drupal 7. If you still have problems getting clean URLs to work, refer to the documentation or open a new issue.

Category:task» bug
Priority:Critical» Major
Issue tags:-Needs issue summary update, -Novice, -Needs change record