Closed (won't fix)
Project:
Drupal core
Version:
7.x-dev
Component:
book.module
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
2 Sep 2005 at 18:46 UTC
Updated:
27 Apr 2009 at 15:20 UTC
Jump to comment: Most recent file
Comments
Comment #1
buddaGood idea! +1
Comment #2
puregin commentedChanging the status to indicate that there is a patch. This is very unlikely to apply, though.
Also changing the version to CVS.
Though the functionality seems like it might be useful, I'm not really keen on the way this is done in this patch. Somewhat like the idea of automagically doing section numbering, this seems like something that should perhaps be done through some kind of template expansion (like having a theme for printer output???)
Comment #3
Tobias Maier commented-1 for using
<table>to format things.please use
<div>Comment #4
Jaza commentedMakes sense to me. +1. Moving to 6.x-dev queue.
Comment #5
catchWould also support this, bumping another version though and this has no relationship to book.module as it currently stands.
Comment #6
mr.baileysI think this is related to the book module, as the book module has the "printer-friendly export"-function which uses the
book_export_html-template to render the entire page.book_export_htmldoes not currently include the footer message.Patch attached hands the site_footer variable to the
book-export-htmltemplate (and prints it at the bottom)Comment #7
dmitrig01 commentedTested, code style looks good.
Comment #8
webchickHm. Unless I'm mistaken, this new variable needs to be added to the arguments list in book_theme().
Other than that, looks great.
Comment #9
dmitrig01 commentedYeah, you're mistaken ;-). Only the variables that are passed in need to be declared.
Comment #10
dries commentedIn another issue, I suggested that we removed "site_footer". People should be able to create a block and create a footer that way. Using a block, you can also have it show up on printer-friendly pages.
We're also moving the mission statement and the context-sensitive help text to blocks so the site footer will soon be the one-off exception ... I think it makes more sense to mark this "won't fix".
Thoughts?
Comment #11
webchickThe only thing that makes me a little bit nervous about a won't fix is that #92895: Drupal System Blocks - Including header, footer and content into the block system doesn't have a patch yet and at #428800-24: Convert mission statements to a region with blocks Gábor indicates that while converting the footer message to a block is planned, it's not yet on the docket. And regardless of implementation details, it seems like there's still value in special-casing the footer message in this template; blindly printing out the $footer region might get you Google Adsense ads or the Powered By Drupal block or any number of other things you don't want on printer-friendly pages.
I don't really see the harm in committing this patch now since it is ready. The eventual patch that makes site footer a block, assuming it's ready in time for 7.x code freeze, could simply change the filter_xss_admin(variable_get('site_footer', FALSE)); to a call to render the site footer message block.
I'll let you make the call though. :)
Comment #12
gábor hojtsy@webchick: Not sure why you picked #92895: Drupal System Blocks - Including header, footer and content into the block system from the many issues around "system blocks". I've marked it as duplicate on other issues, mainly #428744: Make the main page content a real block which has a patch and is subject to a hot discussion :) I am cooking three patches at the same time, all of which touch similar code areas (they all add the same numbered update function or modify the same core install profiles for example :). So juggling the fourth patch (footer message) is not immediately on the plan. It does not mean that once one or more of these three patches are committed, I am not picking that up.
Anyway, the "site footer message" block is not gonna be any special block whatsoever, it is gonna be a "#block-block-13" kind of block, ie. a custom block you'd happen to configure to show up in the footer. It would not differ from any other custom block you'd put into the footer. In fact, it is only gonna be there, if you've run a previous Drupal version before, and your data was migrated, otherwise there will be no footer message block on your site.
What the patch does is completely achievable with a preprocess function and a template override, so it is not like we make this impossible if we don't get this patch committed. People use the footer message for all kinds of neatness, and they might not want to see that show up in the printer friendly export output. I'd argue that Drupal's printer friendly output is so bland anyways, that it needs some touchup on a site-by-site basis (in terms of templates and or CSS) anyway.
I'd suggest a won't fix.
Comment #13
webchickOk, fair enough. :) Thanks for the summary of the block master plan.
And that first issue was just what came up when I searched for 'site_footer'. :)