Pretty URLs instead of "webfm_send"

I think this is a very good suggestion.
subscribing.

I recently did something like this. This uses the webfm-root-directory name.

I also made some changes around the way titles are handled by modifying the modules hook_menu. This patch includes the following changes:

• Translated titles instead of strings in the link titles
• format_date is now used, the date settings form the webfm interface are ignored
• Somewhat prettier urls:
  • Patch above is included: "webfm_send" is renamed to your root directory
  • URLs are created upon the directory structure you choose within webfm.

My hope is to implement some kind of IP-based access control using the paths. Also I've got to say: The attached

subscribe

There is a problem with this apporach: Currently you can rename or move files and directories around in webfm, but the webfm_send url will always stay the same. Thus, any download links/hrefs will stay valid even if you move a whole subdirectory into another one (a situation that we really have from time to time).

Reflecting the webfm directory structure in the download URL causes the same problem as with the filesystem: if you move/rename a file, all old links are broken. Unless you really reimplement the whole pathauto stuff for keeping or redirecting old download URLs when a new one is created by moving/renaming. I just wrote a pathauto patch for exactly this part of code and I can tell you that it is not trivial :-/ You would need another database for keeping all ever generated URLs if the user demands that.

I think abstracting from the real path and filename for download links by using webfm_send is a top feature of webfm, and I couldn't live without :-)

Actually not :-) The problem you describe would only occur, if you rename the root-directory - I guess one could implement an redirect then.

Other than this, this option is fully backwards compatible: I keep the id in the path.

Consider this example:
Old path: webfm_send/40
New path: webfm_send/folder1/folder2/40/file.name

The "usless" information (folder1, folder2, file.name) is stripped - only the id is kept. So webfm_send/folder1/folder2/40/file.name is actually webfm_send/40, it just looks prettier.

If you move your files to folder3, your url will become webfm_send/folder3/40/file.name, still webfm_send/folder1/folder2/40/file.name remains functional

Only if you choose to rename webfm_send, which represents the local root folder you would need to rename the path.

This would solve your problem Frank, however it is also an access problem. You cannot create rules from a path like this, so it probably isn't such a great solution after all. You are probably right that it would be better to think about implementing some hooks from pathauto!

Some adjustments about the patch:

1. Kept the webfm_send - path for compatibilty
2. kicked out left over dfb()

Ok,sounds better. So far you were talking about replacing the webfm_send part :-) Do I get it right that the webfm_send/nn stuff always works, and everything else are just additional aliases?

If you reverse-engineer the id from the alias, have you checked it works also with filenames like "40/bla", possibly resulting in a URL like "../30/40/bla"? I guess you can filenames with / in Windows? Those are cases one has to be careful with.

Btw., I guess all this should be configurable. E.g. I wouldn't like to expose my webfm_root in the download URLs as it is quite long and would make all download links too long an ugly :-)

This now makes use of the pathauto and token module to create or update url aliases, according to your pathauto-module settings.

Note:
You must check out a fresh copy of webfm in order to use this.

What do you mean by "fresh copy"? Do I need the latest cvs? The patch applies to 2.10-rc4.

However, I'm not sure how it is supposed to work. I uploaded a file and in the webfm table I see that is has the full path as title. But when I attach the file, the link in the attachment table still contains the webfm_send href.

If you just want to add the aliases additionally without changing the webfm_send mechanism (which would be a good approach), then how can I see/get the created alias, so that I can insert it somewhere?

A remark: there should be a global option to disable this feature. Not all people might want to have these aliases created. We have over 10.000 files in our db and I wouldn't like to have 10.000 URL aliases :-)

"fresh copy" -> I suggested some patches above and since I cannot remove them I was just trying to make clear that they don't go with the patches above - other than that I've got my webfm copy from cvs.

A few quick remarks about webfm_pathauto_patch.txt:

• You need the pathauto module.
• You have to make sure you set up a pattern at admin/build/path/pathauto. (Default is to keep the original pattern webfm_send/ID)
• Yes I am aliasing the original webfm_send path. This means that the original webfm_send/20 paths will still work.
• It should work like this: If a file is added to webfm it is also inserted into the webfm-database: A webfm-file-ID, eg. 42 is created - now we can use a path like webfm_send/42.
  When the file is added to the database the alias is created depending on your pattern. Drupal applies this alias if the url() function is used.

Ah, ok, I was missing the pattern definition. So without no alias should ever be created.

I've added the "Paste Link in Editor window" to webfm a while ago. Maybe you would like to add an additional context menu entry allowing to paste the alias, too. For people who want to insert links to attachments manually, so that they can get the alias, too.

A question (not reviewed or tested): will the alias change when you move/rename a file/directory within the webfm gui? I guess it shoult, but it depends on where you call the alias generation.

Although I haven't neither reviewed or tested the patch carefully, I like the idea of the pathauto integration! Very clean approach!

Actually you mentioned the problem with moving the file above - that is the main reason for this patch. I realized that once you move the file your old path might be gone. So once you choose to move your file through webfm, webfm.module needs to update its database - thats when the alias is updated as well, according to your pathauto settings (delete/redirect/upgrade old path).

Besides that I might take a look at the context menu.

Hi Niels,

Just getting around to older posts and this looks to be a nice solution for those who don't like 'webfm_send' urls. Thanks again Niels. I fixed a bug that dropped the filename from the path :

          //$reldir = trim(str_replace(file_directory_path(), "", dirname($webfmfile->fpath)), '/\\'); //find root path down to webfm-root
          $reldir = trim(str_replace(file_directory_path(), "", $webfmfile->fpath), '/\\'); //find root path down to webfm-root

It appears to mostly work though I've seen an issue with pdf files.

Hej Rob,
are you sure this needs to be changed?

I am filling the token 'webfmfolder-path-raw' with a value there. You can use this token in the setup to have a representation for the folder path. There is a different token for the file Name.

Now to fill this token ($values['webfmfolder-path-raw'] = $webfmfile->frelativedir;) I am trying to find the relative directory of the file ($webfmfile->frelativdir;) - relative to drupals root file directory:

In $reldir I would like to chop drupal's root file directory of the original (physical) file path of the file. file_directory_path() gives me the (physical) file path down to drupals file directory. Using str_replace I replace drupals file directory with an empty string within the original (physical) file path of the file. Basically I am cutting of the first part of the string.
In the second step I also cut of the webfm_root_dir, I decided to do this because this will stay the same for every file - if someone would like it in his url he can just add it manually to the URL-pattern in pathauto.

My main point is:
If you would drop dirname the filename would stay in the token.
I believe what you are looking for could be achieved with this pattern:

[webfmfolder-path-raw]/[filename]

Maybe we can have this ported in a Development snapshot, and provide it here: http://drupal.org/project/webfm to get some feedback.

Is this included in any release?

I don't think so - but I would be glad if you take the patch above for a spin.

I tried the patch and it works really good as far as I can tell. Thanks! it would be great to include it in an official release.

Thanks for the patch!

In head. Thanks again Niels. Still have to look into getting FCKeditor to use the alias rather than the webfm_send url.

This is great; the ability to create aliases with pathauto is exactly what I needed. New files being uploaded have the aliases being properly created with the [webfmfolder-path-raw]/[filename] tokens.

Would it be feasible to change the Web File Manager interface so that users can copy the _alias_ to the clipboard from the right-click Javascript menu? We will have users manually inserting links in documents, and the ability to copy that aliased URL instead of the 'webfm_send' one would just be great.

Thanks again for all your hard work on this, Niels!

Rob can we get this into head, please?

Hi Niels,

Your module was included in the latest release.

Here it is in the repo:
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/webfm/modul...

-rob

Sorry to post after this has been fixed and included, but I can't get the URL aliases to update. I have Web File Manager 6.x-2.15 and Pathauto 6.x-1.5 installed, and have tried various url formats at admin/build/path/pathauto (with 'Bulk generate aliases' checked) but it doesn't seem to register in WebFM even after a cache refresh and emptying Drupal cache.
When I submit the new path 'webfm_send/[webfmid]/[filename]' it saves the change on the admin page but at WebFM I get a message "Ignoring alias webfm_send/167 because it is the same as the internal path."
In addition when creating a new file, the url is in the usual format webfm_send/nid.

What am I doing wrong?
I think this needs a Book page or at least some documentation...

Ok it appears it's creating the alias which is working as a URL to the file, but it's not updating the metadata of the file even though I have the option checked to 'remove the old alias' in the pathauto settings. Website is at http://viascotland.org.uk . Any help or advice is appreciated as we require this feature to be able to read PDFs with Browsealoud - it doesn't recognise the file as a PDF without the extension in the address bar...

Haven't really used this feature but some quick research suggests the following:

The "ignoring alias..." message might be because Webfm defines a menu item for all URLs that start with webfm_send. Try using a different root for your aliases.. e.g. webfm_download

You may need to change the pathauto punctuation settings to allow "." in the URLs to allow for file extensions. The default is for dots to be stripped. Note however, that users might be able to use this to redirect things to other places... e.g. using dots for directory references.

Ok cheers for the reply.
What I'm getting at is that the actual WebFM file Metadata isn't changed. On examining this it appears the URL is auto-generated by Javascript at runtime rather than a path being stored in the Webfm DB table. As such I don't think it's possible to do what I want with this module ie: actual a href file link from WebFM interface is editable. I even tried hacking the webfm.js generateFileHref function which also didn't seem to have the desired effect...
Anyway no biggie cheers for the help.