I have a few tasks I need to run once per import - for example, I need to set up some custom fields in the database.
The attached patches to csv_format.inc and rdf_format.inc simply add two new hooks - 'vocab_presave' and 'vocab_postsave'.
The changes to the RDF script can easily be pasted into leobard's SKOS script.
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | rdf_format.inc_.patch | 1.76 KB | kenorb |
| #3 | csvhooks.patch | 979 bytes | dotton |
| #3 | rdfhooks.patch | 883 bytes | dotton |
| #2 | taxonomy_xml-791376_hooks.patch | 4.08 KB | dman |
| rdfhooks.patch | 837 bytes | dotton |
Comments
Comment #1
dman commentedI think that adding hooks in strategic places is one of the best things we can do to extend a module, so I'm keen to put this straight in!
2 things though...
I've got to rename those hooks :
hook_taxonomy_xml_vocabulary_presave(),hook_taxonomy_xml_vocabulary_postsave()Need the full module name in it, and nothing is gained by abbreviating to 'vocab' - core has finally eliminated that sort of variation.
And would you be able to provide a cut-down example for the API doc demonstrating why you found these hooks useful?
Dangling hooks without any examples in the wild anywhere are not likely to get used well or properly. Can you give a generally useful example implementation?
Comment #2
dman commentedmy patch - against 2-dev, because that's where I am, but not significantly different from above.
Comment #3
dotton commentedI've fixed the names to match yours and attached the patches again, in case anyone should need to apply them to 6.x-1.3
The hook that already exists in rdf_import.inc is 'taxonomy_term_presave' - should that be renamed to 'taxonomy_xml_term_presave'? (Incidentally, it's missing from csv_import.inc)
I think it would be appropriate to pass success/failure information into the postsave hook, but I'm unsure how best to approach that. Counts of terms successfully imported/failed? Arrays of successful/failed terms? A single array, with the terms flagged as successful/failed?
My use-cases are quite implementation-specific and rely on other modules. This is about the simplest (and, unfortunately, useless) example I could come up with:
/**
* Implementation of hook_taxonomy_xml_vocabulary_postsave().
*/
function example_hook_taxonomy_xml_vocabulary_postsave($vocabulary) {
global $user;
watchdog('example', 'User %name imported vocabulary %id.', array('%name' => $user->name, '%id' => $vocabulary->vid));
}
Comment #4
dman commentedYeah, that other hook sure should be renamed, you are right.
It's getting harder to keep all the different format libraries in line, thanks for noticing the csv one. This is why I wanted to get some test suite going :-}
Comment #5
dotton commentedIf you have a suggestion for how to pass success/failure to the postsave hook, I'd like to submit a patch against 2-dev.
Comment #6
dman commentedcommitted in -dev. (doing some tidy-up)
I can't do much testing or doc until I find a test case or example of these hooks being useful really. But the concept is sound by me. I'll leave the hooks dangling for now
Comment #8
kenorb commentedThanks.
What about:
and
in:
And:
in:
?
Comment #9
kenorb commentedNote that module_invoke_all() doesn't support references, so we can't modify any data.
If we need to pass the $term through reference using module_invoke_all() in PHP 5.3, you need to change it to:
See:
#353494: Remove node_invoke(), comment_invoke(), etc
http://drupal.org/node/686066#comment-2822848
http://api.drupal.org/api/function/module_invoke/6
http://api.drupal.org/api/function/module_invoke_all/6
Comment #10
kenorb commentedSorry for re-opening, but it's still related to this thread.
In attachment - modified David's patch to make it compatible with PHP 5.3 and with references.
Added as well hook_taxonomy_xml_term_postsave and hook_taxonomy_xml_data_preprocess() which was initially written by David.
Comment #11
kenorb commentedComment #12
dman commentedCommitted hunk 2 and 3 from #10 to 6.x-2.x-dev
Because they make sense. Good hooks in sensible places.
Not sure about hunk 1.
hook_taxonomy_xml_data_preprocess feels like overkill. There may be a more graceful way. Or maybe it's worth a whole new format processor if the data needs that much manipulation.
Need some solid examples of use-cases and actual API docs to proceed there. Like what is the expected data, and what is expected to happen.
http://drupal.org/cvs?commit=480614