I've written a patch that adds a new checkbox to the settings page. Checking this new box will, upon node submission, overwrite the original/current author of the node with the user who's name corresponds to the selected name in the author taxonomy term. If a match isn't found, it leaves the old author intact.
This is my first patch ever, so let me know if I messed it up!
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | author_taxonomy_overwrite_node_author_4.patch | 3 KB | emilyf |
| #7 | author_taxonomy_overwrite_node_author_3.patch | 3.01 KB | emilyf |
| #2 | author_taxonomy_overwrite_node_author_2.patch | 2.09 KB | emilyf |
| #1 | author_taxonomy_overwrite_node_author.patch | 2.08 KB | emilyf |
Comments
Comment #1
emilyf commentedsorry, here is the patch...
Comment #2
emilyf commentedI adjusted the patch a little. It was replacing author with anonymous if on first submission it didn't find a match. Now it doesn't do that.
Comment #3
david strausstaxonomy_node_get_terms_by_vocabulary() will load the previously saved taxonomy terms for the node, not the ones set on the current submit.
Comment #4
david straussThis code will also display warnings in PHP's strict mode because there might not be an item 0 in the authors array.
Comment #5
david straussCoding style errors:
* Form element titles should be sentence case.
* t() items should be in double quotes if they contain single quotes (and don't contain double ones).
* Indentation should follow Drupal code style standards.
This line doesn't do anything:
$node->nid = $node->nid;
Comment #6
emilyf commentedYes, I see that you are correct on this. Do you have a suggestion of how I can get around this issue and get the current term that is going to be submitted?
Comment #7
emilyf commentedOK, here is a new version that uses nodeapi better to get taxonomy term before submitting. It also deals with if the multiple select option is turned on, and if you have multiple entries if you're using free tags. However, at present in both those situations it will only look at the first term. My org doesn't even need it to be for multiple select but I included it so it could be more functional with this module. If people are interested and like this patch, then I will add the code to loop through each term until it finds one that matches a user. Alternatively, it could match based on term weight which may be more appropriate. For this I would take input from others. In terms of these comments:
All three I basically followed how it's already being done in the author taxonomy module. And I think I fixed the PHP strict warning issue.
Comment #8
david straussYou probably shouldn't re-implement the term parsing from taxonomy.module. I can come up with about three cases off the top of my head where your parser would work differently than the built-in one.
It's much easier and safer to do the following:
Where _my_module_get_terms is implemented as:
$copy->taxonomy will then be in the same format as when you node_load();
Also, the code still needs changes to comply with Drupal coding standards. Primarily, replace your tabs with two spaces each. Comments like "The following case added by sw9" are generally not part of patches.
Thanks for the work so far!
Comment #9
emilyf commentedHi David,
Now I see why you are still telling me to get to Drupal standards. In my text editor all the tabs are really 2 spaces, so when I made the patch something got funky on my linux distro. I made this version of the patch on my mac and it's rendering them properly. I *hope* the coding styles is at least remedied.
In terms of your other comments, please forgive me for being so newbie in development. I don't think I understand what's wrong with just accessing $node->taxonomy before it's been submitted. Am I going to cause errors somewhere? If you have a moment, could you maybe further explain this and what it would do should it work differently:
Thanks, I really appreciate your assistance.
Comment #10
todd nienkerk commentedThe problem with accessing
$node->taxonomybefore it's submitted is (I think) because the terms have not yet been ordered in terms of weight (or, failing weight, in alphabetical order). This results in the following strange behavior when free tagging is enabled:While you haven't actually changed any information, the overwritten author has changed because Drupal reorders the terms when the node is saved.
I'm working on implementing David's solution.
Comment #11
emilyf commented@Todd, yes David's solution is the better way to go here. I ended up not liking this implementation and wrote my own custom module that assigns a node author based on a cck user ref field. This was cleaner and a better solution based on the assistance I got from David.
Comment #12
todd nienkerk commentedRegarding my earlier statement:
This may not be accurate. It's possible Drupal is reordering the terms when the node is loaded into the edit form, thus reordering the terms on the second save.
Comment #13
todd nienkerk commentedI've added this feature to the 5.x and 6.x versions. (It's very different than the patch originally submitted, but the result is the same.) Thanks for your input!