translation prepare
little red wagon - August 24, 2009 - 15:39
| Project: | Media Mover |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Jump to:
Description
Hi Arthur,
It doesn't look to me like media mover supports core content translation in 6.x -- the "translation prepare" op in hook_nodeapi that would allow newly created translation nodes to reference the same media_mover information as their originals. (I'm not talking about te i18n module, just core translation.) I'm going to work something up quickly and i'll post the code here, but let me know if i've missed something obvious that's already been implemented or if there's anything i should watch out for.
Hope you're good!
John
#1
Howdy!
I haven't played around with this. The old i18n_sync module was supposed to handle this, but clearly this is a way better option. It looks like from the documentation:
"prepare translation": The node is being cloned for translation. Load additional data or copy values from $node->translation_source.
In this case, do we just need to do:
$node->media_mover = $node->translation_source->media_mover;
I hope it's that easy, but when is it ever?
best
a.
#2
Sadly, not that easy! Copying the media_mover array from the translation source node to the new node won't create new entries in the media mover table for the new translation node. And using the "prepare translation" hook to create those entries won't work either, since the new node doesn't have a nid yet. I created this nodeapi hook and it does the trick -- maybe a cleaned up version of this would be useful in the media mover api module? (Sorry for forgetting to post this earlier!)
if ($op == 'insert') {if ($node->translation_source) {
$translation_source = $node->translation_source;
$media_mover = $translation_source->media_mover;
foreach ($media_mover as $cid) {
foreach ($cid as $row) {
$row['data']['nid'] = $node->nid;
db_query("INSERT INTO {media_mover_files} (nid, fid, cid, harvest_file, process_file, storage_file, complete_file, status, date, data) VALUES (%d, %d, %d, '%s', '%s', '%s', '%s', %d, %d, '%s')",
$node->nid, $row['fid'], $row['cid'], $row['harvest_file'], $row['process_file'], $row['storage_file'], $row['complete_file'], $row['status'], $row['date'], serialize($row['data'])
);
}
}
}
}
#3
Ok, of course it isn't this easy either because we have the nasty case of delete. Since delete functions on file paths, it will just go through and delete these files- even if they are in use by another node. Thankfully we have a new NID so I think we can do the following and get around the delete issue:
So I think there needs to be a refactoring of the delete function to be aware of nodes which may reuse the same file (perhaps the rule is simply something like SELECT COUNT(complete_file) FROM {media_mover_files} WHERE complete_file = "%s")
Thus the "physical" file can not be deleted if there are multiple instances of it. I think I'd limit this to the complete file (MM 2.0 will be different).
Then the other piece that will need to be dealt with is when the hook_media_mover('delete') gets fired. I would suppose each module that implements this will need to handle this case on their own. I'd prefer to handle it in the API, but the point of this is to have storage/action outside of the API
#4
That makes sense to me. The CCK FileField and ImageField module share the same problem -- deleting any node in a translation group deletes the original file despite it still being referenced by the other nodes in the group. Maybe there could be a more generalized solution in the translation module? (In practice it hasn't been a huge problem -- usually translation groups are all deleted at the same time anyway...)
#5
I wonder if using the files table in D6 to get an FID for media mover files makes sense. I think there are some forth coming functions to deal with this, but it may be late in the game to worry about it. We should probably make a separate issue for the deletion stuff.
#6
FYI, delete issue is here: http://drupal.org/node/583840
#7
I committed this code, needs testing. Delete code is there as well.