The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.I have created many modifications to the module, see http://drupal.org/node/722052.
As per http://drupal.org/node/363367 I will now create issues for the main new features.
Let's keep this as the overview issue toward a potential stable release in the near future.
I'm summarizing:
- This is more or less a total rewrite.
- I have kept the UI portion of the manual pruning part, I have added an "All" option, and the simulation.
- The automatic pruning fieldset is new and configures the previously commented cron hook. I'm gonna update http://drupal.org/node/599996 as far as that is concerned.
Attached are the current code and a screenshot.
In the long run we might catch up with http://drupal.org/node/571878 and "assimilate" the cleantaxonomy module, although there is not much to assimilate.
| Comment | File | Size | Author |
|---|---|---|---|
| dot.png | 30.8 KB | jmroth | |
| delete_orphaned_terms.tgz | 6.23 KB | jmroth |
Comments
Comment #1
jmroth commentedI've also committed 6.x-2.x-dev to CVS.
Comment #2
matt v. commentedThanks for checking that in. I've installed the 6.x-2.x-dev version on one of my sites, so I could start to look over the new functionality. I really like the additions; they make the module much more flexible. I've only used it for a few minutes, but here is my initial feedback.
It's a bit confusing to me that the Menu item is now called "Taxonomy Pruner - Delete Orphaned Terms". The project page is already established as "Delete Orphaned Terms." I think it would be a good idea to keep the name and terminology consistent (ie, delete vs. prune).
It's also a bit confusing to me to have multiple forms on the same page, that perform different functions (ie, manual vs. automatic). What do you think about creating separate tabs for "Global parameters" (as the default tab), "Automatic deletion", and "Manual deletion"?
Also, the "Failsafe" help text states that it is the "Maximum percentage of tags to delete from all vocabularies combined in automatic mode." If it only applies to automatic mode, should it be under the automatic fieldset/tab instead?
Comment #3
jmroth commentedThanks for testing. Concerning your comments:
Menu item: I just wasn't too sure if the menu item should start with a verb (here: "Delete"). In fact it just says "Delete something", although it's not clear what that is. I believe that's not a good nomenclature to use. But more to that below.
Multiple forms: I get your point. I asked myself the same questions about usability.
Maybe one should separate the manual and automatic stuff completely?
One possibility would be to put the manual stuff back where it was using hook_menu() and keep the configuration for the automatic (new) part of the module in the administration menu using hook_admin(). I actually put your code more or less in my module that's why it ended up like that.
Considering these two things, maybe we can reach a consensus that we would call the menu item "Delete Orphaned Terms" and the admin menu "Taxonomy Pruner"?
PS. Yes, the failsafe value probably should not be in a section called "Global".
Comment #4
jmroth commentedSorry some of that last post sounded confused. Obviously there is no hook_admin() but what I meant was to separate the action part from the configuration part, i.e. manual and automatic stuff: not only to several tabs but to several pages. One could then even issue different permissions for each.
I'll play a little bit with that and see how it turns out.
Comment #5
jmroth commentedI have committed what we talked about by the way.
I have also updated the project page.
And I have put the 1.x-dev version into its own branch, I guess we won't work on that much more.
So now, please use the current DRUPAL-6--2 branch. I guess we should update HEAD (whose release is no longer shown on the project page) just before creating a new branch. Although http://drupal.org/node/93999#HEAD is not completely clear to me.
Comment #6
matt v. commentedI updated to the latest dev version and I'm no longer seeing the manual deletion section. Am I missing something?
Also, on the subject of the menu option, I see your point about starting the menu with a verb; however, I still think that changing the menu title to Taxonomy Pruner causes more confusion than it solves. What do you think about "Orphaned terms deletion" for a menu title? For me personally, when I install a module called "X Y Z", I'm going to search the admin screens for the terms X, Y, and/or Z when looking for the administration pages for that module. That said, I'm not sure what you meant when you suggested that we "call the menu item 'Delete Orphaned Terms' and the admin menu 'Taxonomy Pruner'. Specifically, I'm not sure what you meant by "menu item" versus "admin menu". I guess you're talking about having separate admin screens for manual versus automatic deletion. I think you could still have separate permissions for each, while still having them as tabs under a single menu option. Or am I mistaken?
Personally, I find it more confusing when modules spread out their functionality across multiple menu sections.
Comment #7
jmroth commentedThe "action" menu should be right at the root of the Navigation menu (i.e. visible directly when you are logged in -- maybe you also need to clear caches). That's actually what I meant with separating the manual and automatic part.
Modules like "API reference" and "Code review" do the same thing: the configuration page lies somewhere under "admin/" whereas the "action" page is somewhere else. Obviously this makes sense since configuration != action.
I am still not 100% happy with the nomenclature but I guess I could live with "Orphaned Terms Deletion".
Comment #8
matt v. commentedOkay, I tracked down the updated "Delete Orphaned Terms" menu item, first by looking at the hook_menu implementation and then by viewing the Navigation menu List Items tab. Unfortunately, it does not show up on the Administration menu module menu bar, the administration by module page (/admin/by-module), or the main Admin (/admin) page.
In my opinion, the "/dot" page does involve administering content on the site. I still think its URL should begin with /admin. I believe that modification would also take care of adding it to the three places I initially looked and didn't find it.
I understand that "API reference" and "Code review" work that way, but my argument is that they are the exceptions that prove the rule. From what I've seen, far more modules consolidate their menu items as sub-tabs of a main /admin menu item. I've certainly run into other modules that work the way you describe, but I tend to curse them silently when I run across them because I end up looking in the hook_menu implementation to find where to go.
Comment #9
jmroth commentedAlright, shouldn't we then put the 'action' part under admin/content/taxonomy maybe? We could even add it (or even both) as tab(s) to the Taxonomy menu (besides List/Add vocabulary).
Oh BTW, technically, the terms are not orphaned, which would mean they have no parents. They simply have no children (nodes) attached to them. Just went through my mind.
Anything else keeping us from declaring this release as stable?
Comment #10
matt v. commentedI'm not 100% set on where the menu should go, I just think it's hard to find when not on the administrative menu somewhere.
I mainly chose "Delete Orphaned Terms" as the module name because those were the terms people were using to describe the scenario, so I figure those would be the terms people would use to search for such a module.
I'd be fine with declaring a stable release. Obviously you've put a lot of work into it. Thanks!