Voting starts in March for the Drupal Association Board election.
2 years ago, we changed Drupal's .htaccess URL rewrite rules such that clean URLs do not internally map to a 'q' query string parameter (http://example.com/index.php/foo to index.php, since that is part of the CGI specification (http://www.ietf.org/rfc/rfc3875 section 3.2). Given that both clean and dirty URLs can work without Drupal's legacy "q=" pattern, it is a WTF that we still have so much code in Drupal that both sets and reads PHP's $_GET['q'] variable. Furthermore, this gets in the way of current work to refactor Drupal's request routing logic to leverage Symfony classes (e.g., ), both because Symfony's Request class initializes its path from the URL path (not $_GET['q']), and because we can't reroute the reading of $_GET['q'] to a method call on an appropriate $request object (whereas if all current Drupal code were to call a function like current_path() instead, that function could be progressively iterated to integrate with the appropriate object). Therefore, this issue aims to remove all legacy handling of 'q' as a special query string parameter, and uses current_path() and friends for all path related logic.). Meanwhile, all modern web servers can route URLs like
Doing this also provides the opportunity to remove 'clean_url' as a configuration variable. If the only difference between clean and dirty URLs is a leading 'index.php/', then we can treat that similarly to how we treat the global $base_url / $base_path variables: just like we autodetect if we're serving the 'foo' path at the URL http://example.com/subdirectory/foo rather than at http://example.com/foo, and adjust all URLs accordingly to be relative to 'subdirectory', we can do the same for 'index.php'. The logic is a little different and requires another global variable $script_path, rather than simply appending to $base_path, because URLs to files (e.g., css, js, images, etc.) need to be relative to $base_path while URLs to Drupal paths need to be relative to $base_path . $script_path, but other than that, the essentials of working with relative URLs are the same.
Prior summary that focused on the problems of a 'clean_url' configuration variable
Right now we enable clean URLs in the installer if we can, but then have a bizarre admin screen for checking and enabling the feature, as well as many, many weird hacks in core to support non-clean urls. Image derivative callbacks are one.
Instead of this, we could try to get a more robust clean url check in the installer itself (probably a dedicated .php file so it doesn't require the request to Drupal itself and a full bootstrap, which has also led to a tonne of hacks in the installer), then point people to how to get it enabled if it's not.
Clean URLs should work on 99.9% of web hosts, so it is really going to be people who are running their own servers who run into the issue, and if they're going to run a normal Drupal site with clean URL support they need to fix it anyway.
drush installs etc. are not going to be able to check, but if clean url support works then the site will anyway - and we won't have a crappy variable_get('clean-url') that can go out of sync any more.
What about sites upgrading from D7 and earlier that have legacy content containing links to http://example.com/index.php?q=foo, as well as other sites / search engines / users with bookmarks who have those links? The suggestion in #29 is to require the site to implement a redirect solution, possibly with the help of a contrib module.
PASSED: [[SimpleTest]]: [MySQL] 35,369 pass(es). View
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch interdiff-1183208.patch. Unable to apply patch. See the log in the details link for more information. View
PASSED: [[SimpleTest]]: [MySQL] 35,375 pass(es). View