Rules already supports filefields, but I needed something more fundamental to work with upload.module and also with filefield so I could copy values from one filefield instance to another.

I'd appreciate feedback on this patch, and if the maintainers want to commit it, I can make changes as requested.

CommentFileSizeAuthor
#2 rules_file_support-540316-2.patch6.3 KBAnonymous (not verified)
rules-file-support.patch6.91 KBAnonymous (not verified)

Comments

amitaibu’s picture

Status: Needs review » Needs work

@bangpound,
Some notes from going over patch:

+define('RULES_FILE_LOAD', 'SELECT fid,uid,filename,filepath,filemime,filesize,status,timestamp FROM {files} WHERE fid = %d');

I haven't seen this in core. Maybe it would be nicer to have it as a function returning? Anyway you have missing spaces between the commas.

+function rules_events_file_arguments($file_label, $author_label, $update = FALSE) {

It seems this function is never used?

+ 'label callback' => 'rules_action_file_load_author_variable_label',

You declare the callback, but don't implement it. Anyway, you can and should implement a label callback, but don't have to declare it if you use the naming convention (i.e. RULE-CALLBACK_label). Also, the label callback is per rule, not per argument.

+items['rules_condition_file_is_type'] = $defaults + array(

I think we don't need the $defaults, you can put it directly in the condition, as there are no other conditions currently using it.

+ drupal_write_record('files', $file);

If we are updating an existing file then it I think it should be drupal_write_record('files', $file, array('fid'));

+ return $file->fid ? db_fetch_object(db_query(RULES_FILE_LOAD, $file->fid)) : $file;

return !empty($file->fid) ? ... <- for no PHP warnings.

Anonymous’s picture

Status: Needs work » Needs review
StatusFileSize
new6.3 KB

Amitaibu:

Thanks for the thorough review. It's probably obvious that I'm very new to Rules, so I appreciate it.

My use of a constant was simply to ease the development of the patch. I've merged it into the rest of the functions correctly now.

All of the "event" functions are gone. Files in Drupal 6 don't trigger events. I was copying too much from the node rules.

This new patch takes all of your advice into account. I need to write some more rules to test the set author action and also the file save outcome. My rules so far only rely on the load file and load author.

I'm slightly confused about where I'd see the label callbacks play out (either the explicit ones or the default callback patterned ones). I have written more label callbacks, but I see no changes in the UI as a result.

fago’s picture

Status: Needs review » Postponed

I really appreciate your patch, however it seems to be complicated to use to me. So I think it wouldn't make much sense to add it to rules itself, as most of the users won't be able to use it. Thus I'd suggest you provide a small separate module for that - ideally shipping with some usage instructions.

Part of the problem that your stuff is hard to use is that there is no easy way to get files attached to a node. I'm aware of that problem and I work on improving it for rules2 - so probably then your stuff would make sense. So we can look into including it for rules2.

@code: Hm, usually drupal uses the file ending for identifying the file types right? Perhaps you should call your condition "File has mimetype" instead.

fago’s picture

ah. if you decide to go with the module for now, don't forget to add it here: http://groups.drupal.org/node/14253

Anonymous’s picture

fago:

The use case here is that multiple files are uploaded (using upload.module or a filefield) and then the triggered rule set splits those files into individual nodes (node type is determined by the file's mime type) and the files are attached (or the fid is reused) to new nodes' filefields. This effectively lets me use one simple node type as a "batch" to create an arbitrary number of nodes of various types.

The mimetype is determined in Drupal using file_get_mimetype, which does use file extension. However, mimetypes are more predictable than file extensions. I can let people upload PNG, JPG, GIF, etc. and the rule condition only has to use image/*.

Otherwise, it's cool to postpone it. When I release my feature, perhaps you'll see how I'm using it, or you can advise on the reasons I don't need to do it this way!

friolator’s picture

Just curious - would this patch address the following use case?

We are using content_profile, and we want to allow the user to upload a new user profile photo via CCK filefield upload. The problem is that the system user picture is used in so many locations, and by some contrib modules we're using, that we want to synchronize the user picture and the CCK filefield upload. That is:

1) User goes to "Edit Profile" page, uploads new photo (CCK filefield)
2) User saves their profile changes
3) We capture that upload event with Rules, and make a copy of the photo they've uploaded in the system user picture location.
4) We continue to call the user picture where needed

Is this something we can do with Rules, using this patch?

Anonymous’s picture

friolator:

If the user profile picture is stored in the files table, you can use this patch (see note) to load an item from the files table by ID and save it in a CCK Filefield.

However, I don't suggest you do quite yet if you're not prepared to struggle with the patch a bit. It's already been postponed, so I've been developing it inside the module I need to use it with...

greg.harvey’s picture

There are other Rules use cases for files. For example, I would like to archive files on cron, which could be a rule. In fact, I might make it as a Rule. =)

Anonymous’s picture

@greg.harvey: you can see my code for using rules on the core files table here:

http://bangpound.svn.beanstalkapp.com/drupal/trunk/drupal/sites/all/modu...

greg.harvey’s picture

Brilliant. Thanks for sharing. =)

klausi’s picture

Version: 6.x-1.x-dev » 7.x-2.x-dev
Status: Postponed » Active
fago’s picture

Status: Active » Fixed

As files are entities in d7, with already basic support for them. loading + creating should work, while I know we are missing entity metadata for the file+imagefield. If we have that, file support should be fine. There is an entity metadata issue for that.

Status: Fixed » Closed (fixed)

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

mitchell’s picture

Component: Provided module integration » Provided Module Integrations

Updated component.