This page explains the legacy “Course files” area in LMS and related topics.
It’s useful for any instructor who wants to know how to add files to an LMS course
Contents
1.3 Problems with the LMS model
2.2 More advanced LMS workflow
2.4 How to duplicate LMS functionality
2.4.2 Change a file once and have it update in many places
2.5 WebDAV support for course files and user files
Files in LMS
All the files uploaded into LMS were stored in a physical directory on disk known as the “Course files” area.
This is where an instructor might upload files to be part of the course content, but this area also included everything users uploaded, such as assignments and forum attachments. These “activity files” were stored in a special folder called moddata in a certain structure that helped modules keep track of their own files.
Typical LMS workflows
The course files area was accessed in two ways through the LMS interface by instructors.
- Through the “Files” link in the Course Administration block, or
- When a file was required in other places, such as a resource, or attachment.
When publishing a file as a resource, say a PDF file, an instructor might:
- Upload it to their course files area along with all the other files they intend to use in the course
- Add a resource to the course
- Select the PDF from the course files
Users did not have direct access to read the course files area. All they could do was upload files from their desktop computer straight into activities.
A less typical workflow
- Use FTP to push files straight into the course files area
- Add resources to the course by selecting these files
- Update the resources later by updating the files directly via FTP
This meant expert users could update course content with files or HTML mini-sites without having to change anything in LMS.
Problems with the LMS model
- If the original file was deleted from course files area or renamed, it would result in broken links everywhere where it was previously used
- Storing files on disk meant file names were restricted (eg file names in Japanese would break on some operating systems)
- All course files had to be readable by users (if they knew the URL) because LMS had no way of telling what context you were viewing a file in (eg the same file might be in an HTML text in a forum and also in a resource). This meant that files stored in the course files area were not as secret as instructors thought they were.
- Files could not be reused in several courses – that had to be uploaded to each course files area
- Backups had to include ALL course files, just in case they were required, even if the backup only contained one activity
- Images and other media might look fine for instructors, but others would not see it (eg in course descriptions)
- When importing activities from one course to another, ALL course files were imported, as it was impossible to tell which files were needed
Files in LMS
In LMS the files work a lot more like Web 2.0 systems, such as Facebook and Google Docs.
Each activity and each text has its own file area, and files are associated directly with the place it is used. For example, a file attached to a forum post is stored “with” the forum post and becomes subject to exactly the same access restrictions.
The Files system is intimately connected with the Repository system and a file picker which makes it easy to browse external and internal repositories for files and then copy them into LMS. Certain repositories also allow you to link directly to their media files. Repositories, in general, are the way of the future for content – most Web 2.0 systems are really repositories of data with various management interfaces.
A private files area is provided for each user to store a collection of files for their own use. This is useful for users as well as instructors and makes it easy to re-use media across the LMS site. Only you can access your own private files.
The course files area in LMS is deprecated and is not available by default due to the problems described above. When a site is upgraded, all course files are migrated into new file areas and the old course files area is hidden from view.
Internally, files are stored in a “file pool” of blobs on disk with numbers for names. All the actual names and metadata are stored in a database.
Typical LMS workflow
- Edit a text or activity
- Use the filepicker to select the file from a local or remote repository
The file is then copied to LMS and stored securely with the text or activity.
More advanced LMS workflow
- Edit a text or url resource
- Use the filepicker to select the file from a local or remote repository and select “link”
The file URL is then embedded into the text and when viewed, the media comes directly from the repository.
Why is it better?
Integrity
If a forum post with attached files (eg images) is imported into another course, then the files move with it. Anyone in the new course will also see the files. This makes activities more portable and reusable.
If two activities use the same file and one is deleted, then the other one is not affected.
There should be fewer problems where everything looks fine for instructors but doesn’t appear for users.
Security
Access to files is governed in the same way as the items that they attached to, which is what people expect. All files are now controlled by the settings in the LMS interface, including roles and permissions.
Re-usability
It is now fast and easy to re-use files across LMS. Using the file picker, a recently-used file may easily be chosen, or a file from any course a user has access to.
Backups
Backups of activities are small and accurate because LMS detects exactly what files to include. This is important for things like Community hubs, where sharing of courses and parts of courses will become more common, and sharing every file in a course may be inappropriate.
Internationalization
There are no restrictions on file names – even files with names in Japanese may be used.
Repositories
The world is turning towards better management of files and less “dumping” of files into disks. There are many repository solutions out there that focus on better management of files, with versioning, workflow, metadata, and other features.
How to duplicate LMS functionality
If you really want to mimic older workflows, then there are some solutions, although none of them are exactly the same.
FTP files into LMS
- One way to do this is via the File system repository. This allows you to turn a directory on the server into a repository of files within the LMS file picker. You can then use any server technology to access that directory from a desktop, such as FTP, Samba, AppleShare or WebDAV.
- See the direct WebDAV plans below.
Change a file once and have it update in many places
- See Working with files for the areas in which this is possible.
WebDAV support for course files and user files
This would effectively replace direct FTP access to the file system with WebDAV access to the “virtual” file system inside these file areas in LMS. It would allow people to update files without going near the web GUI.