|
|
|
File Attachments:
|
1.
hash.php (0.8 kB)
2.
newhash.php (0.8 kB)
|
|
Issue Links:
|
Dependency
|
|
This issue will help resolve:
|
|
MDL-11776
user profile pictures no longer display
|
|
|
|
|
MDLSITE-180
Cannot upload image to 'picture of' in 'edit profile'
|
|
|
|
|
|
This issue will be resolved by:
|
|
MDL-10905
Backup misses files if a directory name evaluates to false (eg. "0")
|
|
|
|
|
Relates
|
|
|
|
This issue has been marked as being related by:
|
|
MDL-14550
backup\backuplib.php user_files_check_backup() is invalid
|
|
|
|
|
MDL-13763
1.9 user pictures loading from old location
|
|
|
|
|
|
|
| Participants: |
Andrea Bicciolo, Anthony Borrow, Eloy Lafuente (stronk7), Iñaki Arenaza, Jose Rama, Martin Dougiamas, Nicolas Connault, Oswald Zangerle, Petr Skoda, Red Morris, Ryan Smith and Tim Hunt
|
| Security Level: |
None
|
| QA Assignee: |
Petr Skoda
|
| Resolved date: |
21/Oct/07
|
| Affected Branches: |
MOODLE_18_STABLE, MOODLE_19_STABLE
|
| Fixed Branches: |
MOODLE_18_STABLE, MOODLE_19_STABLE, MOODLE_20_STABLE
|
|
Currently (all Moodle versions) under the moodledata/users directory, one dir with the userid is created to store, basically, the avatar of the user. This system has two big drawbacks:
1) BIG sites are beginning to raise the "Max files per dir" OS limit. And usually, this is one hard limit.
2) The structure under each userid directory is pretty plain and we should start to accommodate it for future personal storage.
So, I would propose to:
1) Create one simple algorithm that, based in one number (userid), will return one unique hash of fixed length.
2) Create one function - create_user_dir($userid) - in order to create the user storage area. Such storage area should be created by creating nested subdirs with parts of the hash calculated in step 1 (nor raising, say, 12 bits, per name = 4096 dirs per dir). This function could have one optional parameter ($migrate = false), to allow migration from old user storage areas to the new ones transparently.
3) Create one function - get_user_dir($userid) - in order to get the path to the user storage area. This function should check for the new areas + the current ones in order to keep compatibility.
4) Inside each user storage area, create one "private" dir, where we'll move the avatars. Such "private" dir is intended to store files that are handled by Moodle but without FileManager access for students in the future.
5) Change all current uses of user storage area to use the functions defined above.
6) Document it to allow developers to know how they must handle files in that zone.
Sounds simple. Ciao :-)
|
|
Description
|
Currently (all Moodle versions) under the moodledata/users directory, one dir with the userid is created to store, basically, the avatar of the user. This system has two big drawbacks:
1) BIG sites are beginning to raise the "Max files per dir" OS limit. And usually, this is one hard limit.
2) The structure under each userid directory is pretty plain and we should start to accommodate it for future personal storage.
So, I would propose to:
1) Create one simple algorithm that, based in one number (userid), will return one unique hash of fixed length.
2) Create one function - create_user_dir($userid) - in order to create the user storage area. Such storage area should be created by creating nested subdirs with parts of the hash calculated in step 1 (nor raising, say, 12 bits, per name = 4096 dirs per dir). This function could have one optional parameter ($migrate = false), to allow migration from old user storage areas to the new ones transparently.
3) Create one function - get_user_dir($userid) - in order to get the path to the user storage area. This function should check for the new areas + the current ones in order to keep compatibility.
4) Inside each user storage area, create one "private" dir, where we'll move the avatars. Such "private" dir is intended to store files that are handled by Moodle but without FileManager access for students in the future.
5) Change all current uses of user storage area to use the functions defined above.
6) Document it to allow developers to know how they must handle files in that zone.
Sounds simple. Ciao :-) |
Show » |
committed 11 files to 'Moodle CVS' - 11/Oct/07 05:01 PM
MDL-8605 New user directories implemented
|
|
|
committed 11 files to 'Moodle CVS' on branch 'MOODLE_19_STABLE' - 11/Oct/07 07:12 PM
MDL-8605 New user directories implemented
|
|
|
committed 9 files to 'Moodle CVS' on branch 'MOODLE_18_STABLE' - 11/Oct/07 09:19 PM
MDL-8605 New user directories implemented
|
|
|
committed 3 files to 'Moodle CVS' on branch 'MOODLE_18_STABLE' - 11/Oct/07 10:16 PM
MDL-8605 Minor typos and version.php fix
|
|
|
committed 1 file to 'Moodle CVS' on branch 'MOODLE_19_STABLE' - 11/Oct/07 10:18 PM
MDL-8605 Preventing new user folder from being created when original folder is empty
|
|
|
committed 1 file to 'Moodle CVS' - 11/Oct/07 10:19 PM
MDL-8605 Preventing new user folder from being created when original folder is empty
|
|
|
committed 2 files to 'Lang CVS' - 12/Oct/07 01:17 AM
Translated a new string for New user directories MDL-8605.
|
|
|
martignoni committed 1 file to 'Lang CVS' - 12/Oct/07 04:38 AM
MDL-8605 New user directories implemented
|
|
|
committed 7 files to 'Moodle CVS' - 13/Oct/07 03:13 AM
MDL-8605 More changes to upgrade and restore, and some unit tests with db and rs mock objects
|
|
|
committed 8 files to 'Moodle CVS' on branch 'MOODLE_19_STABLE' - 13/Oct/07 04:24 AM
MDL-8605 Backup and restore implementation
|
|
|
committed 1 file to 'Moodle CVS' - 13/Oct/07 04:25 AM
MDL-8605 using remove_dir instead of rmdir, which doesn't support deleting non-empty directories
|
|
|
committed 5 files to 'Moodle CVS' on branch 'MOODLE_18_STABLE' - 13/Oct/07 04:26 AM
MDL-8605 Backup and restore implemented, and using remove_dir instead of rmdir, which doesn't support deleting non-empty directories
|
|
|
committed 2 files to 'Moodle CVS' on branch 'MOODLE_18_STABLE' - 14/Oct/07 06:05 AM
MDL-8605 quick fix for broken user pix upgrade
|
|
|
committed 1 file to 'Moodle CVS' on branch 'MOODLE_18_STABLE' - 14/Oct/07 06:14 AM
MDL-8605 eh, forgot to undo some testing code before commit, sorry
|
|
|
committed 2 files to 'Moodle CVS' - 15/Oct/07 01:17 PM
MDL-8605 putting versions in sync between 1.9 and head
|
|
|
committed 2 files to 'Moodle CVS' on branch 'MOODLE_19_STABLE' - 15/Oct/07 01:18 PM
MDL-8605 putting versions in sync between 1.9 and head
|
|
|
committed 1 file to 'Moodle CVS' on branch 'MOODLE_19_STABLE' - 16/Oct/07 12:54 PM
MDL-8605 Upgrade of user folder will not occur if the user folder already exists
|
|
|
committed 1 file to 'Moodle CVS' - 16/Oct/07 12:54 PM
MDL-8605 Upgrade of user folder will not occur if the user folder already exists
|
|
|
committed 1 file to 'Moodle CVS' - 21/Oct/07 04:57 AM
committed 1 file to 'Moodle CVS' on branch 'MOODLE_19_STABLE' - 21/Oct/07 04:59 AM
MFC: MDL-8605 fixed user image restore code
|
|
|
committed 1 file to 'Moodle CVS' on branch 'MOODLE_18_STABLE' - 21/Oct/07 05:04 AM
MFC: MDL-8605 fixed user image restore code
|
|
|
committed 1 file to 'Moodle CVS' on branch 'MOODLE_19_STABLE' - 12/May/09 03:46 PM
MDL-8605 New script (web and CLI) for restoring user profile pictures that failed to move to the new folder during upgrade.
|
|
|
committed 1 file to 'Moodle CVS' on branch 'MOODLE_18_STABLE' - 12/May/09 03:46 PM
MDL-8605 New script (web and CLI) for restoring user profile pictures that failed to move to the new folder during upgrade.
|
|
|
|