[drupal-devel] [feature] Option to disable printer friendly version
for book module
Bèr Kessels
drupal-devel at drupal.org
Fri Feb 18 11:29:50 UTC 2005
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
^-- That was me. logged out for some reason
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
--
View: http://drupal.org/node/13211
Edit: http://drupal.org/project/comments/add/13211
More information about the drupal-devel
mailing list