Talk:Resource module file API migration
Current problems
embedded images are lost during backup & restore which moves the course to a new site. -- Matt Gibson 08:53, 18 May 2009 (UTC)
Separate contrib modules
New local files module - contrib - ???? --Eloy Lafuente (stronk7) 16:21, 19 May 2009 (UTC) mod/resource/type/file/localfile.php is a win32 only hack which is not maintained much these days Petr Škoda (škoďák)
Extracted from HQ chat, pending to confirm (Y/N)
I liked the :
- 0 = native 2.0
- 1= flagged as migrated
- 2= pending to migrate
- lastmodified = for still being migrated-on-demand resources
- so, anything with flag > 2 is susceptible to be marked as migrated (1) by any process (manual/automatic or whatever we can implement) and, at the same time, we keep native (0) and flagge (1) d separate, helping to know the orgin of the resource in case we need it later.
- so, on upgrade... I'd mark everything as pending to migrate (2) and then, think on possible ways to perform the lastmodified => 1 conversion (but never to 0. it's reserved for native 2.0)
--Eloy Lafuente (stronk7) 09:38, 28 May 2009 (UTC)
TODO - explain exactly how pluginfile can derive ...
Here it's a tentative explanation:
The whole path (within legacy course files) will be fully retained when copying files to the resource files area.
So for example, if we have one resource pointing to: "some/dir/with/index.html file", the "some/dir/with" directories will be created (if don't exist) in destination resource file area and then the "index.hml" file will be copied there (also, if don't exist, obviously).
Then, advancing in the example, if that html includes one link to say: "another/different/dir/style.css", then the "another/different/dir" dir will be created (once again, if it doesn't exist) and then the "style.css" file with be copied there (do you guess when? :-P ).
That way, by retaining the "relative paths" present in legacy course files when copying them to 2.0 resource file areas, the only change will be that old resources being server by "file.php" will be now served by "pluginfile.php", (with different parameters related to course/context/filearea, not important) but 100% equivalent in all their relative links.
--Eloy Lafuente (stronk7) 09:49, 28 May 2009 (UTC)
