I'm not totally sure if this is incorrect documentation or not, so I won't CVS it (and the fact that I'd rather bash myself in the temple with a brick than use CVS has nothing to do with it, really); it may just be that I'm not understanding the docs. But if that's the case, I would argue that it's overly-vague.
In the parameters for file_save_upload():
$validators An optional, associative array of callback functions used to validate the file. The keys are function names and the values arrays of callback parameters which will be passed in after the user and file objects. The functions should return an array of error messages, an empty array indicates that the file passed validation. The functions will be called in the order specified.
This seems to imply to me that I can do something like this:
function my_module_valudate($node, &$form) {
file_save_upload('uploaded_file', array('_my_module_file_validator' => array()), file_directory_path(), FILE_EXISTS_REPLACE);
}
function _my_module_file_validator($user, $file) {
$errors = array();
// stuff
return $errors;
}
However, in practice, it seems that the first and only parameter passed to my validator function is the file object. So the user object seemingly is not being passed to the validator. Not a huge tragedy since I can global it if I need to, but it seems the docs is incorrect… Or am I?
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | 286374-6.x.diff.txt | 922 bytes | jhodgdon |
| #5 | 286374.diff | 1.39 KB | jhodgdon |
Comments
Comment #1
Garrett Albright commentedInvestigating this further, I'm noticing parts of core which use these validation functions are not expecting to receive the user object as one of their parameters. See upload_node_form_submit() which lists, among others, file_validate_image_resolution() as a validator. The latter function's parameters are $file, $maximum_dimensions and $minimum_dimensions -- no $user.
Also, in my code above, that should be
my_module_validate(), of course. Oh my God.Comment #2
Noyz commentedChanged the component to reflect the new component categorization. See http://drupal.org/node/301443
Comment #3
johnnocthis is regarding api.drupal.org
Moving to Drupal project, Documentation component
Comment #4
jhodgdonThis is indeed a doc issue in 6.x as well as 7.x. The validation functions only pass the file, not the user object.
Comment #5
jhodgdonHere is a patch for Drupal 7.x
Comment #6
jhodgdonHere is a patch for 6.x -- pretty much the same.
Comment #7
jhodgdonComment #8
quicksketchjhodgdon is definitely correct. Only the $file object is passed into validator functions (FileField has four separate validator functions that all work like this), plus the core validator file_validate_image_resolution() works like this also.
Comment #9
quicksketchBut lets fix in 7.x first, then we'll move to 6.x
Comment #10
dries commentedCommitted to DRUPAL-6 and CVS HEAD. Thanks!
Comment #11
drewish commentedJust wanted to weigh in on this. In an early version of the patch that changes this I think we were passing the $user object in. Looks like the docs never got updated. Need to fix this in D6 too.
Comment #12
jhodgdonOK, now I am confused.
The current 6.x doc for the function on http://api.drupal.org/api/function/file_save_upload/6 says:
"$validators An optional, associative array of callback functions used to validate the file. The keys are function names and the values arrays of callback parameters which will be passed in after the file object. The functions should return an array of error messages; an empty array indicates that the file passed validation. The functions will be called in the order specified."
It doesn't mention the $user object any more -- it's been patched (there was a patch above, and it got committed).
In 7.x http://api.drupal.org/api/function/file_save_upload/7 it says:
"$validators An optional, associative array of callback functions used to validate the file. See file_validate() for a full discussion of the array format."
That also doesn't mention the $user object.
So I think this is fixed in both D6 and D7 now. So I am not sure why Drewish reopened the ticket... please explain in more detail what you meant still needs to be fixed, and I will be glad to create another patch if necessary, but it looks right to me.
Comment #13
drewish commentedbecause i clearly can't read sorry for the confusion.