May 2005 - Development - lists.drupal.org

[drupal-devel] [task] Performance issues with path aliases
by killes 08 May '05

08 May '05

Issue status update for http://drupal.org/node/22035 Project: Drupal -Version: 4.6.0 +Version: cvs Component: base system Category: tasks Priority: normal Assigned to: Anonymous Reported by: mikeryan Updated by: killes(a)www.drop.org -Status: active +Status: patch Attachment: http://drupal.org/files/issues/pathalias.patch (4.98 KB) I've merged the patch into one. Much more convenient. I also changed it to cvs as only there new features will be added. Upgrade path needs to be added. Mike, can you run some more tests? We are especially interested in "hard" data ie numbers with possibly error bars. it would be interesting to know how this patch affects sites that have only a few path aliases vs those with a lot of them. Also, how pages with a lot of node links (tracker) are affected. It might be worthwhile to add static caching in drupal_get_normal_path if it gets calle dmore than once for a link on one page view. killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ May 5, 2005 - 03:10 : mikeryan See Investigate use of conf_url_rewrite [1] for context... The current core support for translating incoming path aliases to the internal Drupal path (drupal_get_path_alias) and substituting aliases when generating links to internal paths (drupal_get_normal_path) does not scale well with many aliases. The ease with which pathauto enables site administrators to generate large numbers of aliases exposes this issue, but it is inherent in the core implementation, because drupal_get_path_map reads in the entire url_alias table at bootstrap time. I'd like to discuss ideas on how to improve the performance... Most obviously, why not simply query the url_alias table as needed instead of loading the whole table? In the incoming case, only a single simple SELECT is necessary, which will always be more efficient than reading the table. In the outgoing case, there might be some slight performance advantage to caching the table with a small number of aliases, but the disadvantage can become huge as the alias table grows. One note - I've noticed that the src column in url_alias is not indexed, I think adding an index should significantly help the performance in the outgoing case if we were to do individual SELECTs. Any other thoughts? [1] http://drupal.org/node/21938 ------------------------------------------------------------------------ May 5, 2005 - 04:02 : mikeryan Attachment: http://drupal.org/files/issues/bootstrap.inc_2.patch (1.06 KB) What the hell, I went ahead and gave it a shot... On my home system, where I'm testing out 4.6.0, page loads have been taking several seconds, which I attributed to the fact that it's an old computer and I'm multi-tasking like crazy. I implemented my own suggestion, and now pages load in about one second, it makes an incredible difference (FWIW, my url_alias table has over 4000 rows). Patches attached, go give it a try... ------------------------------------------------------------------------ May 5, 2005 - 04:02 : mikeryan Attachment: http://drupal.org/files/issues/common.inc_11.patch (723 bytes) One attachment per note, that's tedious... ------------------------------------------------------------------------ May 5, 2005 - 04:03 : mikeryan Attachment: http://drupal.org/files/issues/path.module_0.patch (1.34 KB) ------------------------------------------------------------------------ May 5, 2005 - 04:03 : mikeryan Attachment: http://drupal.org/files/issues/database.mysql_4.patch (553 bytes) ------------------------------------------------------------------------ May 5, 2005 - 04:04 : mikeryan Attachment: http://drupal.org/files/issues/database.pgsql_2.patch (502 bytes) ------------------------------------------------------------------------ May 5, 2005 - 04:07 : mikeryan Note: I just noticed that the database.*sql patches showed an extra diff (not mine) to the location field in locales_source. I did my diffs against a freshly-updated DRUPAL-4-6, and had made the edits against a release from a few days ago... Those locales_source changes should probably be removed from my patches before applying. ------------------------------------------------------------------------ May 8, 2005 - 01:13 : mikeryan I upgraded Fenway Views [2] to Drupal 4.6.0 today, incorporating these patches. Performance is very noticeably improved. [2] http://fenway-views.com/

1 0

[drupal-devel] [feature] Order taxonomy terms by vocabulary weight, then term weight
by grohk 08 May '05

08 May '05

Issue status update for http://drupal.org/node/7684 Project: Drupal Version: cvs Component: taxonomy.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: MrRoot Updated by: grohk -Status: active +Status: patch Attachment: http://drupal.org/files/issues/taxonomy_vocab_weight.patch (901 bytes) I have been looking for this funtionality for a long time, so I have attempted to bring this patch up-to-date and clean it up as per the suggestions. grohk Previous comments: ------------------------------------------------------------------------ May 10, 2004 - 21:33 : MrRoot Attachment: http://drupal.org/files/issues/taxonomy.module_2.patch (866 bytes) This is a trivial patch to the taxonomy_node_get_terms() function. Currently, it was only sorting the results by term weight; the patch joins in the vocabulary table and adds the vocabulary weight as a second preference ordering. I wrote this because I wanted to force ordering of vocabularies when listing the taxonomies of a node using the taxonomy_link() function. Basically, what I was doing was this: I created a "Story Type" vocab which described the overall *type* of post ( News, Rant, Review, ... ) and a "Topic" vocab which described the *topic* of the post ( Programming, Math, Political, Family, ... ). Now, when you added a new story, you picked a Story Type and a Topic. When the story is displayed, it shows the taxonomy assignments as a list of links. The ordering of that list was by term weight, term name. That meant that if I wanted to control the left to right layout of that information, I'd have to set the weight on every term in each vocabulary. That seemed tedious, especially since the vocabularies themselves already had a weight associated with them. Hence, I dug around for about 15 minutes and wrote this patch. It's been tested and seems to work quite well. I can now *force* which taxonomy vocabulary is listed when, and thereby always make the posts appear as "Story Type | Topic". Hope it's useful.. :) ------------------------------------------------------------------------ May 10, 2004 - 21:40 : MrRoot Ack - that patchfile was generated against the current CVS tree, so I suppose the Version should have been 'cvs'? Sorry about that if it was misplaced. ------------------------------------------------------------------------ May 10, 2004 - 22:48 : moshe weitzman this patch makes a lot of sense ... however, your sql is non standard for drupal. we use the x JOIN y ON x.field = y.field syntax. Your SQL doe snot use this JOIN syntax. Please resubmit and then I'll bet that this will be accepted into core. ------------------------------------------------------------------------ May 10, 2004 - 23:47 : MrRoot Attachment: http://drupal.org/files/issues/taxonomy.module_3.patch (872 bytes) Ah.. I was wondering about that.. Looks like most of the rest of taxonomy.module does not make use of JOIN statements. So I was following that. Anyhow, I updated the patch to use JOIN on all of the tables. Cheers ------------------------------------------------------------------------ May 11, 2004 - 16:15 : Dries Is that ANSI SQL? If these are 'left' joins, please use 'LEFT JOIN'. If these are 'inner' joins, please use 'INNER JOIN'. Also, I'd add a small comment to code to explain the rationale behind that query. ------------------------------------------------------------------------ August 12, 2004 - 11:28 : killes(a)www.drop.org Patch doesn't apply.

1 0

[drupal-devel] [bug] Missing ) in locale.inc
by robertDouglass 08 May '05

08 May '05

Issue status update for http://drupal.org/node/22307 Project: Drupal Version: cvs Component: locale.module Category: bug reports Priority: critical Assigned to: Anonymous Reported by: robertDouglass Updated by: robertDouglass Status: patch Attachment: http://drupal.org/files/issues/locale.inc.patch.txt (1.11 KB) missing ) - syntax error. patch might not apply (was full of false character recognition problems), so please just update manually in that case. robertDouglass

2 1

[drupal-devel] PHPTemplate hits core ... finally
by Dries Buytaert 08 May '05

08 May '05

Some changes: 1. I committed the PHPTemplate engine to core and removed the XTemplate engine from core. 2. I replaced the XTemplate-based version of Bluemarine with the PHPTemplate-based version. 3. I moved the XTemplate engine and the Pushbutton theme to the contributions repository. (For almost 2 years XTemplate has been part of Drupal core.) Some TODO-list items: 1. Figure out the menu configuration. High priority. 2. Add one more PHPTemplate-based theme to core. Medium priority. Thanks Adrian et al, -- Dries Buytaert :: http://www.buytaert.net/

15 35

[drupal-devel] [bug] Field location in table locales_source is too short in PostgreSQL
by patryk 08 May '05

08 May '05

Issue status update for http://drupal.org/node/21252 Project: Drupal Version: cvs Component: postgresql database Category: bug reports Priority: normal Assigned to: patryk Reported by: patryk Updated by: patryk Status: patch Attachment: http://drupal.org/files/issues/drupal-cvs-pgsql-locales_field_type-fix.diff (317 bytes) Field "location" in table "locales_source" is too short. The patch makes it limitless. patryk

5 12

[drupal-devel] [bug] Missing aggregate field crashes pgsql in statistics.module
by patryk 07 May '05

07 May '05

Issue status update for http://drupal.org/node/22264 Project: Drupal Version: cvs Component: postgresql database Category: bug reports Priority: critical Assigned to: patryk Reported by: patryk Updated by: patryk Status: patch Attachment: http://drupal.org/files/issues/drupal-cvs-pgsql_stats-fix.diff (468 bytes) Another time: wrong GROUP BY statement crashes PostgreSQL. Does really MySQL allows such brain-damaged things? patryk

1 0

[drupal-devel] [bug] Strange markup in book render functions
by puregin 07 May '05

07 May '05

Issue status update for http://drupal.org/node/1898 Project: Drupal Version: cvs Component: book.module Category: bug reports Priority: critical Assigned to: puregin Reported by: kika Updated by: puregin Status: patch Sorry, I replied to the last post on the list - I'll include the post here for the record, and expand a little. Steven, I think that the issue you're addressing is actually a different one than I am trying to fix in my patch, which addresses how sections are wrapped. My patch would still allow users to write headers in their book pages - it would then be up to post-processing - or something like your approach - to deal with how embedded headers are dealt with. Perhaps we should take up your suggestion in another of the book.module issues dealing with the sequences of headers? How about http://drupal.org/node/8049, or http://drupal.org/node/4118? With respect to your suggestion - I understand now that you're proposing to apply the re-writing only to the printer-friendly output. I'm conflicted about this idea - on the one hand, the output which it produces is clearly an improvement over the present output. On the other hand, it changes what the user types to make it 'right' - I guess this is in the long tradition of HTML being interpreted very forgivingly by web-browsers and other applications. On the balance, I support your idea - I guess it's in the spirit of 'make things easier for the user'. With respect to the actual code - I don't think it will handle the case where h2, h3, and h4 are all used in the text, but the sequence h2, h4 occurs. To put it another way, the problem of checking whether headers are in a legal sequence is context sensitive, while a regular-expression search and replace (even if the replacement sequence remaps the targets) is context-free. When I say legal sequence, I mean legal in terms of book hierarchy, not in terms of the XHTML definition, which doesn't address hierarchy, because headers are titles, not sectional elements. SGML/XML publishing DTDs define such things via inclusion/exclusion on true sectional elements) The case I described is, admittedly, a relatively infrequent occurrence, and the general solution would be way to difficult to deal with - it would involve constructing and manipulating a DOM, or something along those lines. Ugh! Djun puregin Previous comments: ------------------------------------------------------------------------ June 9, 2003 - 14:06 : kika Snippet from book_render(): $output .= "<dt>". l($node->title, "node/view/$node->nid") ."</dt><dd>". book_body($node) ."<br /><br /></dd>"; Is using definition list here is really correct? This should be replaced with appropiate div's or even better, funnel through theme() Same goes for the function book_print(): $output .= "$node->title"; if ($node->body) { $output .= "<ul>". book_body($node) ."</ul>"; } Why wrap body inside <ul>? ------------------------------------------------------------------------ June 10, 2003 - 16:31 : al Yeah, it's all nasty. I patched this ages ago, but no one seemed interested. The patch now won't apply due to all the changes since then. I'm on this - expect a new patch to hit my sandbox shortly. ------------------------------------------------------------------------ June 10, 2003 - 22:03 : ax please remove the superfluous <ul>s and <li> [1], too. to solve the problem of invalid nested <hx> tags, maybe we should change <h$depth> to <h1 class="book-h$depth">? this way, we could use <h2> - <h6> in book pages. alternatively, we should only use <h5> and <h6> in book pages - we shouldn't have nestings deeper than 4 in printed books, then. additionally, i think it would be a good idea to add id's to all book headings so they can be jumped to via fragment identifiers (url#fragment-identifier). i often wish this would be possible when referencing the last paragraph of a long page of documentation ... these id's should be of the form <hx id="foo" name="foo"> [2], with foo probably being the node-id of the single book page. adding id's to headings would also be a good idea for headings / sections in single book nodes. for example, it would be nice if i could link to list point 10 in the drupal installation instructions [3] via something like url#10. these id's had to be added manually. the question is: how can these id's be named to be unique within a /printed/ book? probably <node_id>_<section_id> ... [1] [ [drupal-devel] Drupal handbook formatting and heading tags | http://lists.drupal.org/pipermail/drupal-devel/2003-June/025860.html ] [2] [ XHTML Spec, HTML Compatibility Guidelines, Fragment Identifiers | http://www.w3.org/TR/xhtml1/#C_8 ] [3] http://drupal.org/node/view/260 ------------------------------------------------------------------------ June 15, 2003 - 06:23 : al Fixed in latest CVS. Uses all of Ax's suggestions: - <h1 class="depthX"> - Fixed to use CSS rather than tables. - Changes link at top to standard "breadcrumb" style, rather than hierarchy in tree view. - Removes odd and superfluous <ul> tags and the like. - Makes printed docs have proper <html> and <body> wrapping, etc. ------------------------------------------------------------------------ May 4, 2005 - 23:20 : puregin I'm re-opening this, because the problem persists in CVS. 1) The current CVS version (1.288.2.4) of book module still wraps $node->body in an <ul> element in book_print_recurse(). This produces non-conformant HTML. I'm not sure why this was done in the first place - I'm guessing someone wanted to insulate from having bad markup in a book page throw off the enclosing page. Getting rid of the offending UL tags is a one-line solution, but what is the right thing to do here? I'd like to see something very structural - wrapping the /entire/ output (including the generated sectional header) of the book_print_recurse() wrapped in a <div> element. This will properly nest true structural sections, making the structure accessible to applications via DOM. It will also make it easier to use XSLT, for example, to transform into various XML based export formats, for example. Any reason not to do so? Also... when we get the 'printer-friendly' version of a page, the subtree rooted at that page is returned, and the root page is marked up with a class="book-h1". Is there any reason why we don't compute the depth of the root page, and use that to generate the "in-place" header? In other words, if a section is "book-h3" relative to the top-level book, shouldn't it be "book-h3" whenever it is viewed? In this case, we could apply the same principal to generating the <div> tags around each section. ------------------------------------------------------------------------ May 5, 2005 - 14:58 : puregin Attachment: http://drupal.org/files/issues/book_printer_friendly_div.patch (1.57 KB) I am attaching a patch which fixes improper printer-friendly output, as discussed. The patch fixes book_print and book_print_recurse() to insert a <div> start tag before emitting the header, and to close this after subsections have been recursively generated. The <div> tag has an id attribute of the form id="sect-123", where the node's nid is 123, and a class attribute of form class="sect/n/" where the depth of the section is /n/. I'm marking this issue as critical, since the present HTML output plays havoc with any attempts at sane PDF generation. I will address the issue of where printer-friendly subsections should be 'rooted' in a follow-up. Djun ------------------------------------------------------------------------ May 6, 2005 - 00:53 : Dries Let's not abbreviate 'section' to 'sect'. Also, we use '-' to separate words in CSS names. - If the section ID uses the node ID, maybe we should use 'node-' instead of 'sect-'? - If the class uses depth, maybe we should use 'depth-' instead of 'sect'? The same is true for your other patch where you suggest to use 'n'. Better to make that 'node-'. (Feel free to merge both patches.) Looks like the book.module generates a _lot_ of CSS IDs/classes. If the introduction of these new IDs/classes allows us to remove some of the existing IDs/classes, please do. ------------------------------------------------------------------------ May 6, 2005 - 20:26 : Steven Here's my idea.. why not use regular h tags for the book structure, and renumber the header tags in the content, starting one level after the current book depth? Here's a function which does this: <?php function fix_up_headers($text, $level = 1) { // Find all header tags that are used (if any) if (preg_match_all('/<h[0-9]+/i', $text, $tags) == 0) { return $text; } // Discard duplicates and sort them by number $tags = array_unique(array_map('strtolower', $tags[0])); natsort($tags); // Renumber them and replace them $i = $level; foreach ($tags as $tag) { $from[] = '@'. preg_quote($tag) .'(?![0-9])@i'; $from[] = '@'. preg_quote(str_replace('<', '</', $tag)) .'(?![0-9])@i'; $to[] = '<h'. $i; $to[] = '</h'. $i; $i++; } $text = preg_replace($from, $to, $text); // Change level 7 headers and higher to divs. return preg_replace(array('!<h([7-9]|[1-9][0-9]+)!i', '!</h([7-9]|[1-9][0-9]+)!i'), array('<div class="header-\1"', '</div'), $text); } ?> That way you can use header tags safely in the content (which is useful in the context of a single page) without messing up the book output. ------------------------------------------------------------------------ May 6, 2005 - 23:50 : puregin Attachment: http://drupal.org/files/issues/02_book_printer_friendly_div.patch (1.78 KB) The attached patch changes the div id to the form 'node-123'. I was concerned that a document fragment might be created with both a book section and a non-book section from the same node, leading to non-unique id's, but at this point it seems like an unlikely scenario. I've changed 'class=sect1' to 'class=section-1'. I was trying to be lazy and use the DocBook section name convention to make XSLT conversion a little easier, but it's really not saving any effort, in the end, and this is clearer. I think 'section' rather than 'depth' is appropriate - it describes what the role of the div element is. I've closed the other issue regarding id's in header elements, because I've replaced the whole 'class="book-hx"' business in headers with 'class="book-header"'. Since the level can now be selected by context with respect to the enclosing div, separate classes for headers are not required. That is, we can style with CSS like the following: .section-1 h1.book-header { font-weight: bold; font-size: 2.2em; } .section-2 h1.book-header { font-size: 2em; } .section-1 p { text-align: justified; } .section-3 p { margin-left: 3em; margin-right: 3em; } Note that the section-2 h1 will be bold, since the section-2 div is nested within the section-1 div. Also, all paragraphs regardless of section will be justified; and section-3 paragraphs will be indented left and right. Because we can style /everything/ by section, not just headers, and because the styling specifications respect the sectional hierarchy, it's possible to create very elegant and sophisticated book pages with very little CSS. Even I can do it! :) I'm definitely *not* a designer, but I've played around a bit with this - have a look at http://www.puregin.org/book/print/129 for an example. I will attach patches for misc/print.css and misc/drupal.css separately. I don't understand why, but the present version (cvs) of these files has all of the h1.book-hx selectors in drupal.css - the printer-friendly page actually looks at print.css. Am I missing something? For the record, this approach seems to have been suggested by clairem in http://drupal.org/node/8049 where I have a little rant about headings in book pages. Twice :) Djun ------------------------------------------------------------------------ May 7, 2005 - 00:10 : puregin Steven - that's a neat idea, and very clever, clean code! But it still doesn't catch problems such as, for example, an h5 inside of an h1 section with no intervening h2..h4 headers, or? I'm inclined to be a bit suspicious of the approach, though - I rather think it's 'doing magic behind the user's back'. If people are going to insist on putting headings inside of pages, it should be possible. And it would be odd for users to discover that what they typed isn't what they get. ------------------------------------------------------------------------ May 7, 2005 - 00:32 : puregin Attachment: http://drupal.org/files/issues/print_css_div.patch (1.36 KB) Here's the patch for print.css. There's a couple of commented-out lines - these show how to make section headings 'run in' as part of the following paragraph (or other inline element). I am assuming that print.css is supposed to be something of an example that people would use to experiment with? Please feel free to improve this in any way - as I said, I'm far from being a graphic designer, and I'm also not really sure what the intention of this file is. ------------------------------------------------------------------------ May 7, 2005 - 10:40 : Steven Puregin: nope, the code correctly handles missing h numbers. If the book page only uses h2, then that will be the first new level. If it uses h2 and h4, and it is inside a 3rd level book page for example (whose title would be h3), they they get renumbered to respectively h4 and h5 (no missing number). >From a semantic point of view it is crazy not to use h# for book titles. ------------------------------------------------------------------------ May 7, 2005 - 10:44 : Steven A bit more verbose: I think the overwhelming majority of users browse a book on the site itself. Within a single page, there is a h1 tag for the page title. So it makes sense for a writer to use h2, h3, etc inside a single page. This is semantically valid HTML. On the other hand, the print output places the content in a whole new context. I would expect the book module to take whatever steps necessary 'behind the user's back' to ensure it displays correctly.

1 0

[drupal-devel] [bug] Error on user_save
by robertDouglass 07 May '05

07 May '05

Issue status update for http://drupal.org/node/22262 Project: Drupal Version: cvs Component: user.module Category: bug reports Priority: critical Assigned to: Anonymous Reported by: robertDouglass Updated by: robertDouglass Status: patch Attachment: http://drupal.org/files/issues/user_save.patch.txt (562 bytes) Extra comma caused SQL error robertDouglass

1 0

[drupal-devel] phptemplate in core?
by Dries Buytaert 07 May '05

07 May '05

Adrian et al, here is what I'd like to see happen: get PHPTemplate in core. We'd need to: 1. remove Xtemplate from core. 2. remove the Bluemarine theme from core (Xtemplate based). 3. remove the Pushbutton theme from core (Xtemplate based). 4. add PHPTemplate to core. 5. add a PHPTemplate-based theme to core. Steps 1, 2 and 3 are easy. Steps 4 and 5 need to be discussed. - What needs to be done to get PHPTemplate in core? From what I can tell, PHPTemplate's engine-specific settings (eg. the primary and secondary links) need some work. - What PHPTemplate-based theme should we ship with core? Should we port either Bluemarine or Pushbutton to PHPTemplate or should we go with fresh themes? My requirements for such theme would be: 1. The theme must validate as XHTML. 2. The theme's CSS classes/IDs must comply Drupal's naming conventions. 3. The theme should work on all browsers without hacks. 4. The theme should be simple and easy to customize. No themes with a bazillion of small images that no one will ever change. -- Dries Buytaert :: http://www.buytaert.net/

21 46

[drupal-devel] [bug] Strange markup in book render functions
by Steven 07 May '05

07 May '05

Issue status update for http://drupal.org/node/1898 Project: Drupal Version: cvs Component: book.module Category: bug reports Priority: critical Assigned to: puregin Reported by: kika Updated by: Steven Status: patch Puregin: nope, the code correctly handles missing h numbers. If the book page only uses h2, then that will be the first new level. If it uses h2 and h4, and it is inside a 3rd level book page for example (whose title would be h3), they they get renumbered to respectively h4 and h5 (no missing number). >From a semantic point of view it is crazy not to use h# for book titles. Steven Previous comments: ------------------------------------------------------------------------ June 10, 2003 - 00:06 : kika Snippet from book_render(): $output .= "<dt>". l($node->title, "node/view/$node->nid") ."</dt><dd>". book_body($node) ."<br /><br /></dd>"; Is using definition list here is really correct? This should be replaced with appropiate div's or even better, funnel through theme() Same goes for the function book_print(): $output .= "$node->title"; if ($node->body) { $output .= "<ul>". book_body($node) ."</ul>"; } Why wrap body inside <ul>? ------------------------------------------------------------------------ June 11, 2003 - 02:31 : al Yeah, it's all nasty. I patched this ages ago, but no one seemed interested. The patch now won't apply due to all the changes since then. I'm on this - expect a new patch to hit my sandbox shortly. ------------------------------------------------------------------------ June 11, 2003 - 08:03 : ax please remove the superfluous <ul>s and <li> [1], too. to solve the problem of invalid nested <hx> tags, maybe we should change <h$depth> to <h1 class="book-h$depth">? this way, we could use <h2> - <h6> in book pages. alternatively, we should only use <h5> and <h6> in book pages - we shouldn't have nestings deeper than 4 in printed books, then. additionally, i think it would be a good idea to add id's to all book headings so they can be jumped to via fragment identifiers (url#fragment-identifier). i often wish this would be possible when referencing the last paragraph of a long page of documentation ... these id's should be of the form <hx id="foo" name="foo"> [2], with foo probably being the node-id of the single book page. adding id's to headings would also be a good idea for headings / sections in single book nodes. for example, it would be nice if i could link to list point 10 in the drupal installation instructions [3] via something like url#10. these id's had to be added manually. the question is: how can these id's be named to be unique within a /printed/ book? probably <node_id>_<section_id> ... [1] [ [drupal-devel] Drupal handbook formatting and heading tags | http://lists.drupal.org/pipermail/drupal-devel/2003-June/025860.html ] [2] [ XHTML Spec, HTML Compatibility Guidelines, Fragment Identifiers | http://www.w3.org/TR/xhtml1/#C_8 ] [3] http://drupal.org/node/view/260 ------------------------------------------------------------------------ June 15, 2003 - 16:23 : al Fixed in latest CVS. Uses all of Ax's suggestions: - <h1 class="depthX"> - Fixed to use CSS rather than tables. - Changes link at top to standard "breadcrumb" style, rather than hierarchy in tree view. - Removes odd and superfluous <ul> tags and the like. - Makes printed docs have proper <html> and <body> wrapping, etc. ------------------------------------------------------------------------ May 5, 2005 - 09:20 : puregin I'm re-opening this, because the problem persists in CVS. 1) The current CVS version (1.288.2.4) of book module still wraps $node->body in an <ul> element in book_print_recurse(). This produces non-conformant HTML. I'm not sure why this was done in the first place - I'm guessing someone wanted to insulate from having bad markup in a book page throw off the enclosing page. Getting rid of the offending UL tags is a one-line solution, but what is the right thing to do here? I'd like to see something very structural - wrapping the /entire/ output (including the generated sectional header) of the book_print_recurse() wrapped in a <div> element. This will properly nest true structural sections, making the structure accessible to applications via DOM. It will also make it easier to use XSLT, for example, to transform into various XML based export formats, for example. Any reason not to do so? Also... when we get the 'printer-friendly' version of a page, the subtree rooted at that page is returned, and the root page is marked up with a class="book-h1". Is there any reason why we don't compute the depth of the root page, and use that to generate the "in-place" header? In other words, if a section is "book-h3" relative to the top-level book, shouldn't it be "book-h3" whenever it is viewed? In this case, we could apply the same principal to generating the <div> tags around each section. ------------------------------------------------------------------------ May 6, 2005 - 00:58 : puregin Attachment: http://drupal.org/files/issues/book_printer_friendly_div.patch (1.57 KB) I am attaching a patch which fixes improper printer-friendly output, as discussed. The patch fixes book_print and book_print_recurse() to insert a <div> start tag before emitting the header, and to close this after subsections have been recursively generated. The <div> tag has an id attribute of the form id="sect-123", where the node's nid is 123, and a class attribute of form class="sect/n/" where the depth of the section is /n/. I'm marking this issue as critical, since the present HTML output plays havoc with any attempts at sane PDF generation. I will address the issue of where printer-friendly subsections should be 'rooted' in a follow-up. Djun ------------------------------------------------------------------------ May 6, 2005 - 10:53 : Dries Let's not abbreviate 'section' to 'sect'. Also, we use '-' to separate words in CSS names. - If the section ID uses the node ID, maybe we should use 'node-' instead of 'sect-'? - If the class uses depth, maybe we should use 'depth-' instead of 'sect'? The same is true for your other patch where you suggest to use 'n'. Better to make that 'node-'. (Feel free to merge both patches.) Looks like the book.module generates a _lot_ of CSS IDs/classes. If the introduction of these new IDs/classes allows us to remove some of the existing IDs/classes, please do. ------------------------------------------------------------------------ May 7, 2005 - 06:26 : Steven Here's my idea.. why not use regular h tags for the book structure, and renumber the header tags in the content, starting one level after the current book depth? Here's a function which does this: <?php function fix_up_headers($text, $level = 1) { // Find all header tags that are used (if any) if (preg_match_all('/<h[0-9]+/i', $text, $tags) == 0) { return $text; } // Discard duplicates and sort them by number $tags = array_unique(array_map('strtolower', $tags[0])); natsort($tags); // Renumber them and replace them $i = $level; foreach ($tags as $tag) { $from[] = '@'. preg_quote($tag) .'(?![0-9])@i'; $from[] = '@'. preg_quote(str_replace('<', '</', $tag)) .'(?![0-9])@i'; $to[] = '<h'. $i; $to[] = '</h'. $i; $i++; } $text = preg_replace($from, $to, $text); // Change level 7 headers and higher to divs. return preg_replace(array('!<h([7-9]|[1-9][0-9]+)!i', '!</h([7-9]|[1-9][0-9]+)!i'), array('<div class="header-\1"', '</div'), $text); } ?> That way you can use header tags safely in the content (which is useful in the context of a single page) without messing up the book output. ------------------------------------------------------------------------ May 7, 2005 - 09:50 : puregin Attachment: http://drupal.org/files/issues/02_book_printer_friendly_div.patch (1.78 KB) The attached patch changes the div id to the form 'node-123'. I was concerned that a document fragment might be created with both a book section and a non-book section from the same node, leading to non-unique id's, but at this point it seems like an unlikely scenario. I've changed 'class=sect1' to 'class=section-1'. I was trying to be lazy and use the DocBook section name convention to make XSLT conversion a little easier, but it's really not saving any effort, in the end, and this is clearer. I think 'section' rather than 'depth' is appropriate - it describes what the role of the div element is. I've closed the other issue regarding id's in header elements, because I've replaced the whole 'class="book-hx"' business in headers with 'class="book-header"'. Since the level can now be selected by context with respect to the enclosing div, separate classes for headers are not required. That is, we can style with CSS like the following: .section-1 h1.book-header { font-weight: bold; font-size: 2.2em; } .section-2 h1.book-header { font-size: 2em; } .section-1 p { text-align: justified; } .section-3 p { margin-left: 3em; margin-right: 3em; } Note that the section-2 h1 will be bold, since the section-2 div is nested within the section-1 div. Also, all paragraphs regardless of section will be justified; and section-3 paragraphs will be indented left and right. Because we can style /everything/ by section, not just headers, and because the styling specifications respect the sectional hierarchy, it's possible to create very elegant and sophisticated book pages with very little CSS. Even I can do it! :) I'm definitely *not* a designer, but I've played around a bit with this - have a look at http://www.puregin.org/book/print/129 for an example. I will attach patches for misc/print.css and misc/drupal.css separately. I don't understand why, but the present version (cvs) of these files has all of the h1.book-hx selectors in drupal.css - the printer-friendly page actually looks at print.css. Am I missing something? For the record, this approach seems to have been suggested by clairem in http://drupal.org/node/8049 where I have a little rant about headings in book pages. Twice :) Djun ------------------------------------------------------------------------ May 7, 2005 - 10:10 : puregin Steven - that's a neat idea, and very clever, clean code! But it still doesn't catch problems such as, for example, an h5 inside of an h1 section with no intervening h2..h4 headers, or? I'm inclined to be a bit suspicious of the approach, though - I rather think it's 'doing magic behind the user's back'. If people are going to insist on putting headings inside of pages, it should be possible. And it would be odd for users to discover that what they typed isn't what they get. ------------------------------------------------------------------------ May 7, 2005 - 10:32 : puregin Attachment: http://drupal.org/files/issues/print_css_div.patch (1.36 KB) Here's the patch for print.css. There's a couple of commented-out lines - these show how to make section headings 'run in' as part of the following paragraph (or other inline element). I am assuming that print.css is supposed to be something of an example that people would use to experiment with? Please feel free to improve this in any way - as I said, I'm far from being a graphic designer, and I'm also not really sure what the intention of this file is.

2 1