I'm fairly new to things here so very much learning as I go. I hope this is the best place to post this question/issue relating to Active updating of filefield_paths. Please accept my apologies if it's not. I too was concerned by the 'warning' against 'Active updating' so thank you for your explaination, I feel more comfortable with using it now. However I have found one problem...
I'm experiencing some bizarre behaviour when using CCK with FileFields and FileField Paths. In the main everything works fine. The situation occurs when having filefields which have a filefield_path configured, the field is set to optional (i.e. Required field is unchecked) and does not contain a file, and Active Update is turned on. The issue occurs when the file field is empty. (I have multiple file fields in the content type any they don't always contain content)
I get the error: The selected file could not be copied, because no file by that name exists. Please check that you supplied the correct filename.
That error occurs on node save, an occurs multiple times, once for each file field which doesn't have a file linked. That appears to be generated within file_copy by the call to file_move.
On line 540 of file field_paths.module (v6.x-1.4) it reads:
if (filefield_paths_file_move($file)) {
At that point $file contains:
Array
(
[field] => Array
(
[view] =>
)
[module] => filefield
[name] => field_myfield
[widget] => filefield
[new] =>
[filename] => Array
(
[old] =>
[new] => .
)
[filepath] => Array
(
[old] =>
[new] => sites/default/files/mydir/.
)
)
I just wanted to sanity check whether this is the data structure you would expect?
I can see that module filefield_paths's hook _filefield_paths_process_file is what is causing the above to be populated with the 'new' filename/filepath as '.'. I'm guessing but i'm thinking if that change had not happened then perhaps this attempt to move a non-existent file wouldn't happen. Prior to that hook being called it contained:
Array
(
[field] => Array
(
[view] =>
)
[module] => filefield
[name] => field_myfield
[widget] => filefield
[new] =>
)
The hook filefield_paths_filefield_paths_process_file doesn't appear to check the $file contents to see whether it's a real file before it starts aliasing things. At a guess i'd say the '.' is coming from an attempt to alias the file, but it's a non-existent file so doesn't have a name or extension.
The FileField Path settings for the content type CCK field is:
File path: mydir/[field_mytextfield-raw]
File name: [filefield-onlyname-original].[filefield-extension-original]
File alias: mydir/[field_mytextfield-raw]/[filefield-onlyname-original].[filefield-extension-original]
Display alias: checked
Active updating: checked
When I call node_load on a node of this content type I do see this for the empty file fields:
[field_myfield] => Array
(
[0] =>
)
Versions are:
Drupal 6.22
FileField 6.x-3.10
File Aliases 6.x-1.1
Content Construction Kit (CCK) 6.x-2.9
FileField Paths 6.x-1.4
Any thoughts spring to mind on where this issue/bug might lie?
Would you expect filefield_paths_get_fields($node) to return empty entries in $ffp['#files'], i.e. file fields which don't currently have a file. I'm wondering where best to address this, in filefield_paths_node_update(), filefield_paths_filefield_paths_process_file(), filefield_paths_get_fields(), or is the problem elsewhere? (I'm lacking experience with Drupal to know where best to look next) It seems like it should be a simple test to check that the file is proper filefield rather than a blank entry.
Many thanks for any assistance or pointers you can provide on where I should go next with this.
Many thanks,
Pete
Comments
Comment #1
petew commentedOn further investigation this might be similar to the issue reported here http://drupal.org/node/721454.
If so, hopefully my post provides a bit more information to help investigate. If you have any pointers on how to approach this I could make an appropriate patch rather than a workaround.
Many thanks,
Pete
Comment #2
decipheredNo longer supporting Drupal 6 issues for this module.