I'm curious, why does the timer hop and jump to follow the page? Instead of JavaScript causing it to follow along, why can't it be set with position:fixed; ? The erratic behavior of the JavaScript seems to make it quite distracting.
I've already added a hide/restore behavior with 5 minute remaining visibility to my moodle install, but what about removing the move function and making it a css property? Seems like that would be nicer (plus you could change it to position:absolute via the theme if you didn't want it to follow the student's scrolling).
(I know that this is really only for 1.9 Moodles, since the new version has it in a different place)
You can absolutely make the timer static! In CSS set #mod-quiz-attempt #timer {position:static}
This will make it appear on the bottom of the screen below the buttons.
-- Jeff Snyder
This will make it appear on the bottom of the screen below the buttons.
-- Jeff Snyder
I'm often curious when I read solutions like this: if I make a change like this, then I upgrade from 1.9 to 2.0 for example, and I'm not using any version control system, do I have to manually remember changes like this that I have made to core files, since they will get overwritten by the new files?
Your theme folder is one of the backups you'll make when performing an upgrade. We are advised to paste our old theme folder into our new installation to prevent possibly huge amounts of recoding. It would take me forever to re-do all the changes I made to our theme, so I'm glad these will be interchangeable.
As long as you go by the docs for the upgrade, you should be covered!
--Jeff Snyder
As long as you go by the docs for the upgrade, you should be covered!
--Jeff Snyder
Yes, asking this question about a theme change was a bad example.
In principle, though, if one makes a minor change to a core php file, in the absence of any version control, one would have to manually remember the change and manually put it back into the file following upgrade: as far as I can see, there is no alternative to this?
Unfortunately, I think you're right. I'm not aware of any really easy way to manage that. Personally, I've made many changes to the core code, so I've just been writing down every change...
The timer does not use position: fixed because that never used to work in IE. I guess it was fixed in IE7, but IE6 is still around.
The right solution is to use version control. Git is particularly good for managing your own customisations and combining them with standard Moodle. See Development:Tracking_Moodle_CVS_with_git. However, there is something of a learning curve. Well worth it though, if you are planing to do lots of customisation.
The right solution is to use version control. Git is particularly good for managing your own customisations and combining them with standard Moodle. See Development:Tracking_Moodle_CVS_with_git. However, there is something of a learning curve. Well worth it though, if you are planing to do lots of customisation.
Ahh, okay. That's important to know. We've officially dropped our support of IE6, so that's not really too much of a problem for us - but if there is an issue, now we've got an answer.
Thanks!
Thanks!
Hi Hannah,
We have been making 'minor' changes to the core code for 3 years and although it seemed very doable at first, the more we do the more tedious the upgrades get!
I started tracking all of the code updates in a document so I knew what to check on each upgrade. I subsequently moved these to a spreadsheet for easier tracking and now I take it a step further and make a note of the page version of each page that was altered. After an upgrade, I check the version of the new code against what is in the spreadsheet. If the version has not changed I simply copy the existing page back from the backup. If the version has changed I go in and edit as required. This last step has helped decrease our upgrade time significantly. I tried upgrading with CVS a while back and didn't have much luck. It's on my to do list to try that route again although I need to learn more about it first.
We have been making 'minor' changes to the core code for 3 years and although it seemed very doable at first, the more we do the more tedious the upgrades get!
I started tracking all of the code updates in a document so I knew what to check on each upgrade. I subsequently moved these to a spreadsheet for easier tracking and now I take it a step further and make a note of the page version of each page that was altered. After an upgrade, I check the version of the new code against what is in the spreadsheet. If the version has not changed I simply copy the existing page back from the backup. If the version has changed I go in and edit as required. This last step has helped decrease our upgrade time significantly. I tried upgrading with CVS a while back and didn't have much luck. It's on my to do list to try that route again although I need to learn more about it first.
Thanks, that seems a good method (as long as the developers are really meticulous about changing the version numbers when they change the code) if you're not using CVS.
I was thinking of fixed, not static. I tried it on our test system, I just deleted the call to the JavaScript function and then added the position:fixed, left:10px, etc. to the styles. It's now nice an steady when you scroll the page - no JavaScript needed. Hmm, hadn't thought about adding a link somewhere that toggles static/fixed, hmm...
PS: Now I'm looking at adding jquery draggability to it, but that's probably an overkill.
PS2: Why is it in so many nested tables? It's hard to figure out what all I need to do to change the bg...
PS: Now I'm looking at adding jquery draggability to it, but that's probably an overkill.
PS2: Why is it in so many nested tables? It's hard to figure out what all I need to do to change the bg...