Please use talk page for comments and proposals, thanks.

Current problems

plain text and html resource types separate
embedded images and files in general are stored in course files without appropriate access control
local files and Internet links mixed
HarvestRoad Hive repository type is not maintained.
embedded images are lost during backup & restore which moves the course to a new site. -- Matt Gibson 08:53, 18 May 2009 (UTC)
can't move a "whole" web page properly from one course to another (eg course import).

Types of resources

Plugin	Moodle 1.9	Moodle 2.0
directory	a directory of files on disk	a collection of files in database
html	A html page, containing media from course files or external	A html page, containing associated media or external
text	A plain text page in some format	?
file	A single file, from course files or external URL	A single file, associated file or external URL
ims	An IMS resource package from course file or repository web root	An IMS resource package from associated files
repository	Links to external files in repositories (ie Hive)	(na)

There are other third party plugins in contrib that need to be migrated:

mod/book - displays multiple pages of HTML etc
mod/resource/type/digitalnz - browser and add items listed in http://www.digitalnz.org/
mod/resource/type/globe - browser and add items in Ariadne repositories
mod/resource/type/jmol - display chemistry structures from a jmol format file
mod/resource/type/rss - display one RSS feed on a page
mod/resource/type/slideshow - display a directory of images as a slideshow

Automatic upgrade

Each resource type requires different upgrade code because the files are stored in different places that require special handling. They also have different settings and options with different text encoding in the table fields: reference, alltext and options.

Resources that can not be completely migrated during upgrade time will be flagged using a new field called legacyfiles:

0 = new resource created in Moodle 2
1 = upgraded resource that has completed migration
2 = upgraded resource that has not started migration yet
timestamp = last date of a migrated file within this resource

File

Files in the course directory

Copy the linked file (image, sound, pdf, HTML, etc.) from course area to resource file area
If the file is HTML or SWF then flag this resource for post-upgrade processing with legacyfiles = 2 (see next section), otherwise flag with legacyfiles = 1

Files referenced by URL

(This includes links to other courses and site files)

This does not require any upgrade. The url is stored in reference field and will continue working.

Page (Web and Text)

Convert to one plug-in called 'page' (editable via the new editor forms element)
Flag this resource for post-upgrade processing with legacyfiles = 2 (see next section).

IMS

Copy files from moddata to new resource file area
Copy original backup of package file to another new resource area

No other special upgrade steps required.

Repository

Work out the URL of the resource and convert it to a simple URL.

Others

(TODO: Add some docs here for each type)

Post-upgrade processing

After the Moodle 2.0 upgrade has completed we take the admin to a special page that:

explains the issue of resources that contain links to other files
explains how it can be fixed by on-demand migration (see below)
presents an option for "automatic parsing" which tries to automatically migrate simpler resources such as HTML files with links to HTML files, images, CSS
presents a list of remaining flagged resources as links that need to be visited manually in the browser to be fixed

I imagine this interface might have a small frame on the left with the main pages being loaded in the larger frame on the right. The left frame has controls and info like:

total number of pages to process
next and previous buttons
some button to say "I have completely viewed this resource"

So the admin will have to sit there and go through all these resources and check them off to complete the upgrade. Until this process is finished none of these operations can be guaranteed to work so we might even think about disabling those operations:

Backup
Restore
Import of a course

Normal viewing of resources WILL work fine for teachers and students, because it will just trigger the normal on-demand migration of files.

On-demand migration of files

After the upgraded process we will have resources flagged with legacyfiles = 2 that need migrating, including:

html files possibly containing images, applets and javascript
flash applets containing relative links to media (eg sounds or images)
java applets containing relative links to media
javascript that loads media via relative links (eg imagine an auto-generated slideshow)

We still want to move all these legacy files into the correct resource filearea, so we do it like this:

When a browser requests to view one of these "legacyfile" HTML files, it will load all the JS and Java and Flash it contains.
These programs run, and make relative requests to media if they want to.
These request to Moodle will hit the pluginfile.php script
The pluginfile.php script checks that the file doesn't exist yet in the resource file area, and if so:
pluginfile.php uses the relative path to copy the original file from the courses area to the resource file area
pluginfile.php updates legacyfile field for the resource to be the current timestamp, indicating that some processing has happened.

Problem: we don't really know when the resource is completely "finished" (ie every single associated file has been checked), so we can't automatically reset legacyfiles = 1 after this process. That's why the manual post-upgrade script described above is necessary.

Code refactoring proposal

Technically it would be difficult to split current Resource into multiple modules. The idea of module subplugins was only implemented only partially, it should be much easier to split unmaintained plugins into separate modules in contrib. Considering long term maintenance and support costs it might be better to create a minimal resource-like module skeleton in contrib instead of encouraging people to create new unofficial resource plugins.

Subplugin related problems

no standard subplugin APIs
all internal module API frozen - no internal refactoring allowed
subplugin regression more likely
sloppy db table structures - many universal columns with
no standard way to upgrade subplugins - main version file needs to be bumped up
no standard way to uninstall subplugin - db table leftovers
capability in subplugins not supported
subplugin upgrade is not integrated into main module upgrade - subplugin upgrade is executed after the main module upgrade (critical)
subplugins can not have own lang packs
subplugins do not have own log actions
instead of reducing code duplication advanced plugins may duplicate a lot more core
it is not easy to move unmaintained subplugins into contrib
unofficial subplugins not reported during upgrade
no support for subplugins in file api

Option 1: split Resource into multiple modules

mod/resource - formatted text pages
mod/resourcefile - one or more uploaded files
mod/resourcedir - directory structure
mod/resourcelink - links to external files

+1 to shorter names, like "rsrcfile, rsrcdir ..." due to DB restrictions mainly. --Eloy Lafuente (stronk7) 16:20, 19 May 2009 (UTC)

Activities block would have to be updated to group all resources onto one page instead of listing all resource modules separately. This can be accomplished easily by adding new field into core modules table.

Benefits:

easier maintenance in future
easier upgrade (no problems with new db fields)
showcase of good coding style for beginners
more contrib modules may behave like the real resources (from users' POV)
no need for solving of any subplugin problems

Option 2: keep Resource submodules/types

mod/resource/type/page - replaces Plain text, wiki and HTML resources
mod/resource/type/file - one or more uploaded files one is marked as the main file
mod/resource/type/directory - one or more uploaded files
mod/resource/type/link - links to external files
mod/resource/type/ims - IMS packages, maintained by Eloy

Problems:

each type needs different db structure
we should solve all subplugin problems above (a lot of work, hard to maintain)

Moving to contrib

New module/type for special mod/resource/type/file/localfile.php (win32 only tweak) - originally intended for large files stored on local networks or CDs
(No idea what to do with hive repositories, we should also remove the obsoleted auth hive SSO support)

Other ideas

Dealing with caching issues

To have more control over the caching of files, we could use the same mechanism already implemented in the SCORM module, by changing the URL:

Internally store all files as itemid=0
Add new revision db field into resource table
When serving files always construct links with itemid==revision
Ignore itemid for resource files in pluginfile.php

Documentation

Development:Resource module file API migration

Contents