Issue status update for http://drupal.org/node/20505 Project: Drupal Version: cvs Component: taxonomy.module Category: feature requests Priority: normal Assigned to: Morbus Iff Reported by: Morbus Iff Updated by: Dries Status: patch If would make sense if "free tags" were also shown if there are less than 25 terms, not? Dries Previous comments: ------------------------------------------------------------------------ April 14, 2005 - 18:31 : Morbus Iff Attachment: http://drupal.org/files/issues/_p_25termvocab.patch (1.28 KB) There was some small talk about this here and there during my folksonomy/free tagging patch, but I held off until now to actually implement it. Much like we handle free tagging vocabularies ("this is a free tagging vocabulary: view terms", which leads the admin into the taxonomy pager system), this patch does the same thing for NON-free tagging vocabularies, but ONLY if the vocabulary has more than 25 terms. These patches were made during the exploration and customization of Drupal by http://www.NHPR.org. In loving support of open source software, http://www.NHPR.org will continue to contribute patches they feel the community will benefit from. Questions about this patch should be directed to morbus@disobey.com.

Issue status update for http://drupal.org/node/20505 Project: Drupal Version: cvs Component: taxonomy.module Category: feature requests Priority: normal Assigned to: Morbus Iff Reported by: Morbus Iff Updated by: Jaza Status: patch Two suggestions: 1. Why >25? Anything special about the number 25? +1 For the idea of having 'view terms' for vocabularies with a large number of terms, but I don't see why 25 is necessarily where 'large' begins. This number should be a setting somewhere (not sure where, since taxonomy has no options page of its own). 25 can be the default option - it sounds reasonable to me (but maybe not to all webmasters). Perhaps make it so that if '0' is entered as the number, all terms are always displayed for that vocabulary (unless free tagging is enabled). 2. Taking this concept a bit further, it might be good to have an option: "enable free tagging for vocabularies when the number of terms reaches x". x could be the same variable as the one above, but I suggest that it be stored separately, for a more flexible configuration. As with suggestion 1, it may be hard finding a settings page on which this option belongs. Also, this might be taking it too far - could be one setting too many? In terms of performance, there should be no problem, since free tagging vocabularies do not need to have their terms counted - only others do. Number 2 could also be implemented on a per-vocabulary basis (number 1 also could, but that would be silly), but that would mean another column in the vocabulary table, especially for free tagging. And if that can be avoided, it should. Jaza Jaza Previous comments: ------------------------------------------------------------------------ April 15, 2005 - 02:31 : Morbus Iff Attachment: http://drupal.org/files/issues/_p_25termvocab.patch (1.28 KB) There was some small talk about this here and there during my folksonomy/free tagging patch, but I held off until now to actually implement it. Much like we handle free tagging vocabularies ("this is a free tagging vocabulary: view terms", which leads the admin into the taxonomy pager system), this patch does the same thing for NON-free tagging vocabularies, but ONLY if the vocabulary has more than 25 terms. These patches were made during the exploration and customization of Drupal by http://www.NHPR.org. In loving support of open source software, http://www.NHPR.org will continue to contribute patches they feel the community will benefit from. Questions about this patch should be directed to morbus@disobey.com. ------------------------------------------------------------------------ May 2, 2005 - 21:32 : Dries If would make sense if "free tags" were also shown if there are less than 25 terms, not? ------------------------------------------------------------------------ May 3, 2005 - 04:53 : Morbus Iff My concern with that is how to actually get the term count quickly for a vocabulary that has 8000 terms. On my installation (with 8000+ terms), it takes 360ms (per devel.module) for get_tree(). Following through with the same mentality code as suggested with this patch (using get_tree() to return an array of countable terms), we'd be wasting 360ms just to get a count of free tagging terms (more or less - I've been generally assuming that the very smallest free tagging vocab would be 100 terms, and the largest I've worked with being 8000). The only other countable equivalent would be a brand new SQL statement that'd just return the number of terms in a vocabulary (similar to term_count_nodes, only vocabulary_count_terms). I could certainly add this in, but for consistency / pattern sake, I'd want to use it IN PLACE of the get_tree side- effect/counting as demonstrated in this patch (so, count first, then get_tree when necessary). This would cause NUM_VOCABULARIES more queries than currently, but would certainly add up less than returning an entire tree of 8000 terms just to throw it away again. Thoughts?

Issue status update for http://drupal.org/node/20505 Project: Drupal Version: cvs Component: taxonomy.module Category: feature requests Priority: normal Assigned to: Morbus Iff Reported by: Morbus Iff Updated by: Bèr Kessels Status: patch -1 on yet another option. We must decide what 'big' is. if someone really has objections about our idea of 'big' she should change that in the code. Another option is not an option, IMO. Morbus, what about using variable_get/set? If you detect the number only for very speecial cases, and find that there are more then 25, you do variable_set('taxonomy_is_large', array($vid => TRUE)), if its detected < 25 variable_set('taxonomy_is_large', array($vid => TRUE)) Where exactly you can set that, I do not know, but from that moment on you only need to check against that variable, on all the places where a tree would be rendered. Bèr Kessels Previous comments: ------------------------------------------------------------------------ April 14, 2005 - 17:31 : Morbus Iff Attachment: http://drupal.org/files/issues/_p_25termvocab.patch (1.28 KB) There was some small talk about this here and there during my folksonomy/free tagging patch, but I held off until now to actually implement it. Much like we handle free tagging vocabularies ("this is a free tagging vocabulary: view terms", which leads the admin into the taxonomy pager system), this patch does the same thing for NON-free tagging vocabularies, but ONLY if the vocabulary has more than 25 terms. These patches were made during the exploration and customization of Drupal by http://www.NHPR.org. In loving support of open source software, http://www.NHPR.org will continue to contribute patches they feel the community will benefit from. Questions about this patch should be directed to morbus@disobey.com. ------------------------------------------------------------------------ May 2, 2005 - 12:32 : Dries If would make sense if "free tags" were also shown if there are less than 25 terms, not? ------------------------------------------------------------------------ May 2, 2005 - 19:53 : Morbus Iff My concern with that is how to actually get the term count quickly for a vocabulary that has 8000 terms. On my installation (with 8000+ terms), it takes 360ms (per devel.module) for get_tree(). Following through with the same mentality code as suggested with this patch (using get_tree() to return an array of countable terms), we'd be wasting 360ms just to get a count of free tagging terms (more or less - I've been generally assuming that the very smallest free tagging vocab would be 100 terms, and the largest I've worked with being 8000). The only other countable equivalent would be a brand new SQL statement that'd just return the number of terms in a vocabulary (similar to term_count_nodes, only vocabulary_count_terms). I could certainly add this in, but for consistency / pattern sake, I'd want to use it IN PLACE of the get_tree side- effect/counting as demonstrated in this patch (so, count first, then get_tree when necessary). This would cause NUM_VOCABULARIES more queries than currently, but would certainly add up less than returning an entire tree of 8000 terms just to throw it away again. Thoughts? ------------------------------------------------------------------------ May 3, 2005 - 15:26 : Jaza Two suggestions: 1. Why >25? Anything special about the number 25? +1 For the idea of having 'view terms' for vocabularies with a large number of terms, but I don't see why 25 is necessarily where 'large' begins. This number should be a setting somewhere (not sure where, since taxonomy has no options page of its own). 25 can be the default option - it sounds reasonable to me (but maybe not to all webmasters). Perhaps make it so that if '0' is entered as the number, all terms are always displayed for that vocabulary (unless free tagging is enabled). 2. Taking this concept a bit further, it might be good to have an option: "enable free tagging for vocabularies when the number of terms reaches x". x could be the same variable as the one above, but I suggest that it be stored separately, for a more flexible configuration. As with suggestion 1, it may be hard finding a settings page on which this option belongs. Also, this might be taking it too far - could be one setting too many? In terms of performance, there should be no problem, since free tagging vocabularies do not need to have their terms counted - only others do. Number 2 could also be implemented on a per-vocabulary basis (number 1 also could, but that would be silly), but that would mean another column in the vocabulary table, especially for free tagging. And if that can be avoided, it should. Jaza ------------------------------------------------------------------------ May 3, 2005 - 15:39 : Morbus Iff 25 is an arbitrary number based on the assumption that they'll be at least two vocabularies in a site (one for the site itself, and one for the forums). A single page with a maximum of 48 items on it is quite large already, and that doesn't take into consideration other user-created vocabularies that could increase the size of the page (2 other vocabularies that have 10 items each, for instance, could create a 68-item sized page). I'm against a user-settable option just for the sake of a user-settable option. #2 is a whole 'nother feature request and should be its own separate Issue. I won't respond to it here. In short, however, I don't like it.

Issue status update for http://drupal.org/node/20505 Project: Drupal Version: cvs Component: taxonomy.module Category: feature requests Priority: normal Assigned to: Morbus Iff Reported by: Morbus Iff Updated by: Dries Status: patch Personally, I'm not tempted to commit this patch. First, a 8.000 term vocabulary is not very realistic. It simply doesn't work. While this patch 'fixes' the administration page in such a scenario, it doesn't fix any of the other pages (like those having to render a selection menu with 8.000 terms). Morbus, is this _really_ needed? Dries Previous comments: ------------------------------------------------------------------------ April 14, 2005 - 18:31 : Morbus Iff Attachment: http://drupal.org/files/issues/_p_25termvocab.patch (1.28 KB) There was some small talk about this here and there during my folksonomy/free tagging patch, but I held off until now to actually implement it. Much like we handle free tagging vocabularies ("this is a free tagging vocabulary: view terms", which leads the admin into the taxonomy pager system), this patch does the same thing for NON-free tagging vocabularies, but ONLY if the vocabulary has more than 25 terms. These patches were made during the exploration and customization of Drupal by http://www.NHPR.org. In loving support of open source software, http://www.NHPR.org will continue to contribute patches they feel the community will benefit from. Questions about this patch should be directed to morbus@disobey.com. ------------------------------------------------------------------------ May 2, 2005 - 13:32 : Dries If would make sense if "free tags" were also shown if there are less than 25 terms, not? ------------------------------------------------------------------------ May 2, 2005 - 20:53 : Morbus Iff My concern with that is how to actually get the term count quickly for a vocabulary that has 8000 terms. On my installation (with 8000+ terms), it takes 360ms (per devel.module) for get_tree(). Following through with the same mentality code as suggested with this patch (using get_tree() to return an array of countable terms), we'd be wasting 360ms just to get a count of free tagging terms (more or less - I've been generally assuming that the very smallest free tagging vocab would be 100 terms, and the largest I've worked with being 8000). The only other countable equivalent would be a brand new SQL statement that'd just return the number of terms in a vocabulary (similar to term_count_nodes, only vocabulary_count_terms). I could certainly add this in, but for consistency / pattern sake, I'd want to use it IN PLACE of the get_tree side- effect/counting as demonstrated in this patch (so, count first, then get_tree when necessary). This would cause NUM_VOCABULARIES more queries than currently, but would certainly add up less than returning an entire tree of 8000 terms just to throw it away again. Thoughts? ------------------------------------------------------------------------ May 3, 2005 - 16:26 : Jaza Two suggestions: 1. Why >25? Anything special about the number 25? +1 For the idea of having 'view terms' for vocabularies with a large number of terms, but I don't see why 25 is necessarily where 'large' begins. This number should be a setting somewhere (not sure where, since taxonomy has no options page of its own). 25 can be the default option - it sounds reasonable to me (but maybe not to all webmasters). Perhaps make it so that if '0' is entered as the number, all terms are always displayed for that vocabulary (unless free tagging is enabled). 2. Taking this concept a bit further, it might be good to have an option: "enable free tagging for vocabularies when the number of terms reaches x". x could be the same variable as the one above, but I suggest that it be stored separately, for a more flexible configuration. As with suggestion 1, it may be hard finding a settings page on which this option belongs. Also, this might be taking it too far - could be one setting too many? In terms of performance, there should be no problem, since free tagging vocabularies do not need to have their terms counted - only others do. Number 2 could also be implemented on a per-vocabulary basis (number 1 also could, but that would be silly), but that would mean another column in the vocabulary table, especially for free tagging. And if that can be avoided, it should. Jaza ------------------------------------------------------------------------ May 3, 2005 - 16:39 : Morbus Iff 25 is an arbitrary number based on the assumption that they'll be at least two vocabularies in a site (one for the site itself, and one for the forums). A single page with a maximum of 48 items on it is quite large already, and that doesn't take into consideration other user-created vocabularies that could increase the size of the page (2 other vocabularies that have 10 items each, for instance, could create a 68-item sized page). I'm against a user-settable option just for the sake of a user-settable option. #2 is a whole 'nother feature request and should be its own separate Issue. I won't respond to it here. In short, however, I don't like it. ------------------------------------------------------------------------ May 4, 2005 - 11:20 : Bèr Kessels -1 on yet another option. We must decide what 'big' is. if someone really has objections about our idea of 'big' she should change that in the code. Another option is not an option, IMO. Morbus, what about using variable_get/set? If you detect the number only for very speecial cases, and find that there are more then 25, you do variable_set('taxonomy_is_large', array($vid => TRUE)), if its detected < 25 variable_set('taxonomy_is_large', array($vid => TRUE)) Where exactly you can set that, I do not know, but from that moment on you only need to check against that variable, on all the places where a tree would be rendered. ------------------------------------------------------------------------ May 18, 2005 - 20:20 : Morbus Iff Attachment: http://drupal.org/files/issues/_p_25termvocab_0.patch (1.32 KB) Does anyone else have comments on berkes' suggestion in #5? Dries? Perhaps the more adequate question is: is a "free tagging" vocabulary really useful if it has 25 terms or less? Isn't that more in the realm of a controlled vocabulary? If the user really is typing in the same 25 terms over and over again, that's gotta be an indication that they can save time with a dropdown, right? And if the free tagging vocabulary is just starting out, isn't there an assumption that it will eventually grow to be larger than 25 terms, In almost every use case? I guess my definition of a "free tagging" vocabulary ALSO includes the assumption that it'll grow to be $large, where $large is AT LEAST 100 terms. I've never seen any folksonomy smaller than that, save for those just starting out. is that a valid assumption? If it is, should it be treated as a "speshul" type of vocabulary, one which doesn't need a check on how many terms are actually in it, especially when said check become more prohibitive (in added code as well as processing time) as the vocabulary grows? (Attached an updated, but unchanged, patch to sync with HEAD).

Issue status update for http://drupal.org/node/20505 Project: Drupal Version: cvs Component: taxonomy.module Category: feature requests Priority: normal Assigned to: Morbus Iff Reported by: Morbus Iff Updated by: nedjo Status: patch This general question would be, how do we differentially display object references (nodes, terms, users) depending on the number available? As things stand, we don't do this, but we do take different approaches based on object type. Consider two examples from form elements. (a) Users. When we want the user to designate a user, we present a text box (rather than a select), assuming there will be too many users to present in a select. (b) Terms. We present a select, assuming there will be few enough terms. But neither of these assumptions holds for all sites. I've got several sites with few enough users to fit handily in a select, whereas we've heard there are plenty of sites with too many terms for a select. +1 for the general answer of thresholds and differential display. The proposed patch is a good start. I'd prefer to have the threshold number pulled out into (yes) a configuration option, ideally a general one that is for all object types. This would enable future work on lists of other types. nedjo Previous comments: ------------------------------------------------------------------------ April 14, 2005 - 12:31 : Morbus Iff Attachment: http://drupal.org/files/issues/_p_25termvocab.patch (1.28 KB) There was some small talk about this here and there during my folksonomy/free tagging patch, but I held off until now to actually implement it. Much like we handle free tagging vocabularies ("this is a free tagging vocabulary: view terms", which leads the admin into the taxonomy pager system), this patch does the same thing for NON-free tagging vocabularies, but ONLY if the vocabulary has more than 25 terms. These patches were made during the exploration and customization of Drupal by http://www.NHPR.org. In loving support of open source software, http://www.NHPR.org will continue to contribute patches they feel the community will benefit from. Questions about this patch should be directed to morbus@disobey.com. ------------------------------------------------------------------------ May 2, 2005 - 07:32 : Dries If would make sense if "free tags" were also shown if there are less than 25 terms, not? ------------------------------------------------------------------------ May 2, 2005 - 14:53 : Morbus Iff My concern with that is how to actually get the term count quickly for a vocabulary that has 8000 terms. On my installation (with 8000+ terms), it takes 360ms (per devel.module) for get_tree(). Following through with the same mentality code as suggested with this patch (using get_tree() to return an array of countable terms), we'd be wasting 360ms just to get a count of free tagging terms (more or less - I've been generally assuming that the very smallest free tagging vocab would be 100 terms, and the largest I've worked with being 8000). The only other countable equivalent would be a brand new SQL statement that'd just return the number of terms in a vocabulary (similar to term_count_nodes, only vocabulary_count_terms). I could certainly add this in, but for consistency / pattern sake, I'd want to use it IN PLACE of the get_tree side- effect/counting as demonstrated in this patch (so, count first, then get_tree when necessary). This would cause NUM_VOCABULARIES more queries than currently, but would certainly add up less than returning an entire tree of 8000 terms just to throw it away again. Thoughts? ------------------------------------------------------------------------ May 3, 2005 - 10:26 : Jaza Two suggestions: 1. Why >25? Anything special about the number 25? +1 For the idea of having 'view terms' for vocabularies with a large number of terms, but I don't see why 25 is necessarily where 'large' begins. This number should be a setting somewhere (not sure where, since taxonomy has no options page of its own). 25 can be the default option - it sounds reasonable to me (but maybe not to all webmasters). Perhaps make it so that if '0' is entered as the number, all terms are always displayed for that vocabulary (unless free tagging is enabled). 2. Taking this concept a bit further, it might be good to have an option: "enable free tagging for vocabularies when the number of terms reaches x". x could be the same variable as the one above, but I suggest that it be stored separately, for a more flexible configuration. As with suggestion 1, it may be hard finding a settings page on which this option belongs. Also, this might be taking it too far - could be one setting too many? In terms of performance, there should be no problem, since free tagging vocabularies do not need to have their terms counted - only others do. Number 2 could also be implemented on a per-vocabulary basis (number 1 also could, but that would be silly), but that would mean another column in the vocabulary table, especially for free tagging. And if that can be avoided, it should. Jaza ------------------------------------------------------------------------ May 3, 2005 - 10:39 : Morbus Iff 25 is an arbitrary number based on the assumption that they'll be at least two vocabularies in a site (one for the site itself, and one for the forums). A single page with a maximum of 48 items on it is quite large already, and that doesn't take into consideration other user-created vocabularies that could increase the size of the page (2 other vocabularies that have 10 items each, for instance, could create a 68-item sized page). I'm against a user-settable option just for the sake of a user-settable option. #2 is a whole 'nother feature request and should be its own separate Issue. I won't respond to it here. In short, however, I don't like it. ------------------------------------------------------------------------ May 4, 2005 - 05:20 : Bèr Kessels -1 on yet another option. We must decide what 'big' is. if someone really has objections about our idea of 'big' she should change that in the code. Another option is not an option, IMO. Morbus, what about using variable_get/set? If you detect the number only for very speecial cases, and find that there are more then 25, you do variable_set('taxonomy_is_large', array($vid => TRUE)), if its detected < 25 variable_set('taxonomy_is_large', array($vid => TRUE)) Where exactly you can set that, I do not know, but from that moment on you only need to check against that variable, on all the places where a tree would be rendered. ------------------------------------------------------------------------ May 18, 2005 - 14:20 : Morbus Iff Attachment: http://drupal.org/files/issues/_p_25termvocab_0.patch (1.32 KB) Does anyone else have comments on berkes' suggestion in #5? Dries? Perhaps the more adequate question is: is a "free tagging" vocabulary really useful if it has 25 terms or less? Isn't that more in the realm of a controlled vocabulary? If the user really is typing in the same 25 terms over and over again, that's gotta be an indication that they can save time with a dropdown, right? And if the free tagging vocabulary is just starting out, isn't there an assumption that it will eventually grow to be larger than 25 terms, In almost every use case? I guess my definition of a "free tagging" vocabulary ALSO includes the assumption that it'll grow to be $large, where $large is AT LEAST 100 terms. I've never seen any folksonomy smaller than that, save for those just starting out. is that a valid assumption? If it is, should it be treated as a "speshul" type of vocabulary, one which doesn't need a check on how many terms are actually in it, especially when said check become more prohibitive (in added code as well as processing time) as the vocabulary grows? (Attached an updated, but unchanged, patch to sync with HEAD). ------------------------------------------------------------------------ May 19, 2005 - 15:31 : Dries Personally, I'm not tempted to commit this patch. First, a 8.000 term vocabulary is not very realistic. It simply doesn't work. While this patch 'fixes' the administration page in such a scenario, it doesn't fix any of the other pages (like those having to render a selection menu with 8.000 terms). Morbus, is this _really_ needed? ------------------------------------------------------------------------ May 19, 2005 - 16:20 : Morbus Iff Note that the original intent of this patch was ONLY for NON-FREETAGGING vocabularies, and was intended SOLELY to stop multiple, large, NON-FREETAGGING vocabularies from making the vocabulary page abnormally long. An 8000 term NON-FREETAGGING vocabulary is quite unrealistic, yes - that wasn't the "baseline" for this patch. The baseline for this patch was two or more NON-FREETAGGING vocabularies that had more than 25 terms in it, of which I have three in the NHPR site. 75 terms on one page create a rather long vertical scroll that I didn't really want or like, especially when I had a fourth vocabulary that was alphabetized last, and thus, was four or five pages below the fold. So, again, the patch was catered for NON-FREETAGGING vocabularies. An 8000 term FREETAGGING vocabulary is quite possible actually (witness flickr, delicious and technorati - all community sites that use folksonomies and all have a rather wild number of terms, and my NHPR conversion has, now, 9000 terms). Whether you think 8000 terms in a FREETAGGING vocabulary is realistic or not, that's the reality in four sites, three of which created this whole "folksonomy" meme. But, again, this patch wasn't catered to that - the existing code in core ALREADY ASSUMES that folksonomies will grow large, and thus, doesn't attempt to show them without the "view terms" pagers. This patch was SOLELY created to prevent vertical disruption of the vocabulary page on the oft-chance that NON-FREETAGGING vocabularies grew larger than "normal".

Issue status update for http://drupal.org/node/20505 Post a follow up: http://drupal.org/project/comments/add/20505 Project: Drupal Version: cvs Component: taxonomy.module Category: feature requests Priority: normal Assigned to: Morbus Iff Reported by: Morbus Iff Updated by: RobRoy Status: patch Re: #7 I have a few sites with anywhere from 5000-15,000 term vocabs and have been hacking away to just get a look at the taxonomy admin. So I think this is a very necessary feature. +1 for the idea RobRoy Previous comments: ------------------------------------------------------------------------ April 14, 2005 - 16:31 : Morbus Iff Attachment: http://drupal.org/files/issues/_p_25termvocab.patch (1.28 KB) There was some small talk about this here and there during my folksonomy/free tagging patch, but I held off until now to actually implement it. Much like we handle free tagging vocabularies ("this is a free tagging vocabulary: view terms", which leads the admin into the taxonomy pager system), this patch does the same thing for NON-free tagging vocabularies, but ONLY if the vocabulary has more than 25 terms. These patches were made during the exploration and customization of Drupal by http://www.NHPR.org. In loving support of open source software, http://www.NHPR.org will continue to contribute patches they feel the community will benefit from. Questions about this patch should be directed to morbus@disobey.com. ------------------------------------------------------------------------ May 2, 2005 - 11:32 : Dries If would make sense if "free tags" were also shown if there are less than 25 terms, not? ------------------------------------------------------------------------ May 2, 2005 - 18:53 : Morbus Iff My concern with that is how to actually get the term count quickly for a vocabulary that has 8000 terms. On my installation (with 8000+ terms), it takes 360ms (per devel.module) for get_tree(). Following through with the same mentality code as suggested with this patch (using get_tree() to return an array of countable terms), we'd be wasting 360ms just to get a count of free tagging terms (more or less - I've been generally assuming that the very smallest free tagging vocab would be 100 terms, and the largest I've worked with being 8000). The only other countable equivalent would be a brand new SQL statement that'd just return the number of terms in a vocabulary (similar to term_count_nodes, only vocabulary_count_terms). I could certainly add this in, but for consistency / pattern sake, I'd want to use it IN PLACE of the get_tree side- effect/counting as demonstrated in this patch (so, count first, then get_tree when necessary). This would cause NUM_VOCABULARIES more queries than currently, but would certainly add up less than returning an entire tree of 8000 terms just to throw it away again. Thoughts? ------------------------------------------------------------------------ May 3, 2005 - 14:26 : Jaza Two suggestions: 1. Why >25? Anything special about the number 25? +1 For the idea of having 'view terms' for vocabularies with a large number of terms, but I don't see why 25 is necessarily where 'large' begins. This number should be a setting somewhere (not sure where, since taxonomy has no options page of its own). 25 can be the default option - it sounds reasonable to me (but maybe not to all webmasters). Perhaps make it so that if '0' is entered as the number, all terms are always displayed for that vocabulary (unless free tagging is enabled). 2. Taking this concept a bit further, it might be good to have an option: "enable free tagging for vocabularies when the number of terms reaches x". x could be the same variable as the one above, but I suggest that it be stored separately, for a more flexible configuration. As with suggestion 1, it may be hard finding a settings page on which this option belongs. Also, this might be taking it too far - could be one setting too many? In terms of performance, there should be no problem, since free tagging vocabularies do not need to have their terms counted - only others do. Number 2 could also be implemented on a per-vocabulary basis (number 1 also could, but that would be silly), but that would mean another column in the vocabulary table, especially for free tagging. And if that can be avoided, it should. Jaza ------------------------------------------------------------------------ May 3, 2005 - 14:39 : Morbus Iff 25 is an arbitrary number based on the assumption that they'll be at least two vocabularies in a site (one for the site itself, and one for the forums). A single page with a maximum of 48 items on it is quite large already, and that doesn't take into consideration other user-created vocabularies that could increase the size of the page (2 other vocabularies that have 10 items each, for instance, could create a 68-item sized page). I'm against a user-settable option just for the sake of a user-settable option. #2 is a whole 'nother feature request and should be its own separate Issue. I won't respond to it here. In short, however, I don't like it. ------------------------------------------------------------------------ May 4, 2005 - 09:20 : Bèr Kessels -1 on yet another option. We must decide what 'big' is. if someone really has objections about our idea of 'big' she should change that in the code. Another option is not an option, IMO. Morbus, what about using variable_get/set? If you detect the number only for very speecial cases, and find that there are more then 25, you do variable_set('taxonomy_is_large', array($vid => TRUE)), if its detected < 25 variable_set('taxonomy_is_large', array($vid => TRUE)) Where exactly you can set that, I do not know, but from that moment on you only need to check against that variable, on all the places where a tree would be rendered. ------------------------------------------------------------------------ May 18, 2005 - 18:20 : Morbus Iff Attachment: http://drupal.org/files/issues/_p_25termvocab_0.patch (1.32 KB) Does anyone else have comments on berkes' suggestion in #5? Dries? Perhaps the more adequate question is: is a "free tagging" vocabulary really useful if it has 25 terms or less? Isn't that more in the realm of a controlled vocabulary? If the user really is typing in the same 25 terms over and over again, that's gotta be an indication that they can save time with a dropdown, right? And if the free tagging vocabulary is just starting out, isn't there an assumption that it will eventually grow to be larger than 25 terms, In almost every use case? I guess my definition of a "free tagging" vocabulary ALSO includes the assumption that it'll grow to be $large, where $large is AT LEAST 100 terms. I've never seen any folksonomy smaller than that, save for those just starting out. is that a valid assumption? If it is, should it be treated as a "speshul" type of vocabulary, one which doesn't need a check on how many terms are actually in it, especially when said check become more prohibitive (in added code as well as processing time) as the vocabulary grows? (Attached an updated, but unchanged, patch to sync with HEAD). ------------------------------------------------------------------------ May 19, 2005 - 19:31 : Dries Personally, I'm not tempted to commit this patch. First, a 8.000 term vocabulary is not very realistic. It simply doesn't work. While this patch 'fixes' the administration page in such a scenario, it doesn't fix any of the other pages (like those having to render a selection menu with 8.000 terms). Morbus, is this _really_ needed? ------------------------------------------------------------------------ May 19, 2005 - 20:20 : Morbus Iff Note that the original intent of this patch was ONLY for NON-FREETAGGING vocabularies, and was intended SOLELY to stop multiple, large, NON-FREETAGGING vocabularies from making the vocabulary page abnormally long. An 8000 term NON-FREETAGGING vocabulary is quite unrealistic, yes - that wasn't the "baseline" for this patch. The baseline for this patch was two or more NON-FREETAGGING vocabularies that had more than 25 terms in it, of which I have three in the NHPR site. 75 terms on one page create a rather long vertical scroll that I didn't really want or like, especially when I had a fourth vocabulary that was alphabetized last, and thus, was four or five pages below the fold. So, again, the patch was catered for NON-FREETAGGING vocabularies. An 8000 term FREETAGGING vocabulary is quite possible actually (witness flickr, delicious and technorati - all community sites that use folksonomies and all have a rather wild number of terms, and my NHPR conversion has, now, 9000 terms). Whether you think 8000 terms in a FREETAGGING vocabulary is realistic or not, that's the reality in four sites, three of which created this whole "folksonomy" meme. But, again, this patch wasn't catered to that - the existing code in core ALREADY ASSUMES that folksonomies will grow large, and thus, doesn't attempt to show them without the "view terms" pagers. This patch was SOLELY created to prevent vertical disruption of the vocabulary page on the oft-chance that NON-FREETAGGING vocabularies grew larger than "normal". ------------------------------------------------------------------------ May 19, 2005 - 21:34 : nedjo This general question would be, how do we differentially display object references (nodes, terms, users) depending on the number available? As things stand, we don't do this, but we do take different approaches based on object type. Consider two examples from form elements. (a) Users. When we want the user to designate a user, we present a text box (rather than a select), assuming there will be too many users to present in a select. (b) Terms. We present a select, assuming there will be few enough terms. But neither of these assumptions holds for all sites. I've got several sites with few enough users to fit handily in a select, whereas we've heard there are plenty of sites with too many terms for a select. +1 for the general answer of thresholds and differential display. The proposed patch is a good start. I'd prefer to have the threshold number pulled out into (yes) a configuration option, ideally a general one that is for all object types. This would enable future work on lists of other types. ------------------------------------------------------------------------ May 19, 2005 - 23:02 : Chris Johnson I think nedjo states the problem clearly. I've got a site where when it is fully implement, it could have thousands of terms. Imagine dividing the U.S. by state, then county, then location (city) name. By state by location gives as many as 12,084 locations in the state of Pennsylvania, for example. Dividing the same data into counties, I still have 9 counties with more than 500 locations (terms). I'm sure others have similar large datasets they wish to make use of in their Drupal-based web sites.

Issue status update for http://drupal.org/node/20505 Post a follow up: http://drupal.org/project/comments/add/20505 Project: Drupal Version: cvs Component: taxonomy.module Category: feature requests Priority: normal Assigned to: Morbus Iff Reported by: Morbus Iff Updated by: Dries Status: patch Hey Rob, can you provide a patch so we can compare both? If possible provide a screenshot comparing the approaches. That would really help digest this patch. Thanks. Dries Previous comments: ------------------------------------------------------------------------ 1113496278 : Morbus Iff Attachment: http://drupal.org/files/issues/_p_25termvocab.patch (1.28 KB) There was some small talk about this here and there during my folksonomy/free tagging patch, but I held off until now to actually implement it. Much like we handle free tagging vocabularies ("this is a free tagging vocabulary: view terms", which leads the admin into the taxonomy pager system), this patch does the same thing for NON-free tagging vocabularies, but ONLY if the vocabulary has more than 25 terms. These patches were made during the exploration and customization of Drupal by http://www.NHPR.org. In loving support of open source software, http://www.NHPR.org will continue to contribute patches they feel the community will benefit from. Questions about this patch should be directed to morbus@disobey.com. ------------------------------------------------------------------------ 1115033577 : Dries If would make sense if "free tags" were also shown if there are less than 25 terms, not? ------------------------------------------------------------------------ 1115060039 : Morbus Iff My concern with that is how to actually get the term count quickly for a vocabulary that has 8000 terms. On my installation (with 8000+ terms), it takes 360ms (per devel.module) for get_tree(). Following through with the same mentality code as suggested with this patch (using get_tree() to return an array of countable terms), we'd be wasting 360ms just to get a count of free tagging terms (more or less - I've been generally assuming that the very smallest free tagging vocab would be 100 terms, and the largest I've worked with being 8000). The only other countable equivalent would be a brand new SQL statement that'd just return the number of terms in a vocabulary (similar to term_count_nodes, only vocabulary_count_terms). I could certainly add this in, but for consistency / pattern sake, I'd want to use it IN PLACE of the get_tree side- effect/counting as demonstrated in this patch (so, count first, then get_tree when necessary). This would cause NUM_VOCABULARIES more queries than currently, but would certainly add up less than returning an entire tree of 8000 terms just to throw it away again. Thoughts? ------------------------------------------------------------------------ 1115130397 : Jaza Two suggestions: 1. Why >25? Anything special about the number 25? +1 For the idea of having 'view terms' for vocabularies with a large number of terms, but I don't see why 25 is necessarily where 'large' begins. This number should be a setting somewhere (not sure where, since taxonomy has no options page of its own). 25 can be the default option - it sounds reasonable to me (but maybe not to all webmasters). Perhaps make it so that if '0' is entered as the number, all terms are always displayed for that vocabulary (unless free tagging is enabled). 2. Taking this concept a bit further, it might be good to have an option: "enable free tagging for vocabularies when the number of terms reaches x". x could be the same variable as the one above, but I suggest that it be stored separately, for a more flexible configuration. As with suggestion 1, it may be hard finding a settings page on which this option belongs. Also, this might be taking it too far - could be one setting too many? In terms of performance, there should be no problem, since free tagging vocabularies do not need to have their terms counted - only others do. Number 2 could also be implemented on a per-vocabulary basis (number 1 also could, but that would be silly), but that would mean another column in the vocabulary table, especially for free tagging. And if that can be avoided, it should. Jaza ------------------------------------------------------------------------ 1115131185 : Morbus Iff 25 is an arbitrary number based on the assumption that they'll be at least two vocabularies in a site (one for the site itself, and one for the forums). A single page with a maximum of 48 items on it is quite large already, and that doesn't take into consideration other user-created vocabularies that could increase the size of the page (2 other vocabularies that have 10 items each, for instance, could create a 68-item sized page). I'm against a user-settable option just for the sake of a user-settable option. #2 is a whole 'nother feature request and should be its own separate Issue. I won't respond to it here. In short, however, I don't like it. ------------------------------------------------------------------------ 1115198454 : Bèr Kessels -1 on yet another option. We must decide what 'big' is. if someone really has objections about our idea of 'big' she should change that in the code. Another option is not an option, IMO. Morbus, what about using variable_get/set? If you detect the number only for very speecial cases, and find that there are more then 25, you do variable_set('taxonomy_is_large', array($vid => TRUE)), if its detected < 25 variable_set('taxonomy_is_large', array($vid => TRUE)) Where exactly you can set that, I do not know, but from that moment on you only need to check against that variable, on all the places where a tree would be rendered. ------------------------------------------------------------------------ 1116440425 : Morbus Iff Attachment: http://drupal.org/files/issues/_p_25termvocab_0.patch (1.32 KB) Does anyone else have comments on berkes' suggestion in #5? Dries? Perhaps the more adequate question is: is a "free tagging" vocabulary really useful if it has 25 terms or less? Isn't that more in the realm of a controlled vocabulary? If the user really is typing in the same 25 terms over and over again, that's gotta be an indication that they can save time with a dropdown, right? And if the free tagging vocabulary is just starting out, isn't there an assumption that it will eventually grow to be larger than 25 terms, In almost every use case? I guess my definition of a "free tagging" vocabulary ALSO includes the assumption that it'll grow to be $large, where $large is AT LEAST 100 terms. I've never seen any folksonomy smaller than that, save for those just starting out. is that a valid assumption? If it is, should it be treated as a "speshul" type of vocabulary, one which doesn't need a check on how many terms are actually in it, especially when said check become more prohibitive (in added code as well as processing time) as the vocabulary grows? (Attached an updated, but unchanged, patch to sync with HEAD). ------------------------------------------------------------------------ 1116531109 : Dries Personally, I'm not tempted to commit this patch. First, a 8.000 term vocabulary is not very realistic. It simply doesn't work. While this patch 'fixes' the administration page in such a scenario, it doesn't fix any of the other pages (like those having to render a selection menu with 8.000 terms). Morbus, is this _really_ needed? ------------------------------------------------------------------------ 1116534033 : Morbus Iff Note that the original intent of this patch was ONLY for NON-FREETAGGING vocabularies, and was intended SOLELY to stop multiple, large, NON-FREETAGGING vocabularies from making the vocabulary page abnormally long. An 8000 term NON-FREETAGGING vocabulary is quite unrealistic, yes - that wasn't the "baseline" for this patch. The baseline for this patch was two or more NON-FREETAGGING vocabularies that had more than 25 terms in it, of which I have three in the NHPR site. 75 terms on one page create a rather long vertical scroll that I didn't really want or like, especially when I had a fourth vocabulary that was alphabetized last, and thus, was four or five pages below the fold. So, again, the patch was catered for NON-FREETAGGING vocabularies. An 8000 term FREETAGGING vocabulary is quite possible actually (witness flickr, delicious and technorati - all community sites that use folksonomies and all have a rather wild number of terms, and my NHPR conversion has, now, 9000 terms). Whether you think 8000 terms in a FREETAGGING vocabulary is realistic or not, that's the reality in four sites, three of which created this whole "folksonomy" meme. But, again, this patch wasn't catered to that - the existing code in core ALREADY ASSUMES that folksonomies will grow large, and thus, doesn't attempt to show them without the "view terms" pagers. This patch was SOLELY created to prevent vertical disruption of the vocabulary page on the oft-chance that NON-FREETAGGING vocabularies grew larger than "normal". ------------------------------------------------------------------------ 1116538446 : nedjo This general question would be, how do we differentially display object references (nodes, terms, users) depending on the number available? As things stand, we don't do this, but we do take different approaches based on object type. Consider two examples from form elements. (a) Users. When we want the user to designate a user, we present a text box (rather than a select), assuming there will be too many users to present in a select. (b) Terms. We present a select, assuming there will be few enough terms. But neither of these assumptions holds for all sites. I've got several sites with few enough users to fit handily in a select, whereas we've heard there are plenty of sites with too many terms for a select. +1 for the general answer of thresholds and differential display. The proposed patch is a good start. I'd prefer to have the threshold number pulled out into (yes) a configuration option, ideally a general one that is for all object types. This would enable future work on lists of other types. ------------------------------------------------------------------------ 1116543721 : Chris Johnson I think nedjo states the problem clearly. I've got a site where when it is fully implement, it could have thousands of terms. Imagine dividing the U.S. by state, then county, then location (city) name. By state by location gives as many as 12,084 locations in the state of Pennsylvania, for example. Dividing the same data into counties, I still have 9 counties with more than 500 locations (terms). I'm sure others have similar large datasets they wish to make use of in their Drupal-based web sites. ------------------------------------------------------------------------ 1121382293 : RobRoy Re: #7 I have a few sites with anywhere from 5000-15,000 term vocabs and have been hacking away to just get a look at the taxonomy admin. So I think this is a very necessary feature. +1 for the idea ------------------------------------------------------------------------ 1121382809 : RobRoy Sorry, for the dual comments. But I propose that only vocabs are shown on the admin page and one must click view terms to see the terms (which would have a pager like in cvs). Then all the screens are nice and short. I'm doing this right now and it works great. This way it is consistent and there aren't some vocabs with terms showing and some without, although it does add another click. So it's great for sites with lots of vocabs and tons of terms.

Issue status update for http://drupal.org/node/20505 Post a follow up: http://drupal.org/project/comments/add/20505 Project: Drupal Version: cvs Component: taxonomy.module Category: feature requests Priority: normal Assigned to: Morbus Iff Reported by: Morbus Iff Updated by: RobRoy Status: patch Attachment: http://drupal.org/files/issues/taxonomy_pager.patch (4.76 KB) Here we go. This also includes the one main fix and 3 minor fixes. Let me know how it works. I did the patch off 4.6.2 since that is what I was working off of. Let me know if you want me to do it on the cvs version as I'm not sure what the preferred method is. * The view terms patch described above * In the cvs patch, $start_from > $total_entries should have been $start_from >= $total_entries. It was messing the pager up a bit. * Removed a redundant array initialization * Added a missing sorting fix, to sort by weight, then name. RobRoy Previous comments: ------------------------------------------------------------------------ Thu, 14 Apr 2005 16:31:18 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues/_p_25termvocab.patch (1.28 KB) There was some small talk about this here and there during my folksonomy/free tagging patch, but I held off until now to actually implement it. Much like we handle free tagging vocabularies ("this is a free tagging vocabulary: view terms", which leads the admin into the taxonomy pager system), this patch does the same thing for NON-free tagging vocabularies, but ONLY if the vocabulary has more than 25 terms. These patches were made during the exploration and customization of Drupal by http://www.NHPR.org. In loving support of open source software, http://www.NHPR.org will continue to contribute patches they feel the community will benefit from. Questions about this patch should be directed to morbus@disobey.com. ------------------------------------------------------------------------ Mon, 02 May 2005 11:32:57 +0000 : Dries If would make sense if "free tags" were also shown if there are less than 25 terms, not? ------------------------------------------------------------------------ Mon, 02 May 2005 18:53:59 +0000 : Morbus Iff My concern with that is how to actually get the term count quickly for a vocabulary that has 8000 terms. On my installation (with 8000+ terms), it takes 360ms (per devel.module) for get_tree(). Following through with the same mentality code as suggested with this patch (using get_tree() to return an array of countable terms), we'd be wasting 360ms just to get a count of free tagging terms (more or less - I've been generally assuming that the very smallest free tagging vocab would be 100 terms, and the largest I've worked with being 8000). The only other countable equivalent would be a brand new SQL statement that'd just return the number of terms in a vocabulary (similar to term_count_nodes, only vocabulary_count_terms). I could certainly add this in, but for consistency / pattern sake, I'd want to use it IN PLACE of the get_tree side- effect/counting as demonstrated in this patch (so, count first, then get_tree when necessary). This would cause NUM_VOCABULARIES more queries than currently, but would certainly add up less than returning an entire tree of 8000 terms just to throw it away again. Thoughts? ------------------------------------------------------------------------ Tue, 03 May 2005 14:26:37 +0000 : Jaza Two suggestions: 1. Why >25? Anything special about the number 25? +1 For the idea of having 'view terms' for vocabularies with a large number of terms, but I don't see why 25 is necessarily where 'large' begins. This number should be a setting somewhere (not sure where, since taxonomy has no options page of its own). 25 can be the default option - it sounds reasonable to me (but maybe not to all webmasters). Perhaps make it so that if '0' is entered as the number, all terms are always displayed for that vocabulary (unless free tagging is enabled). 2. Taking this concept a bit further, it might be good to have an option: "enable free tagging for vocabularies when the number of terms reaches x". x could be the same variable as the one above, but I suggest that it be stored separately, for a more flexible configuration. As with suggestion 1, it may be hard finding a settings page on which this option belongs. Also, this might be taking it too far - could be one setting too many? In terms of performance, there should be no problem, since free tagging vocabularies do not need to have their terms counted - only others do. Number 2 could also be implemented on a per-vocabulary basis (number 1 also could, but that would be silly), but that would mean another column in the vocabulary table, especially for free tagging. And if that can be avoided, it should. Jaza ------------------------------------------------------------------------ Tue, 03 May 2005 14:39:45 +0000 : Morbus Iff 25 is an arbitrary number based on the assumption that they'll be at least two vocabularies in a site (one for the site itself, and one for the forums). A single page with a maximum of 48 items on it is quite large already, and that doesn't take into consideration other user-created vocabularies that could increase the size of the page (2 other vocabularies that have 10 items each, for instance, could create a 68-item sized page). I'm against a user-settable option just for the sake of a user-settable option. #2 is a whole 'nother feature request and should be its own separate Issue. I won't respond to it here. In short, however, I don't like it. ------------------------------------------------------------------------ Wed, 04 May 2005 09:20:54 +0000 : Bèr Kessels -1 on yet another option. We must decide what 'big' is. if someone really has objections about our idea of 'big' she should change that in the code. Another option is not an option, IMO. Morbus, what about using variable_get/set? If you detect the number only for very speecial cases, and find that there are more then 25, you do variable_set('taxonomy_is_large', array($vid => TRUE)), if its detected < 25 variable_set('taxonomy_is_large', array($vid => TRUE)) Where exactly you can set that, I do not know, but from that moment on you only need to check against that variable, on all the places where a tree would be rendered. ------------------------------------------------------------------------ Wed, 18 May 2005 18:20:25 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues/_p_25termvocab_0.patch (1.32 KB) Does anyone else have comments on berkes' suggestion in #5? Dries? Perhaps the more adequate question is: is a "free tagging" vocabulary really useful if it has 25 terms or less? Isn't that more in the realm of a controlled vocabulary? If the user really is typing in the same 25 terms over and over again, that's gotta be an indication that they can save time with a dropdown, right? And if the free tagging vocabulary is just starting out, isn't there an assumption that it will eventually grow to be larger than 25 terms, In almost every use case? I guess my definition of a "free tagging" vocabulary ALSO includes the assumption that it'll grow to be $large, where $large is AT LEAST 100 terms. I've never seen any folksonomy smaller than that, save for those just starting out. is that a valid assumption? If it is, should it be treated as a "speshul" type of vocabulary, one which doesn't need a check on how many terms are actually in it, especially when said check become more prohibitive (in added code as well as processing time) as the vocabulary grows? (Attached an updated, but unchanged, patch to sync with HEAD). ------------------------------------------------------------------------ Thu, 19 May 2005 19:31:49 +0000 : Dries Personally, I'm not tempted to commit this patch. First, a 8.000 term vocabulary is not very realistic. It simply doesn't work. While this patch 'fixes' the administration page in such a scenario, it doesn't fix any of the other pages (like those having to render a selection menu with 8.000 terms). Morbus, is this _really_ needed? ------------------------------------------------------------------------ Thu, 19 May 2005 20:20:33 +0000 : Morbus Iff Note that the original intent of this patch was ONLY for NON-FREETAGGING vocabularies, and was intended SOLELY to stop multiple, large, NON-FREETAGGING vocabularies from making the vocabulary page abnormally long. An 8000 term NON-FREETAGGING vocabulary is quite unrealistic, yes - that wasn't the "baseline" for this patch. The baseline for this patch was two or more NON-FREETAGGING vocabularies that had more than 25 terms in it, of which I have three in the NHPR site. 75 terms on one page create a rather long vertical scroll that I didn't really want or like, especially when I had a fourth vocabulary that was alphabetized last, and thus, was four or five pages below the fold. So, again, the patch was catered for NON-FREETAGGING vocabularies. An 8000 term FREETAGGING vocabulary is quite possible actually (witness flickr, delicious and technorati - all community sites that use folksonomies and all have a rather wild number of terms, and my NHPR conversion has, now, 9000 terms). Whether you think 8000 terms in a FREETAGGING vocabulary is realistic or not, that's the reality in four sites, three of which created this whole "folksonomy" meme. But, again, this patch wasn't catered to that - the existing code in core ALREADY ASSUMES that folksonomies will grow large, and thus, doesn't attempt to show them without the "view terms" pagers. This patch was SOLELY created to prevent vertical disruption of the vocabulary page on the oft-chance that NON-FREETAGGING vocabularies grew larger than "normal". ------------------------------------------------------------------------ Thu, 19 May 2005 21:34:06 +0000 : nedjo This general question would be, how do we differentially display object references (nodes, terms, users) depending on the number available? As things stand, we don't do this, but we do take different approaches based on object type. Consider two examples from form elements. (a) Users. When we want the user to designate a user, we present a text box (rather than a select), assuming there will be too many users to present in a select. (b) Terms. We present a select, assuming there will be few enough terms. But neither of these assumptions holds for all sites. I've got several sites with few enough users to fit handily in a select, whereas we've heard there are plenty of sites with too many terms for a select. +1 for the general answer of thresholds and differential display. The proposed patch is a good start. I'd prefer to have the threshold number pulled out into (yes) a configuration option, ideally a general one that is for all object types. This would enable future work on lists of other types. ------------------------------------------------------------------------ Thu, 19 May 2005 23:02:01 +0000 : Chris Johnson I think nedjo states the problem clearly. I've got a site where when it is fully implement, it could have thousands of terms. Imagine dividing the U.S. by state, then county, then location (city) name. By state by location gives as many as 12,084 locations in the state of Pennsylvania, for example. Dividing the same data into counties, I still have 9 counties with more than 500 locations (terms). I'm sure others have similar large datasets they wish to make use of in their Drupal-based web sites. ------------------------------------------------------------------------ Thu, 14 Jul 2005 23:04:53 +0000 : RobRoy Re: #7 I have a few sites with anywhere from 5000-15,000 term vocabs and have been hacking away to just get a look at the taxonomy admin. So I think this is a very necessary feature. +1 for the idea ------------------------------------------------------------------------ Thu, 14 Jul 2005 23:13:29 +0000 : RobRoy Sorry, for the dual comments. But I propose that only vocabs are shown on the admin page and one must click view terms to see the terms (which would have a pager like in cvs). Then all the screens are nice and short. I'm doing this right now and it works great. This way it is consistent and there aren't some vocabs with terms showing and some without, although it does add another click. So it's great for sites with lots of vocabs and tons of terms. ------------------------------------------------------------------------ Mon, 18 Jul 2005 14:11:52 +0000 : Dries Hey Rob, can you provide a patch so we can compare both? If possible provide a screenshot comparing the approaches. That would really help digest this patch. Thanks. ------------------------------------------------------------------------ Mon, 18 Jul 2005 14:24:52 +0000 : Dries Talked to Morbus and I think Rob's approach makes sense. If well-executed, it allows us to community the difference between vocubularies and terms a little better. The current taxonomy adminstration page is anything but easy, so hopefully, it only gets better. Rob? :)

Issue status update for http://drupal.org/node/20505 Post a follow up: http://drupal.org/project/comments/add/20505 Project: Drupal Version: cvs Component: taxonomy.module Category: feature requests Priority: normal Assigned to: Morbus Iff Reported by: Morbus Iff Updated by: Dries Status: patch Patch against CVS applies but doesn't work. My forum terms are not shown at all -- maybe because they are hierarchical. Dries Previous comments: ------------------------------------------------------------------------ Thu, 14 Apr 2005 16:31:18 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues/_p_25termvocab.patch (1.28 KB) There was some small talk about this here and there during my folksonomy/free tagging patch, but I held off until now to actually implement it. Much like we handle free tagging vocabularies ("this is a free tagging vocabulary: view terms", which leads the admin into the taxonomy pager system), this patch does the same thing for NON-free tagging vocabularies, but ONLY if the vocabulary has more than 25 terms. These patches were made during the exploration and customization of Drupal by http://www.NHPR.org. In loving support of open source software, http://www.NHPR.org will continue to contribute patches they feel the community will benefit from. Questions about this patch should be directed to morbus@disobey.com. ------------------------------------------------------------------------ Mon, 02 May 2005 11:32:57 +0000 : Dries If would make sense if "free tags" were also shown if there are less than 25 terms, not? ------------------------------------------------------------------------ Mon, 02 May 2005 18:53:59 +0000 : Morbus Iff My concern with that is how to actually get the term count quickly for a vocabulary that has 8000 terms. On my installation (with 8000+ terms), it takes 360ms (per devel.module) for get_tree(). Following through with the same mentality code as suggested with this patch (using get_tree() to return an array of countable terms), we'd be wasting 360ms just to get a count of free tagging terms (more or less - I've been generally assuming that the very smallest free tagging vocab would be 100 terms, and the largest I've worked with being 8000). The only other countable equivalent would be a brand new SQL statement that'd just return the number of terms in a vocabulary (similar to term_count_nodes, only vocabulary_count_terms). I could certainly add this in, but for consistency / pattern sake, I'd want to use it IN PLACE of the get_tree side- effect/counting as demonstrated in this patch (so, count first, then get_tree when necessary). This would cause NUM_VOCABULARIES more queries than currently, but would certainly add up less than returning an entire tree of 8000 terms just to throw it away again. Thoughts? ------------------------------------------------------------------------ Tue, 03 May 2005 14:26:37 +0000 : Jaza Two suggestions: 1. Why >25? Anything special about the number 25? +1 For the idea of having 'view terms' for vocabularies with a large number of terms, but I don't see why 25 is necessarily where 'large' begins. This number should be a setting somewhere (not sure where, since taxonomy has no options page of its own). 25 can be the default option - it sounds reasonable to me (but maybe not to all webmasters). Perhaps make it so that if '0' is entered as the number, all terms are always displayed for that vocabulary (unless free tagging is enabled). 2. Taking this concept a bit further, it might be good to have an option: "enable free tagging for vocabularies when the number of terms reaches x". x could be the same variable as the one above, but I suggest that it be stored separately, for a more flexible configuration. As with suggestion 1, it may be hard finding a settings page on which this option belongs. Also, this might be taking it too far - could be one setting too many? In terms of performance, there should be no problem, since free tagging vocabularies do not need to have their terms counted - only others do. Number 2 could also be implemented on a per-vocabulary basis (number 1 also could, but that would be silly), but that would mean another column in the vocabulary table, especially for free tagging. And if that can be avoided, it should. Jaza ------------------------------------------------------------------------ Tue, 03 May 2005 14:39:45 +0000 : Morbus Iff 25 is an arbitrary number based on the assumption that they'll be at least two vocabularies in a site (one for the site itself, and one for the forums). A single page with a maximum of 48 items on it is quite large already, and that doesn't take into consideration other user-created vocabularies that could increase the size of the page (2 other vocabularies that have 10 items each, for instance, could create a 68-item sized page). I'm against a user-settable option just for the sake of a user-settable option. #2 is a whole 'nother feature request and should be its own separate Issue. I won't respond to it here. In short, however, I don't like it. ------------------------------------------------------------------------ Wed, 04 May 2005 09:20:54 +0000 : Bèr Kessels -1 on yet another option. We must decide what 'big' is. if someone really has objections about our idea of 'big' she should change that in the code. Another option is not an option, IMO. Morbus, what about using variable_get/set? If you detect the number only for very speecial cases, and find that there are more then 25, you do variable_set('taxonomy_is_large', array($vid => TRUE)), if its detected < 25 variable_set('taxonomy_is_large', array($vid => TRUE)) Where exactly you can set that, I do not know, but from that moment on you only need to check against that variable, on all the places where a tree would be rendered. ------------------------------------------------------------------------ Wed, 18 May 2005 18:20:25 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues/_p_25termvocab_0.patch (1.32 KB) Does anyone else have comments on berkes' suggestion in #5? Dries? Perhaps the more adequate question is: is a "free tagging" vocabulary really useful if it has 25 terms or less? Isn't that more in the realm of a controlled vocabulary? If the user really is typing in the same 25 terms over and over again, that's gotta be an indication that they can save time with a dropdown, right? And if the free tagging vocabulary is just starting out, isn't there an assumption that it will eventually grow to be larger than 25 terms, In almost every use case? I guess my definition of a "free tagging" vocabulary ALSO includes the assumption that it'll grow to be $large, where $large is AT LEAST 100 terms. I've never seen any folksonomy smaller than that, save for those just starting out. is that a valid assumption? If it is, should it be treated as a "speshul" type of vocabulary, one which doesn't need a check on how many terms are actually in it, especially when said check become more prohibitive (in added code as well as processing time) as the vocabulary grows? (Attached an updated, but unchanged, patch to sync with HEAD). ------------------------------------------------------------------------ Thu, 19 May 2005 19:31:49 +0000 : Dries Personally, I'm not tempted to commit this patch. First, a 8.000 term vocabulary is not very realistic. It simply doesn't work. While this patch 'fixes' the administration page in such a scenario, it doesn't fix any of the other pages (like those having to render a selection menu with 8.000 terms). Morbus, is this _really_ needed? ------------------------------------------------------------------------ Thu, 19 May 2005 20:20:33 +0000 : Morbus Iff Note that the original intent of this patch was ONLY for NON-FREETAGGING vocabularies, and was intended SOLELY to stop multiple, large, NON-FREETAGGING vocabularies from making the vocabulary page abnormally long. An 8000 term NON-FREETAGGING vocabulary is quite unrealistic, yes - that wasn't the "baseline" for this patch. The baseline for this patch was two or more NON-FREETAGGING vocabularies that had more than 25 terms in it, of which I have three in the NHPR site. 75 terms on one page create a rather long vertical scroll that I didn't really want or like, especially when I had a fourth vocabulary that was alphabetized last, and thus, was four or five pages below the fold. So, again, the patch was catered for NON-FREETAGGING vocabularies. An 8000 term FREETAGGING vocabulary is quite possible actually (witness flickr, delicious and technorati - all community sites that use folksonomies and all have a rather wild number of terms, and my NHPR conversion has, now, 9000 terms). Whether you think 8000 terms in a FREETAGGING vocabulary is realistic or not, that's the reality in four sites, three of which created this whole "folksonomy" meme. But, again, this patch wasn't catered to that - the existing code in core ALREADY ASSUMES that folksonomies will grow large, and thus, doesn't attempt to show them without the "view terms" pagers. This patch was SOLELY created to prevent vertical disruption of the vocabulary page on the oft-chance that NON-FREETAGGING vocabularies grew larger than "normal". ------------------------------------------------------------------------ Thu, 19 May 2005 21:34:06 +0000 : nedjo This general question would be, how do we differentially display object references (nodes, terms, users) depending on the number available? As things stand, we don't do this, but we do take different approaches based on object type. Consider two examples from form elements. (a) Users. When we want the user to designate a user, we present a text box (rather than a select), assuming there will be too many users to present in a select. (b) Terms. We present a select, assuming there will be few enough terms. But neither of these assumptions holds for all sites. I've got several sites with few enough users to fit handily in a select, whereas we've heard there are plenty of sites with too many terms for a select. +1 for the general answer of thresholds and differential display. The proposed patch is a good start. I'd prefer to have the threshold number pulled out into (yes) a configuration option, ideally a general one that is for all object types. This would enable future work on lists of other types. ------------------------------------------------------------------------ Thu, 19 May 2005 23:02:01 +0000 : Chris Johnson I think nedjo states the problem clearly. I've got a site where when it is fully implement, it could have thousands of terms. Imagine dividing the U.S. by state, then county, then location (city) name. By state by location gives as many as 12,084 locations in the state of Pennsylvania, for example. Dividing the same data into counties, I still have 9 counties with more than 500 locations (terms). I'm sure others have similar large datasets they wish to make use of in their Drupal-based web sites. ------------------------------------------------------------------------ Thu, 14 Jul 2005 23:04:53 +0000 : RobRoy Re: #7 I have a few sites with anywhere from 5000-15,000 term vocabs and have been hacking away to just get a look at the taxonomy admin. So I think this is a very necessary feature. +1 for the idea ------------------------------------------------------------------------ Thu, 14 Jul 2005 23:13:29 +0000 : RobRoy Sorry, for the dual comments. But I propose that only vocabs are shown on the admin page and one must click view terms to see the terms (which would have a pager like in cvs). Then all the screens are nice and short. I'm doing this right now and it works great. This way it is consistent and there aren't some vocabs with terms showing and some without, although it does add another click. So it's great for sites with lots of vocabs and tons of terms. ------------------------------------------------------------------------ Mon, 18 Jul 2005 14:11:52 +0000 : Dries Hey Rob, can you provide a patch so we can compare both? If possible provide a screenshot comparing the approaches. That would really help digest this patch. Thanks. ------------------------------------------------------------------------ Mon, 18 Jul 2005 14:24:52 +0000 : Dries Talked to Morbus and I think Rob's approach makes sense. If well-executed, it allows us to community the difference between vocubularies and terms a little better. The current taxonomy adminstration page is anything but easy, so hopefully, it only gets better. Rob? :) ------------------------------------------------------------------------ Mon, 18 Jul 2005 18:24:05 +0000 : RobRoy Attachment: http://drupal.org/files/issues/taxonomy_pager.patch (4.76 KB) Here we go. This also includes the one main fix and 3 minor fixes. Let me know how it works. I did the patch off 4.6.2 since that is what I was working off of. Let me know if you want me to do it on the cvs version as I'm not sure what the preferred method is. * The view terms patch described above * In the cvs patch, $start_from > $total_entries should have been $start_from >= $total_entries. It was messing the pager up a bit. * Removed a redundant array initialization * Added a missing sorting fix, to sort by weight, then name. ------------------------------------------------------------------------ Mon, 18 Jul 2005 19:01:37 +0000 : RobRoy Attachment: http://drupal.org/files/issues/taxonomy_pager_cvs.patch (4.62 KB) Okay, well I figured a patch on cvs is probably better, so here it is. But the cvs ver of taxonomy.module depends on some other updates so I was kinda flying blind implementing this. It should work.

Issue status update for http://drupal.org/node/20505 Post a follow up: http://drupal.org/project/comments/add/20505 Project: Drupal Version: cvs Component: taxonomy.module Category: feature requests Priority: normal Assigned to: Morbus Iff Reported by: Morbus Iff Updated by: Morbus Iff Status: patch Dries - does your first term have a large number of children - more than 25? Morbus Iff Previous comments: ------------------------------------------------------------------------ Thu, 14 Apr 2005 16:31:18 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues/_p_25termvocab.patch (1.28 KB) There was some small talk about this here and there during my folksonomy/free tagging patch, but I held off until now to actually implement it. Much like we handle free tagging vocabularies ("this is a free tagging vocabulary: view terms", which leads the admin into the taxonomy pager system), this patch does the same thing for NON-free tagging vocabularies, but ONLY if the vocabulary has more than 25 terms. These patches were made during the exploration and customization of Drupal by http://www.NHPR.org. In loving support of open source software, http://www.NHPR.org will continue to contribute patches they feel the community will benefit from. Questions about this patch should be directed to morbus@disobey.com. ------------------------------------------------------------------------ Mon, 02 May 2005 11:32:57 +0000 : Dries If would make sense if "free tags" were also shown if there are less than 25 terms, not? ------------------------------------------------------------------------ Mon, 02 May 2005 18:53:59 +0000 : Morbus Iff My concern with that is how to actually get the term count quickly for a vocabulary that has 8000 terms. On my installation (with 8000+ terms), it takes 360ms (per devel.module) for get_tree(). Following through with the same mentality code as suggested with this patch (using get_tree() to return an array of countable terms), we'd be wasting 360ms just to get a count of free tagging terms (more or less - I've been generally assuming that the very smallest free tagging vocab would be 100 terms, and the largest I've worked with being 8000). The only other countable equivalent would be a brand new SQL statement that'd just return the number of terms in a vocabulary (similar to term_count_nodes, only vocabulary_count_terms). I could certainly add this in, but for consistency / pattern sake, I'd want to use it IN PLACE of the get_tree side- effect/counting as demonstrated in this patch (so, count first, then get_tree when necessary). This would cause NUM_VOCABULARIES more queries than currently, but would certainly add up less than returning an entire tree of 8000 terms just to throw it away again. Thoughts? ------------------------------------------------------------------------ Tue, 03 May 2005 14:26:37 +0000 : Jaza Two suggestions: 1. Why >25? Anything special about the number 25? +1 For the idea of having 'view terms' for vocabularies with a large number of terms, but I don't see why 25 is necessarily where 'large' begins. This number should be a setting somewhere (not sure where, since taxonomy has no options page of its own). 25 can be the default option - it sounds reasonable to me (but maybe not to all webmasters). Perhaps make it so that if '0' is entered as the number, all terms are always displayed for that vocabulary (unless free tagging is enabled). 2. Taking this concept a bit further, it might be good to have an option: "enable free tagging for vocabularies when the number of terms reaches x". x could be the same variable as the one above, but I suggest that it be stored separately, for a more flexible configuration. As with suggestion 1, it may be hard finding a settings page on which this option belongs. Also, this might be taking it too far - could be one setting too many? In terms of performance, there should be no problem, since free tagging vocabularies do not need to have their terms counted - only others do. Number 2 could also be implemented on a per-vocabulary basis (number 1 also could, but that would be silly), but that would mean another column in the vocabulary table, especially for free tagging. And if that can be avoided, it should. Jaza ------------------------------------------------------------------------ Tue, 03 May 2005 14:39:45 +0000 : Morbus Iff 25 is an arbitrary number based on the assumption that they'll be at least two vocabularies in a site (one for the site itself, and one for the forums). A single page with a maximum of 48 items on it is quite large already, and that doesn't take into consideration other user-created vocabularies that could increase the size of the page (2 other vocabularies that have 10 items each, for instance, could create a 68-item sized page). I'm against a user-settable option just for the sake of a user-settable option. #2 is a whole 'nother feature request and should be its own separate Issue. I won't respond to it here. In short, however, I don't like it. ------------------------------------------------------------------------ Wed, 04 May 2005 09:20:54 +0000 : Bèr Kessels -1 on yet another option. We must decide what 'big' is. if someone really has objections about our idea of 'big' she should change that in the code. Another option is not an option, IMO. Morbus, what about using variable_get/set? If you detect the number only for very speecial cases, and find that there are more then 25, you do variable_set('taxonomy_is_large', array($vid => TRUE)), if its detected < 25 variable_set('taxonomy_is_large', array($vid => TRUE)) Where exactly you can set that, I do not know, but from that moment on you only need to check against that variable, on all the places where a tree would be rendered. ------------------------------------------------------------------------ Wed, 18 May 2005 18:20:25 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues/_p_25termvocab_0.patch (1.32 KB) Does anyone else have comments on berkes' suggestion in #5? Dries? Perhaps the more adequate question is: is a "free tagging" vocabulary really useful if it has 25 terms or less? Isn't that more in the realm of a controlled vocabulary? If the user really is typing in the same 25 terms over and over again, that's gotta be an indication that they can save time with a dropdown, right? And if the free tagging vocabulary is just starting out, isn't there an assumption that it will eventually grow to be larger than 25 terms, In almost every use case? I guess my definition of a "free tagging" vocabulary ALSO includes the assumption that it'll grow to be $large, where $large is AT LEAST 100 terms. I've never seen any folksonomy smaller than that, save for those just starting out. is that a valid assumption? If it is, should it be treated as a "speshul" type of vocabulary, one which doesn't need a check on how many terms are actually in it, especially when said check become more prohibitive (in added code as well as processing time) as the vocabulary grows? (Attached an updated, but unchanged, patch to sync with HEAD). ------------------------------------------------------------------------ Thu, 19 May 2005 19:31:49 +0000 : Dries Personally, I'm not tempted to commit this patch. First, a 8.000 term vocabulary is not very realistic. It simply doesn't work. While this patch 'fixes' the administration page in such a scenario, it doesn't fix any of the other pages (like those having to render a selection menu with 8.000 terms). Morbus, is this _really_ needed? ------------------------------------------------------------------------ Thu, 19 May 2005 20:20:33 +0000 : Morbus Iff Note that the original intent of this patch was ONLY for NON-FREETAGGING vocabularies, and was intended SOLELY to stop multiple, large, NON-FREETAGGING vocabularies from making the vocabulary page abnormally long. An 8000 term NON-FREETAGGING vocabulary is quite unrealistic, yes - that wasn't the "baseline" for this patch. The baseline for this patch was two or more NON-FREETAGGING vocabularies that had more than 25 terms in it, of which I have three in the NHPR site. 75 terms on one page create a rather long vertical scroll that I didn't really want or like, especially when I had a fourth vocabulary that was alphabetized last, and thus, was four or five pages below the fold. So, again, the patch was catered for NON-FREETAGGING vocabularies. An 8000 term FREETAGGING vocabulary is quite possible actually (witness flickr, delicious and technorati - all community sites that use folksonomies and all have a rather wild number of terms, and my NHPR conversion has, now, 9000 terms). Whether you think 8000 terms in a FREETAGGING vocabulary is realistic or not, that's the reality in four sites, three of which created this whole "folksonomy" meme. But, again, this patch wasn't catered to that - the existing code in core ALREADY ASSUMES that folksonomies will grow large, and thus, doesn't attempt to show them without the "view terms" pagers. This patch was SOLELY created to prevent vertical disruption of the vocabulary page on the oft-chance that NON-FREETAGGING vocabularies grew larger than "normal". ------------------------------------------------------------------------ Thu, 19 May 2005 21:34:06 +0000 : nedjo This general question would be, how do we differentially display object references (nodes, terms, users) depending on the number available? As things stand, we don't do this, but we do take different approaches based on object type. Consider two examples from form elements. (a) Users. When we want the user to designate a user, we present a text box (rather than a select), assuming there will be too many users to present in a select. (b) Terms. We present a select, assuming there will be few enough terms. But neither of these assumptions holds for all sites. I've got several sites with few enough users to fit handily in a select, whereas we've heard there are plenty of sites with too many terms for a select. +1 for the general answer of thresholds and differential display. The proposed patch is a good start. I'd prefer to have the threshold number pulled out into (yes) a configuration option, ideally a general one that is for all object types. This would enable future work on lists of other types. ------------------------------------------------------------------------ Thu, 19 May 2005 23:02:01 +0000 : Chris Johnson I think nedjo states the problem clearly. I've got a site where when it is fully implement, it could have thousands of terms. Imagine dividing the U.S. by state, then county, then location (city) name. By state by location gives as many as 12,084 locations in the state of Pennsylvania, for example. Dividing the same data into counties, I still have 9 counties with more than 500 locations (terms). I'm sure others have similar large datasets they wish to make use of in their Drupal-based web sites. ------------------------------------------------------------------------ Thu, 14 Jul 2005 23:04:53 +0000 : RobRoy Re: #7 I have a few sites with anywhere from 5000-15,000 term vocabs and have been hacking away to just get a look at the taxonomy admin. So I think this is a very necessary feature. +1 for the idea ------------------------------------------------------------------------ Thu, 14 Jul 2005 23:13:29 +0000 : RobRoy Sorry, for the dual comments. But I propose that only vocabs are shown on the admin page and one must click view terms to see the terms (which would have a pager like in cvs). Then all the screens are nice and short. I'm doing this right now and it works great. This way it is consistent and there aren't some vocabs with terms showing and some without, although it does add another click. So it's great for sites with lots of vocabs and tons of terms. ------------------------------------------------------------------------ Mon, 18 Jul 2005 14:11:52 +0000 : Dries Hey Rob, can you provide a patch so we can compare both? If possible provide a screenshot comparing the approaches. That would really help digest this patch. Thanks. ------------------------------------------------------------------------ Mon, 18 Jul 2005 14:24:52 +0000 : Dries Talked to Morbus and I think Rob's approach makes sense. If well-executed, it allows us to community the difference between vocubularies and terms a little better. The current taxonomy adminstration page is anything but easy, so hopefully, it only gets better. Rob? :) ------------------------------------------------------------------------ Mon, 18 Jul 2005 18:24:05 +0000 : RobRoy Attachment: http://drupal.org/files/issues/taxonomy_pager.patch (4.76 KB) Here we go. This also includes the one main fix and 3 minor fixes. Let me know how it works. I did the patch off 4.6.2 since that is what I was working off of. Let me know if you want me to do it on the cvs version as I'm not sure what the preferred method is. * The view terms patch described above * In the cvs patch, $start_from > $total_entries should have been $start_from >= $total_entries. It was messing the pager up a bit. * Removed a redundant array initialization * Added a missing sorting fix, to sort by weight, then name. ------------------------------------------------------------------------ Mon, 18 Jul 2005 19:01:37 +0000 : RobRoy Attachment: http://drupal.org/files/issues/taxonomy_pager_cvs.patch (4.62 KB) Okay, well I figured a patch on cvs is probably better, so here it is. But the cvs ver of taxonomy.module depends on some other updates so I was kinda flying blind implementing this. It should work. ------------------------------------------------------------------------ Mon, 18 Jul 2005 19:44:22 +0000 : Dries Patch against CVS applies but doesn't work. My forum terms are not shown at all -- maybe because they are hierarchical. ------------------------------------------------------------------------ Mon, 18 Jul 2005 21:11:14 +0000 : Morbus Iff Dries - his page "works"; the problem you're seeing is part of http://drupal.org/node/23687.

Issue status update for http://drupal.org/node/20505 Post a follow up: http://drupal.org/project/comments/add/20505 Project: Drupal Version: cvs Component: taxonomy.module Category: feature requests Priority: normal Assigned to: Morbus Iff Reported by: Morbus Iff Updated by: Morbus Iff Status: patch Attachment: http://drupal.org/files/issues/_p_20505_25termvocab.patch (5.91 KB) This is an updated version of the previous patch, for HEAD, with working pagers. Dries: I did a quick test with hierarchies too, and they should work fine. If this patch gets in, it will also temporarily solve the broken pager issue described over in #23687. Morbus Iff Previous comments: ------------------------------------------------------------------------ Thu, 14 Apr 2005 16:31:18 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues/_p_25termvocab.patch (1.28 KB) There was some small talk about this here and there during my folksonomy/free tagging patch, but I held off until now to actually implement it. Much like we handle free tagging vocabularies ("this is a free tagging vocabulary: view terms", which leads the admin into the taxonomy pager system), this patch does the same thing for NON-free tagging vocabularies, but ONLY if the vocabulary has more than 25 terms. These patches were made during the exploration and customization of Drupal by http://www.NHPR.org. In loving support of open source software, http://www.NHPR.org will continue to contribute patches they feel the community will benefit from. Questions about this patch should be directed to morbus@disobey.com. ------------------------------------------------------------------------ Mon, 02 May 2005 11:32:57 +0000 : Dries If would make sense if "free tags" were also shown if there are less than 25 terms, not? ------------------------------------------------------------------------ Mon, 02 May 2005 18:53:59 +0000 : Morbus Iff My concern with that is how to actually get the term count quickly for a vocabulary that has 8000 terms. On my installation (with 8000+ terms), it takes 360ms (per devel.module) for get_tree(). Following through with the same mentality code as suggested with this patch (using get_tree() to return an array of countable terms), we'd be wasting 360ms just to get a count of free tagging terms (more or less - I've been generally assuming that the very smallest free tagging vocab would be 100 terms, and the largest I've worked with being 8000). The only other countable equivalent would be a brand new SQL statement that'd just return the number of terms in a vocabulary (similar to term_count_nodes, only vocabulary_count_terms). I could certainly add this in, but for consistency / pattern sake, I'd want to use it IN PLACE of the get_tree side- effect/counting as demonstrated in this patch (so, count first, then get_tree when necessary). This would cause NUM_VOCABULARIES more queries than currently, but would certainly add up less than returning an entire tree of 8000 terms just to throw it away again. Thoughts? ------------------------------------------------------------------------ Tue, 03 May 2005 14:26:37 +0000 : Jaza Two suggestions: 1. Why >25? Anything special about the number 25? +1 For the idea of having 'view terms' for vocabularies with a large number of terms, but I don't see why 25 is necessarily where 'large' begins. This number should be a setting somewhere (not sure where, since taxonomy has no options page of its own). 25 can be the default option - it sounds reasonable to me (but maybe not to all webmasters). Perhaps make it so that if '0' is entered as the number, all terms are always displayed for that vocabulary (unless free tagging is enabled). 2. Taking this concept a bit further, it might be good to have an option: "enable free tagging for vocabularies when the number of terms reaches x". x could be the same variable as the one above, but I suggest that it be stored separately, for a more flexible configuration. As with suggestion 1, it may be hard finding a settings page on which this option belongs. Also, this might be taking it too far - could be one setting too many? In terms of performance, there should be no problem, since free tagging vocabularies do not need to have their terms counted - only others do. Number 2 could also be implemented on a per-vocabulary basis (number 1 also could, but that would be silly), but that would mean another column in the vocabulary table, especially for free tagging. And if that can be avoided, it should. Jaza ------------------------------------------------------------------------ Tue, 03 May 2005 14:39:45 +0000 : Morbus Iff 25 is an arbitrary number based on the assumption that they'll be at least two vocabularies in a site (one for the site itself, and one for the forums). A single page with a maximum of 48 items on it is quite large already, and that doesn't take into consideration other user-created vocabularies that could increase the size of the page (2 other vocabularies that have 10 items each, for instance, could create a 68-item sized page). I'm against a user-settable option just for the sake of a user-settable option. #2 is a whole 'nother feature request and should be its own separate Issue. I won't respond to it here. In short, however, I don't like it. ------------------------------------------------------------------------ Wed, 04 May 2005 09:20:54 +0000 : Bèr Kessels -1 on yet another option. We must decide what 'big' is. if someone really has objections about our idea of 'big' she should change that in the code. Another option is not an option, IMO. Morbus, what about using variable_get/set? If you detect the number only for very speecial cases, and find that there are more then 25, you do variable_set('taxonomy_is_large', array($vid => TRUE)), if its detected < 25 variable_set('taxonomy_is_large', array($vid => TRUE)) Where exactly you can set that, I do not know, but from that moment on you only need to check against that variable, on all the places where a tree would be rendered. ------------------------------------------------------------------------ Wed, 18 May 2005 18:20:25 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues/_p_25termvocab_0.patch (1.32 KB) Does anyone else have comments on berkes' suggestion in #5? Dries? Perhaps the more adequate question is: is a "free tagging" vocabulary really useful if it has 25 terms or less? Isn't that more in the realm of a controlled vocabulary? If the user really is typing in the same 25 terms over and over again, that's gotta be an indication that they can save time with a dropdown, right? And if the free tagging vocabulary is just starting out, isn't there an assumption that it will eventually grow to be larger than 25 terms, In almost every use case? I guess my definition of a "free tagging" vocabulary ALSO includes the assumption that it'll grow to be $large, where $large is AT LEAST 100 terms. I've never seen any folksonomy smaller than that, save for those just starting out. is that a valid assumption? If it is, should it be treated as a "speshul" type of vocabulary, one which doesn't need a check on how many terms are actually in it, especially when said check become more prohibitive (in added code as well as processing time) as the vocabulary grows? (Attached an updated, but unchanged, patch to sync with HEAD). ------------------------------------------------------------------------ Thu, 19 May 2005 19:31:49 +0000 : Dries Personally, I'm not tempted to commit this patch. First, a 8.000 term vocabulary is not very realistic. It simply doesn't work. While this patch 'fixes' the administration page in such a scenario, it doesn't fix any of the other pages (like those having to render a selection menu with 8.000 terms). Morbus, is this _really_ needed? ------------------------------------------------------------------------ Thu, 19 May 2005 20:20:33 +0000 : Morbus Iff Note that the original intent of this patch was ONLY for NON-FREETAGGING vocabularies, and was intended SOLELY to stop multiple, large, NON-FREETAGGING vocabularies from making the vocabulary page abnormally long. An 8000 term NON-FREETAGGING vocabulary is quite unrealistic, yes - that wasn't the "baseline" for this patch. The baseline for this patch was two or more NON-FREETAGGING vocabularies that had more than 25 terms in it, of which I have three in the NHPR site. 75 terms on one page create a rather long vertical scroll that I didn't really want or like, especially when I had a fourth vocabulary that was alphabetized last, and thus, was four or five pages below the fold. So, again, the patch was catered for NON-FREETAGGING vocabularies. An 8000 term FREETAGGING vocabulary is quite possible actually (witness flickr, delicious and technorati - all community sites that use folksonomies and all have a rather wild number of terms, and my NHPR conversion has, now, 9000 terms). Whether you think 8000 terms in a FREETAGGING vocabulary is realistic or not, that's the reality in four sites, three of which created this whole "folksonomy" meme. But, again, this patch wasn't catered to that - the existing code in core ALREADY ASSUMES that folksonomies will grow large, and thus, doesn't attempt to show them without the "view terms" pagers. This patch was SOLELY created to prevent vertical disruption of the vocabulary page on the oft-chance that NON-FREETAGGING vocabularies grew larger than "normal". ------------------------------------------------------------------------ Thu, 19 May 2005 21:34:06 +0000 : nedjo This general question would be, how do we differentially display object references (nodes, terms, users) depending on the number available? As things stand, we don't do this, but we do take different approaches based on object type. Consider two examples from form elements. (a) Users. When we want the user to designate a user, we present a text box (rather than a select), assuming there will be too many users to present in a select. (b) Terms. We present a select, assuming there will be few enough terms. But neither of these assumptions holds for all sites. I've got several sites with few enough users to fit handily in a select, whereas we've heard there are plenty of sites with too many terms for a select. +1 for the general answer of thresholds and differential display. The proposed patch is a good start. I'd prefer to have the threshold number pulled out into (yes) a configuration option, ideally a general one that is for all object types. This would enable future work on lists of other types. ------------------------------------------------------------------------ Thu, 19 May 2005 23:02:01 +0000 : Chris Johnson I think nedjo states the problem clearly. I've got a site where when it is fully implement, it could have thousands of terms. Imagine dividing the U.S. by state, then county, then location (city) name. By state by location gives as many as 12,084 locations in the state of Pennsylvania, for example. Dividing the same data into counties, I still have 9 counties with more than 500 locations (terms). I'm sure others have similar large datasets they wish to make use of in their Drupal-based web sites. ------------------------------------------------------------------------ Thu, 14 Jul 2005 23:04:53 +0000 : RobRoy Re: #7 I have a few sites with anywhere from 5000-15,000 term vocabs and have been hacking away to just get a look at the taxonomy admin. So I think this is a very necessary feature. +1 for the idea ------------------------------------------------------------------------ Thu, 14 Jul 2005 23:13:29 +0000 : RobRoy Sorry, for the dual comments. But I propose that only vocabs are shown on the admin page and one must click view terms to see the terms (which would have a pager like in cvs). Then all the screens are nice and short. I'm doing this right now and it works great. This way it is consistent and there aren't some vocabs with terms showing and some without, although it does add another click. So it's great for sites with lots of vocabs and tons of terms. ------------------------------------------------------------------------ Mon, 18 Jul 2005 14:11:52 +0000 : Dries Hey Rob, can you provide a patch so we can compare both? If possible provide a screenshot comparing the approaches. That would really help digest this patch. Thanks. ------------------------------------------------------------------------ Mon, 18 Jul 2005 14:24:52 +0000 : Dries Talked to Morbus and I think Rob's approach makes sense. If well-executed, it allows us to community the difference between vocubularies and terms a little better. The current taxonomy adminstration page is anything but easy, so hopefully, it only gets better. Rob? :) ------------------------------------------------------------------------ Mon, 18 Jul 2005 18:24:05 +0000 : RobRoy Attachment: http://drupal.org/files/issues/taxonomy_pager.patch (4.76 KB) Here we go. This also includes the one main fix and 3 minor fixes. Let me know how it works. I did the patch off 4.6.2 since that is what I was working off of. Let me know if you want me to do it on the cvs version as I'm not sure what the preferred method is. * The view terms patch described above * In the cvs patch, $start_from > $total_entries should have been $start_from >= $total_entries. It was messing the pager up a bit. * Removed a redundant array initialization * Added a missing sorting fix, to sort by weight, then name. ------------------------------------------------------------------------ Mon, 18 Jul 2005 19:01:37 +0000 : RobRoy Attachment: http://drupal.org/files/issues/taxonomy_pager_cvs.patch (4.62 KB) Okay, well I figured a patch on cvs is probably better, so here it is. But the cvs ver of taxonomy.module depends on some other updates so I was kinda flying blind implementing this. It should work. ------------------------------------------------------------------------ Mon, 18 Jul 2005 19:44:22 +0000 : Dries Patch against CVS applies but doesn't work. My forum terms are not shown at all -- maybe because they are hierarchical. ------------------------------------------------------------------------ Mon, 18 Jul 2005 21:11:14 +0000 : Morbus Iff Dries - his page "works"; the problem you're seeing is part of http://drupal.org/node/23687. ------------------------------------------------------------------------ Mon, 18 Jul 2005 21:14:00 +0000 : Morbus Iff Dries - does your first term have a large number of children - more than 25? ------------------------------------------------------------------------ Tue, 19 Jul 2005 07:51:10 +0000 : Dries Not more than 25 but they are hierarchical.

Issue status update for http://drupal.org/node/20505 Post a follow up: http://drupal.org/project/comments/add/20505 Project: Drupal Version: cvs Component: taxonomy.module Category: feature requests Priority: normal Assigned to: Morbus Iff Reported by: Morbus Iff Updated by: Dries Status: patch Committed a modified version of this patch. Please test. Dries Previous comments: ------------------------------------------------------------------------ Thu, 14 Apr 2005 16:31:18 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues/_p_25termvocab.patch (1.28 KB) There was some small talk about this here and there during my folksonomy/free tagging patch, but I held off until now to actually implement it. Much like we handle free tagging vocabularies ("this is a free tagging vocabulary: view terms", which leads the admin into the taxonomy pager system), this patch does the same thing for NON-free tagging vocabularies, but ONLY if the vocabulary has more than 25 terms. These patches were made during the exploration and customization of Drupal by http://www.NHPR.org. In loving support of open source software, http://www.NHPR.org will continue to contribute patches they feel the community will benefit from. Questions about this patch should be directed to morbus@disobey.com. ------------------------------------------------------------------------ Mon, 02 May 2005 11:32:57 +0000 : Dries If would make sense if "free tags" were also shown if there are less than 25 terms, not? ------------------------------------------------------------------------ Mon, 02 May 2005 18:53:59 +0000 : Morbus Iff My concern with that is how to actually get the term count quickly for a vocabulary that has 8000 terms. On my installation (with 8000+ terms), it takes 360ms (per devel.module) for get_tree(). Following through with the same mentality code as suggested with this patch (using get_tree() to return an array of countable terms), we'd be wasting 360ms just to get a count of free tagging terms (more or less - I've been generally assuming that the very smallest free tagging vocab would be 100 terms, and the largest I've worked with being 8000). The only other countable equivalent would be a brand new SQL statement that'd just return the number of terms in a vocabulary (similar to term_count_nodes, only vocabulary_count_terms). I could certainly add this in, but for consistency / pattern sake, I'd want to use it IN PLACE of the get_tree side- effect/counting as demonstrated in this patch (so, count first, then get_tree when necessary). This would cause NUM_VOCABULARIES more queries than currently, but would certainly add up less than returning an entire tree of 8000 terms just to throw it away again. Thoughts? ------------------------------------------------------------------------ Tue, 03 May 2005 14:26:37 +0000 : Jaza Two suggestions: 1. Why >25? Anything special about the number 25? +1 For the idea of having 'view terms' for vocabularies with a large number of terms, but I don't see why 25 is necessarily where 'large' begins. This number should be a setting somewhere (not sure where, since taxonomy has no options page of its own). 25 can be the default option - it sounds reasonable to me (but maybe not to all webmasters). Perhaps make it so that if '0' is entered as the number, all terms are always displayed for that vocabulary (unless free tagging is enabled). 2. Taking this concept a bit further, it might be good to have an option: "enable free tagging for vocabularies when the number of terms reaches x". x could be the same variable as the one above, but I suggest that it be stored separately, for a more flexible configuration. As with suggestion 1, it may be hard finding a settings page on which this option belongs. Also, this might be taking it too far - could be one setting too many? In terms of performance, there should be no problem, since free tagging vocabularies do not need to have their terms counted - only others do. Number 2 could also be implemented on a per-vocabulary basis (number 1 also could, but that would be silly), but that would mean another column in the vocabulary table, especially for free tagging. And if that can be avoided, it should. Jaza ------------------------------------------------------------------------ Tue, 03 May 2005 14:39:45 +0000 : Morbus Iff 25 is an arbitrary number based on the assumption that they'll be at least two vocabularies in a site (one for the site itself, and one for the forums). A single page with a maximum of 48 items on it is quite large already, and that doesn't take into consideration other user-created vocabularies that could increase the size of the page (2 other vocabularies that have 10 items each, for instance, could create a 68-item sized page). I'm against a user-settable option just for the sake of a user-settable option. #2 is a whole 'nother feature request and should be its own separate Issue. I won't respond to it here. In short, however, I don't like it. ------------------------------------------------------------------------ Wed, 04 May 2005 09:20:54 +0000 : Bèr Kessels -1 on yet another option. We must decide what 'big' is. if someone really has objections about our idea of 'big' she should change that in the code. Another option is not an option, IMO. Morbus, what about using variable_get/set? If you detect the number only for very speecial cases, and find that there are more then 25, you do variable_set('taxonomy_is_large', array($vid => TRUE)), if its detected < 25 variable_set('taxonomy_is_large', array($vid => TRUE)) Where exactly you can set that, I do not know, but from that moment on you only need to check against that variable, on all the places where a tree would be rendered. ------------------------------------------------------------------------ Wed, 18 May 2005 18:20:25 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues/_p_25termvocab_0.patch (1.32 KB) Does anyone else have comments on berkes' suggestion in #5? Dries? Perhaps the more adequate question is: is a "free tagging" vocabulary really useful if it has 25 terms or less? Isn't that more in the realm of a controlled vocabulary? If the user really is typing in the same 25 terms over and over again, that's gotta be an indication that they can save time with a dropdown, right? And if the free tagging vocabulary is just starting out, isn't there an assumption that it will eventually grow to be larger than 25 terms, In almost every use case? I guess my definition of a "free tagging" vocabulary ALSO includes the assumption that it'll grow to be $large, where $large is AT LEAST 100 terms. I've never seen any folksonomy smaller than that, save for those just starting out. is that a valid assumption? If it is, should it be treated as a "speshul" type of vocabulary, one which doesn't need a check on how many terms are actually in it, especially when said check become more prohibitive (in added code as well as processing time) as the vocabulary grows? (Attached an updated, but unchanged, patch to sync with HEAD). ------------------------------------------------------------------------ Thu, 19 May 2005 19:31:49 +0000 : Dries Personally, I'm not tempted to commit this patch. First, a 8.000 term vocabulary is not very realistic. It simply doesn't work. While this patch 'fixes' the administration page in such a scenario, it doesn't fix any of the other pages (like those having to render a selection menu with 8.000 terms). Morbus, is this _really_ needed? ------------------------------------------------------------------------ Thu, 19 May 2005 20:20:33 +0000 : Morbus Iff Note that the original intent of this patch was ONLY for NON-FREETAGGING vocabularies, and was intended SOLELY to stop multiple, large, NON-FREETAGGING vocabularies from making the vocabulary page abnormally long. An 8000 term NON-FREETAGGING vocabulary is quite unrealistic, yes - that wasn't the "baseline" for this patch. The baseline for this patch was two or more NON-FREETAGGING vocabularies that had more than 25 terms in it, of which I have three in the NHPR site. 75 terms on one page create a rather long vertical scroll that I didn't really want or like, especially when I had a fourth vocabulary that was alphabetized last, and thus, was four or five pages below the fold. So, again, the patch was catered for NON-FREETAGGING vocabularies. An 8000 term FREETAGGING vocabulary is quite possible actually (witness flickr, delicious and technorati - all community sites that use folksonomies and all have a rather wild number of terms, and my NHPR conversion has, now, 9000 terms). Whether you think 8000 terms in a FREETAGGING vocabulary is realistic or not, that's the reality in four sites, three of which created this whole "folksonomy" meme. But, again, this patch wasn't catered to that - the existing code in core ALREADY ASSUMES that folksonomies will grow large, and thus, doesn't attempt to show them without the "view terms" pagers. This patch was SOLELY created to prevent vertical disruption of the vocabulary page on the oft-chance that NON-FREETAGGING vocabularies grew larger than "normal". ------------------------------------------------------------------------ Thu, 19 May 2005 21:34:06 +0000 : nedjo This general question would be, how do we differentially display object references (nodes, terms, users) depending on the number available? As things stand, we don't do this, but we do take different approaches based on object type. Consider two examples from form elements. (a) Users. When we want the user to designate a user, we present a text box (rather than a select), assuming there will be too many users to present in a select. (b) Terms. We present a select, assuming there will be few enough terms. But neither of these assumptions holds for all sites. I've got several sites with few enough users to fit handily in a select, whereas we've heard there are plenty of sites with too many terms for a select. +1 for the general answer of thresholds and differential display. The proposed patch is a good start. I'd prefer to have the threshold number pulled out into (yes) a configuration option, ideally a general one that is for all object types. This would enable future work on lists of other types. ------------------------------------------------------------------------ Thu, 19 May 2005 23:02:01 +0000 : Chris Johnson I think nedjo states the problem clearly. I've got a site where when it is fully implement, it could have thousands of terms. Imagine dividing the U.S. by state, then county, then location (city) name. By state by location gives as many as 12,084 locations in the state of Pennsylvania, for example. Dividing the same data into counties, I still have 9 counties with more than 500 locations (terms). I'm sure others have similar large datasets they wish to make use of in their Drupal-based web sites. ------------------------------------------------------------------------ Thu, 14 Jul 2005 23:04:53 +0000 : RobRoy Re: #7 I have a few sites with anywhere from 5000-15,000 term vocabs and have been hacking away to just get a look at the taxonomy admin. So I think this is a very necessary feature. +1 for the idea ------------------------------------------------------------------------ Thu, 14 Jul 2005 23:13:29 +0000 : RobRoy Sorry, for the dual comments. But I propose that only vocabs are shown on the admin page and one must click view terms to see the terms (which would have a pager like in cvs). Then all the screens are nice and short. I'm doing this right now and it works great. This way it is consistent and there aren't some vocabs with terms showing and some without, although it does add another click. So it's great for sites with lots of vocabs and tons of terms. ------------------------------------------------------------------------ Mon, 18 Jul 2005 14:11:52 +0000 : Dries Hey Rob, can you provide a patch so we can compare both? If possible provide a screenshot comparing the approaches. That would really help digest this patch. Thanks. ------------------------------------------------------------------------ Mon, 18 Jul 2005 14:24:52 +0000 : Dries Talked to Morbus and I think Rob's approach makes sense. If well-executed, it allows us to community the difference between vocubularies and terms a little better. The current taxonomy adminstration page is anything but easy, so hopefully, it only gets better. Rob? :) ------------------------------------------------------------------------ Mon, 18 Jul 2005 18:24:05 +0000 : RobRoy Attachment: http://drupal.org/files/issues/taxonomy_pager.patch (4.76 KB) Here we go. This also includes the one main fix and 3 minor fixes. Let me know how it works. I did the patch off 4.6.2 since that is what I was working off of. Let me know if you want me to do it on the cvs version as I'm not sure what the preferred method is. * The view terms patch described above * In the cvs patch, $start_from > $total_entries should have been $start_from >= $total_entries. It was messing the pager up a bit. * Removed a redundant array initialization * Added a missing sorting fix, to sort by weight, then name. ------------------------------------------------------------------------ Mon, 18 Jul 2005 19:01:37 +0000 : RobRoy Attachment: http://drupal.org/files/issues/taxonomy_pager_cvs.patch (4.62 KB) Okay, well I figured a patch on cvs is probably better, so here it is. But the cvs ver of taxonomy.module depends on some other updates so I was kinda flying blind implementing this. It should work. ------------------------------------------------------------------------ Mon, 18 Jul 2005 19:44:22 +0000 : Dries Patch against CVS applies but doesn't work. My forum terms are not shown at all -- maybe because they are hierarchical. ------------------------------------------------------------------------ Mon, 18 Jul 2005 21:11:14 +0000 : Morbus Iff Dries - his page "works"; the problem you're seeing is part of http://drupal.org/node/23687. ------------------------------------------------------------------------ Mon, 18 Jul 2005 21:14:00 +0000 : Morbus Iff Dries - does your first term have a large number of children - more than 25? ------------------------------------------------------------------------ Tue, 19 Jul 2005 07:51:10 +0000 : Dries Not more than 25 but they are hierarchical. ------------------------------------------------------------------------ Tue, 19 Jul 2005 15:21:11 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues/_p_20505_25termvocab.patch (5.91 KB) This is an updated version of the previous patch, for HEAD, with working pagers. Dries: I did a quick test with hierarchies too, and they should work fine. If this patch gets in, it will also temporarily solve the broken pager issue described over in #23687. ------------------------------------------------------------------------ Tue, 19 Jul 2005 16:46:57 +0000 : Dries Attachment: http://drupal.org/files/issues/forum-taxonomy-fubar.png (13.42 KB) Strange. Now my forum vocabulary is replaced by 'No categories available'. See screenshot. If I move the  if (!$rows) {-blurb to its proper location, the forum taxonomy is not shown. If I remove the if ($vocabulary->module == 'taxonomy') { check (like we agreed upon earlier!), the forum vocabulary is shown. When I click 'view terms' of the /new/ forum vocabulary, the terms are not shown (however it works for the other vocabularies). If I remove the second if ($vocabulary->module == 'taxonomy') { check (the one in the else clause), the terms are shown.