Posted by sun on November 12, 2010 at 3:34pm
6 followers
| Project: | Comment alter taxonomy |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | major |
| Assigned: | Unassigned |
| Status: | needs work |
| Issue tags: | needs drupal.org deployment, Needs tests |
Issue Summary
Issue tags on drupal.org have become unusable.
Click on arbitrary terms in http://drupal.org/admin/content/taxonomy/9 and chances are very high that you get an empty term page.
Since Drupal's autocomplete "widget" only shows a limited number of entries, it's not possible to select certain issue tags -- even if you completely spell them out.
Attached patch implements hook_cron() to find all terms in configured vocabularies that are no longer assigned to any node.
And deletes them.
| Attachment | Size |
|---|---|
| comment_alter_taxonomy.orphan.0.patch | 1.14 KB |
Comments
#1
suppose it's better to add an Action and save UI in contrib? admin_menu 4?
Better check
$vidsfor emptinessEDIT dreaming about ATM - advanced taxonomy manager
#2
The foreach is not executed if $vids is non-empty.
#3
I mean
db_placeholders()and all after thatif array is empty - no reason to disturb DB layer at all
#4
ah, nice! Gotcha, thanks!
btw, who's in charge of this module's code + able to commit + push upstream to d.o?
#5
There's a 4 maintainers :) I think enough
#6
Any updates or feedback on this? As mentioned in the OP, d.o issue tags are becoming more and more unusable. :(
#7
Should we maybe limit the query to a certain number of terms per cron run? If a site had 10,000 abandoned terms, then it probably wouldn't be good to run taxonomy_del_term() 10,000 times?
#8
bump?
#9
Re-rolled with db_query_range() and git.
#10
Also, if I'm not mistaken, the comment_alter_taxonomy_vocabularies variable looks like this:
Array(
[9] => 9
[1] => 0
[38] => 0
[6] => 0
[4] => 0
[3] => 0
[7] => 0
[2] => 0
[5] => 0
[31] => 0
[32] => 0
[33] => 0
[34] => 0
)
So the query would run on vocabularies that should not get processed since this uses array_keys() without array_filter().
#11
#12
Thanks, @Dave Reid! Attached patch processes the variable value properly.
#13
Any feedback on #12? Looks RTBC to me.
#14
For me too
#15
Thanks for reporting, reviewing, and testing! Discussed with @drumm and @killes in IRC and committed to master.
A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.
#16
Just saw that @dww committed another patch, but asked for tests. Hence, same procedure here.
#17
Tagging.
#18
There is nothing to deploy here, it should not have the tag.
#19
@#18 -- So this feature will not be used on the drupal.org website? We're still going to have hundreds of unused issue tags that never get deleted?
#20
The module maintainers need to commit this and make a release. Just like any other site, Drupal.org will deploy the new version of the module. We don't want local hacks unless they are really necessary.
#21
Taking another look at the history here, I see something was committed. I'd still really want to see a full, stable release. We can run -dev, but point releases are much nicer.
#22
So we need a new tag: "Needs point release" or similar.
#23
That would be a lot of busywork. Every module has issues fixed before deployment. This doesn't need to be any different. I'll put back the needs drupal.org deployment tag since there is code that can be deployed, preferably with a release.
#24
Yes, this was committed to CAT already, and deployed on drupal.org.
As mentioned in #16, this issue was left open to add functional tests for this to the module.
--
That said, probably for a separate issue, I want to go one step further and add an option to the module to also prune out terms that are semi-orphan; i.e., only used once for a certain time. drupal.org heavily suffers from these; the issue tag autocomplete became almost useless in the meantime, as you most often need to type in the full exact term name to make the tag appear in the autocomplete list. A tag that keeps on to have only one issue associated with it is useless. Pruning out those will probably get rid of at least 50% of all issue tags. But anyway, should be a separate issue, I guess.
#25
I'm looking forward to seeing this in action, also for clearing out all the spammer-added terms in the docs pages. See a typical screenshot from the autocomplete widget in "keywords":
I created an issue for that (http://drupal.org/node/1518390), but closed it as a duplicate of this issue after webchick pointed out that this should resolve that one.
It would take some work, but where appropriate, tags only used once, twice, or a few times should be consolidated into appropriate tags that have a similar meaning and more frequent use.