Hello,
I installed Backdrop today and noticed that a "Clean URLs" Doom Loop exists.
Here's the scenario:
Precondition: Your web server configuration is incorrectly set up vis-a-vis enabling Backdrop to load and enact the instructions in its local .htaccess file. This means the following stanza is missing in the web server configuration with respect to the Backdrop website being installed:
# GL 2016-02-16 This setting is necessary for clean URL's in Drupal
# Unihome Setup: <Directory "/var/www/html">
# Multihome Setup: <Directory "/var/www/vhosts/mysite.com/www">
#
<Directory "/full_path_to_your_drupal_installation">
AllowOverride All
</Directory>
Nevertheless, Backdrop will happily install:
- Subject to adjustments to post-unzip but pre-install sites/settings.php
- Subject to adjustments made to post-unzip but pre-install and sites/files
Backdrop will then happily connect to a back-end database:
- Subject to pre-install creation and configuration of a target database and database user
But then a "Doom Loop" in the Administrative GUI will result where it is impossible to enable "Clean URLs", despite the web server configuration having been subsequently corrected:
Reloading the page simply results in a re-iteration of the same failure, though slightly different in form:
This error may have something to do with the fact that fixing the web server configuration behind the scenes instantly brings the instructions within the .htaccess file to bear. The effect is, for reasons as-yet unknown, enabling .htaccess alters the behaviour of Backdrop in such a way that a "Clean URL" is required to access the page that enables "Clean URLs".
This is a paradoxical situation and likely springs from a logical (not technical) error.
How to Escape the "Clean URLs Doom Loop":
Manually convert the "Dirty" URL into a "Clean" URL by replacing ?q= with /:
From:
http://www.mysite.com?q=admin/config/urls/settings
To:
http://www.mysite.com/admin/config/urls/settings
The appropriate page should then result:
Fixing this problem:
- The easiest "fix" for this situation is education (ergo this updated Backdrop specific re-posting).
- The second easiest "fix" would be to simply have the "Clean URL" page to offer both forms of the link ("Dirty" and "Clean") so the Administrator can at least try them out.
- The third easiest "fix" would be to re-program Backdrop so it behaves logically and correctly.
g.
----
Comments
@graham-leach I'm not sure that there is a bug, but I found that I needed all those lines in the vhost for clean urls to work with Backdrop.
I am running D7U3 on CentOS 7 (yes, I am a dinosaur).
On my system, the lines:
RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
Appear in:
/var/www/vhosts/<domain>/web/site/.htaccess
In the following section:
So I did not include them in
/etc/httpd/conf.d/vhosts.conf
As:
Notes:
1) I don't know if BCMS elected not to do the .htaccess thing, or if there is one at the root of your website directory. Could you check please? You might want to check for those instructions in your .htaccess if you have one.
2) I do not use "Require All Granted" in my implementation and it's working just fine for over a decade now. Why are you using it?
3) It looks to me like you may not need the RewriteBase / line, unless you are serving a website with the format www.domain.com/someplace as your URL, which is non-standard, but entirely possible with the RewriteBase parameter set, with:
https://my.domain.com/drupal_7
Acting as the canonical example.
Looking forward to learning more about this situation with you!
g.
----