Download & Extend

Paste file hrefs into arbitrary textfields

Project:Web File Manager
Version:6.x-2.10-rc2
Component:Code
Category:feature request
Priority:normal
Assigned:Frank Steiner
Status:closed (fixed)

Issue Summary

Hi,
since the "put link into clipboard" feature doesn't work with Opera (and not easily with Firefox) (see http://drupal.org/node/246914) I once wrote a patch to add a "Paste link in editor window" patch to paste a href for an attached file directly into the nodes body editor window (see http://drupal.org/node/246921).

Now I've reworked and extended this feature:

  • the href can be inserted for attached and unattached files, so that you can href files without attaching them (usefull when you show attachments in a table and want to href a file without having it shown in an attachment table in the nodes body).
  • the link is relative (i.e. "/webfm_send/..." instead of "http://mysite.com/webfm_send/..." because we had a lot of problems when we tried to move pages from the test server to the real drupal server
  • the href can now be pasted into arbitrary textboxes, i.e., textareas and text fields. The code will remember the last textarea/field that was focussed and insert the href there. It is preset to a comments or node bodys edit form so that the hres is pasted there when you paste it without focussing any field before.
    This feature was added to support mainly biblio nodes which have dozens of fields (textareas and text fields) in which you might want to insert a file href.

The patch is against the clean alpha2 branch, i.e. my former patch for this feature must be revoked if you used it.

Let me know if you consider this useful!
cu,
Frank

AttachmentSize
webfm_paste_href_in_textarea_and_textfields.diff3.84 KB

Comments

#1

Status:needs review» fixed

see 6.x-2.10-rc1

#2

Status:fixed» closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

#3

Version:6.x-2.9-alpha2» 6.x-2.10-rc2
Status:closed (fixed)» needs review

Hi Rob,

just saw that you stripped the code part from the patch that removes the server name from the URL. If that was intentionally, please close the thread again. Otherwise you might want to try the attached patch.

I think links without the web server name shouldn't harm in any situation (but I may be wrong here), but they are very helpful if you copy pages between servers or rename your server (which we did and it was hard work to fix all the links :-)).

cu,
Frank

AttachmentSize
webfm_paste_relative_links.patch 662 bytes

#4

Hi Frank,

I want to know where/how the second parameter is used. Your patch simply shows an instance with an empty parameter.

-rob

#5

I've chosen this way of testing the second parameter for "undefined" so that all existing calls to Webfm.generateFileHref don't have to be changed and still return the same result (if second parameter is not given, getBaseUrl() is used).

But in my call of Webfm.menuPasteHref I pass the empty string as second parameter in the call var fileHref = Webfm.generateFileHref(obj, ''); (line 20 of the patch) and thus avoid the generation of the base URL, resulting in a relative link like /webfm_send/21.

I could also use some boolean parameter but I thought it would be more flexibel this way and could allow to pass some other url prefix (if that was ever needed).

#6

But is there an example where you use a non-empty second parameter? All menu exec functions are based on the treenode|filerow|dirrow object except menuAttach where I reuse the function for attachment during upload inside node edit. I assume that the second argument will also be used programmatically - but where/how? Do you have an example? I'm not trying to be difficult - just thorough.

#7

I'm afraid I don't fully understand what you mean :-) And maybe I'm confusing terms of "empty" and "undefined" parameters.

I try to explain from the roots what I wanted and why: I wanted the hrefs pasted into the textfields to be relative links without the "http://servername/" stuff, so that the server would add this part.

So I needed Webfm.generateFileHref to generate two different results: Once with the baseUrl as prefix so that the use in Webfm.menuPutLinkInClipboard would still return the same result. But also once without the baseUrl as prefix, for my PastHref function.

So I thought that I should add a second parameter to Webfm.generateFileHref to let the function know when to add the baseUrl and when not. I test this second parameter for "undefined" so that the result of the Webfm.generateFileHref would be the same when the second parameter was not specified at all (to make it a conservative extension).

I could make the second parameter a bool, say Webfm.generateFileHref  = function(obj, withBaseUrl=true) (I just don't know if that kind of optional parameter with a predefined value is possible in JS as it is in php). Then I would call it as Webfm.generateFileHref(obj, false) from my Webfm.menuPasteHref function. Maybe that would be better!

At the moment I have no example where the second parameter needs to be more than a boolean, if that was your question! I just need it to say "Use baseURL or not", so I could change the patch to use a boolean parameter if you consider this cleaner!

I'm sorry if I still didn't understand what you mean...?

#8

Ok, I get it now - my head is in an embedded C project. At first I assumed that an alternate base url was going to be provided (ie: proxy) but now I see that you are simply removing the base url for drupal to reinsert.

Btw this fails on my localhost though it works fine on my 1&1 server. On localhost the link <a href="/webfm_send/x">x</a> becomes http://localhost/webfm_send/x rather than http://localhost/path/webfm_send/x. Any ideas why this is so?

#9

What should "path" be in this case? I thought that the webfm url would always be http://servername/webfm_send/... and wasn't aware that there could be sth. additional between the servername and the webfm_send. Where does this "path" come from? Is that defined somewhere within drupal/webfm settings?

I will try to solve this when I understand where that path part comes from... Ah, maybe that's when your drupal is not the root of the webserver. Do you access your drupal installation by http://localhost/path/ instead of just http://localhost/?

If that's the case I must not remove the whole baseUrl but only the server name from the base URL. Seems to make sense.

#10

Yes. My document root folder ('www') in localhost has a separate subdirectory for each test site.

#11

Ok, I will rework the patch to consider this.

#12

Here's a patch against the HEAD version from tonight and now we indeed have the situation where we pass a non-empty string ;-) (Although we could still use a boolean flag and make the distinction between fetching base_url or base_path in the generateFileHref function).

The patch creates another function getBasePath() for the js file. We need to pass $base_path to webfm_inline_js in addition to $base_url, so I had to change some lines in webfm.module. Although I wonder why we couldn't just declare $base_url and $base_path as global in webfm_inline_js itself?

With this patch, it should work on your localhost server, too!

#13

Hi Frank,

Did you forget to attach?

-rob

#14

Oh, sorry :-)

AttachmentSize
webfm_paste_relative_links_with_base_path.patch 4.27 KB

#15

Status:needs review» fixed

Fixed in RC3. Thanks again Frank for your time and excellent work.

#16

Status:fixed» closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

#17

Status:closed (fixed)» needs review

Hi,
I'm not sure how this happened as it was correct in the last patch, but somehow the rc3-release exchanged base_path against base_url in line 761 :-) Resulting in webfm_inline_js($base_url, $base_url,... which is definitely wrong and leads to absolute instead or relative links.

cu,
Frank

AttachmentSize
webfm_href_paste_fix.patch 498 bytes

#18

Thanks again Frank. I'll probably release another rev. soon since I'd like to add the FCKEditor support.

#19

Status:needs review» fixed

in head

#20

Status:fixed» closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

nobody click here