[drupal-devel] [feature] Option to disable printer friendly version
for book module
kbahey
drupal-devel at drupal.org
Mon Feb 28 17:24:57 UTC 2005
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: kbahey
Status: patch
+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).
kbahey
Previous comments:
------------------------------------------------------------------------
November 20, 2004 - 01: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 - 12:01 : kbahey
Setting status to patch, so that it is discussed on the mailing list.
------------------------------------------------------------------------
November 25, 2004 - 18: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 25, 2004 - 19: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 - 16: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 - 09: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 - 10: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 - 15: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 - 15: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 17, 2005 - 21: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 - 00: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 - 06: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 - 06:29 : Bèr Kessels
^-- That was me. logged out for some reason
------------------------------------------------------------------------
February 18, 2005 - 10: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 - 11: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 - 10: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 - 07: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 - 07:13 : Junyor
+1 for a generic _link editor.
More information about the drupal-devel
mailing list