Pass $node and $field for update / insert hooks in API

I realized that even that wont fit all needs. We also need to pass $field to the hook. Otherwise you simply dont know what settings the field has - you dont even know which field it is. I think this is also a very critical argument.

Added this to the patch - still wont affect any default behavior

Fixing title

Fixing category, fixing code style

concurent saving :)

Good catch Daniel, forgot about that this is API and not a private method. but i think field should be rather array() then?

This should finalize it

Well for D7 those hooks are not needed at all, but what about Drupal 6? In Drupal 7 you can also define hook_field in modules which are not defining that field, but in Drupal 6 thats not possible.

No its not the same.

You _cannot_ define hook_field in D6 from outer modules. This is confirmed.
And you _cannot_ define hook_file_update from outer modules. well this is clear anyway (as the fieldtype is unique).

So there is absolutely no other way in D6 catching that hook.

Well but the file and node are in a relation and you want simply lose that information? It is also passed as "entity" in hook_file_field so its surely an important information.

Lets say you want to do something with the file uploaded AND assigend to a node (by a filefield), but you also need the relation to its parent. there is no way doing so without:
- hacking filefield
- using nodeapi and filtering the whole node for fields .. what is really bad.

I see your point, as in D7 fields are not longer node-specific, but can be attached to any entity. But this makes this information even more important, otherwise you now would have to implement hook_nodeapi, then one for comment, user .. and so forth. So even with the perspective to drupal 7 ( eventhough its 6.3.3 and not 7.x. ) i think thats a useful addition. I think with the D7 scope the implementation of the hook would more look like

function drupalwiki_privatefile_filefield_file_update(&$file,$entity,$field) {
  if($field['widget']['drupalwiki_privatefile_makeprivate'] == 1)  {
    _drupalwiki_privatefile_to_private($file->fid,$entity->vid,'node_revision');
  }
}

This way i can implement private files support for every subwidgets of filefield. Yes i could create a widget "filefield_private", but that would mean imagefield_private would need to be created, and swfupload_private and and and. Cant you see the usecase?

_drupalwiki_privatefile_to_private needs the relation to the parent, as it needs to now "who is the parent i check access for later".

Well i just dont see how your statement is taking related to this API change. what you state in #17 is, that there are cases, where files are on their own - not tight to anything. Well in that case, entity is null and those systems which rely on a parent to work will skip this file, e.g. private-files ( as permissions cant be applied ).

So i see your point that there are cases where its not needed but i think you can undestand that there are even more cases ( general ) where it makes a lot of use.

And as providing that API does not harm your case, but not providing it makes the case i described horrible i would please you to let this feature go in.

Thanks

not sure i get your question. as hook_field is gone in D7 i think there is the same issue for both now, you cant hook into update to get entity + file from outer modules.

So you will need this for both.

As explained, this would then need a implementation for every widget type.

And now its not mingeling, hook_file_update is only able to be implemented once - and will be implemented by the field author in his module. so you never can use it. And most file-based hooks _have_ no context, as they only handle "the file" no matter where it is attached.

Filefield is exactly the connection between node and file and i have no idea why you make it that hard implementing those to arguments which are evidently.

You search and search for alternatives which are not even close to be that handy. If you simply dont want to take this feature in - dont do it. Last comment on my side.

Well then i probably make a Drupal 6 fork of filefield to cover fields of D6 as you seem to be focused on D7, which is (for me), not ready to be used in complex productions in 1 our 1,5 years.

I really dont get your D7 focus. D7`s fileapi like differs 200% from d6..you have much better posibilities there. But you go against a feature in D6 which has, well are we even allowed to call it a fileapi? I think its next to the comment module and the taxonomy module one of the darker sides in Drupal. So you just let the D6 in the big black whole because D7 handles things "differenly". And we speak about 2 arguments, not a "code change".