Follow-up to variable_get('clean_url') removal [#1546082]

Spin-off from #1183208: Remove variable_get('clean_url') and switch to index.php/path pattern for dirty URL support

Problem

When visiting http://example.com on a site where clean URLs are not supported, but index.php is found as default document, then all links will use clean URLs, which won't work.
install.php and update.php output links to index.php, which always assume and use clean URLs, which may not be supported.

Details

#1183208: Remove variable_get('clean_url') and switch to index.php/path pattern for dirty URL support removes the 'clean_url' setting.
Requests using a clean URL (http://example.com/foo) will output links using clean URLs.
Requests using a dirty URL (http://example.com/index.php/foo) will output links using dirty URLs.
A request that does not contain a Drupal path (http://example.com) is determined as clean URL. (typical front page)

Proposed resolution

- TBD -

Related issues

#1537540: FallbackResource support (since Apache 2.2.16+ instead of mod_rewrite)

Comments

Comment #1

effulgentsia CreditAttribution: effulgentsia commented 24 April 2012 at 22:30

Note that that patch uses a $script_path global variable that by default is auto-determined, just like $base_url. So, both of the above use-cases could be solved by instructing people running production sites where clean URLs don't work to explicitly set that variable (in settings.php) to 'index.php/', just like we currently have instructions for explicitly setting $base_url on sites where the auto-determination doesn't yield the desired results.

However, I think we can come up with better solutions to this, such as .htaccess and web.config modifications to redirect http://example.com to http://example.com/index.php when the server requirements for the rewrite directives aren't met, and maybe even renaming index.php to drupal.php (to prevent it from being a default document), and add an index.html default document that redirects to drupal.php.

Comment #2

cosmicdreams CreditAttribution: cosmicdreams commented 25 April 2012 at 01:33

You know....

renaming index.php to drupal.php has another benefit if you think about the future where other apps based on symfony will want to integrate with Drupal tightly.

if you have two apps working with the same symfony backend... how do you get the requests to the proper application? We have HttpKernel in place and that's a major win, but how do you define the routes so that requests get to their proper destination.

If we have one app use index.php and the other use drupal.php you can simply write a .htaccess rule to redirect request to the proper code.

So, in short, +1 for renaming index.php

Comment #2.0

sun

German

Karlsruhe

CreditAttribution: sun commented 25 April 2012 at 11:37

Issue summary:

View changes

Updated issue summary.

Comment #3

sun

German

Karlsruhe

CreditAttribution: sun commented 25 April 2012 at 11:43

I've entirely rewritten the issue summary.

Renaming index.php as suggested in #2 seems out of scope for this issue to me, and would make the Drupal setup on special environments (only supporting the default document via DirectoryIndex) even harder.

I'm not sure I understand why we cannot perform a similarly automated clean URL check during the installer, like we previously did on the clean URL setting page (but simplified, and defaulting to clean URLs being enabled if it fails).