First a story, as well as being a Moodle user, i'm also Linux user and a former fan of the KDE desktop for Linux (and other unix systems). Some years ago KDE decided to start a fairly radical re-write of the system, the end result of this was the KDE 4.0 desktop. However, this new desktop system changed the way that the actual desktop worked. We all know how a computer desktop works, you have links, you can save files to it etc etc. With KDE 4.0, you couldn't do this in the normal way, there were other ways in which you could achieve a similar result, but it wasn't quite the same, the result had a different feel to it and people had to re-learn how to do something they felt they should already know how to do. There were quite a lot of other examples within KDE 4.0 of the same problem, much of the work was done for good technical reasons, but the familiarity the average user expects was lost. Many of the classic features were eventually re-implemented in later KDE 4.x releases, but for many this was too late, they had already switched to other desktop systems and the KDE project has been diminished as a result.
What concerns me with Moodle 2.0 is that it displays many of the same characteristics as KDE 4.0 when compared to earlier releases. Some key functions lack the familiarity of the previous versions and things feel more complicated than they used to be. For me course files, the way it works and interacts with every other component goes to the heart of Moodle functionality, it hasn't really been changed since the very first release of Moodle. It is, very familiar. Therefore, it seems to me to be the height of folly to remove it or significantly change it. If you combine the lack of course files with the new (and in my opinion rather clunky) file browser/picker, Moodle 2.0 could very quickly alienate users who are comfortable with the old ways.
I strongly believe that in order to avoid these problems, Moodle 2.0 needs to be more familiar, at the heart of this familiarity are the course files and file browser functionality. Course files need to be capable of working exactly as they used to, right down to the on disk file structure (and not an approximate alternative with the same name), and there needs to be an option which allows the user to have a more familiar file browser interface. The implementation of the classic features may be new in order to account for API changes, but they have to feel like they haven't changed.
(Note I am aware of http://tracker.moodle.org/browse/MDL-23308 and have already contributed to the discussion)
The new file API was designed and implemented to fix a lot of problems we were experiencing.
As one example, you say you'd like to store files on disk using their original names. This single requirement would mean that many of our users would experience huge problems (as they did in Moodle 1.x), since they want to name their files using all kinds of non-latin characters, and many operating systems do not support these well. Talk with people trying to use Moodle in Japan, for example.
Another old problem is that we could never tell what files were being used by exactly what activity. This led to all kinds of issues with backups, security, images appearing to teachers but not students, and so on. For example, if you wanted to backup one Forum you had to include EVERY file in the course, which could be gigabytes. Course import often broke, too, because we did not know what files to bring over with activities.
Following from this, every file in the course files area had to be readable by students (because we had no idea where/how they were seeing it), so a smart student could easily guess URLs and gain access to all kinds of files that teachers thought was private (and thus cheat).
The answer is not to go back to the 1.x design - it's too late for that. If there are issues with the 2.x interface then let's work on them (as we have been for over 2 years). One of the things that was always planned (though sadly not finished yet) was a WebDAV interface (built on top of the File API) to make it easier to drag files in and out of Moodle. There is also the filesystem repository and a new course files repository that mimics a lot of the old behaviour for those who really want it.
To me it's clear that the general trend in the world is to move towards specialised repositories that do that job really well, and then plug these into application servers like Moodle to use the files.
I think most of us involved recognise that there is going to be some re-learning required, that old workflows may have to change, but the result is a more powerful, flexible and international tool with fewer problems.
Finally, Moodle 1.9 is still around. If you can't adapt your custom backend stuff then you may not want to upgrade, and that's fair enough.
Our requirement is for a live local file store which other software on the system can just drop files into and have those files immediately available and manageable through the Moodle interface. 1.x course files worked perfectly for this purpose. Filesystem repos don't work because the content is copied from the repo into Moodle, so if a file in the repo gets changed by the outside software, the version in Moodle isn't automatically updated because the repo can't do a push into Moodle. The coursefiles repo doesn't work because it relies on the new file storage structure underneath.
As you've seen from our discussion on the tracker, i'm trying to find a way to make Moodle 2.x work for me without having to patch the core functions. I want to work with the 2.x design, not against it. I'm hoping to end up with a repo plugin which could be used instead of the internal file store to provide a proper course files area. I have to admit I had expected something like this to already be part of Moodle 2.x and that I would be given the choice during the upgrade to either migrate to the new structure or use a retro fitted repo plugin for my content that provides equivalent functionality via the Moodle 2.x api.
I suppose the alternative to this would be to write an API into Moodle which allows external software to push files into Moodle and retrieve the real file reference of any file in the Moodle file store so that existing files can be updated externally.
I do not want in any way to be seen as talking down much of the fine work that has been done for Moodle 2.0, a lot of it was necessary and is very good. I just feel that you are in danger of loosing people though carelessness, in the same way that KDE 4.0 did.
On a separate issue, how long do you intend to continue support for Moodle 1.9x and to what extent would you allow 3rd parties to continue to support it through the official svn and with releases on the Moodle download page after your own central support has been discontinued?
I have been trying to understand how to use the new Repository system too. I think it has great potential, but there are a few things that have me confused.
1. When you insert either an image or create a hyperlink in the HTML editor, you can use the File Picker to upload files. The files goe into some unknow location in the Repository. I can't find any way to delete these files. Can these files be deleted or are they going to remain on the server to eventually fill up the server?
2. I logged in as a student and opened a forum. Then, as the student, I replyed to a post. Of course, the HTML editor opened and I was able to insert an image or create a hyper link in the reply. This opened the WHOLE Repository to the student via the File Picker. As a student, I could access any file in the Repository and upload files. I don't think that is what it should do. I reported this in the Tracker.
3. I see that you can create folders in the Repository and upload files via FTP then access them via the File Picker. But if you upload a file via the File Picker, you can't specify where the file is stored. It seems to me that a link to the stored file should be placed in the folder of your choice so you can find it again. And, if you don't have FTP access to the Moodledata files, how can you use these folders, except to pick files from them. There should be an Upload Facility that lets teachers upload files to these Private folders.
It seems to me, if you just add an opitional File Upload script that will let the user specify the folder of his choice, it would satisfy most of the complaints I have been reading about here.
- When you say "repository" what do you mean? There are various "repositories" all accessed from the file picker - of which the new course files repository is one. I agree it is difficult to trace one's path back to where the file was uploaded to -although it makes sense when you understand the reasoning.
- When you say the WHOLE repository -again -which do you mean? If admin has enabled Flickr or Youtube or Google docs in addition to the private files then it is correct that the student should be able to access any of those repositories. (They shouldn't be able to access the course files repo though - I will check that out
- If you want to specify where a file is stored then you upload it via the course files link in the course administration and then you can access your file from the course files repository within the file picker.
OK, your right. There are an number of off site repositories that can be accessed.
I am not interested in using the 3rd party servers (repositories). I prefer to keep my files on my own server.
So when I said the "whole repository", I meant the pluggins in that I have enabled including Server Files, Recient Files, Upload a File, Private Files, and System Files. All of these pluggins are available to the student when he replies to a post in a forum and uses the HTML Editor to insert an image or create a hyperlink.
In my oppinion, the student should not have access to any of these files. If he needs to upload a file to the forum, he should use a File Attachment.
I don't know if the student would have access to 3rd party repositories. I doubt it because I expect he would have to know the passwords. But someone who uses these repositories should check that.
I think a lot of the confusion about the File Repositories is the lack of any concise documentation at this stage in the game. I had not seen the Legacy course files link in the Settings Block. Either it is new or I just missed it.
Mary, I may have the file permissions set differently than you do because on my server, the student has full access to all of the repository pluggins that I have enabled.
Also, I don't see how to use the Private files since there doesn't seem to be any way for the student to upload files to the Private files. If the student can't add files to his Private files, what purpose does the Private files pluggin have?
I used FTP to add folders and files to the File System pluggin and I could view and even download these files as a student. On my test site, the student has the same access to these files that I have as the administrator.
For private files to work properly you need to add the private files block and then a student or teacher can add files to there and retrieve them from the private files repository.
I will go and check the set up of my file system folder now
Thanks for the heads up on the Private Files block. I missed that.
I tried hiding the File System repository (set it to Enabled but hidden) and then I could not see the folders as the Administrator, Teacher, or Student. When they are hidden, the Admin/teacher should still be able to see the File System repository.
You said "the capability to View File System repository for a student is set to "allow" by default". The only settings I have found are set to not allow students to create File System folders (see attach screneshot).
I be missing a setting somewhare.
I followed your instructions and you are correct that the Student Role is set to ALLOW the student to view the File System Resource.
So I opened the role editor and found that you can't change that setting in the student role. It is evidently hard coded.
I looked for the file to edit it but so far have not found it.
then click the "edit" button then in the filter , type file system repository
You will get a link like the screenshot below - uncheck the "allow" and that should do it
That did it Mary .
I guess not only are there bugs in the system, there are bugs in my knowledge of the system .
I need to spend more time exploring the Site Admin setup screens. Also, although there are a lot of parameters in the role definitions, I have to pay closer attention to the defaults and change them when I want something different.
What seems like a bug in the system is only a setting that needs to be customized.
OK! I found the problem. It turns out that all of my Role definitions were full of errors. I ported my data from Moodle 1.9.9 and assumed that the Roles would be the same. But in Moodle 2.0, the Role settings were very different.
I opened the Define Roles utility and reset all of the roles to the Default settings. This fixed a lot of things that I thought were bugs in Moodle 2.0
OK, i've just finished writing two new plugins for Moodle 2.x which (too an extent) restore proper course files capability to Moodle 2.x, in the way that it works in 1.x, including the underlying file structure. These plugins are different to the 'Legacy course files' capability which is being discussed on the tracker because they actually use the real "moodledata/course-id" file structure as per Moodle 1.x.
The system consists of a repository plugin which allows you to select files for both internal or external repo types and a block which provides file management capabilities for the repository. Much of the code is a port from the most recent 1.9.x release of Moodle.
These plugins can work without needing any patches to the core Moodle code, with the following caveats:
- Use as an "internal files" repository is off by default (but can be enabled in the repo config).
- When used as an "internal files" repo, the file still gets copied into the new Moodle file storage structure, unless you add my patches to the core code (see below).
- URL's added as external resources are using hard links, so if the Moodle installation gets moved, stuff will probably break.
- I haven't (yet) tested what happens when things are backed up.
- This won't stop existing course files from being migrated to the new structure during a 1.9.x>2.x upgrade. I may look into an upgrade system patch sometime in the future.
There are two small patches which can be applied to the core code that allow the new Moodle file store area to use symbolic links to the actual file inside the real course files area, instead of having a copy of the file. This allows the file in the course files area to remain live so that any changes to that file are immediately reflected by any resources that use it. Quite what the long term effect of filling the Moodle file store with symbolic links will be I don't know, so this is going to need some testing.
If you want to try out the new plugins, please go to http://www.autotrain.org/misc/source/moodle2/ to download them. Testing has so far been fairly minimal. Once they've had a bit more testing, i'll probably add these plugins to the 3rd party addons database.
Edit: I'm also considering a patch which allows the sysadmin to use a 'real files' file store with Moodle 2.x through the underlying files api. Essentially the files held on disc would reflect the names and paths kept in the files table of the Moodle database, rather than using a hash for the file name. The aim of this would be make life easier when trying to identify specific files in a file system backup. This patch would not be aimed at restoring any 1.x functionality.
I'd also like to be able to use it as a substitute file picker, the default one is rather clunky and it can't be resized or pop-out into it's own window (not good if you have a lot of files or a dual-monitor system).
I just wanted to say that this is great news/work! I was having exactly the same complaints and issues as yourself. Because of it we were not going to upgrade to Moodle 2.0 at all and instead extend and develop our own Moodle 1.9 indefinetly. (We already create new blocks, customise the core code and customise other blocks. etc.). I have a play Moodle 2.0 so that in a year or two when we go to Moodle 2.0 I am ready. I will keep an eye on the course files with interest.
With a lot of thought and dialogue with many clients. I must post that not a single one of my clients is happy with the lack of course files. I am still looking at ways to create a central file structure in each course for past files and new files. The repository does not seem to meet any of the needs.
Can someone in the Moodle HQ team provide any explanation on the shelf life of Legacy files? I have thought of renaming this to Course Files in Lang, and enabling it for all new and old courses in Moodle.
If you want a collection of files in a course, add a Folder to the course somewhere, and put files in that.