Ray Morris

> When creating tests, we don't use much of the features, related to grading and still there are other features that we must manually set to the same value every time. We always use deferred feedback, we always have the same settings for giving the student feedback after the test. We always shuffle questions randomly, have time limit and when it's over we want to instruct the system to submit his attempt automatically.

Most (all?) of these can be set to a default and hidden under Site administration ⟩ Plugins ⟩ Activity modules ⟩ Quiz.  Set the setting you want to use, then tick the "Advanced" box to have the setting hidden by default. Many other modules are similar.  

For the course settings, use Site administration ⟩ Courses ⟩ Course default settings.  Those don't have the "advanced" check box to hide them by default.  If you wanted to make a patch, you could submit a patch to add "advanced setting" support for courses and for any modules you use which don't already have that feature.  See Quiz and other modules which DO already have that to see how it's done.

> If I touch some source it seems that I must say goodbye to this little automation.

This is one reason to submit your patches back, so they will be there in the next version.  The review process will also make your patches better.  If for some reason you can't get a patch committed, you can always use a local module.

Right click the image, choose "Save As".  Compare the file size and type to the original.  Also, view the image locally after saving it.  Does it look better?  if it looks better after saving it, that points to CSS resizing the image, if only slightly.

Note that the backup function within Moodle is really a "plan C".  It doesn't really replace a server backup, which should be done by your server administrator and restores tested when you call a drill, and should include all your Moodle data along with the rest of the server.

That is to say, your Moodle stuff should already be backed up as part of your complete server backup using Clonebox or similar, so the Moodle backup is just extra piece of mind since you should already have a tested daily backup of the whole server.

Before replacing the compromised files with a fresh copy, anyone hacked should save the old files via tar or zip.  It's important to save the exact timestamps on the files.  Also, take a note of the exact last modified time on the hacked file.  It would be wise to save your web server logs from that time, at least 20 minutes before and 20 minutes after. 

As Howard said, this indicates improper permissions on the files, allowing the web server to write to them (or suexec, which permits  any visitor to edit any file on the site).  Along with permission to edit the files the attacker must have had a mechanism to do so, probably a flaw in Moodle.  That second part, the mechanism, is something the Moodle community should address.

Victims can compare logs and a pattern should emerge with some hints as to where the flaw is.  If anyone has POST logs, that would probably be immensely helpful.

PS - I said it' most likely a Moodle flaw.  It could also be that all victims were also running some other package like Wordpress or Joomla and the flaw providing the mechanism is in that other package.   Comparing server logs would prove or disprove that.

The message means you edited settings on that page and didn't save them.  It's asking if you are sure you want to leave the page without saving your settings.