June 2005 - Development - lists.drupal.org

[drupal-devel] [task] Make local tasks more themeable
by drumm 13 Aug '05

13 Aug '05

Project: Drupal Version: cvs Component: menu system Category: tasks Priority: normal Assigned to: drumm Reported by: drumm Updated by: drumm Status: patch There is currently a lot of code that does some heavy lifting in the local task themeable functions. This is a bit of a simplification. No HTML is changed by this refactoring. To test this I tried making the local tasks hierarchical instead of two unordered lists. This was a easy change to do, with about 3 lines of changes. drumm -- View: http://drupal.org/node/17869 Edit: http://drupal.org/project/comments/add/17869

3 8

[drupal-devel] [bug] _db_query() does not return FALSE in case of errors, as stated in documentation
by Cvbge 11 Aug '05

11 Aug '05

Issue status update for http://drupal.org/node/25522 Project: Drupal Version: cvs Component: database system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: Cvbge Updated by: Cvbge Status: patch Attachment: http://drupal.org/files/issues/database.mysql.inc.diff (318 bytes) According to documentation db_query() should return FALSE "if the query was not executed correctly". This function calls _db_query() which returns nothing in such cases (for example when the sql syntax is wrong). Attached one-liner fixes this by adding return FALSE to _db_query(). It's from 4.6.1 but should apply to cvs without problems. Please apply this patch also to 4.6 branch. But there seems to be a problem with db_error(). It calls mysql_errno() but it seems that errors are cleared after mysql_error() call. So db_error() does not indicate any errors even if they occur. Cvbge

2 5

[drupal-devel] [bug] Menu system requires a local task to have more than 1 child in order to create secondary local tasks
by andremolnar 10 Aug '05

10 Aug '05

Project: Drupal Version: cvs Component: menu system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: andremolnar Updated by: andremolnar Status: patch Attachment: http://drupal.org/files/issues/menu_inc_1a.patch (826 bytes) This is a minor bug. The menu system requires a local task to have more than 1 child in order to create secondary local tasks. In other words if a local task only had 1 child, menu system would not create a secondary local task menu item. This patch fixes that with the addition of 1 character in the code. andre andremolnar -- View: http://drupal.org/node/17022 Edit: http://drupal.org/project/comments/add/17022

4 5

[drupal-devel] [feature] export book as xml for formatting
by puregin 09 Aug '05

09 Aug '05

Issue status update for http://drupal.org/node/1482 Project: Drupal Version: cvs Component: book.module Category: feature requests Priority: normal Assigned to: puregin Reported by: BenEng Updated by: puregin Status: patch I'd guess you are applying the patch to the wrong version. Probably your best bet is to grab the latest version from CVS, since this batch has been applied. Keep watching though because there are some other changes I'm currently working on. Regards, Djun puregin Previous comments: ------------------------------------------------------------------------ April 5, 2003 - 14:38 : BenEng Export an entire collaborative book to xml (docbook) so that it can be formatted using xslt (e.g., to rtf or pdf) and printed. It would also be nice to be able to perform the reverse. That is to import a collaborative book from an xml (docbook) file that is uploaded. ------------------------------------------------------------------------ June 2, 2004 - 17:10 : moshe weitzman can someone suggest an xml schema for this? i think we need a general xml schema for nodes. after that, this becomes a simple matter of nesting node elements (I think) ------------------------------------------------------------------------ February 1, 2005 - 02:42 : Teto Hi, Is there any news about a such feature ? All i've found about a docbook schema is here : http://docbook.sourceforge.net/projects/schema/ It seems there isn't much in the docbook cvs about that. Teto. ------------------------------------------------------------------------ May 14, 2005 - 02:11 : puregin Here's a list of the Book publishing DTDs I know about: NameNotesRef ISO 12083:1998//DTD Book//EN - this includes ISO 12093:1993//DTD Mathematics//EN Committee standard - very general. Used e.g. by University of California Press. www.xmlxperts.com/bookdtd.htm [1] DocBook Applications - widely used by Computer book publishers, e.g. O'Reilly. Good support. docbook.org [2] TEI/TEI-Lite Applications - scholarly/historical/literary documents www.tei-c.org [3] MIL-STD-38784 (CALS) Applications - Military/Govt/Enterprise publishing http://xml.coverpages.org/mil-std-38784-a1-dtd.txt [4] I'd highly recommend DocBook as a useable, technically focused, XML DTD with strong toolset support. [1] http://www.xmlxperts.com/bookdtd.htm [2] http://docbook.org [3] http://www.tei-c.org/ [4] http://xml.coverpages.org/mil-std-38784-a1-dtd.txt ------------------------------------------------------------------------ May 18, 2005 - 01:37 : puregin I'd suggest we start with something very simple. The patch which I submitted for http://drupal.org/node/1898 wraps each node in <div> tags, with a level, and a node id attribute, for printer friendly output. We can't rely in general on the contents of a node being XHTML, even if we force output through an XHTML validator such as tidy. So our best bet is to encode the entire contents of a node as CDATA. This gives us hierarchy, and encapsulated contents (of any kind - later this could also be other kinds of data or markup) This output will be valid XML, with a pretty simple DTD. It is easy to take such a file and write simple XSLT based scripts on the the client side to explode this file into a directory tree of HTML, a single HTML file, or many other formats. Importing is trickier. It's relatively easy to import an exported file, and update the nodes of the book according to the hierarchy defined by the sectional <div> elements. Importing needs to take care of structure which has changed - child nodes added, deleted, or moved. It would also be nice to have some client-side scripts to import other formats into this nested sectional <div> based format - for example, to take a directory tree of HTML fragments, and make this into an importable file. ------------------------------------------------------------------------ June 1, 2005 - 03:33 : puregin Attachment: http://drupal.org/files/issues/xml-export.patch (14.06 KB) This patch enables export of books as XML documents. The XML is DocBook "at the level of structure", but node contents are wrapped as CDATA, since we can't be sure that the contents are valid XML. Several other bugs/feature requests are also addressed with this patch: - Fixes bugs http://drupal.org/node/1898 http://drupal.org/node/1482 http://drupal.org/node/8049 http://drupal.org/node/1899 Should go a long way towards implementing feature request http://drupal.org/node/2062 It should also be easy to extend this to produce OPML, for example. - Adds about 170 lines, of which more than 100 are comments - Added doxygen comments - Made doxygen comment format consistent; fixed minor grammatical slips - A proper Doctype and more informative HTML element is generated for printer-friendly HTML output. - Refactored book_print() to use book_recurse(). - Refactored book_recurse(). Applies 'visitor' callback functions to nodes during weight/title order tree-traversal. The parameterized visitor callbacks can be used to generate different kinds of output. There are many other kinds of operations on books which can be implemented by writing a pre-node/post-node pair of callback functions: word-count/ statistics gathering, comparison, copying, search and replace... - Introduced book_export() which uses book_recurse() to generate DocBook-like XML to export book contents in a structured form. An md5 hash is computed for each node to help import code to decide if a node needs to be updated or not. ------------------------------------------------------------------------ June 3, 2005 - 01:29 : puregin Attachment: http://drupal.org/files/issues/xml-export-01.patch (14.19 KB) This updated patch adds "weight" metadata, which I forgot to capture in the previous patch. I'm not sure how much other metadata I should include. ------------------------------------------------------------------------ June 3, 2005 - 02:06 : puregin Attachment: http://drupal.org/files/issues/explode2dir.php (6.64 KB) The attached command-line PHP script may be useful in testing the XML export patch supplied. Assuming your local version of PHP is built with CLI support and XML parser support, you should be able to run the script against an XML export file generated by the book module with my patch. After you have installed the patch, you can select a book page, click on the 'export XML' link, and save the result as a file, say 'test.xml'. Then run the script. On my system this looks like this: % ./export2dir.php test.xml This will produce output that looks something like this: ./explode2dir.php test.xml md5: 9e8ca98c6a8be35c21f31f7937608acc weight: 1 md5: 11a1956a1592feac37abee6b469e62c8 weight: 0 md5: ed4c91279d3bed28b56899b75ccaa9aa weight: 0 It will generate a directory hierarchy, with one directory per book node. Each directory contains a file containing the node contents and a file 'nid' containing the metadata. You can check, for example, that the md5 signature of the contents match the md5 signature recorded with the metadata. Djun ------------------------------------------------------------------------ June 3, 2005 - 11:46 : Dries I like the approach taken in this patch! Let's tidy up the menu structure. I suggest changing book/export (docbook) book/print (plain-text) to export/docbook export/text If we add OPML-support, it would then become: export/opmlSimilarly, I suggest renaming 'export XML' to 'export DocBook XML' (or something). ------------------------------------------------------------------------ June 3, 2005 - 11:53 : Dries Haven't tried it but how does DocBook handle CDATA? Does it come out OK? Read: does it make sense to do it this way? ------------------------------------------------------------------------ June 3, 2005 - 16:04 : puregin Dries, The output XML which I've implemented is only 'DocBook-like', not true DocBook. I've been dealing with structure at the top level (book, chapter, section). I've hidden away the actual content inside a CDATA section. The XML is really intended to provide a container for export. At this point I'm trying to focus on a relatively simple way to do an export/import round trip of the current content format (text/'loose' HTML). Most people would probably not edit this using an XML editor. I think I can generate a tar/gzip archive of the directory structure I described (output of explode2dir.php) directly on the server, either by calling an external pipeline, or by using the tar/gzip PEAR extension. So the XML format I described would be useful primarily as means to do the /import/, unless we can think of a better way to import such a directory structure (perhaps via the node_import module?) How the CDATA section is handled depends on the application. Most XML editors will display this as CDATA, allow the user to edit as CDATA, and to perform edit operations such as cut/paste to convert the CDATA to other XML elements. DocBook formatting applications could do various things - ignore the CDATA; format as 'preformatted', e.g., source listing; or try to do something clever, like attempting to parse and convert the CDATA into real DocBook before proceeding. To generate true DocBook, we would have to: * emit a document type declaration * decide if we want to export complete documents (i.e., top level elements such as books, articles, set) or document fragments. The real difficulty is dealing with the /content/: to convert this into DocBook, we'd have to attempt to map (possibly not well formed) text and/or HTML into well-formed DocBook XML. This would require guessing in many cases, since text/HTML doesn't directly encode the author's intent. A problem with this would be that the content might not be returned exactly as exported in an (export/import) 'round trip' . If we want to support true DocBook, it would probably be better to do this via an input filter, similar to the PHP input filter - definitely worth pursuing, but perhaps a separate issue? I will rewrite the patch to make sure that the exported XML validates as a DocBook fragment, and punt off to people who actually want to deal with real DocBook the problem of embedding and converting content. These folks would probably not so interested in round-trip import/export, until we have native DocBook nodes, at which point many of these issues vanish (I hope :) Regards, Djun ------------------------------------------------------------------------ June 3, 2005 - 17:01 : Amazon As an active member of the documentation team I would greatly appreciate any ability to export and import content to and from the documentation handbooks. Drupal is slow for editing, and has some usability issues that I will be following up on. Please consider accepting this as a incremental step to assisting the documentation team and other editors. Kieran ------------------------------------------------------------------------ June 4, 2005 - 00:28 : Dries If the goal is to generate books, DocBook-export is key. However, if the output is only DocBook-like, it is only going to be used by a handful of people. I think the code comments should mention that it is only DocBook-like. If the goal is to import/export books, OPML might be the better choice. I think book syndication (publish/subscribe) is going to be the more popular. Either way, let's clean up the URL scheme and extend the book_help() function a bit (if not already). ------------------------------------------------------------------------ June 5, 2005 - 04:00 : Dries I made some changes (URL scheme) and committed this patch to HEAD. Please update your tree before making more changes. - Can you update the issues affected by this commit? - I wonder why the release info (md5-sum) isn't stored at XML attributes so it can be parsed/extracted easily. Probably DocBook-specific. - Firefox did not recognize the XML document as being XML. I think we might have to send the proper headers: drupal_set_header('Content-Type: text/xml; charset=utf-8');. Haven't checked yet. Great work Djun. ------------------------------------------------------------------------ June 6, 2005 - 02:18 : puregin Attachment: http://drupal.org/files/issues/xml-export-03.patch (22.3 KB) Thanks, Dries. Here is a new patch, against revision r1.299. - now generate value DocBook XML (fragments). Level 0 nodes are exported as books; level 1 as chapters, and level 2 and higher as sections. Content is still wrapped as CDATA, for the moment. I am working on code to generate proper DocBook from HTML, but this will require 1) Tidy, HTMLCorrector or something of the sort, to ensure that the HTML is well-formed XHTML; and 2) XSLT support enabled for PHP. I assume that this will need to be a packaged as a contributed module? - generate OPML (titles only) - issue Content-type: text/xml headers for XML output (DocBook, OPML) - changed URL scheme (single callback for all exports, takes export type as 1st argument) - merged book_export_html and book_export_xml into a single function book_export with 'switch()' logic to handle different output formats, to support the above URL scheme. So for example, book/export/html/154 will generate printer friendly HTML, while book/export/docbook/154 generates DocBook. - added function _book_get_depth($nid) which computes the absolute depth of a node in a book hierarchy - printer-friendly HTML is now generated with the exported node embedded to its absolute depth (e.g., level 3 nodes will always be marked-up as level 3 nodes) - changed name book_node_visitor_print -> name book_node_visitor_html - added parameter depth to 'post-node' visitor function call - fixed incorrect parameter to node_invoke_nodeapi() - changed 'view' to 'print' so as to avoid rendering book navigation in printer friendly (or other export format) output. - Added the new admin/help documentation, updated to include the XML export functionality. ------------------------------------------------------------------------ June 8, 2005 - 18:08 : muralik when i patch, i get this error, any clues? failed at line 321

4 4

[drupal-devel] [feature] Allow for more integers in node_access grant_x columns
by moshe weitzman 05 Aug '05

05 Aug '05

Issue status update for http://drupal.org/node/25395 Project: Drupal Version: cvs Component: node.module Category: feature requests Priority: normal Assigned to: moshe weitzman Reported by: moshe weitzman Updated by: moshe weitzman Status: patch Attachment: http://drupal.org/files/issues/node_access_0.patch (620 bytes) It is useful for modules to store more information in the grant_view, grant_update, Grant_delete columns than just 1 or 0. This patch treats 0 and 1 just as before, and any value greater than 1 is assumed TRUE (just like PHP). Organic groups already has 2 needs for this. One would be to store the 'group role' of a member in this table. Total characters changed: 1 moshe weitzman

2 2

[drupal-devel] [feature] Sort logs by ID instead of timestamp
by njivy 04 Aug '05

04 Aug '05

Issue status update for http://drupal.org/node/23560 Project: Drupal Version: cvs Component: watchdog.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: njivy Updated by: njivy Status: patch In watchdog.module I propose changing the key used to sort logs chronologically. Instead of using the timestamp, which is accurate only to the nearest second, we could use the log entry id ("wid" in the database). As I understand it, the IDs are assigned sequentially, so this is a good approximation to the correct order in which the events are recorded. Also, I don't know of any events that are recorded after a delay. The problem with the current sorting key arises when logged events come within 1 second of each other. The order of events is not always preserved when viewing the log because the timestamp is identical for several events. In "modules/watchdog.module" neard line 91, the word "timestamp" is replaced with "wid": $header = array( ' ', array('data' => t('Type'), 'field' => 'w.type'), array('data' => t('Date'), 'field' => 'w.wid', 'sort' => 'desc'), array('data' => t('Message'), 'field' => 'w.message'), array('data' => t('User'), 'field' => 'u.name'), array('data' => t('Operations'), 'colspan' => '2') ); Preliminary testing suggests this is a good tweak. njivy

7 7

[drupal-devel] [feature] Trigger debug mode on-the-fly
by mathias 03 Aug '05

03 Aug '05

Issue status update for http://drupal.org/node/21379 Project: Drupal Version: cvs Component: other Category: feature requests Priority: normal Assigned to: Anonymous Reported by: mathias Updated by: mathias Status: patch Attachment: http://drupal.org/files/issues/devel_GET_params_core.patch (2.38 KB) This patch allows admins who are using devel.module to optionally toggle the page timer, query logger and page redirection for each request using GET parameters rather than navigating to admin/settings/devel and flipping the global settings back and forth. I added this since I usually don't need to print out this information for every page. Now I just use: http://example.com/index.php?q=node&dev_query=1 for the request I'm interested in. Two other params can also be toggled: dev_timer and dev_redirect. mathias

4 5

[drupal-devel] [bug] Always resizing user pictures breaks transparency?
by leafish_paul 03 Aug '05

03 Aug '05

Issue status update for http://drupal.org/node/24946 Project: Drupal Version: 4.6.1 Component: user.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: leafish_paul Updated by: leafish_paul Status: patch Attachment: http://drupal.org/files/issues/user.module_tweaked_picture_resizing.patch (1.47 KB) I recently noticed that when uploading transparent user pictures to a Drupal site, the transparent colour is lost (replaced with black). I think its to do with image_size()... but I noticed the slightly odd logic in user.module: <?php if (!$info || !$info['extension']) { form_set_error('picture', t('The uploaded file was not an image.')); } else if (image_get_toolkit()) { image_scale($file->filepath, $file->filepath, $maxwidth, $maxheight); } else if (filesize($file->filepath) > (variable_get('user_picture_file_size', '30') * 1000)) { form_set_error('picture', t('The uploaded image is too large; the maximum file size is %size kB.', array('%size' => variable_get('user_picture_file_size', '30')))); } else if ($info['width'] > $maxwidth || $info['height'] > $maxheight) { form_set_error('picture', t('The uploaded image is too large; the maximum dimensions are %dimensions pixels.', array('%dimensions' => variable_get('user_picture_dimensions', '85x85')))); } ?> So, the image is always scaled if an image toolkit is found. The attached patch /only/ scales user pictures if they are too large, and will still show an error if a toolkit is not found. I'm aware that there may be a better patch for image.inc to retain scaled image transparency? leafish_paul

2 2

[drupal-devel] [task] Small improvement in settings.php to make it clearer for noobs
by Bèr Kessels 03 Aug '05

03 Aug '05

Issue status update for http://drupal.org/node/24563 Project: Drupal Version: 4.6.0 Component: other Category: tasks Priority: normal Assigned to: Anonymous Reported by: Bèr Kessels Updated by: Bèr Kessels Status: patch Attachment: http://drupal.org/files/issues/settings_clarify.patch (814 bytes) I was just following a complete newbie when he installed Drupal. I will skip the database-import part, it was hell :) But more important, IMO is that he could not really read the documentation in settings.php correctly. He assumed the part localhost/database in mysql://username:password@localhost/database referred to his database directory. Since he was working on localhost, and knew nothing of the concept of a SQL server, this is not too odd. So I chnaged this into mysql://username:password@databaseserver/databasename in the attached patch. The filled out example reamins the same, with localhost in the url (since 99% has localhost as sql server) Note: I purposely did not user database_name, sinxce that will be confused with the prefix documentation, which uses the _ in its examples. And I hate (or well... dislike) CamelCase. Bèr Kessels

3 4

[drupal-devel] [feature] Per-User Input-Format Preferences
by jchris 01 Aug '05

01 Aug '05

Issue status update for http://drupal.org/node/26036 Project: Drupal Version: 4.6.1 Component: filter.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: jchris Updated by: jchris Status: patch Attachment: http://drupal.org/files/issues/filter.module_9.patch (1.61 KB) Here's a patch to filter.module that allows users to set their preferred input format, when multiple formats are available. A selection of available formats is added to the user-account editing page. The user's selection is persistent and is used to initialize the input-format selector on the node-editing pages. This patch requires an addition of an 'input_format' field to the {users} table: alter table users add input_format int(4) NOT NULL default '0'; I'm not 100% sure I did this correctly. I'm no PHP coder. Anyway, it seems to work. Patch file is attached. Enjoy. jchris

3 4