- Development - lists.drupal.org

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

01 Mar '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 Levering this over to http://drupal.org/node/636 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 ------------------------------------------------------------------------ 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? ------------------------------------------------------------------------ February 28, 2005 - 13:13 : Junyor +1 for a generic _link editor. ------------------------------------------------------------------------ February 28, 2005 - 18:24 : kbahey +10 for a generic link editor too. Why solve it in book module only, and then solve it bit by bit in every module and every link. That would solve another problem I faced with image.module where there is a need to turn off the links at the bottom (e.g. when using ecommerce module).

1 0

[drupal-devel] db_rewrite_sql hook
by Chris Cook 01 Mar '05

01 Mar '05

The db_rewrite_sql hook is not yet documented at Drupaldocs. I'm trying to figure out the best way to fix taxonomy.module so that it only shows terms which are associated with nodes which the user has access to. Károly Négyesi's rewrite patch (http://drupal.org/node/16452) gets us part of the way but it seems that a db_rewrite_sql hook needs to be added to his patch. Is this something you can address, perhaps in a different patch if necessary, Károly?

2 2

[drupal-devel] [bug] SQL error when node_access is used
by tangent 01 Mar '05

01 Mar '05

Project: Drupal Version: cvs Component: taxonomy.module Category: bug reports Priority: critical Assigned to: Anonymous Reported by: tangent Updated by: tangent Status: patch Attachment: http://drupal.org/files/issues/nodeaccess.patch (1.21 KB) I am testing the nodeperm_role.module and I experienced an SQL error when node permissions are changed. The problem is that the query in question uses "INNER JOIN {term_node} USING (tid)" but the db_rewrite_sql() function adds another inner join in front of this one so the USING clause breaks. My patch changes all the USING statements to ON to prevent this. Perhaps the documentation for db_rewrite_sql() should be updated to warn against the use of the USING clause. I don't see any other instances of it in core but many contrib modules use it. tangent -- View: http://drupal.org/node/17794 Edit: http://drupal.org/project/comments/add/17794

2 2

[drupal-devel] [feature] Add support for generating an RSS 0.92 feed of news aggregator items
by playdreamer 28 Feb '05

28 Feb '05

Issue status update for http://drupal.org/node/9167 Project: Drupal Version: cvs Component: aggregator.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: blake7 Updated by: playdreamer Status: patch Thrilled I found this as its the one killer feature that the aggregator appeared to be missing. One point I notice though is that the title of the generated feed is 'drupal', when presumably it should pick up something along the lines of 'sitename news aggregator'. playdreamer Previous comments: ------------------------------------------------------------------------ July 9, 2004 - 04:11 : blake7 Attachment: http://drupal.org/files/issues/aggregator.module_0.patch (2.96 KB) The attached patch adds support for generating an RSS 0.92 feed of the default news aggregator page (the output of aggregator_page_last()). This allows re-use of the Drupal aggregator in other RSS readers like Trillian. The patch consists of the aggregator_page_rss() function which builds the XML output needed. It uses the existing RSS building functions already present to construct the feed. Note the comment about how many items are in the feed. In Drupal 4.4.x, there was a variable "aggregator_page_limit" which represented how many items were returned for both the HTML and RSS versions. It defaulted to 75 items. In Drupal CVS, all the HTML output is now paged through a hard-coded limit of 20 items per page. A limit of 20 seems small for the RSS feed, so I reverted to the old limit of 75. Would it be better to add a new variable like "aggregator_rss_limit"? Also, there are 2 places that the callback to aggregator_page_rss are installed. One is in _aggregator_page_list right before the pager output and shows up as the XML icon (like how the OPML feeds are linked now). The other is in aggregator_menu where I try and install a menu itme called "RSS feed". For some reason, the menu itme is not displaying itself though I believe I am inserting it properly. Feel free to contact me if there are any questions. Thanks! ------------------------------------------------------------------------ July 9, 2004 - 17:29 : blake7 Attachment: http://drupal.org/files/issues/aggregator.module_1.patch (2.54 KB) Fixed the navigation menu problems mentioned above. Please consider this patch instead of the first one. ------------------------------------------------------------------------ July 9, 2004 - 18:09 : drumm When this functionality is added it should be able to generate feeds for each aggregator category as well. ------------------------------------------------------------------------ July 10, 2004 - 01:22 : blake7 Attachment: http://drupal.org/files/issues/aggregator.module_2.patch (3.25 KB) Done. The attached patch supports RSS feeds of each aggregator category through the XML icon at the bottom exactly like the main aggregator page. ------------------------------------------------------------------------ July 10, 2004 - 12:01 : Dries 1. $base_url . "/aggregator" . $url is incorrect. All URLs must be constructed using url() as it is aware of clean URLs and path aliasing. 2. Emitting 75 RSS items is quite much (uncommon) and can easily turn into a bandwidth bottleneck. Can we add one global setting that controls how many entries our feed should have (not just the newly introduced feeds)? To 'export' your content in case you wish to migrate to another tool, a special value 'all' (say '1000000') might be handy. ------------------------------------------------------------------------ September 17, 2004 - 08:19 : blake7 Attachment: http://drupal.org/files/issues/aggregator.module_3.patch (4.47 KB) 1. Using url() now. 2. Added the presistent variable aggregator_rss_limit which controls how many RSS items are generated. A form_select edit control to control the new variable, with all defined as 1000000, was added to the configure tab. I am not sure what you mean by "our feeds" versus "newly introduced feeds" in your comment. Also, even though the code-freeze has taken place, do you think it would be possible to get this into Drupal 4.5? The code change is very minimal and I believe the ability to share aggregated feeds is a great feature. ------------------------------------------------------------------------ September 17, 2004 - 18:07 : Boris Mann +1 I actually assumed (there was much discussion?) that the re-exporting of aggregator items on a per-bundle basis was going to be enabled for 4.5. Let's get this in before the code freeze -- this would be a major feature announcement for 4.5, and could perform the basis for other great functionality for 4.6 (e.g. per category OPML file generation). ------------------------------------------------------------------------ October 22, 2004 - 18:20 : blake7 Now that 4.5 has released. Can this go into CVS/HEAD? Is there any other changes to the patch that need to be made by me to make that happen? Thanks. ------------------------------------------------------------------------ October 23, 2004 - 18:05 : Dries I'll look at it again. Does the patch add XML-icons or how do people find out about the RSS feeds? Can't we make the URLs a bit more intuitive? For example by making it so that you merely have to append '/rss.xml' to the aggregator module's URLs: foo.com/aggregator/rss.xml foo.com/aggregator/categories/1/rss.xml It is certainly not a requirement, just a thought that might be worth considering. ------------------------------------------------------------------------ October 23, 2004 - 18:15 : Dries I'll look at it again. Does the patch add XML-icons or how do people find out about the RSS feeds? Can't we make the URLs a bit more intuitive? For example by making it so that you merely have to append '/rss.xml' to the aggregator module's URLs: foo.com/aggregator/rss.xml foo.com/aggregator/categories/1/rss.xml It is certainly not a requirement, just a thought that might be worth considering. ------------------------------------------------------------------------ October 25, 2004 - 10:50 : Bèr Kessels cross linking to a [feature] that talks about such a unified rss link: http://drupal.org/node/11937 ------------------------------------------------------------------------ February 9, 2005 - 20:17 : sethcohn Bump. Neat feature, would be nice for 4.6 What's the progress on making it happen? ------------------------------------------------------------------------ February 9, 2005 - 20:43 : Boris Mann Here's another bump to this. I would say since it missed 4.5 (and was ready at the time) we get this in to 4.6. Should mesh nicely with walkah's RSS updates. Dries: there is an XML icon at the bottom of each category page, plus the HTML header can include an alternate link to the feed. I vote against any sort of "rss.xml", people can alias if they wish. (ideally we could get per-category OPML links as well, but I'll leave that for another feature request) ------------------------------------------------------------------------ February 10, 2005 - 14:58 : Bèr Kessels A request for unification of feeds [1] is waiting in the queue already. [1] http://drupal.org/node/11937 ------------------------------------------------------------------------ February 10, 2005 - 15:23 : Boris Mann This patch is not about "feed unification", it adds RSS feeds for category bundles...which have been asked about (and coded for, here in this patch) since 4.4.

1 0

[drupal-devel] A Drupal site with paid subscriptions?
by Julian Bond 28 Feb '05

28 Feb '05

Has anyone done any work on Drupal to enable a site where subscribed members (via Paypal subscriptions say) get an additional set of permissions? -- Julian Bond Email&MSM: julian.bond at voidstar.com Webmaster: http://www.ecademy.com/ Personal WebLog: http://www.voidstar.com/ M: +44 (0)77 5907 2173 T: +44 (0)192 0412 433 S: callto://julian.bond/

6 7

[drupal-devel] Re: New taxonomy_xml.module
by Sheldon Rampton 28 Feb '05

28 Feb '05

Dries wrote: >I just checked but both modules/wmfilter and modules/interwiki exist in >CVS ... Does this need further attention or action? Yes, further action IS needed. I just checked, and it appears that Neil Drumm renamed modules/wmfilter to modules/interwiki. That's all well and good. However, modules/interwiki doesn't currently appear in the public list of downloads on drupal.org, and modules/wmfilter *DOES* appear, at the following URL: http://drupal.org/node/14980 If you go to that page and click on "Download latest release," you get a tarbell that contains a GNU public license and nothing else. This needs to be fixed, perhaps by editing project node 14980 so it points to modules/interwiki instead of modules/wmfilter. Unfortunately, I can't do this myself. The project node was created by Aldon Hynes, so I don't have editing access to it. Also: What's the status of my taxonomy_xml.module? The URL for that project is: http://drupal.org/node/17918 Regards, Sheldon Rampton

2 1

[drupal-devel] Re: [drupal:unconed] /modules user.module
by Dries Buytaert 28 Feb '05

28 Feb '05

drupal-devel(a)drupal.org wrote: > User: unconed Branch: HEAD Date: Mon, 28 Feb 2005 18:13:13 +0000 > > Modified files: > /modules user.module > > Log message: > - Delete a user's sessions when blocking his/her account. > > Links: > http://cvs.drupal.org/diff.php?path=drupal/modules/user.module&old=1.444&ne… That change looks incorrect! You are using $user (twice) instead of $account. -- Dries Buytaert :: http://www.buytaert.net/

1 0

[drupal-devel] Re: [drupal:unconed] /database updates.inc /includes session.inc /modules node.module search.module
by Dries Buytaert 28 Feb '05

28 Feb '05

drupal-devel(a)drupal.org wrote: > User: unconed Branch: HEAD Date: Mon, 28 Feb 2005 18:00:59 +0000 > > Modified files: > /database updates.inc > /includes session.inc > /modules node.module search.module > > Log message: > #17747: PGSQL improvements http://cvs.drupal.org/viewcvs/drupal/drupal/includes/session.inc?r1=1.11&r2… I don't understand this change. The $user object is only initialized later on in sess_read(). See also my concern in project issue #17747. -- Dries Buytaert :: http://www.buytaert.net/

1 0

[drupal-devel] [Fwd: [drupal.org] moviereview.module - New]
by Dries Buytaert 28 Feb '05

28 Feb '05

-------- Original Message -------- Subject: [drupal.org] moviereview.module - New Date: 27 Feb 2005 22:49:04 -0000 From: emiliano(a)opiniaopublica.com Dries, Emiliano (http://drupal.org/user/16470) has sent you a message via your contact form (http://drupal.org/user/1/contact) at drupal.org. If you don't want to receive such e-mails, you can change your settings at http://drupal.org/user/1. Message: Hello Dries! How are you doing? I'm writing you because I've just adapted book review module to a movie review module. Since I'm not a PHP programmer, the only thing I can do is update this module everytime bookreview.module gets updated. :-) I'm saying all this because I don't know if you are interested in having it published or not. You may see it in action here: http://www.novayork.com/index.php?q=moviereview If you know someone who might maintain this module, no problem for me, really. If nobody can and you think it's good to make it available, whenever bookreview gets updated I update moviereview.... Thansk, Regards, Emiliano. -- Dries Buytaert :: http://www.buytaert.net/

4 4

[drupal-devel] Remove menu item
by Maykel Moya 28 Feb '05

28 Feb '05

I'd been playing with a module that creates aditional URLS. As per 'Module's developer manual' I'd implemente the _menu hook. But, this way, an item is added to the navigation menu. How can I get rid of it ? Regards, maykel -- ,''`. Debian GNU/Linux : :' : The universal & free Operating System `. `' http://www.debian.org/ `-

3 2