Moodle

I too am experiencing this same error message, however it is only affecting the chat and database modules.

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.

This is an issue with pagelib. It happens when $CFG->wwwroot does not match what is in one of the $_SERVER variables, if I remember what we found out when I helped someone diagnose this in the forums ages ago.

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,
does always start with lib/weblib.php. However, I am not sure of the best way to do this.

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 (MDL-11061), it's about line 270, so you should be able to find the bit to edit.

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+
Apache/2.2.4 (Unix) PHP/5.2.3
mysql 5.0.41
SSL

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() {
global $CFG;
return $CFG->wwwroot;
}

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 MDL-11061." which is just flat-out wrong.

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() {
global $CFG;
return $CFG->wwwroot . 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
33

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:
$CFG->wwwroot = 'https://example.com/moodle';
$CFG->wwwserver = 'https://example.com';

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 MDL-11061."

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 MDL-17802, could you please try to update?

Pretty sure the regression is caused by $ME rather than $FULLME, going to fix in CVS

Petr,

wwwroot is http://servername/moodle20 (no SSL at all)

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 just want to thank Francois for saving my a** with this issue on Moodle 1.9.3+. We implemented full SSL, then no quizzes, then people freaking out, then Ben learning how to apply patches for the first time Thanks!

Ben Frueh

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,
Matt

For anyone still interested, I was able to get around this issue simply by auto prepending the following php code:

<?php
$_SERVER['SERVER_PORT'] = 443;
?>

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;

I know this has been fixed in 2.0, but I encountered a problem in 1.9.13 when we enabled SSL on login (about time!), and my solution may be of use for people still running 1.9.

With SSL enabled the id attribute of the body tag on the course view page changed from id="course-view" to something like id="http:--example.com-course-view" - which broke the CSS on the page.

With some digging I found that the code in qualified_me() uses $_SERVER['SERVER_PORT'] to determine if the protcol is http or https, but by default Apache doesn't necessarily set it to the correct value. In my case https login was over port 443, whilst everything else is http over port 80 - but Apache was reporting 443 for everything.

Solution: in the VirtualHost section for http (80), include the directive "UseCanonicalPhysicalPort On", which makes Apache use the physical port for that request. (http://httpd.apache.org/docs/current/mod/core.html#usecanonicalphysicalport)

HTH.