Seems strange replying to my own post, but other people may benefit from what I've since found. This question is kind of covered in a number of areas and documentation so I'll bring it all together here. (This is a long post but I hope it is useful to academic managers.)
Our basic need was to access (from outside Moodle) the files uploaded to the Moodle data directory which, during site installation, had been placed outside the normal public HTML directory of our webhosted domain. These files were therefore not accessible via a web browser. Yet, the audio and video resources used in our Moodle courses also need to be linked to from our other related websites (main website, blogs, YouTube, Airset, Veodia, Facebook, WizIQ, Second Life and so on). I did not know how to do this and, although a wiz php programmer probably would, I didn’t happen to have one lying around.
At the same time as school principal, I was concerned about IP/copyright - controlling and tracking who had access to these files. I believe any organization would probably need to think about this, especially a school or training organization such as Moodle is designed for.
While researching this, I did come to the painful conclusion that it really isn’t a good idea to have a CMS (Joomla in our case) managing my main website, alongside a LMS (Moodle) managing the courses. It would be far better to have Moodle providing the CMS as well as LMS functions. That way you would have just one list of registered users (Joomla-speak) or accounts (Moodle-speak). Another reason is very precise access control to resources as further explained below.
Automatic and Manual Installation
Moodle can be installed automatically by scripts such as Fantastico, which is where we started and although very easy, it does create 2 major problems. Firstly you can’t decide to install a latest version when you wish (only when your webhost provides that update script), although minor upgrades within versions may be possible (e.g. 1.8.2 to 1.8.4 – at your webhost’s discretion). Secondly your data files are set up in a directory within the public HTML folder of your website. In other words, you can’t really stop anyone downloading them – bad for business and potentially also bad for IP/copyright liability.
For our English language teaching, we needed a feature of Moodle 1.9 (longer text boxes in SHORTANSWER questions) and my CPANEL Fantastico couldn’t help upgrade past 1.8.4, so I needed to learn how to do a manual installation - not so bad after all – phew! A consequence of this was that now our data files were in a folder in the root directory of our domain. Good for security, bad for easy access – two sides of the same coin.
Method to have publicly accessible files (using site files / front page)
Moodle accesses this data directory using a file called file.php in the folder /public_html/moodle/ (In our case we had installed Moodle into a subdirectory rather than the main public folder of our website.) Sometimes this is also referred to as the root directory (because it is the deepest a web browser can see), but the root directory of the domain is one level deeper than this (where your site mail is stored for example). You need to use your CPANEL file manager to browse this area.
An FTP client can also do it if you set it up with the domain root as its default remote directory. I strongly recommend using an FTP client to manage your data files. It will save time and ultimately your sanity. (I use FileZilla Portable)
So file.php is in the public area and this ‘re-directs’ your file requests to the otherwise-inaccessible Moodle data directory one level deeper. I couldn’t decode the php in this file but it turns out you don’t need to.
In the data directory are subfolders named with numbers (1, 2, 3 etc) which correspond to your courses. The front page is actually a course as well and has the ID of 1. You can find the ID number of any of your courses by looking at its URL. The URL for my site files folder is: http://www.workplaceenglish.com.au/moodle/files/index.php?id=1
Yours would be the same apart from the domain name, and perhaps you wouldn’t have the subfolder /moodle as your installation location. The important bit is /files/index.php?id=1 because this redirects the file request to the hidden data directory (wherever it may be) and further to the actual course containing that data (front page in this case).
Files contained here are publicly accessible – simply because your front page is public, as it needs to be. However if you enter the above URL into your browser, you will still be redirected to our login screen. (I believe that is because you would need administrator, or at least enrolled, privileges to view an entire folder’s contents.)
Happily though, you can link directly to files within that folder. For example this is the URL to the logo image on our front page: http://www.workplaceenglish.com.au/moodle/file.php/1/logo.jpg
If you enter this URL in your browser it will bring up the logo without the need for logging in. This will work for any file you place in the front page files area (which is the same as the site files area). Again, the important bits are /1/logo.jpg the course ID and file name. Subdirectories will also work.
Method for controlled access files
The same method as above works for any course. For example we have a course (still in draft) with the URL: http://www.workplaceenglish.com.au/moodle/course/view.php?id=2
To access a file uploaded for this course we would use (for example):
Now whatever restrictions are placed on that course will apply to access of that file. If the course allows guest access, then logging in as a guest allows access to this file. If you allow guest access but with a key, then that works as well, and so on all the way up to needing to be fully enrolled (and having paid).
This precision in access control is even better that most website Content Management Systems (like Joomla) offer – another reason for using Moodle as your CMS as well as LMS. If only I had known this six months ago!
Intellectual Property and Copyright Protection
Teachers have an obligation to protect the copyright of materials they use in their courses. So for example we use audio files for listening scripts from our course books. Placing them online is ‘sailing close to the wind’ legally, but at least we have the defence of restricting access to our immediate class. Moodle allows us to define enrolment periods and control the availability of courses. The media filters also make it possible to play media files whilst hiding their location. That’s about as much IP/copyright protection as any conventional language listening lab or CALL lab could offer.
For material we generate ourselves, including text content of lessons as well as audio/visual material, we have adopted a three stage approach as follows.
Low grade material such as YouTube-quality video is made freely available via the front page / site files area. This material is also posted as ‘teasers’ on YouTube, Google Video, Second Life and other sites for viral marketing purposes and to drive visitors to our site. Higher quality versions of that material are made available via enrolled courses (which may require enrolment fees). Ultimate quality material is made available via paid-for courses specifically set up to deliver premium grade resources.
It is possible to externally access Moodle data files normally hidden from public view. In fact using Moodle as your file access control mechanism is a very good idea, as is using Moodle as your CMS because of its account and course settings functions. You can have very fine access control ranging from public-free to restricted-paid-for.
I hope this helps.
That is a great compliment. I'll try to do that.
One question that I still have is any possibility of making Site materials more portable (or knowing "if" they are). What I mean is "hard-coded links" don't work as soon as something is moved or renamed. For example if a backup is made to make a copy of a course using some site material in another moodle.
For example if I put a java applet I wish to use in several courses in the /1/ file area and I want to copy one of the courses to another moodle. I assume the usual course backup wouldn't include things in /1/ (or is Moodle that advanced?). Could I just make a backup of the frontpage, /1/, (with just the parts needed for the course I want to copy) and restore that too, on the other site? If the links start from the public_html root "/moodle/" and the Moodle site course is in THAT folder on the new site, my guess is that it might work.
Is there any php tool for bulk updating links on the server otherwise? (There is, of course, the possibility to unpack locally and use a search and replace tool, before uploading to the server.)
We have installed a fresh Moodle 2.02 site and we want to use content we created that is currently hosted on a remote hosted site in version 1.9.8. We don't have access to the file system outside of Moodle for this installation like we have for our own hosted new site. We would like to see definitive instructions, step by step to backup to a zip file, content elements where users can migrate sections of content to newly created content areas in the Moodle 2.02 site structure.
We believe the ability to selectively or in bulk, port content by suitably authorised administrators from an old installation to a new installation should be included as an administrative tool with source and destination wizard type functionality included. Users will value and want to reuse content accross Moodle version and perhaps hosting scenarios.
In the absence of such a tool instructions would be most helpful and greatly appreciated.
The information in Mike's post is very useful for reverse engineering purposes and we are most grateful for his efforts to share such helpful information. Nonetheless there still needs to be a mature, tested and verified migration procedure posted in Moodle docs for something as important as migration of content.