Details
Bug
Closed
Major
Description
The id of the glossary from which the random_glossary block takes its data is not recoded during restore.
Attachments
Activity
- All
- Comments
- History
- Activity
- Source
- Test Sessions
I've attached my preliminary patch. It's not ideal, but it does solve the problem my client is having with their site. Comments/feedback/fixes welcomed 
Cheers - Luke
Cheers - Luke Hi Luke,
I've been looking your proposed patch and looks a bit complex IMO. Also.. it seems that only will work when restore happens in the SAME server where the original course is stored (because you look course_modules.
IMO it's really simpler if you, directly, ask to the backup_ids table about the glossary->id against the 'glossary' table.
I've added one patch (agains 19_STABLE) that seems to work properly (it's missing some output if the glossary cannot be found and so) IMO. More yet it works also if you restore the course in a different server.
And I think it can be backported to 18_STABLE easily, or am I missing anything?
Ciao
Hi again,
I've tested the patch against 18_STABLE and it seems to be another bug in the restoring of blocks, not able to properly generate contexts (!!!) because of missing $instance->id or so.
So I've backported from 19_STABLE the minimum required to have 1.8 restore of blocks working properly.
So here it's another patch, for 18_STABLE, that:
1) Fixes problems in restore of blocks.
2) At the same time, enable the glossary_random patch to work under 18_STABLE
Ciao
Adding Petr here.... he did changes in restore of blocks for 19_STABLE...
Hi Petr,
the basic proposal here is to:
1) Apply restorelib.php_18_STABLE.patch to 1.8. I've backported it from your 1.9 code (only the minimum needed to allow 1.9 to work, basically the lack og $instance->id was causing a lot of stuff to fail (contexts creation, after_restore()...).
2) Apply block_glossary_random_19_STABLE.patch from 1.8 (if previous point is ok), 1.9 and HEAD.
I've performed some tests both with 1) and 2) and seem to be working ok. For your consideration. I think the change in 1.8 stable is safe and will save some problems.
Ciao
Done, both patches have been applied as commented.
Resolving as fixed...thanks and ciao
It appears this is due to the block storing the source glossary id in its (base64-encoded) config column. The restore process doesn't know anything about this, and so cannot remap the old id to a new one.
Now, the restore process calls (if it exists) $block->after_restore(), so I tried to put a fix in there. However, at the time after_restore() is called, the restore process has not yet updated the course_module.instance field, so the block will only get '0' as the relevant glossary id.
So, I'm currently a little stuck. One solution would be to move the after_restore call to the end of the restore process, which means saving a list of restored blocks then iterating through those.
Any feedback or suggestions are welcomed; I'm keen to fix this as soon as I can.
Cheers,