February 2005 - Development - lists.drupal.org

[drupal-devel] [feature] Option to disable printer friendly version for book module
by Junyor 28 Feb '05

28 Feb '05

Issue status update for http://drupal.org/node/13211 Project: Drupal Version: cvs Component: book.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: kbahey Updated by: Junyor Status: patch +1 for a generic _link editor. Junyor Previous comments: ------------------------------------------------------------------------ November 20, 2004 - 07:30 : kbahey Attachment: http://drupal.org/files/issues/book_17.patch (2.18 KB) I wanted an option for the book module to NOT display a 'printer-friendly version' link for every node. So, I implemented an option for the book module to allow this to be turned off. Using this option: - Go to the /admin/node/book - Uncheck the box that say 'show printer friendly links for books' if you want - Click 'Save settings' There will be no printer friendly links after you do this. Please consider applying this patch to CVS. ------------------------------------------------------------------------ November 21, 2004 - 18:01 : kbahey Setting status to patch, so that it is discussed on the mailing list. ------------------------------------------------------------------------ November 26, 2004 - 00:36 : kbahey Attachment: http://drupal.org/files/issues/book_18.patch (2.3 KB) I have remade this patch to match what is in the current CVS version. The previous patch had conflicts with the latest CVS version. Will this be included in the base any time soon? ------------------------------------------------------------------------ November 26, 2004 - 01:07 : Bèr Kessels options, options, options. Alltough an option is an easy method to add fetaures, while not breaking backwards compatibility, it is generally very bad for useability. I am therefore a -1 for this patch. kbahey, Eventhough the functionality is very nice, I would rather see you either make thisa single site wide setting (in books settings). Or -even better IMO- make the link dis(appear) through a theme function. Or -and thats the best option IMO- help the folks who are working on a better $links (the links under each node) and introduce a general API and theme system to show, hide and markup those links on nodes. ------------------------------------------------------------------------ November 26, 2004 - 22:55 : Anonymous "I would rather see you either make thisa single site wide setting (in books settings). " That is what it already does. The setting is global in books settings, and not in every individual book. It just so happens, for a reason unknown to me, that book's setting page is under administer -> content -> books, and not under administer -> settings -> book like other modules. "Or -even better IMO- make the link dis(appear) through a theme function. Or -and thats the best option IMO- help the folks who are working on a better $links (the links under each node) and introduce a general API and theme system to show, hide and markup those links on nodes. " Those sound like a better option for sure. If the option is in admin -> themes -> configure, under the "Toggle display" part. I am not familiar with that code at this point. Will do some digging to see what can be done. ------------------------------------------------------------------------ February 17, 2005 - 15:58 : kbahey One of the objections to this patch is that it introduces one more option. If I resubmit this patch without an option, does it have a change to be accepted? I will rely on the new $conf variable being able to override variable_get(), so there is no option screen needed. How about that? ------------------------------------------------------------------------ February 17, 2005 - 16:23 : stefan nagtegaal Imo this is a theme feature, so it should be handled in there.. A link management system should be the best to handle such things, but is - unfortunatly - quite hard to inplement... ------------------------------------------------------------------------ February 17, 2005 - 21:41 : kbahey Ideally it would be a theme function. However, most themes, specially the ones that ship with the standard Drupal distribution, do not provide a way to turn that off at will. Most ideal solution is the link management interface you mention, where site admins can turn on off any link they like for any module. But that does not exist so far, so until either one of the above solutions exist, I will be submitting a patch that allows turning off the printer friendly link. ------------------------------------------------------------------------ February 17, 2005 - 21:52 : Bèr Kessels With a theme function, is not meant a function that will make an option on your screen. "Ideally it would be a theme function. However, most themes, specially the ones that ship with the standard Drupal distribution, do not provide a way to turn that off at will." With a theme function, stefan most probablt meant a function theme_printer_friendly(). That function would return the link. If you want to turn it off, you woudl have to make a function yourtheme_printer_friendly() that does /not/ return that link. Problemd solved, without adding more clutter to the UI. ------------------------------------------------------------------------ February 18, 2005 - 03:48 : kbahey Attachment: http://drupal.org/files/issues/book-2.patch (1017 bytes) There are no UI changes in this patch. If someone wants to turn off the printer friendly link, then all they do is : - Go to settings.php - Uncomment the lines that have the $conf variable and the closing bracket - Add a line like this: 'book_hide_printer_friendly' => 1, That is it. No menus, no options, nothing ... Preferrably, we should document these 'hidden' options in the future, under an 'Advanced Configuration' section. ------------------------------------------------------------------------ February 18, 2005 - 06:42 : nedjo kbahey's point reflects a general problem in Drupal--much of the content returned is hard-coded, generated in modules, and therefore without any way of being overridden. As a site administrator, my feeling is that I should have full control over what I present to my users and therefore /nothing/ should be forced on me. My observation is that, many times when suggestions are made to try to free Drupal's core from hard-coded content, there is resistance on the basis that this would require more configuration. Fair enough--but sticking us with content we don't want isn't much of an option either. The three options suggested in this issue - theming, ui configuration options, and settings.php configuration options - all have some merit, and are all currently in use; but it looks like we need a larger discussion, and perhaps some fresh approaches. I'm thinking the proposed solution of passing the content filtering to theming is tempting, but ultimately problematic. Basically, the theme approach would say: generate content pass to theme function optionally (and manually), insert theme override function that doesn't display the content that's been generated In a practical sense, this approach is cumbersome because it requires, for every optional content element, (a) edits to the core module to pass content through a theme_ function, and (b) manual theme editing to write an override function. (This second piece, of course, necessitates extra work every time a theme is updated, even if we use otherwise unmodified themes). The workflow of first generating content and then overriding it is more than inefficient--it suggests a confusion in the separation of content and presentation. Ideally, I still believe, a theme should answers the question /how/ do you want to present content--not /what/ do you want to present. Of course, in Drupal, we break this ideal routinely. But to push even more decision-making logic into the themes feels like a step in the wrong direction. Ultimately, if we don't want content displayed, probably we shouldn't generate it in the first place. My own preference is configuration options over hard-coded content (thought the lastest suggestion of hiding this option in settings.php seems a bit confusing--most admins will never know about this option). But maybe we need a completely different approach. It strikes me that the menu system provides a possible model. It offers a way to assign generated content to various categories, e.g., MENU_SUGGESTED_ITEM. Could we extend this approach to other types of content--allowing administrative override, as we do with the menu module? ------------------------------------------------------------------------ February 18, 2005 - 12:28 : Anonymous I plan to address this issue shortly on the Interface and useability meetings on dropalCOM. My vision on this is: If a setting requires frequent change, or if a setting is that of an oblect, such as a taxonomy term, or if a setting is user, role or permission sepcific, or if we cannot find a "good default" because an option differs per case [1] ** we will allow UI elelements ** we should not have UI config options, but settings in conf.php or htacess If a setting is technical, server aimed site specific and a good default can be found (e.g. settings for time to remain logged in) ** we should not have UI config options, but theme functions, for setting that are: clearly layout settings or, provide output (e.g should horizontal tabs be UL or not) or, very site specific [1] and on all outputted HTML,( off course.) [1] this is a debatable part, and thus needs some clarification. With cases i mean a targetted group. An example of a case is "community site" or "personal blog". Specific suites, will fit within these cases, but is more specific. This print_link thing is obviously very specific. There is not one case that would not want a print link. on contrary: the user-details with each post are only interesting for cases of community sites. "corporate sites" are not interested. So that post-info should be ui configurable, since 50% of the sites wants it, and 50% does not. A print link will suit 98% of the people, while hiding is only interesting for 2%. Thus it it specific. Bèr ------------------------------------------------------------------------ February 18, 2005 - 12:29 : Bèr Kessels ^-- That was me. logged out for some reason ------------------------------------------------------------------------ February 18, 2005 - 16:57 : kbahey Nedjo, You feel my pain. Here is another example of the need for options to turn on/off certain links. This site uses image gallery to display products. http://originaltilly.com/node/view/144&n=all As you notice, there are no links at the bottom for resolution, gallery, ...etc. When I asked the author (asitis.org) how he did it, he said he edited out the links he does not need! On other sites, he overrode it in the theme. Doing this stuff in the theme is really ugly, because a theme should not have a lot of logic in it, and I agree with nedjo it should be about presentation of content not fiddling with content. The other problem that I pointed out is that no 'standard' theme does that today. My resorting to $conf was basically to get over the "no new options" objection. The option would be there and are hidden from view. We can have a note in a ADVANCED.txt file describing what options can be set there are how to set them, then we have satisfied both camps, the average user will not get confused, the advanced user can do what they want. Another approach is to have those infrequent options grouped under an advanced tab or something, where theywould not confuse the average user. Guys: Please! Let us be more pragmatic about this options thing. We may be introducing options that have the potential for confusion, but the price we pay is more than that: - Creating fragmented and ugly hacks in some themes - Forcing the introduction of unneeded complexity in some themes - Not having a general solution out of the box - Depriving functionality for others who cannot modify themes. ------------------------------------------------------------------------ February 18, 2005 - 17:02 : moshe weitzman Personally, I like the 'Advanced' tab. There should be a permission which is universal across all modules which says 'access advanced configuration options'. If user has that permission, he can see these tabs. -moshe ------------------------------------------------------------------------ February 24, 2005 - 16:41 : javanaut On the topic of an "advanced settings" tab, I implemented this for a module I'm working on here: http://drupal.org/node/17781#comment-29737 It does simplify an otherwise very messy UI (ok, it's still messy :). Additionally, I like the idea of a global flag/permission that would hide the "advanced" tab. I would think that every setting under the advanced tab would have a sensible default that, in general, wouldn't need to be modified for default module behavior. Ber, would such a feature offset your hesitation to add new configuration options? -Mark ------------------------------------------------------------------------ February 28, 2005 - 13:07 : Bèr Kessels I would like to close this issue. IMO we should just get a mechanism for handling /any/ link from the _link hook, not a book specific solution. Anyone objects against closing this, in favour of a more general solution/feature?

1 0

[drupal-devel] [feature] Option to disable printer friendly version for book module
by Bèr Kessels 28 Feb '05

28 Feb '05

Issue status update for http://drupal.org/node/13211 Project: Drupal Version: cvs Component: book.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: kbahey Updated by: Bèr Kessels Status: patch I would like to close this issue. IMO we should just get a mechanism for handling /any/ link from the _link hook, not a book specific solution. Anyone objects against closing this, in favour of a more general solution/feature? Bèr Kessels Previous comments: ------------------------------------------------------------------------ November 20, 2004 - 07:30 : kbahey Attachment: http://drupal.org/files/issues/book_17.patch (2.18 KB) I wanted an option for the book module to NOT display a 'printer-friendly version' link for every node. So, I implemented an option for the book module to allow this to be turned off. Using this option: - Go to the /admin/node/book - Uncheck the box that say 'show printer friendly links for books' if you want - Click 'Save settings' There will be no printer friendly links after you do this. Please consider applying this patch to CVS. ------------------------------------------------------------------------ November 21, 2004 - 18:01 : kbahey Setting status to patch, so that it is discussed on the mailing list. ------------------------------------------------------------------------ November 26, 2004 - 00:36 : kbahey Attachment: http://drupal.org/files/issues/book_18.patch (2.3 KB) I have remade this patch to match what is in the current CVS version. The previous patch had conflicts with the latest CVS version. Will this be included in the base any time soon? ------------------------------------------------------------------------ November 26, 2004 - 01:07 : Bèr Kessels options, options, options. Alltough an option is an easy method to add fetaures, while not breaking backwards compatibility, it is generally very bad for useability. I am therefore a -1 for this patch. kbahey, Eventhough the functionality is very nice, I would rather see you either make thisa single site wide setting (in books settings). Or -even better IMO- make the link dis(appear) through a theme function. Or -and thats the best option IMO- help the folks who are working on a better $links (the links under each node) and introduce a general API and theme system to show, hide and markup those links on nodes. ------------------------------------------------------------------------ November 26, 2004 - 22:55 : Anonymous "I would rather see you either make thisa single site wide setting (in books settings). " That is what it already does. The setting is global in books settings, and not in every individual book. It just so happens, for a reason unknown to me, that book's setting page is under administer -> content -> books, and not under administer -> settings -> book like other modules. "Or -even better IMO- make the link dis(appear) through a theme function. Or -and thats the best option IMO- help the folks who are working on a better $links (the links under each node) and introduce a general API and theme system to show, hide and markup those links on nodes. " Those sound like a better option for sure. If the option is in admin -> themes -> configure, under the "Toggle display" part. I am not familiar with that code at this point. Will do some digging to see what can be done. ------------------------------------------------------------------------ February 17, 2005 - 15:58 : kbahey One of the objections to this patch is that it introduces one more option. If I resubmit this patch without an option, does it have a change to be accepted? I will rely on the new $conf variable being able to override variable_get(), so there is no option screen needed. How about that? ------------------------------------------------------------------------ February 17, 2005 - 16:23 : stefan nagtegaal Imo this is a theme feature, so it should be handled in there.. A link management system should be the best to handle such things, but is - unfortunatly - quite hard to inplement... ------------------------------------------------------------------------ February 17, 2005 - 21:41 : kbahey Ideally it would be a theme function. However, most themes, specially the ones that ship with the standard Drupal distribution, do not provide a way to turn that off at will. Most ideal solution is the link management interface you mention, where site admins can turn on off any link they like for any module. But that does not exist so far, so until either one of the above solutions exist, I will be submitting a patch that allows turning off the printer friendly link. ------------------------------------------------------------------------ February 17, 2005 - 21:52 : Bèr Kessels With a theme function, is not meant a function that will make an option on your screen. "Ideally it would be a theme function. However, most themes, specially the ones that ship with the standard Drupal distribution, do not provide a way to turn that off at will." With a theme function, stefan most probablt meant a function theme_printer_friendly(). That function would return the link. If you want to turn it off, you woudl have to make a function yourtheme_printer_friendly() that does /not/ return that link. Problemd solved, without adding more clutter to the UI. ------------------------------------------------------------------------ February 18, 2005 - 03:48 : kbahey Attachment: http://drupal.org/files/issues/book-2.patch (1017 bytes) There are no UI changes in this patch. If someone wants to turn off the printer friendly link, then all they do is : - Go to settings.php - Uncomment the lines that have the $conf variable and the closing bracket - Add a line like this: 'book_hide_printer_friendly' => 1, That is it. No menus, no options, nothing ... Preferrably, we should document these 'hidden' options in the future, under an 'Advanced Configuration' section. ------------------------------------------------------------------------ February 18, 2005 - 06:42 : nedjo kbahey's point reflects a general problem in Drupal--much of the content returned is hard-coded, generated in modules, and therefore without any way of being overridden. As a site administrator, my feeling is that I should have full control over what I present to my users and therefore /nothing/ should be forced on me. My observation is that, many times when suggestions are made to try to free Drupal's core from hard-coded content, there is resistance on the basis that this would require more configuration. Fair enough--but sticking us with content we don't want isn't much of an option either. The three options suggested in this issue - theming, ui configuration options, and settings.php configuration options - all have some merit, and are all currently in use; but it looks like we need a larger discussion, and perhaps some fresh approaches. I'm thinking the proposed solution of passing the content filtering to theming is tempting, but ultimately problematic. Basically, the theme approach would say: generate content pass to theme function optionally (and manually), insert theme override function that doesn't display the content that's been generated In a practical sense, this approach is cumbersome because it requires, for every optional content element, (a) edits to the core module to pass content through a theme_ function, and (b) manual theme editing to write an override function. (This second piece, of course, necessitates extra work every time a theme is updated, even if we use otherwise unmodified themes). The workflow of first generating content and then overriding it is more than inefficient--it suggests a confusion in the separation of content and presentation. Ideally, I still believe, a theme should answers the question /how/ do you want to present content--not /what/ do you want to present. Of course, in Drupal, we break this ideal routinely. But to push even more decision-making logic into the themes feels like a step in the wrong direction. Ultimately, if we don't want content displayed, probably we shouldn't generate it in the first place. My own preference is configuration options over hard-coded content (thought the lastest suggestion of hiding this option in settings.php seems a bit confusing--most admins will never know about this option). But maybe we need a completely different approach. It strikes me that the menu system provides a possible model. It offers a way to assign generated content to various categories, e.g., MENU_SUGGESTED_ITEM. Could we extend this approach to other types of content--allowing administrative override, as we do with the menu module? ------------------------------------------------------------------------ February 18, 2005 - 12:28 : Anonymous I plan to address this issue shortly on the Interface and useability meetings on dropalCOM. My vision on this is: If a setting requires frequent change, or if a setting is that of an oblect, such as a taxonomy term, or if a setting is user, role or permission sepcific, or if we cannot find a "good default" because an option differs per case [1] ** we will allow UI elelements ** we should not have UI config options, but settings in conf.php or htacess If a setting is technical, server aimed site specific and a good default can be found (e.g. settings for time to remain logged in) ** we should not have UI config options, but theme functions, for setting that are: clearly layout settings or, provide output (e.g should horizontal tabs be UL or not) or, very site specific [1] and on all outputted HTML,( off course.) [1] this is a debatable part, and thus needs some clarification. With cases i mean a targetted group. An example of a case is "community site" or "personal blog". Specific suites, will fit within these cases, but is more specific. This print_link thing is obviously very specific. There is not one case that would not want a print link. on contrary: the user-details with each post are only interesting for cases of community sites. "corporate sites" are not interested. So that post-info should be ui configurable, since 50% of the sites wants it, and 50% does not. A print link will suit 98% of the people, while hiding is only interesting for 2%. Thus it it specific. Bèr ------------------------------------------------------------------------ February 18, 2005 - 12:29 : Bèr Kessels ^-- That was me. logged out for some reason ------------------------------------------------------------------------ February 18, 2005 - 16:57 : kbahey Nedjo, You feel my pain. Here is another example of the need for options to turn on/off certain links. This site uses image gallery to display products. http://originaltilly.com/node/view/144&n=all As you notice, there are no links at the bottom for resolution, gallery, ...etc. When I asked the author (asitis.org) how he did it, he said he edited out the links he does not need! On other sites, he overrode it in the theme. Doing this stuff in the theme is really ugly, because a theme should not have a lot of logic in it, and I agree with nedjo it should be about presentation of content not fiddling with content. The other problem that I pointed out is that no 'standard' theme does that today. My resorting to $conf was basically to get over the "no new options" objection. The option would be there and are hidden from view. We can have a note in a ADVANCED.txt file describing what options can be set there are how to set them, then we have satisfied both camps, the average user will not get confused, the advanced user can do what they want. Another approach is to have those infrequent options grouped under an advanced tab or something, where theywould not confuse the average user. Guys: Please! Let us be more pragmatic about this options thing. We may be introducing options that have the potential for confusion, but the price we pay is more than that: - Creating fragmented and ugly hacks in some themes - Forcing the introduction of unneeded complexity in some themes - Not having a general solution out of the box - Depriving functionality for others who cannot modify themes. ------------------------------------------------------------------------ February 18, 2005 - 17:02 : moshe weitzman Personally, I like the 'Advanced' tab. There should be a permission which is universal across all modules which says 'access advanced configuration options'. If user has that permission, he can see these tabs. -moshe ------------------------------------------------------------------------ February 24, 2005 - 16:41 : javanaut On the topic of an "advanced settings" tab, I implemented this for a module I'm working on here: http://drupal.org/node/17781#comment-29737 It does simplify an otherwise very messy UI (ok, it's still messy :). Additionally, I like the idea of a global flag/permission that would hide the "advanced" tab. I would think that every setting under the advanced tab would have a sensible default that, in general, wouldn't need to be modified for default module behavior. Ber, would such a feature offset your hesitation to add new configuration options? -Mark

1 0

[drupal-devel] *Begging* for checkbox to moderation pages
by Abalieno 28 Feb '05

28 Feb '05

To understand why I'm asking this you have too see this picture: http://www.cesspit.net/misc/spam.gif Now all that is *already* in the moderation queue, so it's not published. But I absolutely need a way to delete all that crap. It spans various pages and it would take me HOURS to delete each message one by one. Please, can someone build a small patch to apply to Drupal 4.5.2 that adds checkboxes to each comment so that I can wipe all that with one action? Who I have to pay for that? -HRose / Abalieno

7 9

[drupal-devel] [task] Postgres updates for 4.6
by adrian 28 Feb '05

28 Feb '05

Project: Drupal Version: cvs Component: postgresql database Category: tasks Priority: critical Assigned to: adrian Reported by: adrian Updated by: adrian Status: patch Attachment: http://drupal.org/files/issues/postgres_updates_inc.diff (8.71 KB) Here are the updates for updates.inc for the postgres port of drupal 4.6 I am still in the process of working through all the new functionality and making sure it all works, and I also need to finish testing the new installs (database schema) although I am 99% sure they are correct. More patches will probably be forthcoming, but I need to run to catch my plane to belgium. See you guys soon. adrian -- View: http://drupal.org/node/17747 Edit: http://drupal.org/project/comments/add/17747

4 7

[drupal-devel] [feature] List matching terms by vocabulary for nodes
by Bèr Kessels 28 Feb '05

28 Feb '05

Issue status update for http://drupal.org/node/9780 Project: Drupal Version: cvs Component: taxonomy.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: nedjo Updated by: Bèr Kessels Status: patch Bump. This still lloks interesting but is old and does no longer apply. Should it be updated or closed? Bèr Kessels Previous comments: ------------------------------------------------------------------------ August 5, 2004 - 07:13 : nedjo Attachment: http://drupal.org/files/issues/taxonomy-select-link-list-type-patch.zip (2.76 KB) When displaying the terms for a node, it would be desirable in some contexts to have a vocabulary-specific list instead of the default list of all matching terms. For example, consider a posting that represents a farm, categorized by (a) products produced, (b) farming practices, (c) location, etc. By default, it would display as follows: Submitted by Tracy Brock [1] on Mon, 06/14/2004 - 22:20. beans [2] | certified organic [3] | corn [4] | Fruits and Berries [5] | gooseberries [6] | Grainery [7] | herbs [8] | Nanaimo [9] | Pacific Agricultural Certifcation Society (PACS) [10] | peas [11] | Producers [12] | raspberries [13] | rye [14] | vegetables, various [15] But it would be useful to be able to separate out the different vocabularies, to see at a glance, for instance, products produced, as follows: Farming Practices [16] certified organic [17] Location [18] Nanaimo [19] Membership [20] Pacific Agricultural Certifcation Society (PACS) [21] Products [22] rye [23] raspberries [24] gooseberries [25] Fruits and Berries [26] vegetables, various [27] peas [28] herbs [29] corn [30] beans [31] Resource Type [32] Producers [33] Grainery [34] The attached patch introduces a new vocabulary setting, link_display, to allow site admins to select either the default display of terms for a node ("top") or, if prefered, a vocabulary-specific breakout in the body of the node display ("body"). It's implemented using the _nodeapi() "view" option. Also included are patches for the database.mysql and database.pgsql files to introduce a new field into the vocabulary table. [1] http://drupal.org/?q=user/view/3\" title=\"View user profile. [2] http://drupal.org/? [3] http://drupal.org/? [4] http://drupal.org/? [5] http://drupal.org/? [6] http://drupal.org/? [7] http://drupal.org/?q=taxonomy/page/or/112 [8] http://drupal.org/? [9] http://drupal.org/?q=taxonomy/page/or/146 [10] http://drupal.org/? [11] http://drupal.org/? [12] http://drupal.org/? [13] http://drupal.org/? [14] http://drupal.org/? [15] http://drupal.org/? [16] http://drupal.org/?q=vocabulary/view/4 [17] http://drupal.org/?q=taxonomy/view/or/127 [18] http://drupal.org/?q=vocabulary/view/6 [19] http://drupal.org/?q=taxonomy/view/or/146 [20] http://drupal.org/?q=vocabulary/view/5 [21] http://drupal.org/?q=taxonomy/view/or/136 [22] http://drupal.org/?q=vocabulary/view/2 [23] http://drupal.org/?q=taxonomy/view/or/137 [24] http://drupal.org/?q=taxonomy/view/or/66 [25] http://drupal.org/?q=taxonomy/view/or/108 [26] http://drupal.org/?q=taxonomy/view/or/8 [27] http://drupal.org/?q=taxonomy/view/or/32 [28] http://drupal.org/?q=taxonomy/view/or/114 [29] http://drupal.org/?q=taxonomy/view/or/31 [30] http://drupal.org/?q=taxonomy/view/or/83 [31] http://drupal.org/?q=taxonomy/view/or/39 [32] http://drupal.org/?q=vocabulary/view/3 [33] http://drupal.org/?q=taxonomy/view/or/11 [34] http://drupal.org/?q=taxonomy/view/or/112 ------------------------------------------------------------------------ August 15, 2004 - 05:17 : nedjo No response as yet, so I'll try to do a better job of explaining the advantages of this patch! While it's most used for simple sections of a website, the taxonomy system enables rich relational database functionality. For any data type, it can track multiple "one-to-many" or "many-to-many" relationships. For example, using no more than the existing taxonomy system, it would be possible to track, for a company node type, multiple products, customers, projects, and staff (each of these being a separate vocabulary). The current way of displaying linked terms for a node - lumping them together in an alphabetical list with no indication of what vocabulary they are from - makes sense for the "sections of a website" use, but doesn't take full advantage of the taxonomy system's ability to provide multiple categorizations. For the company example, it would be preferable to separate out, e.g., products as a distinct listing. This patch doesn't replace the existing way of displaying categories. Rather, it provides an option--to designate specific vocabularies to display instead in a list form. This functionality would help to take fuller advantage of the powerful and flexible taxonomy system. ------------------------------------------------------------------------ August 16, 2004 - 09:29 : Dries Maybe provide some screenshots to illustrate the proposed changes/additions?

1 0

[drupal-devel] [task] Content type admin code cleanup
by JonBob 27 Feb '05

27 Feb '05

Issue status update for http://drupal.org/node/18045 Project: Drupal Version: cvs Component: node.module Category: tasks Priority: normal Assigned to: JonBob Reported by: JonBob Updated by: JonBob Status: patch Attachment: http://drupal.org/files/issues/node_28.patch (4.44 KB) The node type admin page uses an unclear callback name, and uses arg() where it is not necessary. The attached patch cleans this up by unifying node_types() with node_types_configure(). The fact I may want node_types() for my own use in CCK work is purely coincidental. :-) JonBob

1 1

[drupal-devel] [feature] Block access by role patch (attached)
by flexer 27 Feb '05

27 Feb '05

Project: Drupal Version: cvs Component: block.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: flexer Updated by: flexer Status: patch Attachment: http://drupal.org/files/issues/block_access_by_role.tar.gz (2.54 KB) This is my patch(es) to add support for a per-role basis blocks visibility. How it works (user): block administrators can select which role(s) could access every block, via the configure block setting. In the same way one could "Restrict block to specific content types", now can "Show block to specific roles". Selecting one or more roles will cause the block to only be shown if the current user belongs to one of the selected roles. If no role is selected, the block is showed to everyone. Selecting all roles or selecting none, has the same effect. Note that Administrator (user 1) is never affected by this restriction. How it works (developer): I have added a new table to the system (block_access). It contains the module, delta and role for each defined block. Permission check is made in the "list" hook of the block module. A patch is given also for the *user.module*: when a role is deleted, we need to delete the specific records in block_access. Why this is useful: I use the menu.module very much, so I wondering why there was no way to create menu (as blocks) with content visible only to certain roles. So, my patch prevent the menu blocks to be displayed only for certain roles. I have also create, with this patch, an admin block that say "Register now ! Blah blah...", visibile only to anonymous users. Security issues: None that I could be awaew of... Performace issues: Every time a block_list is called, an additional database query is performed. What the file contains: The attached file contains: the block.module patch *block.module.patch* the user.module patch *user.module.patch* the MySQL DDL for block_access *block_access.mysql.sql* the PostgreSQL DDL for block_access *block_access.pgsql.sql* What to worry about This is my first contribution to Drupal English is not my first language :) flexer -- View: http://drupal.org/node/18018 Edit: http://drupal.org/project/comments/add/18018

2 2

[drupal-devel] [feature] Proposal for new hook: hook_settings()
by nysus 27 Feb '05

27 Feb '05

Project: Drupal Version: cvs Component: node system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: nysus Updated by: nysus Status: patch Attachment: http://drupal.org/files/issues/poll_1.patch (683 bytes) I was checking out the CVS version of Drupal and noticed that when creating a poll, the first field on the form is labeled "Title". If our goal is to make Drupal usable, then clearly it should be labeled "Question". This problem occurs for other modules, like Flexinode. The first field is always called "Title" which is rarely appropriate for the Flexinode. I think Drupal needs the flexibility to change this kind of thing. So I'm proposing a new hook called hook_settings(). I thought about creating a new hook called hook_title_label() but figured a more generic hook named "hook_settings()" would have others uses. For example, you could also use it to replace the hook_node_name(). Attached is patch for the poll module to give an example of this hook in action. I'll also upload a patched node.module that takes advantage of this hook. nysus -- View: http://drupal.org/node/18003 Edit: http://drupal.org/project/comments/add/18003

3 6

[drupal-devel] New module nameing.
by Aran Clary Deltac 26 Feb '05

26 Feb '05

I've written a new module and would like other module devels to give me their opinion. This module allows editing of the help messages for any page on a drupal site from within the administration pages. Right now I have it named "helpdb". From a technical point, sure the name describes that it adds a database back-end to the help system. But, its not a pretty name. I was thinking maybe "help_edit". What do you guys think? Are there any conventions to nameing modules other than all lowercase and underscores instead of spaces? I see in the current module list that some patterns are emerging (like taxonomy_ and node_), but is anything enforced? Thanks, Aran

3 4

[drupal-devel] it sure is quiet
by Ross Kendall 26 Feb '05

26 Feb '05

...with everyone but me in Belgium. I guess you are all having a great time. -sigh-

6 6