Option to disable printer friendly version for book module

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.

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...

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.

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?

^-- That was me. logged out for some reason

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

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

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 for a generic _link editor.

Levering this over to http://drupal.org/node/636