- Development - lists.drupal.org

[drupal-devel] [bug] bluemarine mistakenly loads home page every time
by moshe weitzman 24 Aug '05

24 Aug '05

Issue status update for http://drupal.org/node/29283 Post a follow up: http://drupal.org/project/comments/add/29283 Project: Drupal Version: cvs Component: theme system Category: bug reports Priority: normal Assigned to: moshe weitzman Reported by: moshe weitzman Updated by: moshe weitzman Status: patch (code needs review) Attachment: http://drupal.org/files/issues/logo.patch (830 bytes) if admin chooses no logo in theme config, bluemarine still lays down an img tag which points back to the site home page. thats a sure way to increase your load and bandwidth. yikes! moshe weitzman

9 16

RE: [drupal-devel] CCK Name Conflict
by Boerland, Bert (PinkRoccade IT Management Consultant) 24 Aug '05

24 Aug '05

-----Original Message----- From: drupal-devel-bounces(a)drupal.org >> Dunno if y'all were aware, but Firefox has a new feature that goes by >> CCK which might cause some confusion with the Drupal CCK: >> http://www.mozilla.org/projects/cck/firefox/ > This isn't "new", relatively. I remember using IE 3's > CCK to custom build an IE for some of my customers. No not new indeed. TDM TLA's exists. In 1989, a random of the journalistic persuasion asked hacker Paul Boutin "What do you think will be the biggest problem in computing in the 90s?" Paul's straight-faced response: "There are only 17,000 three-letter acronyms." (To be exact, there are 26^3 = 17,576.) [1] To get -a bit- more on toppic, we could be more creative than having a TLA for a module or a very detailed explaining name. Every tried looking for a module that does "something" with taxonomy? There are at least 10 modules with taxonomy in its name [2]. Now its up to the developer of a module to name its child, but lets get a bit more creative. There is nothing wrong with calling a module like Taxonomy Access Controle, "Cats and Dogs Control". I installed "Markdown with SmartyPants" just because it smelled funny. I know that when its rather specific, it doesnt hurt to have desciptive names like ""Amazon Search" but we can do better than having a module named "Members". Just imagine, Dries didnt came up with "Drupal" as a name but "CMS". [3] and [4] [1] http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?TLA [2] http://drupal.org/project/Modules [3] http://www.google.com/search?hl=en&lr=&q=define%3Adrupal [4] http://www.google.com/search?hl=en&q=define%3Acms

3 2

[drupal-devel] CCK Name Conflict
by Chris Messina 24 Aug '05

24 Aug '05

Dunno if y'all were aware, but Firefox has a new feature that goes by CCK which might cause some confusion with the Drupal CCK: http://www.mozilla.org/projects/cck/firefox/ Something to consider. Chris

4 3

[drupal-devel] google jabber server
by Adrian Rossouw 24 Aug '05

24 Aug '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Couldn't we set it up so that we have the jabber module in core again, and let people use their gmail accounts as their login? How does jabber auth handle the server being connected to being different from the account? - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDDCIIgegMqdGlkasRAtZMAJ9XWUTdR2SpVwwYbloi+/c4Yq6bfQCbBbHn 9xE6wdg4DoQLcJqe0jSEFHA= =NmSK -----END PGP SIGNATURE-----

1 0

[drupal-devel] [task] Move pagers out of tables
by drumm 24 Aug '05

24 Aug '05

Issue status update for http://drupal.org/node/28786 Post a follow up: http://drupal.org/project/comments/add/28786 Project: Drupal Version: cvs Component: other Category: tasks Priority: normal Assigned to: drumm Reported by: drumm Updated by: drumm Status: patch (code needs review) Attachment: http://drupal.org/files/issues/pagers.patch (10.87 KB) A couple themers have told me that the pagers do not belong in the last row of tables. Here is a big patch to move them all. drumm

3 2

[drupal-devel] [bug] URL aliases crippled by recent commit
by walkah 24 Aug '05

24 Aug '05

Issue status update for http://drupal.org/node/29518 Post a follow up: http://drupal.org/project/comments/add/29518 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: critical Assigned to: Anonymous Reported by: walkah Updated by: walkah Status: patch (ready to be committed) Attachment: http://drupal.org/files/issues/bootstrap-inc.patch (487 bytes) looks like some debug code slipped into bootstrap.inc that effectively disables url aliasing (always returning when doing path lookups). the culprit is here [1]. patch attached... tested and working. [1] http://cvs.drupal.org/viewcvs/drupal/drupal/includes/bootstrap.inc?r1=1.60&… walkah

1 0

[drupal-devel] End of lifeing the fontsize module
by neil＠civicspacelabs.org 24 Aug '05

24 Aug '05

Unless someone else decides to take over the fontsize module I will end of life it. Here is why: - All web browsers with sizable text have usable sizing controls. - I can't actually find anything in US Sec. 508 or W3C WAI saying these resizing thingers are recomended. - It can be baked into your theme if necessary. -Neil

2 1

[drupal-devel] [bug] make standard roles translatable
by stefan nagtegaal 24 Aug '05

24 Aug '05

Issue status update for http://drupal.org/node/5570 Post a follow up: http://drupal.org/project/comments/add/5570 Project: Drupal Version: cvs Component: user system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: stefan nagtegaal Updated by: stefan nagtegaal Status: patch (code needs work) Indeed Cvbge.. Even in the latest CVS version 24-08-2005 this is still an issue.. It's the last 2 strings which could not be properly translated which really frustrates me, and hopefully other users.. Probably we can fix this issue when adding id's to the roles? Or by defining them as constants? <?php DEFINE('ANONYMOUS_USER', t('Anonymous user')); DEFINE('AUTHENTICATED_USER', t('Authenticated user')); ?> The pro's of the defined constants method is that we can also get rid of the 'Anonymous user'-option on the settings page, because it becomes translatable.. What do you think, will this work? stefan nagtegaal Previous comments: ------------------------------------------------------------------------ Sun, 01 Feb 2004 18:03:37 +0000 : stefan nagtegaal There are several things that would need to be fixed before we are going to release drupal 4.4. One of that is proper translation.. - The basic roles 'Anonymous user'/'Anonymous' & 'Authenticated user' aren't translatable on the following places (admin >> users / admin >> users >> roles / admin >> users >> permission / ) ------------------------------------------------------------------------ Fri, 23 Jul 2004 17:19:35 +0000 : killes(a)www.drop.org Changing title. ------------------------------------------------------------------------ Wed, 06 Oct 2004 09:53:48 +0000 : stefan nagtegaal This is still a problem.. The default roles 'Anonymous user' and 'Authenticated user' can not be translated. ------------------------------------------------------------------------ Wed, 06 Oct 2004 12:55:38 +0000 : Axel But why this bug is critical? Drupal works on such manner long time. This bug don't prevent Drupal to work. I think priority of this bug must be set as 'normal', but not 'critical'. ------------------------------------------------------------------------ Wed, 03 Nov 2004 18:53:46 +0000 : com2 I would say either committed to multilingual / localization or not. Calling it a feature seems to say "translation has a low priority". When that is the case, why all the trouble to localize? Jus drop localization and make life easier! All depends on the chosen concept of Drupal. If you choose Drupal to be multilingual / localized, then this is definitely is a bug. You cannot expect a non-english speaker to understand these special users. What happens when I just translate them in table /role/? Would it break Drupal? ------------------------------------------------------------------------ Wed, 04 May 2005 13:48:34 +0000 : schalker As I can tell, standard roles still can not be translated. Is this correct? Is there a work-around or some plan to implement this? I'd agree with the former poster com2 that this is more a bug than a feature request: I love the locale module, but I cannot see a reason why almost everything is translateable, but not the standard roles. If there is no reason for this behaviour /from a user-point-of-view/, then this is a bug, I'd say. ------------------------------------------------------------------------ Wed, 04 May 2005 14:05:33 +0000 : schalker Sorry, it's me again. I searched on and on to find a similar bug report, but I haven't found one. So as two people think this is a bug, I change the category of this issue back to "bug report". ------------------------------------------------------------------------ Tue, 09 Aug 2005 19:40:42 +0000 : Cvbge Attachment: http://drupal.org/files/issues/translate_default_roles.diff (1.84 KB) Patch not tested, but it's quite simple. I'd like to hear some thoughts about t()ing default roles (anonymous and authenticated user). ------------------------------------------------------------------------ Tue, 09 Aug 2005 20:01:02 +0000 : Cvbge Ok, this won't work, because roles are selected from db when put on admin/access. The only way I see to solve this (although it's still not clean) is to a) make default roles editable (so user can change the 'anonymous user' to something else), but not deletable b) make sure anon user and auth user have static id c) do not check in code for name, but for role id Need to think about it...

1 0

[drupal-devel] [feature] move user-selected themes out of core
by drumm 24 Aug '05

24 Aug '05

Issue status update for http://drupal.org/node/26302 Post a follow up: http://drupal.org/project/comments/add/26302 Project: Drupal Version: cvs Component: theme system Category: feature requests Priority: normal Assigned to: TDobes Reported by: Torenware Updated by: drumm Status: patch (code needs review) +1 never thought of how easy this would be with $custom_theme. drumm Previous comments: ------------------------------------------------------------------------ Mon, 04 Jul 2005 01:50:45 +0000 : Torenware Attachment: http://drupal.org/files/issues/add-user-themable-option.diff (1.86 KB) >From the forum thread How To Prevent Users From Changing The Theme. I asked: " I'm working on a module that uses organic groups. I want to allow different groups to choose different themes, but I don't want individual users to have that capability. I'm assuming that this is easy to do, but I can't find a setting. Can anybody point me in the right direction? Thanks, Rob " At sepeck's suggestion, I'm submitting a patch to do this. It's against 4.6.0, and modifies theme.inc and system.module. It creates a variable 'configurable_user_themes' which defaults to "enabled" (4.6.0's current behavior), and if activated, makes system.module remove the UI for selected a theme, and also causes theme.inc to ignore any setting for $user->theme if it exists. ------------------------------------------------------------------------ Mon, 04 Jul 2005 01:54:40 +0000 : Torenware Attachment: http://drupal.org/files/issues/add-user-themable-option_0.diff (1.86 KB) Didn't set this to "patch" initially, so I'm including the patch again. Not sure what the procedure is just yet. ------------------------------------------------------------------------ Mon, 04 Jul 2005 05:07:44 +0000 : TDobes -1 -- sorry, but I feel that we should use a different method for this sort of thing. Any theme that is checked in the admin-> themes screen should be selectable by users. Modules should get their list of available themes from list_themes(), which provides a list of all available themes, not just those that are selected for use by users. ------------------------------------------------------------------------ Mon, 04 Jul 2005 09:21:57 +0000 : Bèr Kessels I think we should simply rename the "enabled" into "selecatble". Or any better term. For the only thing tha checkbox does is enable it for users to select. It does not enable or disable the theme at all. ------------------------------------------------------------------------ Mon, 04 Jul 2005 18:56:53 +0000 : Torenware A couple of comments: To TDobbs: for most applications, you're right. But for some applications where it's important to the site that user experience is well tested, letting individual users set the theme is something of a nightmare; a problem with the theme is perceived as a problem with the site. So for /those/ sites (such as the one I'm currently working on), letting the user set the theme was APITA. Still, for a community site, I agree that the current behavior is fine. So I made the current behavior the default. To Bèr Kessels: Let me see if I understand what you mean. Currently, I've coded the UI to say in its English default: User theme settings Configurable Themes: * Disabled * Enabled Enable or disable user-configurable themes. When enabled, users can set their own theme to override the site's default theme. Would you prefer: User theme settings Selectable Themes: * Disabled * Enabled Enable or disable user-selectable themes. When enabled, users can select their own theme to override the site's default theme. I don't really want to lose the "Disable"/"Enable" part, because if you look at the current UI in 4.6, all similar settings are done that way. So using a checkbox would be inconsistent with the rest of the page. How's that? Rob ------------------------------------------------------------------------ Mon, 04 Jul 2005 21:31:14 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/theme.png (17.19 KB) you indeed misunderstood me. We have a "enable theme" checkbox in the theme overview. That checkbos *does not enable anything* it only gives users the opportunity to select that theme. Please se the screeny (sorry, Dutch locale enabled) for what I mean. Th e second comumn. That chackbox. Just investigte its use. You will its complete and utter cruft, that checkbox. Ber ------------------------------------------------------------------------ Mon, 04 Jul 2005 23:20:55 +0000 : Torenware Ber, I have a site that may well use themes set at the group level, so unactivating the theme via admin/theme is not a great solution for me. The problem with your solution is that if a theme is deactivated, it is not available for anyone. I need multiple themes available, but need to make the rather confusing UI that appears in user/n/edit to go away. Your options will not do that. ------------------------------------------------------------------------ Mon, 04 Jul 2005 23:28:27 +0000 : Torenware Ber, /Please se the screeny (sorry, Dutch locale enabled) for what I mean. Th e second comumn. That chackbox. Just investigte its use. You will its complete and utter cruft, that checkbox./ I'm not following you. Could you please explain a bit more? Thanks, Rob ------------------------------------------------------------------------ Mon, 04 Jul 2005 23:37:13 +0000 : TDobes /I have a site that may well use themes set at the group level, so unactivating the theme via admin/theme is not a great solution for me./ Sure it is! Deactivating themes in admin->theme removes them *ONLY* from the list of themes available for users to select. It should not remove them from the list of available themes for modules to use (via. the $custom_theme variable). If themes are disappearing from the modules' lists, these are bugs in the modules and should be reported elsewhere. I was under the impression that you were writing your own module, which is why I suggested you use the list_themes function. This function returns all available themes, not just those that are selected in admin->themes. Ber has mentioned that the term "enabled" is poorly chosen and should be replaced with something else, such as "user-selectable". I agree with him. /The problem with your solution is that if a theme is deactivated, it is not available for anyone./ This is completely false. It is not available to be chosen in the "my account" screen, but it is still very readily available for use by modules through the $custom_theme variable. /I need multiple themes available, but need to make the rather confusing UI that appears in user/n/edit to go away. Your options will not do that./ Yes they do. How are you determining the list of available themes in your module? If the themes are disappearing when you deselect them from admin->themes, then your module is working improperly. ------------------------------------------------------------------------ Mon, 04 Jul 2005 23:59:25 +0000 : Torenware OK, if I'm understanding you, then indeed the UI in admin/themes is bad done enough to fool a native English speaker. What y'all from Europe make of some of the terms, I can't even guess :-) I'll see if the UI disappears if all of the items are "deactivated" makes the UI go away (and doesn't break Organic Groups...). But it sounds like the real "bug" is in the documentation. This string: / Select which themes are available to your users and specify the default theme. To configure site-wide display settings, click the "configure" task above. Alternately, to override these settings in a specific theme, click the "configure" link for the corresponding theme. / needs changing. Perhaps something like "Choose a default theme for your site, and select which themes your users can choose to override the default." For the record: I do not have a clue what "Alternately, to override these settings in a specific theme, click the "configure" link for the corresponding theme.". If someone will tell me what that means, maybe some of us can translate it into English :-) Then someone can translate it into whatever else we need to support. ------------------------------------------------------------------------ Sat, 20 Aug 2005 05:22:53 +0000 : TDobes Please see the patch I've attached to this issue [1], which renames "enabled" to "user-selectable"... this should hopefully clear up a lot of confusion. [1] http://drupal.org/node/29002 ------------------------------------------------------------------------ Sat, 20 Aug 2005 07:52:28 +0000 : robertDouglass I'd like to propose a different solution; create a "can select own theme" permission for users. I agree that there are cases where some people should be able to choose their theme and others shouldn't. Personally, I don't make many sites where you get to "skin" the site just for fun. More likely, I use theme selection for development purposes (I develop the next version of a site's theme and can switch back and forth, and so can the developer, but nobody else). If we had a permission that could be given to roles, then og group administrators could be given this permission, if I'm not mistaken. Would this fit the bill, Torenware? ------------------------------------------------------------------------ Sat, 20 Aug 2005 17:30:29 +0000 : Bèr Kessels personally I am all for removing that option alltogether. "for development reasons" is simply not a reason to leave this in. What about getting rid of this "let users select their alternative theme". And focus more on sections/themeswitchers ? ------------------------------------------------------------------------ Sat, 20 Aug 2005 18:52:03 +0000 : robertDouglass I'm not for removing it. There are a lot of efforts going forward to do things like theme an individual's blog differently (blog_theme module, I think), and this is very interesting, especially if combined with some form of theme editor. The best interface we have for choosing themes is part of the user edit page. Let's not get rid of it. What's wrong with an permission to allow users to choose their own theme? ------------------------------------------------------------------------ Sun, 21 Aug 2005 08:56:32 +0000 : Bèr Kessels There is nothnig wrong witha permission. But with the options in your profile. * Does anyone actually allow his users to choose his or her theme in the profile? I have never come across a drupal site that does this. Never! * As you state, there are loads of much better uses of personal themes, like letting a user choose a theme for his blog. Or a print theme, or a theme for better visibility. Or even a theme special for bots. sections, admin themes, etc. None of these cases benefit from the in-profile theme choice. I think this is some odd *nuke ripoff feature, that is only there, because no-one took the time to remove it. Really, have you ever seen this being used on a site? So to conclude: IMO the in-profile theme choice should go. We should focus on writing or improving modules that do advanced themeswitching. ------------------------------------------------------------------------ Sun, 21 Aug 2005 09:07:02 +0000 : robertDouglass Ok, I agree that the in-profile theme changing stuff is cruft. Better would be a module that lets users do this. It could even show up in the same place, but at least it wouldn't be in core. ------------------------------------------------------------------------ Sun, 21 Aug 2005 09:13:59 +0000 : TDobes In response to Bèr: "* Does anyone actually allow his users to choose his or her theme in the profile? I have never come across a drupal site that does this. Never! " Well, I use the feature. In fact, it was the reason I got interested in the Drupal theming system to begin with. I was extremely frustrated by users' inability to switch between chameleon styles and xtemplate templates in Drupal prior the the last major theming patch. However, I tend to agree with you that this feature could be removed from core. This sort of functionality could be added to the user profile page by a contrib module and implemented by using the $custom_theme variable. ------------------------------------------------------------------------ Sun, 21 Aug 2005 21:37:56 +0000 : Dries Agreed. Let's move this to a contributed module and let's tidy up the theme configuration page (unless I'm mistaken, the enabled-checkboxes could probably be removed?). ------------------------------------------------------------------------ Sun, 21 Aug 2005 21:43:23 +0000 : killes(a)www.drop.org Moving to cvs. I am delighted about this change. This "feature" annoyed me right from when I started to use Drupal... ------------------------------------------------------------------------ Mon, 22 Aug 2005 04:14:48 +0000 : TDobes Attachment: http://drupal.org/files/issues/no_more_user_selectable_themes.patch (5.39 KB) I've attached a patch which removes the option for selecting themes from the _user hook and the special handling of $user->theme from init_theme. While I did consider removing the "enabled" field, I decided against it. When all themes are always enabled, the number of sub-tabs of "configure" can become unmanagable. drumm's recent usability improvement [2] to the theme admin involved hiding tabs for those themes which are not enabled. Additionally, contrib modules which manipulate $custom_theme should be obtaining their list of selections by using list_themes(). Therefore, they too would benefit by displaying only those themes which have been enabled by the site admin. For example, a site admin may wish to make only certain themes available to other site developers who have the ability to switch themes in certain sections of the site. [2] http://drupal.org/node/29002 ------------------------------------------------------------------------ Mon, 22 Aug 2005 04:19:12 +0000 : TDobes Attachment: http://drupal.org/files/issues/usertheme.module.txt (3.06 KB) Here's a quick copy-and-paste module containing the code removed from core... it allows users (whom are granted the appropriate permission) to switch the theme with which they view the site. I made it as a proof-of-concept that this same functionality can easily be recreated by a standalone module.

1 0

[drupal-devel] [feature] export book as xml for formatting
by Uwe Hermann 24 Aug '05

24 Aug '05

Issue status update for http://drupal.org/node/1482 Post a follow up: http://drupal.org/project/comments/add/1482 Project: Drupal Version: cvs Component: book.module Category: feature requests Priority: normal Assigned to: puregin Reported by: BenEng Updated by: Uwe Hermann Status: patch (code needs review) Attachment: http://drupal.org/files/issues/book_30.patch (15.89 KB) Rerolled patch to improve format (diff -u -p). Uwe Hermann Previous comments: ------------------------------------------------------------------------ Sat, 05 Apr 2003 21:38:33 +0000 : 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. ------------------------------------------------------------------------ Thu, 03 Jun 2004 00:10:41 +0000 : 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) ------------------------------------------------------------------------ Tue, 01 Feb 2005 09:42:35 +0000 : 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. ------------------------------------------------------------------------ Sat, 14 May 2005 09:11:53 +0000 : 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 ------------------------------------------------------------------------ Wed, 18 May 2005 08:37:53 +0000 : 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. ------------------------------------------------------------------------ Wed, 01 Jun 2005 10:33:12 +0000 : 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. ------------------------------------------------------------------------ Fri, 03 Jun 2005 08:29:40 +0000 : 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. ------------------------------------------------------------------------ Fri, 03 Jun 2005 09:06:17 +0000 : 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 ------------------------------------------------------------------------ Fri, 03 Jun 2005 18:46:15 +0000 : 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). ------------------------------------------------------------------------ Fri, 03 Jun 2005 18:53:17 +0000 : 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? ------------------------------------------------------------------------ Fri, 03 Jun 2005 23:04:40 +0000 : 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 ------------------------------------------------------------------------ Sat, 04 Jun 2005 00:01:57 +0000 : 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 ------------------------------------------------------------------------ Sat, 04 Jun 2005 07:28:06 +0000 : 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). ------------------------------------------------------------------------ Sun, 05 Jun 2005 11:00:28 +0000 : 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. ------------------------------------------------------------------------ Mon, 06 Jun 2005 09:18:58 +0000 : 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. ------------------------------------------------------------------------ Thu, 09 Jun 2005 01:08:17 +0000 : muralik when i patch, i get this error, any clues? failed at line 321 ------------------------------------------------------------------------ Thu, 09 Jun 2005 03:11:02 +0000 : puregin 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 ------------------------------------------------------------------------ Sun, 07 Aug 2005 01:30:28 +0000 : killes(a)www.drop.org patch has been applied. ------------------------------------------------------------------------ Tue, 09 Aug 2005 14:09:00 +0000 : ax is xml export supposed to reveal the code of php-pages? have a look at http://drupal.org/book/export/docbook/3 for an example. this strikes me as a security issue, so i'm marking this ACTIVE. ------------------------------------------------------------------------ Tue, 23 Aug 2005 21:30:40 +0000 : puregin Attachment: http://drupal.org/files/issues/book.module_6.patch (13.62 KB) The attached patch for book module implements the following changes * new XML export format includes all attributes required for re-import, supports book import (which I am going to provide as a contributed module) * DocBook XML export functionality has been removed (to a separate module) * Re-architected book_export() to enable external modules to provide support for different kinds of export I have not addressed ax's concert re: visibility of PHP code. I agree this is important. We could introduce a new permission: 'export books', or go for something more granular, 'export PHP code in books'. What would people prefer to see here? Djun

1 0