David Scotson

Does the Moodle wiki(s) not support something similar to <nowiki> which in MediaWiki for example, stops processing of text for wiki markup. It's used in the Moodle Docs Wiki for exactly this kind of thing.

edit: the efurtwiki docs appear to claim that using <code> will prevent it from messing with your text. However, I can't seem to get it to work.

Off-topic, but I'm highly amused that the wiki markup for <small> text is two µ's!

Actually, this might be better:

<pre class="geshi"><code .....

<code class="geshi php" ....

<ol class="geshi" ....

where geshi can be used to set backgrounds/borders etc. and php for the syntax highlighting. You'd probably want to make minor changes to the list, inline and pre styles but by and large they'd probably share the same look and the actual syntax highlighting is likely to be indentical across all three.

Further to one of the above points:

I think

<pre><code class="php"> ... </code></pre>

for normal output,

<code class="php" ... </code>

for inline code snippets, and

<ol class="geshi-code-listing">
    <li><pre><code class="php"> ... </code></pre></li>
    <li><pre><code class="php"> ... </code></pre></li>
    ....
</ol>

might be the best solution. I don't think lists are allowed in pre blocks and code needs a container like pre or p but it's simpler to use pre even if the content is always going to be a single line.

You could also use list-style-position: inside to include the line number inside the highlighted section (yes, purely cosmetic I know), though having said that when I try it (using Firefox's edit CSS function) there seems to be some kind of collapse or interaction happening.

html2text is supposed to catch these things so it's more likely a problem with that rather than TinyMCE. It would be interesting to test if catches &#039 i.e. effectively identical but textually different from &#39 because (I think) that's what PHP generates going the other way.

Ah, it's only the file pop-up that doesn't have any header div outputted! One more oddity for the file.

Regarding Kubrick, to be honest it was never meant as a theme as such, more as living documentation of all the various work arounds needed to theme Moodle in a meaningful way, and that would need to be fixed in later versions of Moodle to make themeing Moodle easier (meaning: possible for mere mortals).

The idea was that by starting with something designed with no knowledge of Moodle, and trying very hard to make it work exactly as envisioned you'd hit all the snags you'd subconsciously avoid if you worked within Moodle's confines. Unfortunately that grew to became a very big list and it's simply too much effort to keep it updated as things change and new modules get added.

You could compromise in various places, as I've done for the theme I'm developing for my institution (which is usually on display here: http://learn.gla.ac.uk/moodle/stable15/) because I have no way of knowing which modules and add-ons will be used with it, and if you try to get clever with the theme there's a good chance they'll simply break in odd corner cases. While I'll happily make those compromises for a working theme as part of my job, it rather takes the fun, and to a great extent the point, out of themeing Moodle for it's own sake, rather than for a specific installation.

I'm hoping to show off some ideas I have for rethinking the way Moodle is themed at MoodleMoot UK and I'm trying to add the various nuggets of Moodle theme wisdom (stripey tables, fixed width stuff, hiding icons) contained within Kubrick to the Themes section of the Moodle Docs wiki as and when I get a chance so it will live on in that way, via any themes that take advantage of those ideas.