Great module. But for some reason, images uploaded with fupload don't get placed in their proper directories as specified by the Filefield_paths module (6.x-1.0).

I've been going through the code to find out why and I think I've narrowed it down to the following function: _fupload_import_widget_files_directory

Is there a way to make this function use whatever standard filepath function the Filefield module uses so that advanced tokens are available?

Thanks!

CommentFileSizeAuthor
#8 The node edit form when editing a node where images were added on creation101.62 KBrsm08

Comments

mudd’s picture

mudd commented

Can you comment on whether your experience conforms to what I'm seeing with FifleField_path + Transliteration? (See #421058: Upgrade -- is there a special method?)

Basically, when I tell Filefield_path to use Transliteration to replace spaces with dashes in file and path names, the path names are not cleaned (spaces remain). Earlier I tried Pathauto for this but there's a bug somewhere that causes a recursion failure when upload more than a few files at at time.

I'm seeing this Transliteration/Token problem on Filefield 3.0 RC1 also, so if this sounds like the same issue then I'll open a bug report on FF RC1 and/or Transliteration and/or Token.

pnigro’s picture

pnigro commented

File path tokens do not work with Image FUpload for me as well. I have the following modules installed:

FileField 6.x-3.0-rc1
FileField Paths 6.x-1.0
Image FUpload 6.x-3.0-alpha4
ImageField 6.x-3.0-rc1

grandcat’s picture

grandcat commented
Status: Active » Needs work

Filefield_paths won't work with Image FUpload at the moment because I think the modules is trimmed to Filefield. I will have a closer look in Filefield_path's code next time.

Edit:
I had a closer look at this module: I'm not sure whether the official version (not dev) is working at all?
I will do some further tests on the dev version because it seems that this one works a lot better.

aasarava’s picture

aasarava commented

grandcat -- Yeah, I couldn't get a previous dev version of filefield_paths to work. I'm using 6.x-1.0.

aasarava’s picture

aasarava commented
Version: 6.x-3.0-alpha3 » 6.x-3.0-rc1

I've been tracking this down and here's what I think the problem is: When using filefield_paths with image_fupload, the file path gets truncated back to the nearest existing directory instead of creating a new directory.

For example, if you set up your imagefield to save images to gallery/[title-raw], the [title-raw] portion of the path doesn't exist in the file structure yet. So the path gets truncated back to just gallery/ and images get saved there.

So, I hacked image_fupload_imagefield.module to create the directory if needed. Here's the code I had to add. It assumes you have filefield_paths and pathauto installed.

Added just under $files_path= at line 302 in image_fupload_imagefield.module (version RC1):

// Build the destination folder tree if it doesn't already exists.
        require_once('includes/file.inc');
        if (!file_check_directory($files_path, FILE_CREATE_DIRECTORY) && !mkdir($dir, 0775, true)) {
          watchdog('image_fupload', 'Failed to create destination image directory: %dir', array('%dir' => '$files_path'), WATCHDOG_ERROR);
          return false;
        }

Not sure this is ready for a patch yet. It seems though that the directory should really be getting built elsewhere. After all, without image_fupload, filefield_paths does its job as expected. Why would the extra code be needed here? Not sure if the problem is in image_fupload or filefield_paths. Can anyone who understands the file modules better chime in?

grandcat’s picture

grandcat commented

I don't think that the patch is working as well. Creating the folder, this is filefield_paths for. Additionally, if you set "mkdir($dir, 0775, true)" directly under line 302, a dir will be created like

gallery/[title-raw]

, because [title-raw] wasn't replaced yet.

By the way, I didn't have autopath installed, because token should be enough for a lot of installations.

Nevertheless, I will do some additional checks how I can solve this. It should be possible.

aasarava’s picture

aasarava commented

Grandcat, it's correct that gallery/[title-raw] should be created. This is a temporary directory that must be created to hold the files until the node is saved and the [title-raw] token actually becomes available for conversion.

Once the node is saved, filefield_paths takes over using the nodeapi hook and renames the folder accordingly.

rsm08’s picture

rsm08 commented
Version: 6.x-3.0-rc1 » 6.x-3.0-rc2
StatusFileSize
new The node edit form when editing a node where images were added on creation101.62 KB

I might have the same problem.

I just installed Fupload, and it's acting very strange. It seems that the module can't always find the files it uploaded, and this probably causes strange behaviour like the Fupload interface showing up at the same time as the normal filefield upload interface. (See attached screenshot showing the edit form when editing a node where images were added on creation).

On the page for writing title and description right after upload, there's no pictures displayed. No wonder, since the paths are like this:
"sites/default/files/imagecache//filename.jpg"

I've read this and previous threads regarding this. I don't have a "Filefield Paths" module, but still, I have a "Path settings" form group in the imagecache field settings, where I can specify a path for uploaded images. I haven't used this though, but I'm puzzled as to why I have this option when I don't have a "Filefield Paths" module?!

I'm using:
FileField 6.x-3.0-rc1
ImageField 6.x-3.0-rc1

grandcat’s picture

grandcat commented

I think you installed another module which changes the behaviour of uploading a file.

rsm08’s picture

rsm08 commented

I think you installed another module which changes the behaviour of uploading a file.

I don't think that is likely, considering that uploads work fine throughout the site. It's only Fupload that can't find the files it uploaded itself.

Normal uploads with ImageField work fine. ImageCache works fine. The upload action itself works fine with Fupload. But it can't find the files, after it uploaded them.

I think it's more likely that this problem is pretty much related to the issue that you discussed above with aasarava. The fact that a piece of the image URI is missing seems to indicate that there's a problem with the file path.

grandcat’s picture

grandcat commented

This problem only appears if your files' directory (managed by filefield or imagefield) is not set correctly.
Also, your tmp directory and so on should be set correctly.
Please give me more details about your system, otherwise the problem's roots could be everything.
Also a detailed list of used modules would be helpful.

rsm08’s picture

rsm08 commented

Ok I think I solved the problem partially. I found out that I didn't have a tmp directory. This hadn't caused any problems before, but after adding it, the images show up correctly in the edit caption step of Fupload, and it takes the files from the correct preset directory under Imagecache.

However, when editing a node with images, I still get the strange combination of the Fupload interface and the regular filefield upload interface (See my initial screenshot). Fupload says that there's 0 uploaded images, so something is still not right.

This problem only appears if your files' directory (managed by filefield or imagefield) is not set correctly.

I looked for such settings, but neither FileField nor ImageField provides any admin settings besides permissions. Instead there's a drupal core setting for upload paths. There's 2 values, one for upload path and one for tmp. Both paths are set correctly:
- File path: "sites/default/files"
- tmp: "tmp"

I see your point about more system details, but I don't know which modules to mention besided the ones we're already discussing. I don't have any other modules affecting upload. I still don't know why I can specify a file path for each imagefield, when I don't have the "Filelfield paths" module you're talking about. They must have integrated it in filefield?!

grandcat’s picture

grandcat commented

Ok I think I solved the problem partially. I found out that I didn't have a tmp directory. This hadn't caused any problems before, but after adding it, the images show up correctly in the edit caption step of Fupload, and it takes the files from the correct preset directory under Imagecache.

I knew that something was wrong ;)

However, when editing a node with images, I still get the strange combination of the Fupload interface and the regular filefield upload interface (See my initial screenshot). Fupload says that there's 0 uploaded images, so something is still not right.

The filefield upload interface should allow the user to delete or sort already uploaded images.
Nevertheless, the FUpload interface appears to be able to add some additional images to the node, that's the reason for it. Of course, Fupload says that there are 0 uploaded images, because no additional images have been selected yet.
But perhaps, you know a solution to handle this better? (UI concerning)

For each filefield, you can define a storage path using the widget settings page, independent of any other contributed modules.

rsm08’s picture

rsm08 commented

Ok so what you're saying is that Fupload is actually working correctly now? But still, I don't understand why it doesn't disable the regular FileField upload interface when editing an existing node, like it does when a new node is created?

Is this because you can't disable the actual upload field of filefield without removing the sortable list of uploaded images as well?

Funny you should ask about UI, I'm a bit of a usability geek ;), so I'd LOVE to share these thoughts:

  • I would expect Fupload to replace the filefield upload form always. Uploaded files should still show up in an editable list like filefield's.
  • I think it's odd that the user has to first upload the images and then press "next" to edit titles and description. Why can't the editing take place on the node edit page like it does with filefield?
  • When I opened the site in a browser without flash 10, Fupload displayed but without the button to add images - effectively disabling uploading. I would expect that it would instead degrade gracefully and just revert to the normal filefield interface

What do you think about this?

grandcat’s picture

grandcat commented

Is this because you can't disable the actual upload field of filefield without removing the sortable list of uploaded images as well?

That's right. I want to keep some parts of filefield, especially the files list is very comfortable. But, I can't remove the actual upload field of filefield, that's the fact.
Nevertheless, you can do by some CSS modifications, normally.

I would expect Fupload to replace the filefield upload form always. Uploaded files should still show up in an editable list like filefield's.

Have a look at the first response.

I think it's odd that the user has to first upload the images and then press "next" to edit titles and description. Why can't the editing take place on the node edit page like it does with filefield?

Theoretically, it would be possible, but most of the users do like the "next step" because some people wouldn't realize that new fields appear where they can change the title, ... etc.
Also, have a look at big platforms like mysp@ce, it's handled as same.

Additionally, in the programmer's view, it's much easier to handle. I think we should not "ajaxify" too much because this is often the source of a problem.

When I opened the site in a browser without flash 10, Fupload displayed but without the button to add images - effectively disabling uploading. I would expect that it would instead degrade gracefully and just revert to the normal filefield interface

Ok, this seems to be a bug. I don't have Flash 9 anymore. I'll take a look at that.

Thank you for your comments.

rsm08’s picture

rsm08 commented

Theoretically, it would be possible, but most of the users do like the "next step" because some people wouldn't realize that new fields appear where they can change the title, ... etc.
Also, have a look at big platforms like mysp@ce, it's handled as same.

Based on my experience from elsewhere, I'd agree with you totally that user rarely notice when new things appear dynamically. But FileField in particular does it in a way that's noticed instantly. It's evident when you use it, I think.

Maybe the "next" page is more relevant when using Fupload for nodes like photo galleries and similar, where images are the main purpose of the node. This is probably why they use it on Mysp@ce. I'm using your field for product images in Ubercart, and here images aren't the main focus of the node.

IMO, the problems with the current setup is...

  • The need to continue to a new page, I think, is intrusive on the user. What if the user don't want to specify title and description for all his images?
  • What if the user needs to look at or copy from other form fields in the node edit form when editing the captions?
  • Having to leave the edit page is error prone in its nature, because it gives the user a new way to get confused, screw up and accidentally navigate away from the page
  • This behaviour is not consistent. - The "next" page is only used when uploading new images. When editing title and description on already uploaded images, FileField's interface is used. Unconsistent behaviour made me, for one, think that the script wasn't working as intented.

Don't get me wrong. Generally I think your script is great, and I know you're doing this on a voluntary basis, so I'm in no position to demand anything from you. So I hope you'll take this as constructive critisism and ideas for making a great script even better!

That's right. I want to keep some parts of filefield, especially the files list is very comfortable. But, I can't remove the actual upload field of filefield, that's the fact.

As a future improvement you might consider just implementing the filelist functionality of filefield completely into Fupload, so you can disable FileField completely. I think this would make for a much better UI and remove the need for the separate title/description editing page.

Nevertheless, you can do by some CSS modifications, normally.

Yeah I thought about that. It's a really ugly solution, but that's a tradeoff I guess I'll have make for the benefits of using a CMS.

rsm08’s picture

rsm08 commented

Hi grandcat

Did you get a chance to look at the flash support issue?

grandcat’s picture

grandcat commented

I'm sorry. At the moment, I found actually no time to check this with Flash 9.

deciphered’s picture

deciphered
Primary language English
Location Ballarat, Victoria, Australia
commented

Subscribing to this issue so I can have a proper look over it so I can determine if there is anything on FileField Paths end that needs to be modified.

I did do some testing with the latest dev (post 6.x-1.1) of FileField Paths with ImageField Tokens (dev) and Image FUpload to get basic integration working. I wasn't specifically checking for FileField Paths integration, but I didn't notice any specific issues.

Cheers,
Deciphered.

grandcat’s picture

grandcat commented

@ Deciphered:
Thank you for your help. I will check the imagefield paths problems in addition to fupload in more detail, if I have time to do it.

deciphered’s picture

deciphered
Primary language English
Location Ballarat, Victoria, Australia
commented
Status: Needs work » Fixed

HI guys,

Looked through this whole issue (until it got terribly off topic - please make a separate issue for unrelated issues, it makes developers lives much easier) and have determined that there is no issue, Image FUpload and FileField Paths work perfectly together.

To the users that mentioned that they where using FileField Paths 6.x-1.0, please be sure to update to 6.x-1.1. Also make sure to always run the update.php and/or clear your site cache when updating modules, especially when updating to development builds.

Cheers,
Deciphered.

kassissieh’s picture

kassissieh commented

Image FUpload and filefield path tokens are not working properly for me. I am not using the FileField Paths module. I am using ImageFUpload 6.x-3.0-rc2, FileField 6.x-3.0, and ImageField 6-x.3.0.

I have set the path for my imagefield to gallery/[user-name], but the files are ending up in gallery/ instead. Otherwise, everything is working great. I did have to create the gallery folder manually for it to work.

Thank you for any time you have to devote to this issue.

pnigro’s picture

pnigro commented

The purpose of Filefield paths is to do exactly what you are trying to do, save files to a directory based on selected tokens. Install the module and it will work.

kassissieh’s picture

kassissieh commented

Sorry to appear dense, but I thought that Filefield Paths provides additional tokens beyond those already supported. Without installing Filefield Paths, I can see a list of replacement tokens I can use, albeit a shorter list than what Filefield Paths provides. I like to avoid installing additional modules if they are not needed.

Richard

deciphered’s picture

deciphered
Primary language English
Location Ballarat, Victoria, Australia
commented

Hi Richard (kassissieh),

You are entirely correct, FIleField Paths adds Node based tokens, whereas FileField already supports User based tokens, so as long as you are only using User based tokens then there should not be an issue.

As you say you are using a User based token and it isn't being processed it is likely an issue.

The best way to get your issue resolved is by providing as much information as possible; server environment, modules installed, sub-modules installed (CCK: Text, Number, etc), step-by-step guide to reproduce the issue (preferably on a clean development environment), etc.
It enables others to determine if your issue is a real issue and if so determine a fix, plus it helps you learn more about Drupal at the same time.

Cheers,
Deciphered.

P.S. You will also receive more attention if you aren't posting in an issue marked as fixed. If you are positive it is exactly the same issue as the the original fixed issue, set the status to active. If not, create a new issue.

Status: Fixed » Closed (fixed)

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

mafi-a’s picture

mafi-a commented
Status: Closed (fixed) » Active

Is this problem solved?

I'm using
Content 6.x-2.5
FileField Paths 6.x-1.3
Image FUpload (CCK) 6.x-3.0-rc2
FileField 6.x-3.1
ImageField 6.x-3.1

Private download

It seems that Fupload is completely ignoring my file path set with FileField Paths, whereas the normal Imagefield Upload uses the path correctly.
All images are saved in the folder specified by the upload module what creates a large mess...

It doesn't depend on tokens, hardcoded path also don't work.

greets Marco

marcus178’s picture

marcus178 commented

I can't get it to work with FileField Paths either. If I disable to module it works with the standard tokens that are available, but it doesn't seem to work with the node tokens made available with the FileField Paths Module

my-family’s picture

my-family commented

subscribing

marcus178’s picture

marcus178 commented

I have found that jUpload for Imagefield (http://drupal.org/project/jifupload) works with Filefield Path, however it ignores pathauto. I'm guessing that this module works in a similar way to fupload so maybe someone who knows their way around code could look at this.

grandcat’s picture

grandcat commented

No, it's working in another way. It was built more simpler and not as flexible as fupload. You'll see.

krabbe’s picture

krabbe commented

Subscribing.

Having the same problem, that Fupload and FileFieldPaths are not working together.
I switched off FileFieldPaths (and ImageFieldToken) and the uploaded pictures go to the right folder.

But I would like to get the ImageFieldToken back.

marcus178’s picture

marcus178 commented

For anyone who needs a temporary solution to this problem, the imagefield zip module works with tokens.

ddbell’s picture

ddbell commented

I turned off the filefieldpaths and imagefieldtoken, the pictures still do not load to the right folder. I selected [user] for the path. Thanks.

grandcat’s picture

grandcat commented

Change the patch to a more basic directory,

ddbell’s picture

ddbell commented
Status: Active » Closed (fixed)

Thanks.

marcus178’s picture

marcus178 commented

I've found that although it doesn't initially create the correct paths, if you edit the node and then save ,the paths get correctly updated. So it's like when you click done editing, it's not doing the same thing as saving a node, which then updates the paths.,

Jonah Fenn’s picture

Jonah Fenn commented

Running into this issue as well:

Drupal 6.14
CCK 6x-2.5
Imagefield 6x-3.2
Filefield Paths 6x-1.3
Image FUpload 6.x-3.0-rc2
ImageCache 6.x-2.0-beta10
Token 6.x-1.12

FileField Paths behaves perfectly when Image FUpload is not enabled. Image FUpload is a small miracle in terms of its intended performance, but the inability to rename, sanitize, and organize the uploaded batches leads to bigger headaches at the end of the day.

It would be great if these two modules were compatible as it would solve the two biggest problems I'm dealing with for my customer. Any chance that something could be worked out between the two?

H3x’s picture

H3x commented
Title: Doesn't support file path tokens via Filefield Paths module » Image FUpload doensn't support file path tokens via Filefield Paths module
H3x’s picture

H3x commented
Status: Closed (fixed) » Active
magnus’s picture

magnus commented

Check out the patch in comment #10 and see if that helps you: #635854: Node links to original file path after creation until the node is saved again

magnus’s picture

magnus commented
Status: Active » Fixed
delty’s picture

delty commented

subscribing

Status: Fixed » Closed (fixed)

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