Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
After I upgraded my site to RC3 it seems like all the links on the site are "broken".
Whenever I click on ANY link, I am just redirected back to the frontpage.
Check it out at http://www.dieinter.net
I don't know where to start looking for what might be causing this.
Is this something with my site, or something with RC3?
Thanks
Jacauc
Comment | File | Size | Author |
---|---|---|---|
#64 | system.module_28.patch | 4.15 KB | webchick |
#63 | system.module_27.patch | 4.07 KB | webchick |
#62 | explicit_clean_url_tester_3.patch | 3.85 KB | chx |
#61 | explicit_clean_url_tester_2.patch | 3.77 KB | chx |
#56 | explicit_clean_url_tester_1.patch | 3.68 KB | chx |
Comments
Comment #1
paddy_deburca CreditAttribution: paddy_deburca commentedI have just visited your site.
I noticed that if I use http://www.dieinter.net/aggregator/sources - I get redirected back to the home page.
But, if I use http://www.dieinter.net/?q=aggregator/sources - I get the desird page.
Can you please check your clean URL settings. I also noticed that I was being redirected back to the home page on page not found - is this an apache setting or have you got a drupal module installed? If it is a drupal module - can you disable it and see what happens?
Comment #2
Uwe Hermann CreditAttribution: Uwe Hermann commentedWhat does your $base_url say?
Comment #3
hunmonk CreditAttribution: hunmonk commentedi seem to recall having this problem when drupal's .htaccess wasn't being read--which is probably an apache config issue. i'm downgrading this to normal for now, as no one else has confirmed. please report back and close if that solves the issue
Comment #4
jacauc CreditAttribution: jacauc commentedMy Base URL is as follows:
$base_url = 'http://www.dieinter.net';
and my .htaccess has a CHMOD permission of 644
The contents of my .htaccess file is:
Can anyone suggest how to get this resolved?
Thanks
jacauc
Comment #5
jacauc CreditAttribution: jacauc commentedI've disabled clean URLs now, and it seems to be ok.
When i try to re-enable it, i get the following message:
It appears your host is not configured correctly for Clean URLs. Please check for ModRewrite support with your administrator.
It has always worked in the past. Strange stuff.
Comment #6
Uwe Hermann CreditAttribution: Uwe Hermann commentedThe first part of the .htaccess file seems to come from gallery, not Drupal. It might interfere...
Comment #7
chx CreditAttribution: chx commentedthen it's a won't fix.
Comment #8
jacauc CreditAttribution: jacauc commentedThis is the part that the Drupal Gallery module inserted.
It has worked before, and I havent changed anything there.
Can anyone assist in getting this problem resolved? (Even if it is not a bug?)
Thanks
jacauc
Comment #9
Michael Hofmockel CreditAttribution: Michael Hofmockel commentedMy problem may be related. (I don't think this is a gallery issue but a Drupal core issue)
I was making a change on the admin/settings page, changing the site name, and "clean urls" failed to load even though I had it working already.
I am running drupal4.7rc3 but not gallery. I can consistently break "clean urls" by just resubmitting the admin/settings page. I get this error:
"It appears your host is not configured correctly for Clean URLs. Please check for ModRewrite support with your administrator."
I then checked phpinfo() to see if apache had not loaded mod_rewrite. Mod_rewrite was loaded fine. Hmmmm.
I then tried to resubmit the settings page and was able to get "clean urls" working again. Took two resubmissions of the settings page to get it to work.
I can however easily break it again by resubmitting the settings page. I can then get it to work again after resubmitting the settings page a few times.
I know little about Drupal core but...
It seems to me there is a check of the .htaccess rewrite rules before accepting the "clean urls" enable change. If this check is flawed it could explain the problem.
Especially if, the check works fine if "clean urls" is disabled but fails if "clean urls" is already enabled.
Comment #10
housetier CreditAttribution: housetier commentedI also experience the error message as in this comment: http://drupal.org/node/59999#comment-92240
Clean URLs work, I just cannot enable them. I know they work, because my bookmarks still work.
Comment #11
kayfish CreditAttribution: kayfish commentedI can also confirm this new problem after a recent upgrade to 4.7 rc3.
All was fine, clean URLs worked, but I cannot enable clean_urls
in my >admin>settings.
I can type in a clean url and it will work. However, all of my menu
links still have 'dirty' urls.
Comment #12
kayfish CreditAttribution: kayfish commentedI think we sort of hijacked this issue, but the bug i just mentioned
seems to be serious. Anyone agree?
Comment #13
BryanSD CreditAttribution: BryanSD commentedThere have been changes made in both the settings.php file and some of the recommended changes for the .htaccess file. If you made no changes to either of the files when you upgraded to RC3, I would recommend taking another look at those files. It may also be that the third-party modules have not taken into account some of the later RC changes.
Comment #14
kayfish CreditAttribution: kayfish commentedThanks Bryan,
I forgot to mention that I also just completed a fresh new RC3 installation and have the same problem.
I think the following issue is related: http://drupal.org/node/60005
Strangely enough, it only seems to happen if I change 'clean url' under >>administrator>settings
when using the bluemarine theme. It doesn't give me a problem when using pushbutton.
The specific error we get is:
>Home » administer
>settings
>General configuration options for your site.
>Set up the name of the site, e-mail address used in mail-outs, clean URL options, caching, etc.
>It appears your host is not configured correctly for Clean URLs. Please check for ModRewrite support with your administrator.
>The configuration options have been saved.
Comment #15
Steven CreditAttribution: Steven commentedI've tested the clean URL autodetection in HEAD with both Bluemarine and Pushbutton. They both work fine.
The first issue reported here is likely the consequence of mixing in the Gallery rewrite rules. That's not a Drupal issue.
As for the second issue, we need more information. Is your Drupal site installed in a subdirectory? If so, did you edit .htaccess' RewriteBase setting? If the clean URL setting won't allow itself to be turned on, can you access your Drupal pages manually without the
?q=
? If yes, then there is a Drupal bug. But more likely, this will not work either. This means that the .htaccess file is simply not being processed.In that case, please consult the existing documentation on the requirements for Clean URLs here on Drupal.org.
I'm marking this "won'tfix". Please re-open if you have new information.
Comment #16
kayfish CreditAttribution: kayfish commentedThanks again Steve,
I sure hope that I'm not doing something stupid, but I'm pretty sure there is a bug.
I don't want to make work for anyone.
Here are a few things i've confirmed.
- My .htaccess is being processed.
RewriteCond %{HTTP_HOST} !^temp.server263\.com$ [NC]
RewriteRule .* http://temp.server263.com/ [L,R=301]
I know its being processed because I previously had an error in
one of these lines and it balked.
- RewriteBase is -not- defined.
- My website is not in a subdirectory.
- Both of the following links function perfectly:
node/28
?q=node/28
Perhaps it is a .htaccess/server configuration quirk, but I have other sucessful
installations with the same hosting service.
I'll be glad to try something else if you have any ideas. Otherwise, I can just
live with it until 4.7 is released and try again.
Thanks again
Comment #17
moshe weitzman CreditAttribution: moshe weitzman commentedthis is now afflicting groups.drupal.org if any admin wants to take a look. manually entering a clean url works fine but admin/settings page shut them off and wants to keep them off.
Comment #18
moshe weitzman CreditAttribution: moshe weitzman commentedi manually set my clean_url variable to 1 on groups.drupal.org so that site does not have to suffer. to see the bug again, try to submit the settings page on groups site.
Comment #19
Michael Hofmockel CreditAttribution: Michael Hofmockel commentedHaving same problem.
Fresh install of 4.7rc3 in root directory.
I successfully setup clean urls. Then when I resubmit the settings page with out any changes clean urls returns an error.
"It appears your host is not configured correctly for Clean URLs. Please check for ModRewrite support with your administrator."
Very consistent.
Menus return to dirty urls but clean urls can be entered manually with success.
I can turn it back on with out erro but only from another computer(IP#). Very consistent.
.htaccess is loading fine and is 4.7rc3 version.
Bug for sure!
Comment #20
markus_petrux CreditAttribution: markus_petrux commentedIMHO, this is not a bug in Drupal per se, but a mod_rewrite problem. Probably different issues for anyone reporting problems here.
For instance, the topic starter does have the Drupal mod_rewrite rules commented. In addition to that, he has other rules (generated from a control panel maybe). Maybe a misunderstanding when installing Gallery?
moshes: is there anything special at groups.drupal.org ? could you please post the .htaccess file?
Anyway, I'm not sure if a Drupal issue is the best place to discuss this... AFAICT, Drupal works with its own rules, or is there anyone here having problems with a default Drupal installation with no add-ons?
Comment #21
moshe weitzman CreditAttribution: moshe weitzman commentedmarkus - groups.druapl.org has made no changes to core at all, including .htaccess. this could be an apache problem, but i doubt it. we should treat it like it isn't and find root cause.
Comment #22
moshe weitzman CreditAttribution: moshe weitzman commentedthe cleanurl checker does some tricky form api code and i suspect that there is a problem there. my guess.
Comment #23
markus_petrux CreditAttribution: markus_petrux commentedhm... the image used in system module to check for clean_urls doesn't use base_path(). This is a bug.
Maybe that isn't enough?
Comment #24
housetier CreditAttribution: housetier commentedI don't think it related to apache or its mod_rewrite: I use lighttpd and experience the same problems as other people.
Comment #25
markus_petrux CreditAttribution: markus_petrux commentedsorry, I've been wrong.
Comment #26
moshe weitzman CreditAttribution: moshe weitzman commentedcan we not use url() here with $absolute=TRUE? i also think something more is happenning here. will test when i can.
Comment #27
dopry CreditAttribution: dopry commentedI seriously doubt this is an Apache Problem. If you think it is use RewriteLog to gather some info about what is going on instead of grasping at straws. I think it is more likely that drupal is not properly testing if clean_urls are working. Maybe the way the #pre_render => system_test_clean_url gets called , is unsetting the clean_url_ok variable in some cases. As I'm not experiencing this problem I can't really trouble shoot it first hand.
.darrel.
Comment #28
jacauc CreditAttribution: jacauc commentedI'm back again... sorry, had a few days of travelling.
I am still having the exact same problem similar to the one experienced by the others:
"It appears your host is not configured correctly for Clean URLs. Please check for ModRewrite support with your administrator."
Marcus: you mentioned:
Can you explain what you mean by "...does have the rerwite rules commented"? Shouldn't this be automatically uncommented by drupal if required? I did not change anything in the .htaccess for weeks, and the problem came up after I upgraded to RC3.
The first part of my .htaccess is part of the installation of the Gallery drupal module, and the final part is an addon domain.
Both these parts defnitely did not change recently.
Something's defnitely still fishy. I'm running www.dieinter.net without clean URLs for now. Please let me know if there's anything I can try. I am not a programmer, but I am comfortable with all the aspects involved, so I can be a guinea-pig if required.
Thanks
jacauc
Comment #29
markus_petrux CreditAttribution: markus_petrux commentedI mean the part of your .htaccess content, posted in comment #4, that is labelled
Apache/PHP/Drupal settings:
. Here live all mod_rewrite rules related to Drupal, but they all are prefixed with a hash (ie. commented).This is (basically) the reason why I started to think the problem was not related to Drupal, but a mod_rewrite issue.
If it isn't a mod_rewrite issue, it looks like there is something going on with the way clean_ulrs are checked.
For what it worths, if I understand this well now (not the case in one of my previous posts), the implemented method to check for clean urls, does the following:
clean_url_ok
). This routine is supposed to be invoked before the form is sent to the browser.index.php?q=system/test-clean-url/a-20-chars-random-string.png
. The request for this image is supposed to invoke a Drupal menu handler that will enable the flagclean_url_ok
, if the mod_rewrite rules are working ok.clean_url_ok
will remain disabled.clean_url_ok
is checked by a routine that's processed when the form is submitted. If at that time, the flagclean_url_ok
is still disabled, it shows the "It appears your host is not configured correctly for Clean URLs. Please check forModRewrite
support with your administrator." message and the real flag that governs clean urls (clean_url
) in Drupal gets disabled.It's a nice method recently implemented (IIRC by Steven). It normally works. Otherwise, everyone would be complaing about broken clean urls. So what happens?
ok, to get clean urls enabled, the flag
clean_url_ok
must be enabled when the form is submitted. What can make this flag to be disabled?a) mod_rewrite rules not working? Probably, the most common issue.
b) the image is not requested by the browser?
c) any other ideas???
If b), it might depend on the browser (or its cache settings?), or if page cache is enabled in Drupal, or...
Comment #30
archetwist CreditAttribution: archetwist commentedI just want to say that after every update since (approximately) beta2 I get the error message
followed by deactivation of the Clean URLs. But then i *can* reenable Clean URLs without a problem.
Comment #31
chx CreditAttribution: chx commentedJust a quick note. I had problems with switching clean URLs on, and after setting AllowOverride All in httpd.conf I needed to restart Apache2 , reload was not enough. Your mileage may wary.
Comment #32
Rosamunda CreditAttribution: Rosamunda commentedI´ve the same issue... Just wanted to add that I have the RC3 Version, and it works OK in a MySQL v.4.0 server, but won´t work on the MySQL 4.1 server... There´s the same php version... just the MySQL changed...
Anyway, I´m gonna install the RC4 version just to look if this problem is solved with it... :-)
Rosamunda
Buenos Aires | Argentina
www.ligadelconsorcista.org
Comment #33
Rosamunda CreditAttribution: Rosamunda commentedIt´s the same with RC4...
Comment #34
markus_petrux CreditAttribution: markus_petrux commentedDo you mean the same exact site works in MySQL 4.0, but not in 4.1. ...or there are other differences?
I'm running on MySQL 4.1 with no problems.
Comment #35
jacauc CreditAttribution: jacauc commentedFor what it's worth I am also running on MySQL 4.1:
...and hosting on Bluehost
Comment #36
chx CreditAttribution: chx commentedMarkus, nice writeup. The base of the current checker comes from me http://drupal.org/node/19515 with lots of help from Steven and the form API port is from again Steven. I only mention this to make it clear -- I know very well some design goals. Let's see the 4.6 version and then the form API port. To make caching impossible for Drupal, proxies and browsers I have choosen a random named image. All three does caching based on the URL. So it's impossible to be a caching issue. It's even commented so.
Next, let's see the form API workflow: it's alter-build-(validate-submit)-pre render-render. So, when you first call up the form, the validate-submit part won't get called but pre render is called unconditionally. Used as a pre render call, the system_test_clean_url function clears the test variable. But during render, when the pseudo image is requested, the same system_test_clean_url is called as a page callback and as such it gets the random image name as a parameter and then it sets the clean_url_ok variable to 1. So, when you see the form, the clean_url_ok variable indeed tells the system whether clean URLs are OK or not (unless, of course you have images off). When you press Save settings, the submit callback runs before the pre render and that checks the clean_url_ok.
So far, the only thing that makes this possible is the image stuff. Markus' patch is wrong, because $base_url contains base_path() and all. base_path() would be necessary only if we would use /system but we use $base_url . /system. I am running Drupal in a subdir (with PHP5 and MySQL5 -- worst case scenario).
So, the only thing I can imagine is the image somehow not requested. Here is a patch for testing purposes only. Do you see a Druplicon after the Clean URLs radios?
Comment #37
chx CreditAttribution: chx commentedSo, steps to test. Apply my patch, go to system/test-clean-url/1 , you will see a Druplicon. If you get an error from the server, then clean URLs do not work. If you get an empty page then you have not applied the patch. Now go to system/settings, and look at Clean URLs, you should see the Druplicon again.
If you do see a Druplicon at system/test-clean-url/1 and you do not see that on system/settings then and only then we have an issue with Drupal. Otherwise, it's an issue with your server and/or your browser, your proxies and hell knows what else.
Comment #38
jacauc CreditAttribution: jacauc commentedOK, I've done the steps as you described. I see the druplicon if I go to "?q=system/test-clean-url/1"
You mentioned
Now go to <b>system/settings</b>, and look at Clean URLs, you should see the Druplicon again.
I assume you meant admin/settings right?
I went there but I don't know where to look for the druplicon, and I don't see it under the "general settings" section.
I've tried again to enable clean URLs, but I still get the message:
Comment #39
Rosamunda CreditAttribution: Rosamunda commentedYes, the system config is the same, except for the MySQL version...
Thanks for the patch!
As I don´t know how to patch a file I´ll better wait until someone adds the patched version to the original file... :-)
(I know, I know, but no, I didn´t learn how to patch yet... and yes, I know it´s easy, but couldn´t do it right yet...)
Rosamunda
Comment #40
chx CreditAttribution: chx commented*sigh* if your site is http://mysite.com then go to http://mysite.com/system/test-clean-url/1 to check for your Druplicon first. You tested whether you have succeeded in applying my patch. And yes, next I meant http://mysite.com/admin/settings. Attached is the screenshot.
Comment #41
markus_petrux CreditAttribution: markus_petrux commentedhmm... what about using an IFrame instead of an image? Maybe that way we could print a message (within the IFrame) so it would be easier to figure out if it is really invoked.
Let's admins would have to use an IFrame capable browse to enable clean URLs, oh well... :D
Comment #42
chx CreditAttribution: chx commentediframe -1 -- it's filtered by ad filters and who knows what else. images are more safe.
Comment #43
markus_petrux CreditAttribution: markus_petrux commentedok, so... why use a hidden image?
If it was visible, it would be easier to isolate these problems, maybe. :D
Comment #44
qqqq CreditAttribution: qqqq commentedused that patch, I can't see Druplicon on http://mysite.com/system/test-clean-url/1.
I already change clean_url_ok="b:1;" in db.
Comment #45
chx CreditAttribution: chx commentedif you do not see a Druplicon on that URL then there is nothing that Drupal can do. Your Apache is not configured right.
Comment #46
qqqq CreditAttribution: qqqq commentedI already tested, rewrite is on and working.
Comment #47
moshe weitzman CreditAttribution: moshe weitzman commentedi have applied chx patch to groups.drupal.org and i see the druplicon on both the test url and the admin/settings page. yet i submit the form for any reason and drupal rudely disables clean urls. considering that this site runs on the same hardware as drupal.org, i think we can rule out server config. i don't use proxies and my browsers are pretty standard. i don't agree is the conclusion that this is a local problem.
So, why would the clean url test succeed but drupal still refuse to enable clean urls?
Some observations:
- I don't really understand how this ever works. We cache $conf for the duration of a request. Sure, the clean url test menu callback sets value to 1 and causes a cache delete. but thats in separate request from the original form submission and thus is invisible where it matters.
- Even if the variable_set(clean_url_ok, 1) *is* effective during the request which issues the POST, don't we have a race condition here where between the menu callback request and the form submit processing? Seems to me that we can call the submit function before the out of band image request has processed.
- We are performing validation during the submit function for this form. Thats not ideal. Probably unrelated to our problems though.
- We have some unneeded validation code in system_settings_form(). fapi handles this on its own now:
if (!empty($_POST) && form_get_errors()) {
drupal_set_message(t('The settings have not been saved because of the errors.'), 'error');
}
changing title because it is quite clear that mod_rewrite() is working properly on everyone's servers.
Comment #48
jacauc CreditAttribution: jacauc commentedchx, are you saying that I should test it by going to "http://mysite.com/system/test-clean-url/1" (and NOT to "http://www.mysite.com/?q=system/test-clean-url/1" - If I go to this URL i see the druplicon)
If I do that, I am redirected back to the frontpage (possibly because of a 404)
Should I manually enable clean URLs in the DB? (and if so, how/where?)
Thanks
jacauc
Comment #49
jacauc CreditAttribution: jacauc commentedSorry, just want to clarify what I said in my previous post:
"http://mysite.com/system/test-clean-url/1" - Gets redirected back to frontpage (Prabably because of 404
"http://www.mysite.com/?q=system/test-clean-url/1" - If I go to this URL i see the druplicon
"http://www.mysite.com/?q=admin/settings" - I don't see any druplicon and also when I submit with Clean URLs enabled I get the "It appears your host is not configured correctly for Clean URLs......." message
Where can I manually enable clean URLs in the DB?
Comment #50
qqqq CreditAttribution: qqqq commentedin table variable, you can update clean_url_ok to b:1
sql: update variable set value='b:1' where name='clean_url_ok';
Comment #51
chx CreditAttribution: chx commentedSo you say the image does not load soon enough? That can be helped of... if you happen to misconfigure the server under a running Drupal then this may cause some problems because we do not reset the variable in pre_render any more, but I do not deem this too big a problem -- if you happen to do that, you need to force clean_url to 0 in $conf anyways.
Comment #52
chx CreditAttribution: chx commentedThis is better. uid 1 edits are rare enough that this won't be a serious hit to any Drupal site. Esp. that if you have clean_urls on this won't fire any more.
The basic idea is that when user 1 initially edits his account the image gets loaded. That's early enough.
Comment #53
chx CreditAttribution: chx commentedmoshe suggested something. working on it.
Comment #54
chx CreditAttribution: chx commentedHere is a new, expicit clean URL tester.
Comment #55
chx CreditAttribution: chx commentedWording cleanup from Moshe.
Comment #56
chx CreditAttribution: chx commentedRemoved the second def.value on Moshe's advice.
Comment #57
moshe weitzman CreditAttribution: moshe weitzman commentedtested on groups site. works. code is much much less magical which is good.
Comment #58
jacauc CreditAttribution: jacauc commentedStill, after applying the patch, the clean URLs didn't work, and the link on the settings page took me back to the frontpage.
I have now tried something manually, and it seems to have worked though:
I enabled clean URLs in the DB as explained above, and then I manually changed the end part of my .htaccess file from:
To:
Everything works fine now. ...but shouldn't drupal have added/changed this to my .htaccess automatically? (I don't think it's a permissions thing either because at one stage my .htaccess was chmod'ed to 666)
Comment #59
chx CreditAttribution: chx commentedjacauc , your modrewrite settings are obviously wrong. and I won't fix them in this issue.
Comment #60
Dries CreditAttribution: Dries commentedCommitted to CVS HEAD.
Comment #61
chx CreditAttribution: chx commentedComment #62
chx CreditAttribution: chx commentedComment #63
webchickJust some minor (what are hopefully) improvements on descriptions.
Comment #64
webchickForgot to concatenate the second description.
Comment #65
Gerhard Killesreiter CreditAttribution: Gerhard Killesreiter commentedapplied to 4.7 branch
Comment #66
drummComment #67
(not verified) CreditAttribution: commented