Best,
Przemek

I don't think there is anything I can do about bad data already in the database. Well, if createdby or modifiedby point to a non-existent user, then I will reset it to NULL, but where they point to an actual user, there is no way for Moodle to know if that is the correct information of the result of a bad restore in the past.

As admin, you could get a list of question_category ids that came from bad backups, and then manually do a database query to fix them. Something like:

UPDATE mdl_question SET createdby = NULL, modifiedby = NULL WHERE category IN (123, 234, 345, ...);

using a tool like phpMyAdmin. However, messing around directly in the DB is not something to be undertaken lightly.

} else if ($restore->original_wwwroot == $CFG->wwwroot) {

lines. Thanks.

Yes, I understand that My question was about future restores.

I just wanted to know which of the following you are planning to implement as a fix for this issue:

1/ if during the restore process the original wwwroot is different than the wwwroot of the target site, then CREATEDBY and MODIFIEDBY will be set to unknown

OR

2/ if during the restore process the original wwwroot is different than the wwwroot of the target site, then CREATEDBY and MODIFIEDBY will be set to admin

If the backup includes users, then we will update the fields to point to the new userid of the user who created/modified the question. If the user is not in the file, we set it to null, unless $restore->original_wwwroot == $CFG->wwwroot.

The if ($restore->original_wwwroot == $CFG->wwwroot) is dangerous because of this scenario:

1. Admin backs up everything important in their Moodle 1.9.
2. wipes their server.
3. Installs Moodle 1.9.4.
4. Restore just the bits they want, in order to have a nice clean DB.

In this case $restore->original_wwwroot == $CFG->wwwroot but it is a different moodle.

However, there is a $CFG->siteidentifier, which is initialised on install to random_string(32).$_SERVER['HTTP_HOST']. It is used for registration, and a couple of other places. Unfortunately, at the moment, this is not stored in the backup file.

So, the plan is:

1. Change backup, so $CFG->siteidentifier is stored in every backup file.
2. Change restore so that the siteidentifier from the backup file is available during restore, as $restore->originalsiteidentifier.
3. Write a restore_is_same_site($restore) function that returns true or false to let you know if the backup file came from this site. If this is an old backup that does not include siteidentifier, then restore_is_same_site will return false.
4. Use restore_is_same_site($restore) in my code.
5. Search the rest of the restore code (briefly) to see if there are any other hacks that should be replaced by restore_is_same_site.

Hopefully I will be able to do this on Monday.

I was suprised how many places were already using a nasty hack to see if this was the same site.

I also refactored the three or four places where $CFG->siteidentifier was initialised, so they all called a function.

Otherwise, people may be able to hijack each-other's site registrations.

Also the questions part is ok, with those 2 lines we talked deleted. Perfect!

+1 for stable