David Scotson

Another thought I've had in the back of my mind is that "Using Moodle" is in fact the most comprehensive database of documentation that we have

A very true statement. There is an article (transcribed presentation) called Splitting Books Open: Trends in Traditional and Online Technical Documentation on O'Reilly's website exploring this issue. Though often written from the point of view of a publisher (and becoming something of an advert in the middle) I think it picks up on a lot of the trends that have made Using Moodle such an excellent resource.

You could probably distil some alternative 'documentation' guidelines from it, such as asking regular contributors to consider the wider audience (and Google) when answering tech questions.

Scalabilty and performance are strange topics, the kind that can start near apocalyptic flame wars because there is such a wide range of strongly held opinions.

I have personally read in-depth, well argued articles advocating everything from learning assembly language so you will always know what your code is doing at the lowest level through to using the highest level language and abstractions possible and letting the Virtual Machine writers and Moore's Law take care of it.

But I think the one thing almost all of them agree on is that if you aren't measuring your app and finding the bottlenecks then your optimisations will have no impact at all on overall application speed (though they might be breaking your code in odd corner cases and/or making it harder to debug).

The book Advanced PHP Programming by George Schlossnagle has some good advice on how to benchmark your website and find exactly where you are needing a speed up:

Try the attached file, it works for me in Safari and I think it might work elsewhere though I've not tested it on any other machines.

The key is to be more specific. The style cascade prioritises on how tightly defined the style is, that is why font tags override styles targetting the area they are contained in.

I just changed the style definition to this;

<style>
body p font {
    font-family: Verdana;
    font-size: 11px;
}
</style>

But yes, it is a hack and the font tags should be removed as part of the move to XHTML anyway, so this won't be needed for much longer.

I don't think it's the exactly same problem, though it's in the same area.

After some digging around I discovered the following about my problem:

Mozilla (and IE, sometimes!) substitutes the decimal encoded rpresentation of a Unicode character i.e. ampersand-hash-digits-semicolon for any character outside the allowed range of the page when submitting a form. These then get stored as simple ascii but translated back to the correct character by the browser when displayed as HTML.

Safari (and possibly Opera) simply substitute a question mark for characters outside the specified encoding.

Neither is actually 'correct', in fact the Mozilla way, while more useful for my purposes, may actually be less correct from a standards point of view.

ref:
http://lists.w3.org/Archives/Public/www-international/2003JulSep/0209.html

A fix would appear to have to wait until Moodle can fully cope with Unicode data, which I believe some of the non-english translations are already experimenting with.

Similarly I assume that your LDAP database is Unicode and since it isn't being translated into the character set that Moodle expects the characters outside of ascii are getting garbled. Probably the only reason ascii character work is due to their codes being identical across many different encodings. This is handy sometimes but can also mask bugs if you only test with ascii data.

A related task that could be usefully carried out at the same time is to set all the colors in config.php to 'green'. All the areas that aren't overridden in the CSS file will show through as deep forest green and can easily be spotted.

I've done this before and many of the green areas can be easily fixed by specifying the color in the CSS with the appropriate class selector, as CSS will trump the HTML written out based on the config file. However, there are some areas that don't have a suitable id or class, and one would need to be added to allow CSS to target them. If these were fixed then it would be possible to entirely switch themes via CSS and use config.php only to support older browsers.

This will A) allow for making the themes better and more accessible and B) also allow user selectable themes.