Last modified: 2014-05-22 22:47:05 UTC
As discussed in IRC with ^demon, varnent, myself, sumanah, etc, a plan for migrating the "images" directory to "files" or more likely, "uploads" should be in place. ^demon has concerns about the buildup of backwards compatibility cruft, so to address that, some thought needs to be put into the issue of eventually obsolescence by gracefully driving the "images" directory to extinction. I propose that just one small, simple, manual change by a wiki admin is acceptable with each new upgrade, for the purpose of eliminating obsolete installations and compatibility code.
Here's a good example of a file path that can cause confusion for users (login with Demo/test if needed): http://www.coincompendium.com/w/images/5/5e/LargeBlindSubmission.csv That's a CSV file, but the path makes people expect it to be an image.
I believe that badon and ^demon bring up good points. I've had enough end-users complain about the images folder to change the setting on some wikis before. Not always the most tech-savy end-users sure, but we don't get to set the skill level of our readers (sadly). I haven't done a sampling or thought to ask before now, but I would not be surprised to learn that new sysadmins have run into problems not understanding this. I have scratched by head about it several times and now that others have too, whether they'd admit to it actually causing them problems...not sure...but can check. Similarly, as more and more other open-source projects begin to standardize terms like "uploads" and "themes" - anyone coming into MW work has a handicap in that our terms and setup are unique. Moving towards standard language has a lot of advantages for long-term developer recruitment and ease of support for third-party wiki sysadmins. At the same time, upgrading third-party wikis seem infamous for not reading the upgrade notes. So I think the actual setting would need to be backward compatible - and probably remain that way for several versions to come (if not forever, or until "2.0").
I bet the confusion increased for users whose first language is not English. In addition, now that I think about it, I prefer "files" over "uploads" just because of the way the URL path will read. For example http://www.somewiki.com/w/files/5/5e/download_this_file.xyz versus: http://www.somewiki.com/w/uploads/5/5e/download_this_file.xyz A user looking at the file path may be confused as to whether the link lets them download, or asks them to upload. So, I think the neutral "files" word is a better choice than "uploads", and also happens to match the files namespace for even more consistency and clarity. I'm going to rename the title of this to match that, if everyone agrees "files" is a better alternative to explore than "uploads".
Regarding files vs. uploads - I'd favor whichever seems to be most common in projects right now - which I think is uploads - but I could be wrong. :)
The major place I see people getting confused right now is the error messages relating to "public" because people have *zero* clue what that means. That should be fixed regardless of what we decide here (and it's bug 13812)
Unless backwards compatibility is maintained, I feel changing this would result in orders of magnitude more confusion than any confusion caused by the current name of the directory. (and backwards compatibility for something like this would probably be kind of ugly) There's even a README in the image directory to explain what it is. Its not like we're putting uploaded files in a directory whose name is logically disconnected from the action of uploading. As an aside, according to [[manual:$wgUploadDirectory]] we used to use uploads directory until about 1.8. Making breaking changes with almost no benefit = bad imho.
I think the benefit is dependent on who you ask. If I had a site for videos, I'd be annoyed that every link said they were "images". Same goes for anything that's not an image, which is a non-trivial use-case. I'm sure this is something that will have to be changed eventually, even though it may not be urgent. My usage of MediaWiki does not hinge on this issue, but even I would appreciate the change, as long as it was done carefully, with due respect for upgraders.
This can trivially be solved without breaking backwards compatibility by letting the installer add $wgUploadDirectory to LocalSettings.php for new installs. I agree with Bawolff that making this a breaking change would be unacceptable.
That sounds like a quick and easy solution. I'm in favor of that solution, for new installations. Any more opinions about what we should call it? Varnent favors "uploads", I favor "files". Any other opinions or suggestions?
(In reply to comment #9) > That sounds like a quick and easy solution. I'm in favor of that solution, for > new installations. Any more opinions about what we should call it? Varnent > favors "uploads", I favor "files". Any other opinions or suggestions? What if we let user specify it like the dbtable prefix and default to "files"?
>What if we let user specify it like the dbtable prefix and default to "files"? We certainly could, but it seems like that'd be just adding another question that 99% of the userbase doesn't care about [which i would consider a bad thing]. (but then again I think this entire bug is an exercise of bikeshedding for an already built bikeshed, so I'm probably biased)
(In reply to comment #10) > (In reply to comment #9) > > That sounds like a quick and easy solution. I'm in favor of that solution, for > > new installations. Any more opinions about what we should call it? Varnent > > favors "uploads", I favor "files". Any other opinions or suggestions? > > What if we let user specify it like the dbtable prefix and default to "files"? You already *can* specify the upload directory in the installer. This is about changing the default and making sure people with current default settings work on upgrade.
In favor of "files", Special:SpecialPages contains these phrases: Most linked-to files Search for duplicate files Upload file Gallery of new files File list File path Uncategorized files Wanted files Unused files Media reports and uploads (section heading) So, out of 2 uses of variants of the word "upload", one of them uses it as a verb instead of a noun to say "Upload file". The other uses it in combination with "Media" in a section heading. That's a strong precedent for the usage of variants of the word "file" instead of "upload", especially considering that we have a "File" namespace for all uploads, but not an "upload" namespace. To choose the word "upload" over "file" would probably be more confusing than "image", since all but one phrase in MediaWiki that speaks of the subject uses the word "file". Indeed, the one phrase that doesn't use "file" - "Media reports and uploads" - probably ought to be changed to "File reports".
Badon: those are fair points - and my main interest in whatever seems to be the least confusing and most commonly used. I switch my vote from uploads to files. :)
By altering setup.php we could set $wgUploadPath & $wgUploadDirectory to use 'files' unless "$IP/images" exist. Thus fresh installs will use the new 'files'. Older install will stick to 'images' on upgrade until the admin manually rename the 'images' directory to 'files'.
(In reply to comment #15) > By altering setup.php we could set $wgUploadPath & $wgUploadDirectory to use > 'files' unless "$IP/images" exist. How would you test existence?
Since these are configuration variable values, they have no migration path. There should be no hardcoded reference to "images" anywhere other than in the default settings setup. We can flip the default and that's it. Existing wikis that care can change their configuration value to their liking and move their directory at will. One thing to keep in mind is to make sure that wikis not having $wgUploadPath & $wgUploadDirectory defined in LocalSettings. I suggest the updater harcodes these to LocalSettings if they are not defined otherwise – before setting the new defaults.
(In reply to comment #17) > Since these are configuration variable values, they have no migration path. > There should be no hardcoded reference to "images" anywhere other than in the > default settings setup. > We can have a migration path, see comment 15. In response to comment 16, it would be as simple as doing a file_exists() && is_dir() on 'images.' In fact, we could end up setting it to null in DefaultSettings rather than $IP/images and that'll make it easier to detect if the user's customized it (leave it alone) or to use the default behavior. > We can flip the default and that's it. Existing wikis that care can change > their configuration value to their liking and move their directory at will. > Only that doesn't happen. People don't read the RELEASE-NOTES, they upgrade, and their wiki breaks so they file a bug. Happens every time. So this change absolutely must cause no b/c break. > One thing to keep in mind is to make sure that wikis not having $wgUploadPath & > $wgUploadDirectory defined in LocalSettings. I suggest the updater harcodes > these to LocalSettings if they are not defined otherwise – before setting the > new defaults. See above.
