I'm not exactly sure how useful it will be to have the Pathauto pattern for files defaulted to file/[file:name] especially since when you install the module, [file:name] by default is the basename of the file on the system. Not exactly the most useful. Also this can create conflicts if I named a file '1' so that now the alias file/1 overrides the system path file/1.
Pathauto integration is good and useful, but I don't agree that it's useful enabled by default. Discuss?
| Comment | File | Size | Author |
|---|---|---|---|
| #14 | file_entity-leave_pathauto_pattern_blank-1959268-14.patch | 720 bytes | othermachines |
| #4 | 1959268-4-pathauto-defaults.patch | 736 bytes | aaron |
Comments
Comment #1
devin carlson commentedMy 2¢:
The content editors here always change a file's filename to something more friendly after it's uploaded. It makes finding existing files much easier (on the file listing page, in the Media Browser and when linking to files using CKEditor Link File).
In the event that they don't input a filename manually, they still prefer to pass around poorly formed URLs (example.com/file/new-memo-finaldoc) over plain file IDs since they still give some idea of what file they represent vs. file IDs.
How does pathauto deal with other entities when it comes to aliases conflicting with system paths and are there any ways around it?
Should a filename field be added to the file upload wizard so that users can give files a "proper" filename during upload?
Do any other entity types provide Pathauto integration but are disabled by default? If not, do you think that it will be confusing to users who expect that pathauto just works automatically out-of-the-box?
Comment #2
dave reidpathauto deals with it by failing to save the alias. I'm just not sure how useful this is to be configured by default. As a pathauto maintainer, I don't really like that we ship with aliases by defaults since most people go in and have to change them anyway, and then have ended up with a bunch of aliases that they don't want or need that have already been generated. I would prefer if site builders made choosing the alias patterns something they had to think about first.
I'd like to get more input on this proposal.
Other things to note:
http://drupal.org/sandbox/damz/1332096 (pathauto integration for all entity types) uses empty string by default.
Comment #3
aaron commentedI agree with both the points here. On the one hand, I think that it would be best to leave it blank, however, considering that pathauto currently sets some defaults, it might make sense to add a default for file entities as well. However, if we do that, I don't believe that it would be good practice to leave the first element of the URL alias as file/ because of the overriding issue. Perhaps it would be better to call it files/ instead. Otherwise I am neutral as to what direction we choose to go.
Comment #4
aaron commentedThis patch makes the pathauto pattern default to files/fid.
Comment #5
aaron commentedBumping for review and comment.
Comment #6
aaron commented#4: 1959268-4-pathauto-defaults.patch queued for re-testing.
Comment #7
aaron commentedI have committed this to http://drupalcode.org/project/file_entity.git/commit/e74d2f2
Comment #9
dave reidEncountered this on several projects, I'm still thinking it would be better to be blank by default.
Comment #10
dave reidAnother argument against having a default pattern by default, is that is when a file is originally created/uploaded, typically users go in and rename the file name field to a more human-readable name. This means that the file is first created with an alias of files/file-name.pdf and then gets changed to files/nice-pdf-title. For most users that have Pathauto + Redirect both installed, this means that for every file that this happens for, they will have a redirect created that didn't need to exist.
If we are going to provide a default Pathauto pattern, it should only apply if the file is permanent.
Comment #12
othermachines commentedSeems to me providing a pattern is a convenience for some but creates issues for others; leaving it blank is an inconvenience for some and creates no issues.
To me it seems like a no-brainer to leave it blank (FWIW).
Comment #13
joseph.olstad@othermachines, can you please provide a patch for setting the pathauto to blank ?
Comment #14
othermachines commentedSure thing. I'm never sure about posting patches when people are disagreeing. :) Two years is a long time though.
Comment #16
joseph.olstadcommitted in 7.x-2.x branch, thanks