|
The problem is that the function page_id_and_class in lib/weblib.php assumes that the global $ME, which is the URL of the current page as the web server tells us, start with $CFG->httpswwwroot.
This assumption is false in two situations: 1. The person writing config.php accidentally added a '/' at the end of $CFG->wwwroot, despite the comment in config-dist.php. 2. The sort of situation described in this bug, where there are good technical reasons why $CFG->wwwroot is different from the URLs the moodle server acutally serves. In this case, probably the best place to fix moodle is in the qualified_me function from lib/weblib.php, so that $ME, If you are experiencing this problem, and you can't fix it just by editing $CFG->wwwroot, then you can probably fix it by editing qualified_me. There is now a TODO comment in there, which mentions this bug id ( To improve the situation for now, I have added two admin notifications, that are displayed if the situations 1. or 2. above are detected, with a link here. I have added them to 1.9 and HEAD, do we want them backported further? Tim, THANKS! your advice fixed our site! We are so pleased to have your contribution.
Hi Tim,
We have the same issue and are wondering how to edit the qualified_me function so that $CFG->wwwroot matches $_SERVER? We are running 1.7.1+ What is the point of having to set $CFG->wwwroot and having qualified_me()? The qualified_me() function will always return the wrong URL if Moodle is behind a reverse proxy, load balancer, or SSL terminating proxy. Usually having a configuration variable for an application's base URL is so that you can avoid doing things like qualified_me(), which can't account for a lot of relatively common environments. I have been able to fix all my problems where Moodle redirects to the wrong URL by replacing my qualified_me() function with this:
function qualified_me() { Of course, Moodle still tells me "You have defined $CFG->wwwroot incorrectly in your config.php file. It does not match the URL you are using to access this page. Please correct it, or you will experience strange bugs like Checked the qualified_me function and it was really confusing i think that in order to eliminate the extrange behaviour of moodle when it is behind a https reverse proxy you have to refactor it to something like this:
function qualified_me() { so i created a patch that modifies lib/weblib.php for the Moodle 1.9.2+ (Build: 20080730) I don't really understand why qualified_me integrates the url prefix from within the server variables adding some complexity along the way when you have defined $CFG->wwwroot in config.php to apply this little patch: cd moodle/lib patch -u weblib.php < weblib.patch i hope this is useful I think that this patch (weblib.patch) is the right sort of general approach. However, I am worried that it will not work if, for example, $CFG->wwwroot = 'http://example.com/moodle' - that is, with a path after the server name. Won't me() also contain the /moodle bit?
I acutally think a better long term solution is to completely remove me() and qualified_me() from the code-base (or at least move it to depricatedlib.php). I don't think it is necessary, and I think it is not used in many places anyway. I think you're right, i'm not very experienced on moodle's code but is evident that this function does not make sense it should be removed because it causes more problems that the ones is supposed to solve (whichever they are).
Eventualy most moodle installations are goingo to escale from a single server to some sort of load balancing/failover scheme that is going to be affected by this function. It should not be very hard to do. being simplistic: $ grep -ri 'qualified_me()' * | grep -v function | wc -l only 33 appereances on the whole code base Just wanted to say that as of the latest version of 1.9.x for August 20, 2008, this is still an issue. The 'Affects Versions' part of this bug should reflect this.
This has been a showstopper for us, unfortunately. It has brought an entire summer's worth of work to a halt for us. I'm about to try the patch now, and I sincerely hope that someone can remove this function quickly. I've attached a hack that should work for all sites. However, it's a hack because it forces you to add one more variable to your config.php: wwwserver
For example: This is not meant to fix the issue in Moodle, it's just there to fix the immediate issue for people who are running into this problem. It still needs to be fixed properly in Moodle. I have committed several changes, it should be now possible to use external SSL - the only problem here is that you can not use both http: and https: at the same time - see http://docs.moodle.org/en/masquerading
The setting can be enabled only in config.php, see config-dist,php thanks for the report, please test 2.0dev and reopen if needed! The message
"You have defined $CFG->wwwroot incorrectly in your config.php file. It does not match the URL you are using to access this page. Please correct it, or you will experience strange bugs like now appears on Linux setup of Moodle 2.0 with no apparent reasons. The config.php is visually correct and updted to latest config-dist.php, and Moodle works correctly. Andrea What exactly is in your $CFG->wwwroot and what address did you use to access moodle?
It might be also caused by Pretty sure the regression is caused by $ME rather than $FULLME, going to fix in CVS
Petr,
wwwroot is http://servername/moodle20 and the server is accessed using http://servername/moodle20 No proxies are between servers and clients. Also updated to the latest CVS HEAD as of 20090107 15:05 GMT+1, no changes.
Fixed this in CVS - Petr - please can you review this.
big thanks!
I overlooked these www tests on admin/index.php - I have removed them - the new code in lib/setuplib.php should be much more reliable. Thanks Petr, looks ok now.
Andrea I'm experiencing this again, after an upgrade from 1.8.3+ to 1.9.5+. I've got Apache2 (httpd-2.0.52-38.ent.2), php-5.2.9-1.rs.el4, and RHEL4, and $_SERVER['SERVER_PORT'] is 80 even though I'm clearly connecting via https (and http connections are rewritten by Apache to be https).
I'm planning to just hack around this the same way I did in 1.8.3 - I'll set $protocol = 'https://' toward the end of qualified_me(). I see this is fixed in 2.0 - great. Cheers, For anyone still interested, I was able to get around this issue simply by auto prepending the following php code:
<?php Just added that, and changed $CFG->wwwroot to https:// and we were good to go. I've run into this issue running 1.9.5 behind a Varnish proxy as well. I've found that adding the following to config.php immediately after setting $CFG->wwwroot seems to work:
$_SERVER[SERVER_PORT] = 80; |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
This is what I see:
Page class mapping requested for unknown type: http:--reta.nmsu.edu:16080-moodle-mod-data-view
line 100 of lib/pagelib.php: call to debugging()
line 65 of lib/pagelib.php: call to page_map_class()
line 50 of lib/pagelib.php: call to page_create_object()
line 146 of mod/data/view.php: call to page_create_instance()
Notice: Undefined index: http:--reta.nmsu.edu:16080-moodle-mod-data-view in /Library/WebServer/Documents/reta/moodle/lib/pagelib.php on line 103
Notice: Undefined index: http:--reta.nmsu.edu:16080-moodle-mod-data-view in /Library/WebServer/Documents/reta/moodle/lib/pagelib.php on line 104
Page class mapping for id "http:--reta.nmsu.edu:16080-moodle-mod-data-view" exists but class "" is not defined
line 104 of lib/pagelib.php: call to debugging()
line 65 of lib/pagelib.php: call to page_map_class()
line 50 of lib/pagelib.php: call to page_create_object()
line 146 of mod/data/view.php: call to page_create_instance()
Notice: Undefined index: http:--reta.nmsu.edu:16080-moodle-mod-data-view in /Library/WebServer/Documents/reta/moodle/lib/pagelib.php on line 107
Fatal error: Class name must be a valid object or a string in /Library/WebServer/Documents/reta/moodle/lib/pagelib.php on line 67
I am not running SSL so I am not able to use that work around.
If anyone finds a fix, please advise.