Images uploaded in CCK via image_fupload ignored by filefield_paths
sharifudinrizal - August 11, 2009 - 14:47
| Project: | FileField Paths |
| Version: | 6.x-1.3 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Description
It seems the files are only uploaded to the "files" directory and not moved to the directories specified in the path config. I needed to run retroactive update everytime, and everytime I ran out of memory. Any advise?
#1
Can you provide me with a bit more information?
What versions of each module are you using?
What have you got in the replacement values?
What configuration options are you using?
How much memory have you allocated in your PHP.ini?
Anything else that you can think of that would help me reproduce this issue and help me pinpoint the solution would be appreciated.
One thing that strikes me as odd is that Retroactive Updates uses the Drupal Batch API, which shouldn't be running out of memory.
Cheers,
Deciphered.
#2
I am having the same issue with images not getting moved to the correct folder unless a retroactive update is done.
Here is my current configuration:
- Modules: FileField Paths 6.x-1.3, Image FUpload (CCK) 6.x-3.0-rc2
- Filefield Path setting: File Path: photos/[title-raw]
- PHP memory limit: 128M
The 'photos' folder does exist and permissions are 755. The issue seems to be the creation of the subdirectory when the files are initially uploaded, as the retroactive update does not have the same issue. I have not had an issue yet with running out of memory, but I have only attempted this with 4 files and have halted since noticing the bug.
Any advise would be appreciated.
#3
I too am experiencing the same problem.
#4
subscribe
#5
Filefield 6.x-3.2
Filefield Paths 6.x-1.3
Imagefield 6.x-3.2
I'm also having the same problem but only when trying to process more than about 80 images.
If I upload say 100 pictures to a node when I save I get the following error
Fatal error: Out of memory (allocated 131596288) (tried to allocate 40 bytes) in /sites/all/modules/cck/content.module on line 2335
and it has only managed to move 9 images to the correct folder. Then if I try to do a retroactive update I get this error
An error occurred. /batch?id=39&op=do
Fatal error: Out of memory (allocated 131596288) (tried to allocate 19456 bytes) in /sites/all/modules/cck/theme/content-field.tpl.php on line 49
#6
Seems the issue still remains. Subscribing to this because this holds back what could have been awesome module.
#7
I have just tested this using the following modules and configurations without issues:
Content Construction Kit (CCK) 6.x-3.x-dev (2009-Oct-15)
FileField 6.x-3.2
FileField Paths 6.x-1.x-dev (2009-Aug-03)
Image FUpload 6.x-3.0-rc2
ImageAPI 6.x-1.6
ImageCache 6.x-2.0-beta10
ImageField 6.x-3.2
Storage mode: One image per node
File Path: photos/[title-raw]
Number of Values: 1
Storage mode: Multiple images per node
File Path: photos/[title-raw]
Number of Values: Unlimited
If possible, a guide to reproduce this issue flawlessly would be appreciated.
Cheers,
Deciphered.
#8
Interesting.. I will try that combo.
It doesn't work on mine.
Content Construction Kit (CCK) 6.x-2.5
FileField 6.x-3.2
FileField Paths 6.x-1.3
Image FUpload 6.x-3.0-rc2
ImageAPI 6.x-1.6
ImageCache 6.x-2.0-beta10
ImageField 6.x-3.2
The images will always upload to files/. It only moves to the set directory (e.g. files/photos) after I run the retroactive update..
Btw how safe/proper is it to run dev modules, since I only run stable releases for production?
#9
From what I know about image_fupload, some of the issues is likely in their ballcamp, so may want to consult them also.
Among other things, Image_fupload makes simplified nodes with just the image, type on insert (ie nodes are created before body, title are set, among other things. Then they are resaved once titles are set).
(I tried image_fupload, then after looking at the code made a .. branch? for myself, so I know the code a bit)
#10
I have the same problem, it also doesn't seem to work with another module called type local nids. If I use a regular nid token for a single image field it works fine, but if I use a type local nid token I get the same problem as above. The images are uploaded to a different location and only if I run retroactive update do they put them in the destination with the type local nid.
#11
image_fupload_imagefield_node_create :: http://drupalcode.org/viewvc/drupal/contributions/modules/image_fupload/... to see how nodes are created/saved.
<?php517 function filefield_paths_filefield_paths_process_file($new, &$file, $settings, &$node, &$update) {
518 if ($new) {
?>
<?php$function(($file['new'] || variable_get("ffp_{$node->type}_{$file['name']}", 0)), $file, $ffp['#settings'][$file['name']], $node, $update);
?>
http://drupalcode.org/viewvc/drupal/contributions/modules/filefield_path...
Files are only moved when marked as 'new'
Files are marked as $file['new'] via this check:
<?php'new' => (!empty($file['filepath']) && !empty($file['data']['process']))
? TRUE
: FALSE
?>
http://drupalcode.org/viewvc/drupal/contributions/modules/filefield_path...
For those expierncing the problem, are the files coming in as 'new'?
#12
Sorry, pretty new to Drupal, how would I check whether it's coming in as new or not?
#13
Insert a testing statements as drupal_set_message (since image_fupload uses ajax, need someway to view the statement) near a relavent area to see what the value is. If you don't know php... then perhaps someone else with the issue does?
#14
Know some php, but probably not enough to be useful... I tried inserting a drupal_set_message (at the same place where it tells you your image was added) with the $file['new'] variable, but it was empty, didn't get a boolean response. I'm probably not doing it right :O
#15
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?
#16
Hi,
same issue here, also when running 'imagefield_import'. Additionally, 'fid' tokens are not written into the filename (to force it to be distinct). Can be fixed by running the retroactive update after every upload (which makes using this module pretty painful).
This issue becomes quite critical if images with identical filenames get messed up; views and even image nodes start to show completely bogus content (not the actual image, but those from earlier uploads).
I "accidentaly" reproduced this on two different and pretty freshly set up D6 sites. Thus I can provide more detailed information, however not only the 'FileField Paths' module might cause this. Please drop a note if I should open a separate issue for 'imagefield_import' problems.
Thanks & greetings, -asb