David Scotson

For this particular issue, note that Google doesn't really like visiting sites with large numbers of parameters after the '?'. In this case it appears to be cutting off the last one and just trying what's left anyway.

The googlebots are actually quite smart, and do seem to learn about your site to spider it better, e.g. they know which pages are updated regularly and spider them more often to get the 'fresh' content (the recent updates page is therefore an ideal candidate for spider blocking with robots.txt) so I'm guessing it would stop visiting these pages if it recieved a 404 or other machine readable error page, but it doesn't and the bot isn't (yet) smart enough to read the actual page and realise that it is an error.

I had a read through the Google guidelines for webmasters and the only thing that jumped out at me that Moodle might be doing to confuse these spiders is the following:

• Allow search bots to crawl your sites without session IDs or arguments that track their path through the site. These techniques are useful for tracking individual user behaviour, but the access pattern of bots is entirely different. Using these techniques may result in incomplete indexing of your site, as bots may not be able to eliminate URLs that look different but actually point to the same page.

I'd guess that if the googlebot doesn't accept cookies then the sessionID will be written into the URL. Those with multiple visits from the googlebot might want to check to see if the same page is being visited by bots with different sessionIDS.

You might want to try submitting your site to the Google Sitemaps service.

This is basically a document that tells Google what parts of your site are static and which sites need to be regularly updated. Most of the documentation addresses people who want Google to search their site more often but I'd guess that you could use it equally well to stop Google from pointlessly re-indexing pages that haven't changed or which may have changed but are only pointers to the real content such as recent activity.

It might be a nice project to have Moodle automatically generate these according to some admin options. In the meantime, they also accept RSS feeds. Maybe Martin could point them at the Moodle.org RSS feeds and we could see how that works out?

I'm not really a fan of the styles.php approach myself, mostly because it doesn't fit the expectations of those who know CSS rather than PHP and work seamlessly with the standard tools and techniques.

However, I don't think it's actually necessary to change anything in order to achieve your goal. You could just replace the call with PHP code in header.html to make static calls to the relevant css files. (I don't think that there is currently any other way to, for example, specify print, handheld or alternate stylesheets).

I'm not sure what happens with the extra CSS for Modules, maybe you can leave the call to this function for that purpose and bringing in the standard styles and just remove from the list in config.php any styles you link to statically.

As for the classes and id's, there are certainly areas that have been overlooked, but these are simple mistakes that are hard to find until you actually try to create a theme that needs them so please report any you find so that they can be fixed.

Not every theme needs every style hook but summed over every possible theme they soon add up so there should certainly be more rather than less classes and id's than you would expect in a normal webpage. On the other hand, the contextual selector approach mentioned by Martin works well in cases where the page is using semantically meaningful tags rather than classes (or worse, tables for non-tabular data, eek!). There's still work to be done in that area too.

Unfortunately the work is rather more involved than something that could be automated. You're really taking the design ideas, rather than the just CSS code, and translating them so that they make sense in the context of Moodle. On the other hand, if you look at a variety of Wordpress (or Moodle) themes you start to see a distinct pattern, that basically suggests all you need is a header, a footer and a repeating vertical motif in between. I confindently predict that, as a result of the CSS changes made for 1.5, there will soon be a body of Moodle Themes from which to draw, and that subtle variations of these will suffice for most people. That was part of my thinking in choosing Kubrick, as the distinctive blue blob can be personalised with an image simply by uploading to the Moodle file area. The rest of the theme is non-descript enough for this to transform the look of your site.

My masterplan, which I've not had much time to devote to recently, is to take the Kubrick theme for Moodle and break it down into its component parts to make it easier to steal, leverage, and learn from individual parts of it e.g. you may want to have stripey tables and new-style tabs without 2-columns and fixed width.

Or, on a simpler level, you may just want to take everything blue and make it green, red, purple etc. Hopefully this kind of change will be so easy that anyone can do it since the color stuff will all be broken out and logically arranged together in a single file.

To test that I've broken it down properly, I intend to create a final Kubrick theme, and one based on it's sequal K2 and another popular Wordpress theme, maybe Fresh Bananas (can't quickly find an example but you can see it in the Wordpress theme browser if you select it from the dropdown). These will all be using the same 'foundation' CSS but with a different facade creating a substantially different 'look' without, hopefully, changing the 'feel' too much. I'd hope that theme designers would also be able to build on that same foundation (and contribute fixes to it where problems are found).

(I'll also need to take a look at the block column code before two-column themes can really hit the mainstream.)

edit: Miles's post appears to be linking to a variety of glossary definitions in the Thai Moodle course. Is anyone else seeing this? edit2: it's stopped now. Very strange.

There's two parts to this:

• stopping the black border being added to new images. The latest version of lib/gdlib.php doesn't add this to images. Simply replace (after backing up) your current copy of this file and new images should not have borders.

• removing borders from currently existing images. This obviously isn't needed if you are setting up a brand new site but there is code in the latest lib/gdlib.php to do this. However, it is only called from a test page located at userpix/upgrade.php. Currently there are two different methods, called depending on what capabilities your copy of the GD library has, either rezising and zooming in or duplicating the outer rim of the image. The resize code has the issue that if you run it on the same image more than once, it gets blurrier and blurrier as it zooms in, the main reason I've used it as the default is that it is probably (total guess!) much faster than the other code, which could be an issue if it was called automatically as part of an upgrade of a large site.

You might want to try it on a backup site first. I'd be very interested in hearing how long it took too. I'm hoping that a few keen beans will use this for their 1.5 sites and that it can become the default for 1.6 when it is released.