This is the third post in the series: #Moodle Tricks of the Trade
This is a technique that I use widely on different Moodles or Totaras to better manage the images that I use within the courses and the learning materials. The basic principle is rather than uploading the same image lots of times, the image is uploaded once to a central location using a ‘Lightbox Gallery‘, then when it is needed, we link to that image by URL.
On some systems, I set this mechanism up on the Front Page – this means I can then use the images anywhere across the site and for sites with a small number of courses and where I build most of the learning, this works well. For other sites, I create a mechanism within each course – this works better when there are lots of courses each with their own editing teacher.
Note – if setting the mechanism up, on the frontpage, any images that are uploaded are potentially visible to anyone in the World, as items on the frontpage are by default visible outside of the login process. This could be mitigated by changing permissions to users so that only authenticated users can view the items.
The advantage of using a technique like this, is if a certain image is being used lots of times (e.g. I use icons a lot to connect items together), the image is stored once on the system, rather than potential duplicates. This saves memory on the server (which for some sites I work on is a huge issue), and if in the future I wish to change that image to another one, I only have to change it in one place, rather than hunt through the entire site to try and find every place it was used and swap it one by one. The other advantage, is if I have one type of resource or activity (e.g. a page or a book) and I wish to use that content in a different activity type (e.g. a forum, lesson, quiz etc.) – the easiest way for me to do this, is to simply copy and paste the html code from one page to another. If I have uploaded an image by the traditional technique this may not work, as the copying and pasting of the html, may break the link to the image, and as an editor you may not spot this at first (if your browser has cached a copy of the image), and by the time you do spot it, you have no idea where the original image is or what it is called, and if you don’t have the source file to hand to re-upload, can be in trouble. It is this behaviour catching me out on numerous occasions that has led me to take a different approach to manage images.
There are two very strong caveats to using this technique, which is important to understand before starting:
- If you are adding the lightbox into a course, and you wish to create a copy of the course e.g. to set up a version of the course for a future year, when you restore the back-up, the new course will give the lightbox a different ID number, which means that the URLs of the images within it, will also change. However, the images within the other resources won’t change, so they will initially point to the lightbox in the old course. All that needs to change is a single number within the URL, so it would be possible to use the site wide Moodle ‘find a replace’ tool to correct this problem in one move – but this would then mean that the old course would also update e.g. it would be looking up images in the new course, which may or may not be a problem (e.g. if the course is now an archive, and has no active students accessing it, then not a problem – but if there are still active students on it, then this would be a problem). If the lightbox is placed centrally (e.g. on the front page of the Moodle), then this isn’t a problem as the central lightbox won’t change when the course is backed up and restored so will work fine.
- If you were to ever move the Moodle to another host, the process of migrating the content over to the new host, may result in the module IDs changing (it depends how you do the migration), which in turn would create a similar problem. This could be rectified with a site wide find and replace, but you would have to do this for each lightbox in turn – and there is a possibility you could get an overlap of modules IDs which would then mess things up completely.
If you do not understand these caveats, or are not comfortable with the risks that this brings, then I would walk away now, and don’t follow this suggestion further. If however, you do understand these caveats and the potential risks involved, then this can be a very useful mechanism….