Moodle in English: The case of the (not so) missing YUI

I have spent hours and hours on this problem and would dearly love some help!

The problem: The Moodle menus don't work (along with other symptoms).

Configuration: Dedicated server Windows 2008 Web Edition, IIS7, PHP 5.3.6, MySQL 5.5.14, Moodle 2.1+ (Build: 20110719) (in fact any build since 20110701 - I've tried them all, with the same result). Client: Firefox 5 with Firebug. Also, just in case Firebug is introducing a problem, the run-time sypmtoms are the same in IE9. And for comparison I have Moodle 2 installed and running well on a local Vista PC with IIS7.

yui_combo.php files not found

The trace from Firebug tells me that everything is OK except for the YUI calls, and the Console trace follows up with a "YUI is not defined" error (its hard to find, but YUI is defined in a js file somewhere).

But the yui_combo.ph file is there, and its server permissions are the same as for the other files. So after some excrutiating investigation, a bit of code has been inserted in moodle\lib\yui\phploader\phploader\loader.php, which is where the action takes place (as far as I can tell). Here's the code for the CSS calls, for the four parameters of the first call to yui_combo.php:

if ($type == YUI_CSS) {
   $myCombo = "C:/inetpub/wwwroot/moodle/theme/yui_combo.php";
   echo("<BR/>File permission for $myCombo: ".decoct(fileperms($myCombo)));
   $myBase = "C:/inetpub/wwwroot/moodle/lib/yui/";
   $perms =decoct(fileperms($myBase.$pathToModule));
   echo("<BR/>Module permissions for $myBase/$pathToModule: $perms ");
   $myArr = stat($myBase.$pathToModule);
   echo("<BR/>File size of $myBase/$pathToModule: ".$myArr[7]." bytes<BR/>");

The second and third lines are looking for permissions of yui_combo.php. The remainder looks for (a) the file permissions of the four YUI CSS files, and (b) the size of the CSS files.

Here's the result, clipped from the Moodle front page:

File permission for C:/inetpub/wwwroot/moodle/theme/yui_combo.php: 100666
Module permissions for C:/inetpub/wwwroot/moodle/lib/yui//3.2.0/build/cssreset/reset-min.css: 100666
File size of C:/inetpub/wwwroot/moodle/lib/yui//3.2.0/build/cssreset/reset-min.css: 859 bytes

File permission for C:/inetpub/wwwroot/moodle/theme/yui_combo.php: 100666
Module permissions for C:/inetpub/wwwroot/moodle/lib/yui//3.2.0/build/cssfonts/fonts-min.css: 100666
File size of C:/inetpub/wwwroot/moodle/lib/yui//3.2.0/build/cssfonts/fonts-min.css: 437 bytes

File permission for C:/inetpub/wwwroot/moodle/theme/yui_combo.php: 100666
Module permissions for C:/inetpub/wwwroot/moodle/lib/yui//3.2.0/build/cssgrids/grids-min.css: 100666
File size of C:/inetpub/wwwroot/moodle/lib/yui//3.2.0/build/cssgrids/grids-min.css: 1458 bytes

File permission for C:/inetpub/wwwroot/moodle/theme/yui_combo.php: 100666
Module permissions for C:/inetpub/wwwroot/moodle/lib/yui//3.2.0/build/cssbase/base-min.css: 100666
File size of C:/inetpub/wwwroot/moodle/lib/yui//3.2.0/build/cssbase/base-min.css: 761 bytes

As I read this, yui_combo.php and the four CSS files have read+write permissions as seen by the IIS7 Application User (the write permission is hopefully unnecessary but was assigned so the Moodle installer could set up the data folder - but that's a different issue).

And the files sizes of the four CSS files are 859, 437, 1458 and 761 bytes, which checks out exactly on the server.

So some debug code tells me the files are there, reporting OK file permissions and OK file sizes.

So why does the run-time report a 404 error for these files? I'm starting to choke on this!

Average of ratings: -

Re: The case of the (not so) missing YUI

by Howard Miller - Wednesday, 27 July 2011, 4:58 PM

I know next to nothing about Windows, however, have you run your site with developer debugging turned on and checked the web server logs? If Moodle is tripping up loading the includes the reason for it might turn up there.

Also - are you absolutely sure there is nothing tripping up your web server (for example a rogue .htaccess file left there from some other/previous application)?

Average of ratings: -

Re: The case of the (not so) missing YUI

by Ian Wright - Wednesday, 27 July 2011, 5:13 PM

Thanks for the quick response, Howard.

.htaccess is an Apache thing? IIS doesn't natively use .htaccess files.

Inability to get access to the debugger setting is one of the menu symptoms, but I have got to it using Search. But the debugger doesn't throw any messages.

Average of ratings: -

Re: The case of the (not so) missing YUI

by Howard Miller - Wednesday, 27 July 2011, 5:37 PM

And what's in the logs? You shouldn't get a 404 error without something getting logged.

BTW... If you have a dig through Debugging (and in config-dist.php) you can add lines to your config.php file that force debugging on.

I don't absolutely nothing about IIS so can't comment, but I have witnessed instances of servers being (inadvertently) set up to block certain files. This can't be the case if the machine has just been rebuilt, of course.

EDIT:
The only thing that I can see that was fixed recently in that area was MDL-28440. It *could* be a bug I suppose. Anyway, it's worth grabbing the latest weekly.

Average of ratings: -

Re: The case of the (not so) missing YUI

by Ian Wright - Wednesday, 27 July 2011, 7:36 PM

The log indicates a bit of contrary evidence that I don't quite understand.

Here's a call to yui_combo.php with the CSS parameters, that gets a 500 error (not the 404 error reported by Firebug).

2011-07-27 00:19:13 77.68.60.254 GET /theme/yui_combo.php 3.2.0/build/cssreset/reset-min.css&3.2.0/build/cssfonts/fonts-min.css&3.2.0/build/cssgrids/grids-min.css&3.2.0/build/cssbase/base-min.css 80 - 121.212.249.184 Mozilla/5.0+(Windows+NT+6.0;+rv:5.0)+Gecko/20100101+Firefox/5.0 500 0 0 374

But here's a call to one of the CSS files that's 200 OK - but are these files not called via yui_combo.php?

2011-07-27 01:02:05 77.68.60.254 GET /lib/yui/3.2.0/build/cssfonts/fonts-min.css - 80 - 121.212.249.184 Mozilla/5.0+(Windows+NT+6.0;+rv:5.0)+Gecko/20100101+Firefox/5.0 200 0 0 390

How come the CSS file gets a 200 status if yui_combo.php is in error?

The server is configured to send detailed errors for local requests and custom error pages for remote requests, so I presume that the 500 status for the yui_combo.php call means a server-side processing error ("There is a problem with the resource you are looking for, and it cannot be
displayed.") And then, I know that in some cases (e.g. if parameters are empty), the Moodle code is written to throw a synthetic FNF error, which is a bit misleading.

There's more to this than meets my eye!

Average of ratings: -

Re: The case of the (not so) missing YUI

by Howard Miller - Wednesday, 27 July 2011, 8:21 PM

Well, in no particular order...

Those log entries look like 'access' logs (excuse Apache parlance if it does not apply) rather than error logs. A 500 error can be bad news (a non-specific error) but I would expect the *error* log to contain specific information about the cause of the error. This will be vital information for you. Are you sure you are looking in the right place?

You are starting to loose me a bit after this..

The file that works isn't a javascript file and isn't in the YUI file area. I'm not sure why you think it has anything to do with the problem?

Lastly - I have no idea what you mean when you say a "synthetic FNF error" (new term on me, sorry) but the *only* errors that the server can log are server errors. It can't log errors that may have occurred on the client. Sorry, if this isn't what you are getting at.

A long shot.... but have you completed basic setup of your server. Have you gone through php.ini and checked the settings for minimum Moodle requirements? At the very least the maximum script memory will need increasing (a lot). It could be something as "simple" as that. Resource limits of any kind are a classic for weird errors.

EDIT:
The penny dropped, "File Not Found". Well, one would hope that Moodle would check for missing files that it expects. In all cases I have seen it throws an exception. That gives you normal PHP error handling - subject to (again) your php.ini settings and the Debugging settings in Moodle.

Average of ratings: -

Re: The case of the (not so) missing YUI

by Ian Wright - Thursday, 28 July 2011, 7:17 AM

Thanks, Howard.

IIS7 normally just keeps access logs, which include the request status. It is possible to enable Failed-Request Tracing for the site, which writes data to inetpub\FailedReqLogFiles\. I did that in a previous iteration of this problem (before I rebuilt the server) but there was simply too much information (XML, with which I am OK) that never told me what was a server problem. (There's a good description of this at http://mvolo.com/blogs/serverside/archive/2007/07/26/Troubleshoot-IIS7-errors-like-a-pro.aspx

The CSS log file entry is one that is called from the yui package; the full path on my server is C:\inetpub\wwwroot\moodle\lib\yui\3.2.0\build\cssfonts\fonts-min.css. Why I think its relevant is because its a file that is supposed to be pulled by via yui_combo.php (its the second parameter of the query string in the first red trace in the image at the top of this post).

The "synthetic FNF error" was a bit obscure, I guess. I was referring to yui_combo.php line 32 (and similar for line 44):

if (!$parts = combo_params()) {
combo_not_found();
}

and at line 164:

function combo_not_found() {
header('HTTP/1.0 404 not found');
die('Combo resource not found, sorry.');
}

I think my server is properly set up, and I've compared the IIS settings with a local installation running on Vista (some features are a bit different). And I've waded through php.ini. The maximum script memory is 128MB.

BTW, your probing is welcome - clearly there's something wrong somewhere, and I'm about to follow through Petr Skoda's comments. Maybe this problem would never have come up if I'd stayed with Linux, but then I would probably still be climbing that near-vertical learning curve while trying to figure out why all those repo routines weren't working!

Average of ratings: -

Re: The case of the (not so) missing YUI

by Ian Wright - Wednesday, 27 July 2011, 5:15 PM

...and after wrestling with this for a few days, I rebuilt the server (as in reinstalled everything from the OS up), fully expecting that a clean installation of Moodle would work just fine. It doesn't.

Average of ratings: -

Re: The case of the (not so) missing YUI

by Mary Evans - Wednesday, 27 July 2011, 7:58 PM

Hello again Ian,

I see you are still struggling with this! I 'm going to see if I can up the stakes on MDL-28382 and assign it to Pete Skoda, as this seems to be an issue that needs resolving. This way he will get to read it and also, if need be assign to someone to look at. And if I get told off for doing this, well I can handle that too! LOL

Is this related?
In another of your posts, which I found this morning, http://moodle.org/mod/forum/discuss.php?d=170544 - can you verify that what the last comment asks is not casuing this latest problem?

Cheers

Mary

Average of ratings: Useful (1)

Re: The case of the (not so) missing YUI

by Ian Wright - Wednesday, 27 July 2011, 8:19 PM

Thank you lots, Mary.

The 170544 thread was all about a CentOS 5 installation, but as time-and-a-half went by I decided that the benefits of a Linux server were far outweighed by the time it was taking to achieve results. So I rebuilt the server with MS Server 2008 (The ISP I use allows a rebuild with whatever OS they have on offer, and I've always used Windows/IIS.) So its actually the same hardware and same domain name, but logically a new machine.

Thanks again, ATB

Ian

Average of ratings: -

Re: The case of the (not so) missing YUI

by Mary Evans - Wednesday, 27 July 2011, 8:59 PM

OK...here's the lowdown on the MDL tracker.

This is what Pete Skoda says on the subject...

Hello, please do not assign any bugs to me, I will not have time to work on this in the near future. I assign bugs to myself only when I am really planning to work on it in the next 2 weeks. As a workaround you can try to disable the yui combo loading in the admin settings ($CFG->yuicomboloading = false I can not reproduce/diagnose this problem on my test servers, sorry. Could it be IIS specific problem or just a configuration issue?

So...back to square 1...

I tried...and no harm in that...

Mary

Average of ratings: -

Re: The case of the (not so) missing YUI

by Howard Miller - Wednesday, 27 July 2011, 9:04 PM

If nothing else you have "outed" another "secret" $CFG setting that is not mentioned in config-dist.php

Average of ratings: -

Re: The case of the (not so) missing YUI

by Petr Skoda - Wednesday, 27 July 2011, 10:19 PM

Next time please search the admin settings first, the yuicomboloading setting is on the "AJAX and Javascript" page. Another workaround might be the "Use online YUI libraries" setting, but I am afraid something is wrong in these installs and some other problems might appear elsewhere.

Average of ratings: -

Re: The case of the (not so) missing YUI

by Howard Miller - Wednesday, 27 July 2011, 10:21 PM

Ha ha

I had a bad feeling when I was typing that..........

Average of ratings: -

Re: The case of the (not so) missing YUI

by Ian Wright - Thursday, 28 July 2011, 7:33 AM

Thanks Petr.

AJAX is enabled. I agree about not using the online YUI libraries - my objective is to get this running as it should, with no kluges. I'll follow up your comments on MDL-28382

Average of ratings: -

Re: The case of the (not so) missing YUI

by Howard Miller - Wednesday, 27 July 2011, 8:24 PM

Mary - unless you know other people are having the same problem I'm yet to be convinced that this stacks up as a reproducable bug. I think the jury is still out on that one.

The other report seemed to be about the well-worn 'open basedir' (closely related to 'safe mode') problem. This is old news really. Interestingly, that is not (AFAIK) a default php.ini setting on any installation I have seen.

This is the first time I have heard of someone giving up on Linux and moving to Windows though. Greater pain, surely

Average of ratings: -

Re: The case of the (not so) missing YUI

by Mary Evans - Wednesday, 27 July 2011, 9:01 PM

Yes...I know Howard, but even so, I have heard there are probs with Moodle2.1 on Linux now!!!

Mary

Average of ratings: -

Re: The case of the (not so) missing YUI

by Ian Wright - Friday, 29 July 2011, 6:02 AM

SOLVED (subject to detailed review).

In the server described (dedicated Windows 2008 x64 Web Edition with IIS7) the value of $_SERVER['REQUEST_URI'] was not handled correctly in the error handler for yui_combo.php, returning a misleading 404 error.

Interestingly, IIS7 in Vista Business doesn't have this problem.

But it's hard to believe that the dedicated server is unique in this respect, and I suspect many installation issues have their root in this behaviour.

Average of ratings: -

Re: The case of the (not so) missing YUI

by Matteo Scaramuccia - Friday, 29 July 2011, 8:02 AM

Hi Ian,
maybe http://support.microsoft.com/kb/954946 could be a solution?

BTW it sounds a fix should be also evaluated in MDL-28382, having found different (from what expected in Apache) behaviours (at least 2: empty|w/o QS) for REQUEST_URI in IIS: maybe reverting the order of the current if...then...else or removing the 1^st block.

Matteo

Average of ratings: Useful (1)

Re: The case of the (not so) missing YUI

by Ian Wright - Friday, 29 July 2011, 8:34 AM

Thanks, Matteo. I think you're right on the button with the MS hotfix article - wouldn't it be nice to know what to look for right at the outset!

Having spent more time on this issue than any other, IMO the error handling in this particular area warrants very precise error messaging. By default YUI is critical to Moodle administration, and while the 404 error mechanism was identified fairly early in the process, it did point towards server errors when there wasn't any (apart from the incomplete URI string, which doesn't show as an error).

Also, I note that MS recommend not using the hotfix and waiting until it is incorporated in a routine update.

Average of ratings: -

Re: The case of the (not so) missing YUI

by Visvanath Ratnaweera - Monday, 14 March 2016, 12:42 PM

Hi Ian

You decided:
> that the benefits of a Linux server were far outweighed by the time it was taking to achieve results.

Yes, yes. You noted too:
> that MS recommend not using the hotfix and waiting until it is incorporated in a routine update.

P.S. I know this is an old thread and Ian has left in Oct 2011, still SCNR.

Average of ratings: -

Re: The case of the (not so) missing YUI

by Shirley Concepción - Monday, 14 March 2016, 1:27 AM

I had this same problem, but my server was under Nginx Debian 8.0.

The solution was to add:

rewrite ^ / (* \ php..) (/) $ / $ 1 file = / $ 3 last (. *);

in nginx configuration. For example:

server {

server_name example.com www.example.com;

listen 80;

root / home / example / public;

rewrite ^ / (* \ php..) (/) $ / $ 1 file = / $ 3 last (. *);

index.htm index.html index.php index;

....

Average of ratings: -

Installing and upgrading help

The case of the (not so) missing YUI

The case of the (not so) missing YUI

Re: The case of the (not so) missing YUI

Re: The case of the (not so) missing YUI

Re: The case of the (not so) missing YUI

Re: The case of the (not so) missing YUI

Re: The case of the (not so) missing YUI

Re: The case of the (not so) missing YUI

Re: The case of the (not so) missing YUI

Re: The case of the (not so) missing YUI

Re: The case of the (not so) missing YUI

Re: The case of the (not so) missing YUI

Re: The case of the (not so) missing YUI

Re: The case of the (not so) missing YUI

Re: The case of the (not so) missing YUI

Re: The case of the (not so) missing YUI

Re: The case of the (not so) missing YUI

Re: The case of the (not so) missing YUI

Re: The case of the (not so) missing YUI

Re: The case of the (not so) missing YUI

Re: The case of the (not so) missing YUI

Re: The case of the (not so) missing YUI

Re: The case of the (not so) missing YUI

Empowering educators to improve our world

Moodle

Support

Get Involved

Contributions

Downloads

Tracker

Development

Empowering educators to improve our world