Use absolute paths and file_create_url() for private files

roaming - September 17, 2007 - 01:14
Project:Image Assist
Version:5.x-1.x-dev
Component:Code
Category:bug report
Priority:critical
Assigned:Unassigned
Status:closed
Description

I am trying to insert an image into a story. When I click the image icon, a pop-up window opens and doesn't find my image (the image is already on the server at files/images). I tried to delete the image from the server and upload it from the pop-up window. That works, but it creates a whole new page outside of my current story.
It doesn't insert the image into my text.

I have drupal 5.2, image module 5.x-1.5 (also attach, gallery, import, assist, all downloaded Sept. 4 (2007).
My file system is set to private.

#1

drewish - September 17, 2007 - 18:15
Project:Image» Image Assist
Version:5.x-1.5» 5.x-1.x-dev
Component:image.module» User interface

i think this is an img_assist issue.

#2

sun - September 23, 2007 - 03:13
Status:active» postponed (maintainer needs more info)

After creating the image (node) with Image Assist, what happens if you select the image (in the popup window), fill out the meta information and click on the insert button?

#3

Crashtest - September 24, 2007 - 22:48

I have a similar issue. My filesystem is also set to private and the files-path is outside the httdocs-root.

The img_assist dialogue displays the names of the images but doesn't display the images themselves. The Problem is that the module uses a wrong path. It looks something like that:
http://var/www/vhosts/domain.de/subdomains/foo/files/images/animage.thum...

This is the absolute path, so it cannot work.

greez

#4

Crashtest - September 24, 2007 - 22:59

Hmm. It doesn't seem to be an issue on image assist. I've the same problem with upload-module and upload_preview-module.

#5

Crashtest - September 27, 2007 - 17:47

I don't know if my issue really is the same than roaming's. So I don't change the status. Plz reply, if I should create a new issue.

But I found a why to solve my problem. I've created a patch file against the current dev-release of img_assist. Its simply on line that have to change.

See yourself.

thx and greets

AttachmentSize
img_assist_25.patch 583 bytes

#6

sun - September 28, 2007 - 04:23

@crashtest: Interesting, we recently removed file_create_url() to support multi-site and multi-theme setups properly. So you are using private files and claim that this change displays images correctly now? If so, I'll have a deeper look into private files support. If you will answer fast enough, we might get this fixed in the next release of Image Assist (to be released within the next days).

#7

Crashtest - September 28, 2007 - 09:55

So you are using private files and claim that this change displays images correctly now?

Yes, absolutly. As an irony the site is even running as a multi-site from a single codebase ;)

Without the url processing I had an absolute path as an url as posted above. This path was given to the display_image-function. But of course this can't work.

thx and greets

#8

samuelet - September 29, 2007 - 08:35

I don't know if it's a related bug or i missed something in my configuration, but it seems it was introduced by the multi-theme setups patch.
Images inserted in nodes with a path are not displayed because their urls are created relative (so for example in the http://example/article/myarticle node the images path gets http://example/article/files/image.jpg) . It does not work also the preview image of img_assist interface.
Filesystem is public, and it's path setting is relative (simply "files").
Thanks

#9

sun - September 29, 2007 - 19:40
Title:can't insert image in existing text» Private files support
Component:User interface» Code
Category:support request» feature request
Status:postponed (maintainer needs more info)» active

As an irony the site is even running as a multi-site from a single codebase

Yes, it works. However, since contents are cached, all image urls point to the site a content was created/edited from. If the site that was used to publish a content is not reachable from certain sources, no images are displayed.
See http://drupal.org/node/109380 for further information and let's re-open that issue for further investigation. It would be great if you could post your use-case as a follow up to be able to take it into account.

Let's focus on private files support in this issue.
I could imagine to implement a condition that invokes file_create_url() to retrieve a working url and strips the base_url afterwards. Or we simply add /system/files to the url if private files are enabled.

#10

Crashtest - September 29, 2007 - 22:34

Sorry. Seems that I've understood something different under the term multi-site. No I understand the problem.

What I've got is one drupal installation and some seperate sites that simply symlink the drupal code base. So I have no exchange between the sites.

To simply add a '/system/files/' isn't enough. Then the path would look like this:
/system/files/var/www/vhosts/domain.de/subdomains/foo/files/images/animage.jpg
This should look like: /system/files/images/animage.jpg

Or did I get you wrong?

So to use file_create_url an strip the base_url should work. Or just simply use the code of file_create_url but without adding the base_url to the link. Something like this (not widely tested, but works fine in my scenario):

<?php
function file_create_relative_url($path);
 
// Strip file_directory_path from $path. We only include relative paths in urls.
 
if (strpos($path, file_directory_path() . '/') === 0) {
   
$path = trim(substr($path, strlen(file_directory_path())), '\\/');
  }
  switch (
variable_get('file_downloads', FILE_DOWNLOADS_PUBLIC)) {
    case
FILE_DOWNLOADS_PUBLIC:
      return
$GLOBALS['base_url'] .'/'. file_directory_path() .'/'. str_replace('\\', '/', $path);
    case
FILE_DOWNLOADS_PRIVATE:
      return
'system/files/'. $path;
  }
}
?>

#11

Crashtest - September 29, 2007 - 22:57

Sorry, of course it should look like this (sometimes I miss an edit function...):

<?php
function file_create_relative_url($path);
 
// Strip file_directory_path from $path. We only include relative paths in urls.
 
if (strpos($path, file_directory_path() . '/') === 0) {
   
$path = trim(substr($path, strlen(file_directory_path())), '\\/');
  }
  switch (
variable_get('file_downloads', FILE_DOWNLOADS_PUBLIC)) {
    case
FILE_DOWNLOADS_PUBLIC:
      return
file_directory_path() .'/'. str_replace('\\', '/', $path);
    case
FILE_DOWNLOADS_PRIVATE:
      return
'system/files/'. $path;
  }
}
?>

#12

Crashtest - September 30, 2007 - 22:36

I've forgotten to mention that the code above should also work for public file mode.
It should be tested in a multi-site environment where different sites exchange their data.

So you have to call the function in "img_assist_display" like that:

<?php

return theme('image_display', $node, $label, file_create_relative_url($node->images[$label]), $attributes);
?>

#13

sun - October 8, 2007 - 22:22
Title:Private files support» Use absolute paths and file_create_url() for private files
Category:feature request» task

After discussing this with zoo33 on IRC, we came to the conclusion that we should revert img_assist to use file_create_url() (thus using absolute paths and support private files) and furthermore, introduce a new local task in img_assist's settings to empty a site's filter cache. The code for the latter one can be forked from devel module.

#14

yuit - October 17, 2007 - 14:37

I am posting this here, as I guess it relates to the same issue. Let me know if I should open a new separate bug report instead.

Setup:
* Drupal 5.2
* Image module 1.5
* latest img_assist module (5.x-1.x-dev 2007-Oct-12; I was updating from 5.x-1.x-dev 2007-Sep-12 which was working fine)
* private file system used, with directory outside the codebase root.

Since updating to the latest version, images no longer display. When I look at the source code of the page displayed, I get the following HTML code (example) :

<img src="/d:\InetPub\www_downloads/img/logo.img_assist_custom.jpg" alt="" title=""  class="image image-img_assist_custom" width="149" height="69" />

d:\InetPub\www_downloads is the file system path. I guess it should not display in the HTML code, which should read system/files...

#15

arh1 - October 18, 2007 - 08:29

i'm seeing the same thing on a site i'm trying to upgrade from Drupal 4.7 to 5.3. i'm running Image 5.x-1.6 and Image Assist 5.x-1.x-dev (2007-Oct-12) with Private files.

my image urls are being output as a concatenation of a root relative path (/root/relative/path) and the absolute file system path (/file/system/path) with a resulting url like this: /root/relative/path//file/system/path/image/path/image.jpg
the desired url is: http://example.com/root/relative/path/system/files/image/path/image.jpg

the previous 5.x-1.x-dev version of Image Assist (2007-Sep-12?) seems to not have this problem.

thanks to the developers for all their work on this module.

#16

charles_elwood - October 20, 2007 - 02:01

I stumbled on this issue via problems with the LiveJournal Cross poster (bug: http://drupal.org/node/178328) (module: http://drupal.org/project/ljxp)

I think rather than trying to find one way that works for everything, we could follow some other modules in having maybe the options of

  • Use relative path
  • Use absloute path at insert server here
  • insert your own php code here

Of course it's a lot more complicated than what currently happens, but possibly more flexible?

I suppose the alternative is to make my issues an LJXP problem and not yours?

#17

Standart - November 12, 2007 - 20:43
Category:task» bug report

Re: #15

Yes, please use file_create_url(). I need to use private files setting. Patch #5 works for me.

I don't know though, if it's a good idea to fork code from another module. What in clearing the filter cache is specific to img_assist?

BTW, this is clearly a bug. Let's fix this before releasing a "stable" version.

#18

wrunt - November 13, 2007 - 04:40

+1 on using file_create_url and having an option to flush the caches (comment #13). I'm having the same problem as yuit.

#19

sun - November 19, 2007 - 02:19

Sorry, I'm quite busy these days... anyone able to step in and provide a solid patch?

#20

sun - November 20, 2007 - 12:12

#21

grendzy - November 28, 2007 - 23:03

I had this issue too, after upgrading from drupal 4.7. The patch in #5 fixed the issue for me.

#22

jt_jones - December 3, 2007 - 00:00

subscribing

#23

Roger Lipscombe - December 13, 2007 - 10:37

The patch in #5 worked for me, with one caveat: I had to delete my cache tables in the database:

delete from cache;
delete from cache_filter;
delete from cache_menu;
delete from cache_page;

I've got caching turned off, so I don't know why some of this stuff is getting cached, but there ya go...

#24

antiorario - December 13, 2007 - 12:50

Thanks #5. But my question is: why are 1.5 and the latest dev not patched as suggested?

Thanks,
Tony

#25

js1 - December 13, 2007 - 21:40
Version:5.x-1.x-dev» 5.x-1.5

The img_assist_25.patch worked for me as well, but I also had to update the filepath for all the entries in the files table that weren't full, i.e. from images/SomeImage.png to /web/drupal5_private/images/SomeImage.png. Image and img_assist related functions seem to be working much more consistently. Thanks for the helpful responses.

#26

zoo33 - December 25, 2007 - 10:52

To sum things up, we have a few different options here:

1) Use full URLs with file_create_url(). Works with private files, but will introduce problems for people moving between domains while using the HTML insert mode. Possibly add an option to clear the filter cache for those who move between domains and use [filter tags]. (This is what me and sun discussed on IRC.)

2) Create a custom file_create_url() replacement like in #11. Only it could probably be simplified by having it first call file_create_url() and then strip the domain from the returned string:

function img_assist_image_url($path) {
  $path = file_create_url($path);
  $path = preg_replace([filter out the http:// and domain parts here]);
  return $path;
}

This should work pretty well in most situations, but it doesn't help people who move their sites between subdirectories.

3) Add an option for choosing between absolute and relative paths.

4) A combination of 2 and 3: provide the custom path generation, but add an option to use file_create_url() instead.

Please let me know if I missed something.

#27

sun - January 8, 2008 - 13:44
Status:active» needs review

Attached patch implements 1)

IMHO, we should not implement a custom absolute/relative URL solution in Image Assist. If that is really an issue, better file a feature request against Drupal core.

Please report back if this patch works for you. You'll gain bonus points for testing RSS feeds.

AttachmentSize
img_assist-DRUPAL-5.absolute.patch 4.14 KB

#28

micah - January 8, 2008 - 17:01

I tested patch #27 and it partly works.

For me, this patch fixed the following:

  • Thumbnail and preview now appear correctly in img_assist wizard.
  • Embedded image appears correctly in node body (using filter code).
  • Popup window works in IE7
  • Embedded image appears correctly in RSS feed.

The following things do not work:

  • Wrong URL appears in status bar when mouseover the embedded image.
  • Popup window does not work in Firefox (goes to wrong URL)
  • Link to popup from RSS feed is bad.

Here are the specifics. Please note that my files directory is in /portal/files on my test server. I'm running Drupal 5.5 and the latest image-5.x-2.x-dev dated 2008-Jan-06.

Code generated in HTML view:

<a href="//portal/files/images/vmware05_0_1.gif" onclick="launch_popup(7, 500, 433); return false;" target="_blank"><img src="http://c7.hfcc/system/files/images/vmware05_0_1.preview.gif" alt="Image Test" title="Image Test" class="image image-preview" width="277" height="240" /></a>

Code generated in RSS feed:

&lt;a href=&quot;//portal/files/images/vmware05_0_1.gif&quot; onclick=&quot;launch_popup(7, 500, 433); return false;&quot; target=&quot;_blank&quot;&gt;&lt;img src=&quot;http://c7.hfcc/system/files/images/vmware05_0_1.preview.gif&quot; alt=&quot;Image Test&quot; title=&quot;Image Test&quot;  class=&quot;image image-preview&quot; width=&quot;277&quot; height=&quot;240&quot; /&gt;&lt;/a&gt;

Thanks!
Micah

#29

sun - January 8, 2008 - 17:52

Thanks for testing. New patch, should at least fix 3 points of your not-working-list. ;) Move on!

AttachmentSize
img_assist-DRUPAL-5.absolute.patch 4.74 KB

#30

Standart - January 8, 2008 - 23:20

Seems to be working with my setup.

Drupal 5.5
Image 1.6
private files

RSS feed shows the image, too!

#31

sun - January 9, 2008 - 13:41
Status:needs review» reviewed & tested by the community

#32

micah - January 9, 2008 - 15:17

I concur with Standart. I tested with popup, link to URL, and link to image node for both Filter and HTML methods, and I don't see any additional problems.

Thanks!

#33

zoo33 - January 9, 2008 - 22:37

I've looked through the patch a couple of times and everything seems to make perfect sense. And you have my support in choosing this solution (1).

Two successful testers – RTBC. Good job!

#34

sun - January 10, 2008 - 10:13
Status:reviewed & tested by the community» fixed

Thanks all! Committed.

If each one of you will look through and comment on at least 2-3 open issues in the queue, then v5.x-1.6 will be released in the next days.
Please help out where you can!

#35

Anonymous (not verified) - January 24, 2008 - 10:13
Status:fixed» closed

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

#36

yuit - February 1, 2008 - 16:05
Version:5.x-1.5» 5.x-1.x-dev
Priority:normal» critical
Status:closed» active

Problem again.

It was working fine since I had installed 5.x-1.x-dev version dated 2008-Jan-05.

But I have now installed the latest 5.x-1.x-dev version (dated 2008-Jan-30), and images no longer display. We are using the private file system, and I again get the file system path in the code.

Example:
<img src="http://www.example.com/system/files/D%3A%5CInetPub%5C/www_downloads/img/background_photo_HRES.thumbnail.jpg" alt="" title=""  class="image image-thumbnail" width="150" height="97" />

where D%3A%5CInetPub%5C/www_downloads is the file system path.

Setup:
* Drupal 5.6
* Image module 5.x-1.6
* latest img_assist module (5.x-1.x-dev 2008-01-30)
* private file system used, with directory outside the codebase root.

#37

micah - February 1, 2008 - 19:53
Status:active» postponed (maintainer needs more info)

That seems kind of strange. This update got committed on the January 10 version, and the only thing that changed on the January 29 commit was the README.txt file. This version is still working for my sites.

I wonder if you need to clear your filter cache. I ran into that a few times during testing. It's hard to find this setting. It's a link at the very top of admin/settings/img_assist, and I just spent 10 minutes trying to find it again, but it links to img_assist/cache/clear. Try clearing your cache via this link and see if it fixes the problem.

#38

sun - February 3, 2008 - 21:27

Yes, please try to clear your site's cache first and report back if that solved the problem.

I was not yet able to test Image Assist on IIS. However, AFAIK, Drupal's general support for IIS is not that advanced like for Apache. If the error still occurs for you, please perform the following steps:

1) Create a new node
2) Attach a file with upload.module
3) Save the node
4) Please post the URL to the file here, so we can compare that URL to Image Assist's URL to see what's actually wrong.

#39

yuit - February 4, 2008 - 16:31

to micah: I did clear the cache and it did not change anything. Strange as you say.

to sun: you mention IIS, but we use Apache 2.0.63. I'll send you and micah privately the URL to the test pages you requested.

One more thing: we recently updated tinymce from 2.1.2 to 2.1.3.

#40

micah - February 4, 2008 - 18:32

yuit sent me some links to his site via email. The test requested by sun in #38 did generate a valid link on an attachment using upload.module.

I took a look, and it appears that the image node has some broken links in it. The brokenness of the link generated by img_assist appears to be mirroring this existing problem with the image node in question. I recommended that he check out the image node and make sure everything is valid there before trying to resolve any apparent img_assist problems.

#41

yuit - February 5, 2008 - 17:50
Status:postponed (maintainer needs more info)» closed

After having updated the site concerned with the problem from Drupal 5.6 to 5.7, I have run further tests. As micah suggested in #40, the issue was limited to the specific image node. The links to the image were broken for a reason beyond my understanding, as we had not been doing any config modification to the site. I created another image node, inserted this new image in yet another node using img_assist. It worked.

Since then, I have updated one by one some 10+ other Drupal sites running on the same server, and all went well. So as the issue cannot be reproduced, I suggest to change the status of this issue back to closed again. Sorry for having somewhat wasted your time...

#42

nutkenz - February 28, 2008 - 19:51
Status:closed» active

There are still issues when using img_assist in combination with an RSS feed: f.e. http://feeds.feedburner.com/cruisereizen

edit: not sure if it's the same problem though, should I open a new issue?

#43

zoo33 - February 29, 2008 - 08:20

Images seem to work for me. However: image paths are specified without the domain:

<img src="/files/images/Pride of Hawaii.thumbnail.jpg" ...

Not sure why – isn't img_assist supposed to output full paths now?
Anyway, it works (for me at least) thanks to this:

... xml:base="http://cruisereizen.info" ...

Maybe somewhere in the process the domain is stripped from the paths if it's the same as xml:base? Maybe this is even standard behavior with these RSS services (Drupal and/or Feedburner)?

BTW, you may want to use file names without spaces in them: "Pride_of_Hawaii.jpg"

#44

sun - April 6, 2008 - 18:41
Status:active» closed

This looks pretty standard to me. However, if you still encounter this bug (and please ensure you also experience it with other feedreaders than Feedburner), please file new issue.

 
 

Drupal is a registered trademark of Dries Buytaert.