- Development - lists.drupal.org

[drupal-devel] [bug] Do not execute functions in include files
by chx 04 Jun '05

04 Jun '05

Issue status update for http://drupal.org/node/18213 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: chx Reported by: killes(a)www.drop.org Updated by: chx Status: patch Attachment: http://drupal.org/files/issues/bootstrap_4.patch (12.36 KB) Fixed drupal_bootstrap('database') -- $phase was 0 , and == FALSE fired. === FALSE is used. chx Previous comments: ------------------------------------------------------------------------ March 2, 2005 - 00:09 : killes(a)www.drop.org Drupal currently executes functions in include files. This is very annoying if you want to include files from external scripts such as update scripts or other scripts that want to use Drupal as a framework. Offending files are: database.inc: db_set_active(); session.inc: session_set_save_handler("sess_open", "sess_close", "sess_read", "sess_write", "sess_destroy", "sess_gc"); session_start(); common.inc: A bunch of stuff at the bottom. All this should be moved into a start.inc file. ------------------------------------------------------------------------ March 27, 2005 - 08:44 : adrian I haven't done this recently, but back in 4.4 era I attempted something similar to this for the install api. A _lot_ of modifications were required to be able to use (for instance) the theme api without needing to have a database connection active. ------------------------------------------------------------------------ March 27, 2005 - 08:55 : adrian It's definately not a simple problem. For instance.. the db connection needs to be started during bootstrap, and during normal execution. I think the better idea is to include a DRUPAL_INIT constant we can check before executing the function. (or a DRUPAL_NO_INIT .. i'm not picky). ------------------------------------------------------------------------ April 28, 2005 - 23:53 : killes(a)www.drop.org Here's an old patch by me that illustrates what I want to do. http://lists.drupal.org/archives/drupal-devel/2005-03/txtq23pAcHATw.txt Instead of putting the stuff into index.php, alternative file names need to be found. ------------------------------------------------------------------------ May 4, 2005 - 19:36 : chx Attachment: http://drupal.org/files/issues/boot.patch (6.83 KB) Well, I have written something to address the issue. Now you can include everything to your hearts content just include init.inc as well and do an appropriate drupal_bootstrap. Alas, ATM database and bootstrap is very interwined. This interdependency could be obliterated if we'd not use variable_get('dev_query') in database.*.inc. cvs diff -u -N -F^f against cvs.drupal.org as CVSROOT failed to include to include the two new files, so I'll include them as followups. ------------------------------------------------------------------------ May 4, 2005 - 19:37 : chx Attachment: http://drupal.org/files/issues/boot_0.patch (10.31 KB) Hm, settings.php changes were ommited. ------------------------------------------------------------------------ May 4, 2005 - 19:37 : chx Attachment: http://drupal.org/files/issues/init.inc (3.46 KB) ------------------------------------------------------------------------ May 4, 2005 - 19:38 : chx Attachment: http://drupal.org/files/issues/settings_ini_set.php (850 bytes) ------------------------------------------------------------------------ May 4, 2005 - 19:44 : chx Attachment: http://drupal.org/files/issues/boot_1.patch (14.49 KB) Following advice from darix I have now created one patch. Still, I'd like to know how could I do this with cvs. ------------------------------------------------------------------------ May 4, 2005 - 20:01 : chx Attachment: http://drupal.org/files/issues/boot_2.patch (14.48 KB) Steef found that I had $$ in settings.php. He also asked what's this good for. Several things, but most advantages come when you use only parts of Drupal. If you want use, say, only our forms functions then now you can include('common.inc'); without side effects. If you need the database layer, you do a include('init.inc') and call drupal_bootstrap('database') ------------------------------------------------------------------------ May 5, 2005 - 23:03 : chx Attachment: http://drupal.org/files/issues/boot_3.patch (17.98 KB) The database layer is now totally independent of other parts of Drupal. ------------------------------------------------------------------------ May 15, 2005 - 21:37 : chx A very stupid bug related to variable init is fixed and I am sync'd to HEAD, so timer_init('page') is called. ------------------------------------------------------------------------ May 16, 2005 - 23:12 : chx Attachment: http://drupal.org/files/issues/bootstrap_3.patch (12.36 KB)

1 0

[drupal-devel] amazon items
by NSK 04 Jun '05

04 Jun '05

a version of amazon items which works better with 4.6.1 is available from http://nsk.wikinerds.org/amazon_items/ Can someone upload it to the cvs server so that interested users can find it more easily? or should I just link from the html page? It seems to work almost ok on my local server, so I suppose it can be added to the list of modules for Drupal 4.6 now. -- NSK http://portal.wikinerds.org

1 0

[drupal-devel] [feature] export book as xml for formatting
by Dries 04 Jun '05

04 Jun '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: Dries Status: patch 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). Dries Previous comments: ------------------------------------------------------------------------ April 5, 2003 - 23: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 3, 2004 - 02: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 - 11: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 - 11: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 - 10: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 - 12: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 - 10: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 - 11: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 - 20: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 - 20: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 4, 2005 - 01: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 4, 2005 - 02: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

1 0

[drupal-devel] [feature] export book as xml for formatting
by Amazon 04 Jun '05

04 Jun '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: Amazon Status: patch 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 Amazon Previous comments: ------------------------------------------------------------------------ April 5, 2003 - 21: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 3, 2004 - 00: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 - 09: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 - 09: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 - 08: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 - 10: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 - 08: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 - 09: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 - 18: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 - 18: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 - 23: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

1 0

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

04 Jun '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 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 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?

1 0

[drupal-devel] [feature] export book as xml for formatting
by Dries 03 Jun '05

03 Jun '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: Dries Status: patch 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? Dries Previous comments: ------------------------------------------------------------------------ April 5, 2003 - 23: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 3, 2004 - 02: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 - 11: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 - 11: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 - 10: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 - 12: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 - 10: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 - 11: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 - 20: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).

1 0

[drupal-devel] [feature] export book as xml for formatting
by Dries 03 Jun '05

03 Jun '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: Dries Status: patch 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). Dries Previous comments: ------------------------------------------------------------------------ April 5, 2003 - 23: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 3, 2004 - 02: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 - 11: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 - 11: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 - 10: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 - 12: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 - 10: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 - 11: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

1 0

[drupal-devel] Bug#311817: marked as done (Please allow drupal 4.5.3-1)
by owner＠bugs.debian.org 03 Jun '05

03 Jun '05

Your message dated Fri, 3 Jun 2005 16:39:26 +0200 with message-id <20050603143926.GJ12099(a)mails.so.argh.org> and subject line Please allow drupal 4.5.3-2 into sarge has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -------------------------------------- Received: (at submit) by bugs.debian.org; 3 Jun 2005 13:43:19 +0000 >From bengen(a)debian.org Fri Jun 03 06:43:19 2005 Return-path: <bengen(a)debian.org> Received: from mail.kamp-dsl.de (dsl-mail.kamp.net) [195.62.99.42] by spohr.debian.org with smtp (Exim 3.35 1 (Debian)) id 1DeCSE-0005iY-00; Fri, 03 Jun 2005 06:43:18 -0700 Received: (qmail 12372 invoked by uid 513); 3 Jun 2005 13:43:21 -0000 Received: from 213.146.117.234 by dsl-mail (envelope-from <bengen(a)debian.org>, uid 89) with qmail-scanner-1.24 (clamdscan: 0.80/609. spamassassin: 2.60. Clear:RC:1(213.146.117.234):SA:0(-1.6/5.0):. Processed in 1.305859 secs); 03 Jun 2005 13:43:21 -0000 Received: from hilluzination.de (HELO paranoia) (hillu%kamp-dsl.de(a)213.146.117.234) by dsl-mail.kamp.net with SMTP; 3 Jun 2005 13:43:20 -0000 Received: from ataraxia ([192.168.1.251] helo=localhost.localdomain) by paranoia with esmtp (Exim 4.34) id 1DeCSA-0004dC-WB; Fri, 03 Jun 2005 15:43:15 +0200 Received: from bengen by localhost.localdomain with local (Exim 4.50) id 1DeCTv-0003vq-4r; Fri, 03 Jun 2005 15:45:03 +0200 To: debian-release(a)lists.debian.org, debian-security(a)lists.debian.org Cc: submit(a)bugs.debian.org Subject: Re: Please allow drupal 4.5.3-1 Mail-Copies-To: nobody In-Reply-To: <20050603120107.GB5280(a)heinrich.complete.org> (John Goerzen's message of "Fri, 3 Jun 2005 07:01:07 -0500") References: <87ll5tskf1.fsf(a)ataraxia.int.hilluzination.de> <200506011916.04838.ieure(a)debian.org> <20050603055550.GI5149(a)mauritius.dodds.net> <20050603061922.GU884(a)finlandia.infodrom.north.de> <20050603064823.GL5149(a)mauritius.dodds.net> <87psv3es34.fsf(a)ataraxia.int.hilluzination.de> <20050603120107.GB5280(a)heinrich.complete.org> From: Hilko Bengen <bengen(a)debian.org> Date: Fri, 03 Jun 2005 15:45:03 +0200 Message-ID: <87u0kfd068.fsf(a)ataraxia.int.hilluzination.de> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Delivered-To: submit(a)bugs.debian.org X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2005_01_02 X-Spam-Level: Package: drupal Version: 4.5.2-0 Severity: critical Tags: security, sarge John Goerzen <jgoerzen(a)complete.org> writes: > On Fri, Jun 03, 2005 at 10:56:47AM +0200, Hilko Bengen wrote: >> Steve Langasek <vorlon(a)debian.org> writes: >> >> So, you are not accepting my drupal_4.5.3-1 (or -2) package into sarge >> because 4.5.3 fixes more than cited security issue? > > Why are you not using the simple patch available at > http://drupal.org/drupal-4.6.1 I had only been told that 4.5.3 which is supposed to fix some security issue had been released. Hoping that the release team would simply accept it into sarge, I just packaged that. BTW: Dries Buytaert, one of the main developers of Drupal, just told me that most of the other fixes in 4.5.3 are input checks. Moreover, the 4.5.3-2 package I uploaded also adds Vietnamese Debconf translations, which might qualify it for inclusion in Sarge. Again, there is _no_ added functionality over 4.5.2 in 4.5.3. I frankly don't see why the issue is still being discussed and casual comments are made about what a maintainer should do to "get it right". I'd rather not be responsible for stressing the security team nor the release team too much a few days before Sarge is going to be released. OTOH, I _have_ uploaded a package which fixes the security issue and I suppose I could just sit there and assume that this is ok until told otherwise. Cheers, -Hilko --------------------------------------- Received: (at 311817-done) by bugs.debian.org; 3 Jun 2005 14:39:34 +0000 >From aba(a)not.so.argh.org Fri Jun 03 07:39:34 2005 Return-path: <aba(a)not.so.argh.org> Received: from neualius.turmzimmer.net [217.160.169.58] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1DeDKg-0003w7-00; Fri, 03 Jun 2005 07:39:34 -0700 Received: from [195.60.122.97] (helo=metis.turmzimmer.net) by neualius.turmzimmer.net with esmtp (Exim 4.50) id 1DeDKe-0003xK-DM; Fri, 03 Jun 2005 16:39:32 +0200 Received: from eos.turmzimmer.net ([10.2.3.1]) by metis.turmzimmer.net with esmtp (Exim 4.50) id 1DeDKU-0000X2-Pp; Fri, 03 Jun 2005 16:39:22 +0200 Received: from aba by eos.turmzimmer.net with local (Exim 4.50) id 1DeDKZ-0004Rp-1O; Fri, 03 Jun 2005 16:39:27 +0200 Date: Fri, 3 Jun 2005 16:39:26 +0200 From: Andreas Barth <aba(a)not.so.argh.org> To: Hilko Bengen <bengen(a)debian.org> Cc: debian-release(a)lists.debian.org, 311817-done(a)bugs.debian.org Subject: Re: Please allow drupal 4.5.3-2 into sarge Message-ID: <20050603143926.GJ12099(a)mails.so.argh.org> Mail-Followup-To: Andreas Barth <aba(a)not.so.argh.org>, Hilko Bengen <bengen(a)debian.org>, debian-release(a)lists.debian.org, 311817-done(a)bugs.debian.org References: <87ll5tskf1.fsf(a)ataraxia.int.hilluzination.de> <878y1trsto.fsf(a)ataraxia.int.hilluzination.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <878y1trsto.fsf(a)ataraxia.int.hilluzination.de> X-Editor: Vim http://www.vim.org/ User-Agent: Mutt/1.5.9i Delivered-To: 311817-done(a)bugs.debian.org X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-3.0 required=4.0 tests=BAYES_00 autolearn=no version=2.60-bugs.debian.org_2005_01_02 X-Spam-Level: * Hilko Bengen (bengen(a)debian.org) [050602 12:57]: > Hilko Bengen <bengen(a)debian.org> writes: > > > Just a few hours ago, the Drupal project has released version 4.5.3, a > > bugfix release which fixes a serious security bug. I have created and > > just uploaded a 4.5.3-1 package to unstable. Updated Debconf > > translations are the only additional changes over 4.5.2-3 which is > > the version in sarge. > > > > The corresponding advisory from upstream can be found here: > > http://drupal.org/files/sa-2005-001/advisory.txt. > > As I write this mail, I am uploading drupal 4.5.3-2 which adds > Vietnamese translation that I received this morning. Please allow > either -1 or -2 to go into sarge because of mentioned security fix. hinted in. Cheers, Andi

1 0

[drupal-devel] [bug] replace binary strings in node.module with hex encodings
by danielc 03 Jun '05

03 Jun '05

Issue status update for http://drupal.org/node/24025 Project: Drupal Version: 4.6.0 Component: base system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: danielc Updated by: danielc Status: patch Attachment: http://drupal.org/files/issues/node.module.nobinary.diff (864 bytes) drupal/modules/node.module contains three binary strings. The use of binary strings causes problems in text editors incapable of handling such strings. For example, I have modified this file for internal use, but when I save the file, the binary strings get converted to question marks. While someone could argue that I should get a better text editor, this issue exists for many users, not just me. Better yet, the solution is simple... PHP allows representing binary characters via hex encoding. That's what this patch does. Thanks. danielc

5 8

[drupal-devel] Bug#311817: Please allow drupal 4.5.3-1
by Hilko Bengen 03 Jun '05

03 Jun '05

Package: drupal Version: 4.5.2-0 Severity: critical Tags: security, sarge John Goerzen <jgoerzen(a)complete.org> writes: > On Fri, Jun 03, 2005 at 10:56:47AM +0200, Hilko Bengen wrote: >> Steve Langasek <vorlon(a)debian.org> writes: >> >> So, you are not accepting my drupal_4.5.3-1 (or -2) package into sarge >> because 4.5.3 fixes more than cited security issue? > > Why are you not using the simple patch available at > http://drupal.org/drupal-4.6.1 I had only been told that 4.5.3 which is supposed to fix some security issue had been released. Hoping that the release team would simply accept it into sarge, I just packaged that. BTW: Dries Buytaert, one of the main developers of Drupal, just told me that most of the other fixes in 4.5.3 are input checks. Moreover, the 4.5.3-2 package I uploaded also adds Vietnamese Debconf translations, which might qualify it for inclusion in Sarge. Again, there is _no_ added functionality over 4.5.2 in 4.5.3. I frankly don't see why the issue is still being discussed and casual comments are made about what a maintainer should do to "get it right". I'd rather not be responsible for stressing the security team nor the release team too much a few days before Sarge is going to be released. OTOH, I _have_ uploaded a package which fixes the security issue and I suppose I could just sit there and assume that this is ok until told otherwise. Cheers, -Hilko

1 0