August 2005 - Development - lists.drupal.org

[drupal-devel] [bug] request_uri() broken if in subdir
by Robin Monks 09 Aug '05

09 Aug '05

Issue status update for http://drupal.org/node/10917 Post a follow up: http://drupal.org/project/comments/add/10917 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal -Assigned to: Robin Monks +Assigned to: Anonymous Reported by: killes(a)www.drop.org Updated by: Robin Monks Status: patch (code needs work) I'm removing myself from this bug, as I can't adequately understand it to make a quality patch. Robin Robin Monks Previous comments: ------------------------------------------------------------------------ Fri, 17 Sep 2004 19:05:57 +0000 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/requi.patch (678 bytes) We asumme the $_SERVER[REQUEST_URI] would contain only the url from the point of Drupal's directory on. This is true only iff you run from the root of your site. If you are in a subdir, the function request_uri() will be unusable if we want to construct a valid url from $base_url and request_uri() (what we do in a number of places). The attached patch fixes this by using basename(). ------------------------------------------------------------------------ Fri, 17 Sep 2004 19:45:26 +0000 : killes(a)www.drop.org The patch doesn't suffice if your access only the base_url of your Drupal site in a subdir. Putting on hold. ------------------------------------------------------------------------ Fri, 17 Sep 2004 21:39:36 +0000 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/request.patch (761 bytes) ok, I think I got it. The distinction between apache and non-apache servers went away to keep it simple. ------------------------------------------------------------------------ Sat, 18 Sep 2004 00:19:57 +0000 : killes(a)www.drop.org Apparently the action in forms depends on the bug that I found, ie it needs request_uri to contain the full url (from documentroot on). ------------------------------------------------------------------------ Sat, 18 Sep 2004 00:53:24 +0000 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/request_0.patch (2.46 KB) This new patch fixes the problem with forms. request_uri() also does not start with a leading slash anymore. Ask Steven for why this is good. http://acko.net/dumpx/relative.html is apparently a clue I don't get. ------------------------------------------------------------------------ Sat, 18 Sep 2004 01:04:41 +0000 : Steven Explanation: People are going to stick relative_uri() into links. These links are resolved relative to the $base_url which is put into the <head> tag. However, if a link URI starts with a / then it is relative to the root of the site, even if the base tag uses a path with a subdirectory. Example: <html> <base href="http://www.test.com/subdir1/"> <body> test [1] test [2] </body> </html> The first link resolves to http://www.test.com/subdir2, the second resolves to http://www.test.com/subdir1/subdir2. Thus, it is more meaningful to not have a leading slash, as this will avoid possible bugs with subdirs (which often do not get caught because the tester uses a site without a subdir) and hints at the callee that this is a relative URI too. [1] http://drupal.org//subdir2 [2] http://drupal.org/subdir2 ------------------------------------------------------------------------ Sun, 13 Mar 2005 18:38:21 +0000 : Chris Johnson Patch no longer applies completely to bootstrap.inc: Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: includes/bootstrap.inc |=================================================================== |RCS file: /cvs/drupal/drupal/includes/bootstrap.inc,v |retrieving revision 1.28 |diff -u -F^f -r1.28 bootstrap.inc |--- includes/bootstrap.inc 16 Sep 2004 07:17:54 -0000 1.28 |+++ includes/bootstrap.inc 18 Sep 2004 00:52:12 -0000 -------------------------- Patching file bootstrap.inc using Plan A... Hunk #1 succeeded at 273 (offset 83 lines). Hunk #2 succeeded at 292 (offset 83 lines). Hunk #3 failed at 446. 1 out of 3 hunks failed--saving rejects to bootstrap.inc.rej Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: includes/common.inc |=================================================================== |RCS file: /cvs/drupal/drupal/includes/common.inc,v |retrieving revision 1.390 |diff -u -F^f -r1.390 common.inc |--- includes/common.inc 16 Sep 2004 16:12:21 -0000 1.390 |+++ includes/common.inc 18 Sep 2004 00:52:12 -0000 -------------------------- Patching file common.inc using Plan A... Hunk #1 succeeded at 988 (offset -90 lines). done ------------------------------------------------------------------------ Tue, 14 Jun 2005 11:21:49 +0000 : Robin Monks Attachment: http://drupal.org/files/issues/request_uri.broken.if.in.subdir.patch (2.6 KB) Here is that patch re-rolled for latest CVS HEAD. Since killes hasn't been active in this bug lately, I hope he won't mind my reassigning this to myself. Robin ------------------------------------------------------------------------ Tue, 14 Jun 2005 11:22:40 +0000 : Robin Monks I've also tested this to work on CVS HEAD. Robin ------------------------------------------------------------------------ Tue, 14 Jun 2005 13:33:52 +0000 : moshe weitzman did you test this on non apache servers? the comment that you removed is crystal clear about a need for 2 different cases. it is OK to 'make it simpler' as long as you don't remove compatibility with other web servers. I am primarily concerned with IIS. ------------------------------------------------------------------------ Tue, 14 Jun 2005 14:42:44 +0000 : Robin Monks I took great care to ensure I didn't remove any support needed for other servers. I also tested this patch to work on Xitami on Win32. Robin ------------------------------------------------------------------------ Tue, 14 Jun 2005 17:09:29 +0000 : Robin Monks I spent some more time testing, and this broke some (perhaps all) configuration forms. It appears the / is needed after all. Perhaps killes will have better luck understanding this, the / is needed IMHO. Robin ------------------------------------------------------------------------ Fri, 01 Jul 2005 13:20:27 +0000 : killes(a)www.drop.org Another manifestation of this bug: http://drupal.org/node/26163 ------------------------------------------------------------------------ Tue, 09 Aug 2005 17:26:44 +0000 : killes(a)www.drop.org Another occurrence: http://drupal.org/node/20555

1 0

[drupal-devel] [bug] request_uri() broken if in subdir
by killes 09 Aug '05

09 Aug '05

Issue status update for http://drupal.org/node/10917 Post a follow up: http://drupal.org/project/comments/add/10917 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Robin Monks Reported by: killes(a)www.drop.org Updated by: killes(a)www.drop.org -Status: patch (code needs review) +Status: patch (code needs work) Another occurrence: http://drupal.org/node/20555 killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ Fri, 17 Sep 2004 19:05:57 +0000 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/requi.patch (678 bytes) We asumme the $_SERVER[REQUEST_URI] would contain only the url from the point of Drupal's directory on. This is true only iff you run from the root of your site. If you are in a subdir, the function request_uri() will be unusable if we want to construct a valid url from $base_url and request_uri() (what we do in a number of places). The attached patch fixes this by using basename(). ------------------------------------------------------------------------ Fri, 17 Sep 2004 19:45:26 +0000 : killes(a)www.drop.org The patch doesn't suffice if your access only the base_url of your Drupal site in a subdir. Putting on hold. ------------------------------------------------------------------------ Fri, 17 Sep 2004 21:39:36 +0000 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/request.patch (761 bytes) ok, I think I got it. The distinction between apache and non-apache servers went away to keep it simple. ------------------------------------------------------------------------ Sat, 18 Sep 2004 00:19:57 +0000 : killes(a)www.drop.org Apparently the action in forms depends on the bug that I found, ie it needs request_uri to contain the full url (from documentroot on). ------------------------------------------------------------------------ Sat, 18 Sep 2004 00:53:24 +0000 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/request_0.patch (2.46 KB) This new patch fixes the problem with forms. request_uri() also does not start with a leading slash anymore. Ask Steven for why this is good. http://acko.net/dumpx/relative.html is apparently a clue I don't get. ------------------------------------------------------------------------ Sat, 18 Sep 2004 01:04:41 +0000 : Steven Explanation: People are going to stick relative_uri() into links. These links are resolved relative to the $base_url which is put into the <head> tag. However, if a link URI starts with a / then it is relative to the root of the site, even if the base tag uses a path with a subdirectory. Example: <html> <base href="http://www.test.com/subdir1/"> <body> test [1] test [2] </body> </html> The first link resolves to http://www.test.com/subdir2, the second resolves to http://www.test.com/subdir1/subdir2. Thus, it is more meaningful to not have a leading slash, as this will avoid possible bugs with subdirs (which often do not get caught because the tester uses a site without a subdir) and hints at the callee that this is a relative URI too. [1] http://drupal.org//subdir2 [2] http://drupal.org/subdir2 ------------------------------------------------------------------------ Sun, 13 Mar 2005 18:38:21 +0000 : Chris Johnson Patch no longer applies completely to bootstrap.inc: Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: includes/bootstrap.inc |=================================================================== |RCS file: /cvs/drupal/drupal/includes/bootstrap.inc,v |retrieving revision 1.28 |diff -u -F^f -r1.28 bootstrap.inc |--- includes/bootstrap.inc 16 Sep 2004 07:17:54 -0000 1.28 |+++ includes/bootstrap.inc 18 Sep 2004 00:52:12 -0000 -------------------------- Patching file bootstrap.inc using Plan A... Hunk #1 succeeded at 273 (offset 83 lines). Hunk #2 succeeded at 292 (offset 83 lines). Hunk #3 failed at 446. 1 out of 3 hunks failed--saving rejects to bootstrap.inc.rej Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: includes/common.inc |=================================================================== |RCS file: /cvs/drupal/drupal/includes/common.inc,v |retrieving revision 1.390 |diff -u -F^f -r1.390 common.inc |--- includes/common.inc 16 Sep 2004 16:12:21 -0000 1.390 |+++ includes/common.inc 18 Sep 2004 00:52:12 -0000 -------------------------- Patching file common.inc using Plan A... Hunk #1 succeeded at 988 (offset -90 lines). done ------------------------------------------------------------------------ Tue, 14 Jun 2005 11:21:49 +0000 : Robin Monks Attachment: http://drupal.org/files/issues/request_uri.broken.if.in.subdir.patch (2.6 KB) Here is that patch re-rolled for latest CVS HEAD. Since killes hasn't been active in this bug lately, I hope he won't mind my reassigning this to myself. Robin ------------------------------------------------------------------------ Tue, 14 Jun 2005 11:22:40 +0000 : Robin Monks I've also tested this to work on CVS HEAD. Robin ------------------------------------------------------------------------ Tue, 14 Jun 2005 13:33:52 +0000 : moshe weitzman did you test this on non apache servers? the comment that you removed is crystal clear about a need for 2 different cases. it is OK to 'make it simpler' as long as you don't remove compatibility with other web servers. I am primarily concerned with IIS. ------------------------------------------------------------------------ Tue, 14 Jun 2005 14:42:44 +0000 : Robin Monks I took great care to ensure I didn't remove any support needed for other servers. I also tested this patch to work on Xitami on Win32. Robin ------------------------------------------------------------------------ Tue, 14 Jun 2005 17:09:29 +0000 : Robin Monks I spent some more time testing, and this broke some (perhaps all) configuration forms. It appears the / is needed after all. Perhaps killes will have better luck understanding this, the / is needed IMHO. Robin ------------------------------------------------------------------------ Fri, 01 Jul 2005 13:20:27 +0000 : killes(a)www.drop.org Another manifestation of this bug: http://drupal.org/node/26163

1 0

[drupal-devel] [bug] Small patch to sort "new users" correctly
by killes 09 Aug '05

09 Aug '05

Issue status update for http://drupal.org/node/18778 Post a follow up: http://drupal.org/project/comments/add/18778 Project: Drupal Version: cvs Component: user system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: Olen Updated by: killes(a)www.drop.org -Status: active +Status: patch (ready to be committed) Attachment: http://drupal.org/files/issues/usersort.patch (767 bytes) Right. killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ Sat, 12 Mar 2005 10:53:00 +0000 : Olen After importing and merging several drupal installastions, i came across this "bug". Nothing important, but I think it's better to sort the users after "created" than "uid" when getting the latest aditions. --- user.module.orig 2005-03-12 11:48:54.485881868 +0100 +++ user.module 2005-03-12 11:49:06.146192209 +0100 @@ -526,7 +526,7 @@ case 2: if (user_access('access content')) { - $result = db_query_range('SELECT uid, name FROM {users} WHERE status != 0 ORDER BY uid DESC', 0, 5); + $result = db_query_range('SELECT uid, name FROM {users} WHERE status != 0 ORDER BY created DESC', 0, 5); while ($account = db_fetch_object($result)) { $items[] = format_name($account); }

1 0

[drupal-devel] [bug] Some URLs get ?PHPSESSID added to them
by djnz 09 Aug '05

09 Aug '05

Issue status update for http://drupal.org/node/4109 Post a follow up: http://drupal.org/project/comments/add/4109 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Eric Scouten Reported by: Eric Scouten Updated by: djnz Status: patch (code needs review) Attachment: http://drupal.org/files/issues/both_sid_patches.patch (1.39 KB) Yes, you are both right - I was being too kind to the code just FALSEing it out, it should just be deleted. I don't want to lose the url_rewriter.tags patch though so the attached patch has both. djnz Previous comments: ------------------------------------------------------------------------ Thu, 13 Nov 2003 00:22:39 +0000 : Eric Scouten Some URLs get ?PHPSESSID=(whatever) added to them. I find this distracting and unnecessary for anonymous users. Submitting patch #147 for consideration to remove this issue. ------------------------------------------------------------------------ Fri, 05 Dec 2003 14:39:25 +0000 : Kjartan This is a local PHP configuration issue. Don't see it as something Drupal should mess with, the less PHP settings Drupal messes with the better. ------------------------------------------------------------------------ Fri, 05 Dec 2003 15:11:33 +0000 : killes(a)www.drop.org Could you elaborate which config setting one has to tweak? ------------------------------------------------------------------------ Fri, 05 Dec 2003 15:18:11 +0000 : Anonymous php_flag session.use_trans_sid off php_flag session.use_only_cookies on The first will disable the automatic addition of the session ID to internal URLs, the second will remove support for passing session IDs in URLs. See http://php.net/session [1] for more info. BTW the above settings are for Apache, in PHP.ini you should not add the php_flag part, and you should use = inbetween the name and value... [1] http://php.net/session ------------------------------------------------------------------------ Mon, 07 Jun 2004 22:42:06 +0000 : shane It seems that Drupal (via the .htaccess file) already "messes with" a bunch of PHP settings. For example, my Drupal install "came with" these messed with settings: php_value register_globals 0 php_value track_vars 1 php_value short_open_tag 1 php_value magic_quotes_gpc 0 php_value magic_quotes_runtime 0 php_value magic_quotes_sybase 0 php_value arg_separator.output "&" php_value session.cache_expire 200000 php_value session.gc_maxlifetime 200000 php_value session.cookie_lifetime 2000000 php_value session.auto_start 0 php_value session.save_handler user php_value session.cache_limiter none php_value allow_call_time_pass_reference On I'm not sure that adding two more "php_value" flags to the stock .htaccess file is going to arguably mess with more than already is. Personally I find it extremely un-professional and very un-clean to have funky PHPSESSID url strings tacked onto a majority of my URLs. I've worked extremely hard to implement clean URLs (above and beyond the already great "clean url" feature of Drupal - I don't like them being turned into muck. I'd vote that these two flags be added to the .htaccess file that is distributed with Drupal. However, I'm uncertain of the overall true impact of making these changes, so barring an technical reason - I would absolutely request this as a feature. I've implemented these in many of my production sites already (just today) - we'll see what impact they have. ------------------------------------------------------------------------ Tue, 08 Jun 2004 02:56:00 +0000 : marky It's a performance thing. You need to remember that while not everyone has edit access to php.ini, those of us that do control our own servers see no need for .htaccess directives that set php options. >From the Apache docs [2]: "Apache will look in every directory for .htaccess files. Thus, permitting .htaccess files causes a performance hit, whether or not you actually even use them! Also, the .htaccess file is loaded every time a document is requested." Ok, I'm lucky in that I control my own server, so I can effectively remove the .htaccess file and move its config options to php.ini and the vhost section of httpd.conf, thus speeding up the responsiveness of my server. But if you don't have that option there's nothing wrong with adding those directives to your directory .htaccess file. That's what it's for - it allows directory specific config options for those that don't have access to their server config. As Kjartan said, "the less PHP settings Drupal messes with the better". I've got to agree - as far as I'm concerned it's already big enough. The "php_value short_open_tag 1", "php_value session.auto_start 0" and "php_value session.cache_limiter none" for example serve little purpose, as they mirror the installation default settings (apart from the last, where the available options are: nocache, private or public). If you don't have the choice, use .htaccess, and add whatever directives you see fit. But please remember that not everyone uses it. Anyway, just my 2 beads. [2] http://httpd.apache.org/docs-2.0/howto/htaccess.html#when ------------------------------------------------------------------------ Tue, 08 Jun 2004 04:38:32 +0000 : cel4145 Why not add them, but commented out with an explanation? When I encountered this problem, I had to spend a little time on drupal.org finding the solution. However, I am familiar with the .htaccess file from doing installs. If it had been included there commented out, I would have probably remembered it. After all, this is much the same way that httpd.conf functions with it's many, optional, commented out configuration options. Just makes it easier when a non-standard configuration option has to be used. Besides, I've also seen many Drupal sites with this problem. I suspect that some of those sites would have implemented these flags if they had been an option in the .htaccess file. And it looks bad. People that visit the sites that don't know any better will assume it's Drupal, not the lack of proper PHP settings. ------------------------------------------------------------------------ Tue, 08 Jun 2004 10:39:27 +0000 : killes(a)www.drop.org It wouldn't hurt if Drupal had a better documented and possibly extended .htaccess file. Those who whish not to use it should really not care... session.save_handler = user should probably included as well. ------------------------------------------------------------------------ Tue, 08 Jun 2004 12:17:06 +0000 : robertDouglass If you use these settings: php_flag session.use_trans_sid off php_flag session.use_only_cookies on won't it make it so that people with cookies disabled cannot have session state? And if the PHPSESSID is in the URL, isn't that an indication that the browser being used refused to take a cookie? I'd really like clarification on this, if anyone knows the answers. ------------------------------------------------------------------------ Tue, 27 Jul 2004 13:25:46 +0000 : JonBob The original issue is definitely by design, as these URLs need the session ID to preserve the session when running under the given PHP settings. A better-documented .htaccess is a different issue entirely. ------------------------------------------------------------------------ Thu, 19 Aug 2004 18:04:13 +0000 : gtoddv It hasn't been mentioned in this thread or anywhere else that I can find, but this session ID issue breaks validation. I don't know is this will cause accessibility issues too. I have tried the .htaccess fix and that doesn't change anything. ------------------------------------------------------------------------ Sat, 06 Nov 2004 07:17:21 +0000 : wazdog The non-validating problem is another problem with your server setup. PHP can be setup to used encoded &'s or not. Your server isn't if the url isn't validating. You'd have to talk to your server admin to fix that. ------------------------------------------------------------------------ Thu, 30 Dec 2004 20:32:35 +0000 : m_freeman2004 This is what you have to include in the .htaccess file: # Fix for ?PHPSESSID in clean URLs php_value session.use_trans_sid 0 php_value session.use_only_cookies 1 # End of fix ------------------------------------------------------------------------ Wed, 01 Jun 2005 19:07:53 +0000 : dr05 The code in .htaccess file: # Fix for ?PHPSESSID in clean URLs php_value session.use_trans_sid 0 php_value session.use_only_cookies 1 # End of fix don't work! Error: "Internal Server Error!" ------------------------------------------------------------------------ Thu, 14 Jul 2005 15:25:22 +0000 : jasonwhat Anyone else looking into this? Can one get rid of the id added onto the url but still keep the sessions going? ------------------------------------------------------------------------ Mon, 25 Jul 2005 06:16:22 +0000 : Eric Scouten dr05, what version of Apache and what OS are you using? I've been using this same patch with no problems on Mac OS X, Linux, and FreeBSD-based servers using both Apache 1.3.x and 2.0.x. Attached patch will apply these changes to .htaccess. (IMHO, this is useful for the majority of users; those who are smart enough to understand the performance issues can comment out these lines.) ------------------------------------------------------------------------ Mon, 25 Jul 2005 06:57:18 +0000 : clydefrog You forgot the patch, Eric. ------------------------------------------------------------------------ Mon, 25 Jul 2005 08:02:26 +0000 : Eric Scouten Attachment: http://drupal.org/files/issues/htaccess-no-session-ids.patch (383 bytes) D'oh! ------------------------------------------------------------------------ Mon, 25 Jul 2005 08:45:48 +0000 : kbahey There are cases where no parameter will fix this issue. On shared hosting systems where you do not have access to php.ini, and the hosting company has setup things in a way that they cannot be overriden. I found this out the hard way, after lobbying for the settings to be included in the init_set() statements in the settings.php prior to 4.6 being released. They are simply ignored on some hosts. On other hosts, you need to have a php.ini of your own, if suphp or SuExec is being used. In some cases, the only way to make things work is to compile your own PHP as a CGI (detailed writeup) [3]. This can have disadvantages too, such some performance impact, as well as excessive CPU utilization (hosting company may not like it). [3] http://baheyeldin.com/drupal/how-to-get-rid-of-phpsessid-in-drupal-and-othe… ------------------------------------------------------------------------ Mon, 25 Jul 2005 08:49:31 +0000 : kbahey Here is some references: issue 21170 [4], and a forum discussion [5]. [4] http://drupal.org/node/21170 [5] http://drupal.org/node/17947 ------------------------------------------------------------------------ Sat, 30 Jul 2005 16:24:47 +0000 : ufku in my case (shared hosting, ini_set() disabled) a php.ini file with only this line in it solved the problem. url_rewriter.tags = '' you should place the php.ini in your site's base directory ------------------------------------------------------------------------ Sun, 07 Aug 2005 12:18:31 +0000 : djnz Attachment: http://drupal.org/files/issues/rewrite_tags.patch (468 bytes) Drupal already attempts to change a number of values using ini_set() in settings.php, including session.use_trans_sid which should cure this problem. Unfortunately as already noted elsewhere [6], session.use_trans_sid only worked in ini_set() up to PHP 4.2.3. Rather than change the whole philosophy and change this setting in .htaccess or php.ini (neither of which work for many hosted set-ups), surely the answer is to correct settings.php as described The attached patch does just that - it is only one line. Note that session ids are still appended to the url when redirecting by Drupal eg after a POST. This is also easily patched [7], but as it is done deliberately (why?) I have left it alone. [6] http://drupal.org/node/17947#comment-36339 [7] http://drupal.org/node/25852#comment-45111 ------------------------------------------------------------------------ Sun, 07 Aug 2005 13:26:17 +0000 : kbahey PHPSESSIDs in the URL are a) ugly, b) negatively affects search engine indexing, and most importantly, c) is a security risk that can enable a malicious user to hijack your session. We should work on a solution to eliminate this once and for all, and for all configurations. The current approach (putting some PHP parameters in settings.php, or instructing users to change them in .htaccess or php.ini) has severe shorcomings: Whatever we do, there are bound to be some configurations that no amount of PHP parameters will cure. Some hosts deny their users the ability to change some or all of the above parameters. I discovered this the painful way with many hosts I have used, and friends and clients I have helped. I think we need to rethink this whole session thing, in a way that we are not dependant on idiosyncracies of various hosts and PHP configurations. Perhaps attempt to set a DRUPAL cookie and not maintain a session unless we are able to set it. This way we know that we will not have a PHPSESSID in the URL. If we are not able to set the cookie, then we allow only anonymous access that is sessionless.. I am not sure if that will work or not: what other options do we have here? ------------------------------------------------------------------------ Sun, 07 Aug 2005 22:02:19 +0000 : djnz I am convinced that ini_set('url_rewriter.tags','') is the answer. I find it hard to believe that any host would go to the trouble to disable this (not just a matter of setting compile time paramaters, you would have to hack the PHP source; and why would they?) - certainly no cPanel host I have used does. The reason the code currently in settings.php doesn't work is not because hosts disable it, it is because PHP does not support it. RTFM. ------------------------------------------------------------------------ Sun, 07 Aug 2005 22:23:59 +0000 : djnz Attachment: http://drupal.org/files/issues/trans_sid.patch (1.4 KB) After further thought, there really is no point in appending the SID to a redirect url, so the attached patch solves this problem too. If anyone has a problem with session IDs in URLs after applying this patch, I'll offer them free hosting myself. Maybe. ;) ------------------------------------------------------------------------ Mon, 08 Aug 2005 03:14:41 +0000 : kbahey You are right about the fact that the use of PHPSESSID in the URL on a redirect is totally unnecessary. That line should be removed from the base code altogether, there is no excuse for it. As for url_rewriter.tags, I am not 100% sure, but I tried it with someone who was facing difficulties, and it did not work as far as I can recall. In any case, your solution should go in base. It cannot hurt, unless some host has disabled it. ------------------------------------------------------------------------ Mon, 08 Aug 2005 20:09:40 +0000 : moshe weitzman yeah, i think that is cruft. ------------------------------------------------------------------------ Mon, 08 Aug 2005 21:15:29 +0000 : kbahey Attachment: http://drupal.org/files/issues/common.inc-trans_sid.patch (759 bytes) Actually, since the code in common.inc should not fiddle with PHPSESSID in URL in the first place, why not junk that whole section of the code altogether? A patch for common.inc is attached that removes this whole section. As Moshe said, this is cruft.

1 0

[drupal-devel] [bug] url() does not obey $absolute parameter properly
by crunchywelch 09 Aug '05

09 Aug '05

Issue status update for http://drupal.org/node/28491 Post a follow up: http://drupal.org/project/comments/add/28491 Project: Drupal Version: 4.6.0 Component: base system Category: bug reports Priority: critical Assigned to: crunchywelch Reported by: crunchywelch Updated by: crunchywelch Status: patch (code needs review) in common.inc the url() function inverts the treatment of the $absolute parameter on line 1467 in v4.6: $base = ($absolute ? $base_url .'/' : ''); This prepends the $base_url to the path if $absolute is TRUE, which is inverted logic, it should be: $base = ($absolute ? '' : $base_url .'/'); This is still a problem in cvs, but I dont have the line number. I can submit a proper patch if needed. crunchywelch

2 1

[drupal-devel] [feature] Send copy of Contact submission to sender's email
by Robin Monks 09 Aug '05

09 Aug '05

Issue status update for http://drupal.org/node/26236 Post a follow up: http://drupal.org/project/comments/add/26236 Project: Drupal Version: cvs Component: contact.module Category: feature requests Priority: normal Assigned to: Robin Monks Reported by: mjohnson16 Updated by: Robin Monks Status: patch (ready to be committed) Attachment: http://drupal.org/files/issues/send_copy_contact.patch (2.66 KB) Here is the same patch, using "Send me a copy.". #5 still applies, should you like "Send a copy of this to me." better. Ready to commit :) Robin Robin Monks Previous comments: ------------------------------------------------------------------------ Sat, 02 Jul 2005 13:53:57 +0000 : mjohnson16 When using the contact form to send a message to another user, it would be nice if a copy of the sent message was sent to the sender's email address. This would allow for an easy way to archive those messages for reference. ------------------------------------------------------------------------ Sun, 03 Jul 2005 00:53:08 +0000 : Robin Monks I'll take this one. Robin ------------------------------------------------------------------------ Tue, 05 Jul 2005 22:45:17 +0000 : Robin Monks Attachment: http://drupal.org/files/issues/contact.module.patch (1.56 KB) Here is my best shot. This allows users to have a copy of their message sent to themselves. Useful for those who like to keep records of emails. Robin ------------------------------------------------------------------------ Wed, 06 Jul 2005 03:53:05 +0000 : Nathan_ +1 for this patch. I tested it against HEAD, and it works perfectly. One thing I would suggest is that the option also apply to the person contact forms as well. I am not sure if this was in the original request, but I think, especially on community sites, users might like to a have a reccord of peer to peer correspondance. Just my 2cents. ------------------------------------------------------------------------ Wed, 06 Jul 2005 11:52:27 +0000 : kbahey I did not test the patch, but I support the functionality. +1 for me. ------------------------------------------------------------------------ Wed, 13 Jul 2005 12:48:40 +0000 : Robin Monks Attachment: http://drupal.org/files/issues/contact..copy.module.patch (2.65 KB) Here is a second patch, which also provides a copy checkbox in user contact forms. Robin ------------------------------------------------------------------------ Tue, 09 Aug 2005 15:09:47 +0000 : tostinni The help sentence "Send a copy of this to me." sounds to me a little bad... IMHO I would prefer had something like "Send me a copy." or "Receive a copy of the email." because I don't like very much using "this"...

1 0

[drupal-devel] [feature] Send copy of Contact submission to sender's email
by tostinni 09 Aug '05

09 Aug '05

Issue status update for http://drupal.org/node/26236 Post a follow up: http://drupal.org/project/comments/add/26236 Project: Drupal Version: cvs Component: contact.module Category: feature requests Priority: normal Assigned to: Robin Monks Reported by: mjohnson16 Updated by: tostinni Status: patch (ready to be committed) The help sentence "Send a copy of this to me." sounds to me a little bad... IMHO I would prefer had something like "Send me a copy." or "Receive a copy of the email." because I don't like very much using "this"... tostinni Previous comments: ------------------------------------------------------------------------ Sat, 02 Jul 2005 13:53:57 +0000 : mjohnson16 When using the contact form to send a message to another user, it would be nice if a copy of the sent message was sent to the sender's email address. This would allow for an easy way to archive those messages for reference. ------------------------------------------------------------------------ Sun, 03 Jul 2005 00:53:08 +0000 : Robin Monks I'll take this one. Robin ------------------------------------------------------------------------ Tue, 05 Jul 2005 22:45:17 +0000 : Robin Monks Attachment: http://drupal.org/files/issues/contact.module.patch (1.56 KB) Here is my best shot. This allows users to have a copy of their message sent to themselves. Useful for those who like to keep records of emails. Robin ------------------------------------------------------------------------ Wed, 06 Jul 2005 03:53:05 +0000 : Nathan_ +1 for this patch. I tested it against HEAD, and it works perfectly. One thing I would suggest is that the option also apply to the person contact forms as well. I am not sure if this was in the original request, but I think, especially on community sites, users might like to a have a reccord of peer to peer correspondance. Just my 2cents. ------------------------------------------------------------------------ Wed, 06 Jul 2005 11:52:27 +0000 : kbahey I did not test the patch, but I support the functionality. +1 for me. ------------------------------------------------------------------------ Wed, 13 Jul 2005 12:48:40 +0000 : Robin Monks Attachment: http://drupal.org/files/issues/contact..copy.module.patch (2.65 KB) Here is a second patch, which also provides a copy checkbox in user contact forms. Robin

1 0

[drupal-devel] [bug] blocked users have been members since unix epoch
by Robin Monks 09 Aug '05

09 Aug '05

Issue status update for http://drupal.org/node/25325 Post a follow up: http://drupal.org/project/comments/add/25325 Project: Drupal Version: cvs Component: user.module Category: bug reports Priority: minor Assigned to: viksit Reported by: deekayen Updated by: Robin Monks Status: patch (code needs work) -1 from me too. This has far reaching consequences. Can't we just fix the date query? Robin Robin Monks Previous comments: ------------------------------------------------------------------------ Sun, 19 Jun 2005 22:15:34 +0000 : deekayen Attachment: http://drupal.org/files/issues/blockeduserepoch.png (4.15 KB) Once a user has been switched from active to blocked state in user administration, their "Member since:" date shows since UNIX epoch. ------------------------------------------------------------------------ Thu, 23 Jun 2005 05:10:18 +0000 : deekayen So far I blame the query in user_load() which comes out something like: SELECT u.* FROM users u WHERE u.uid = 3 AND LOWER(u.status) = '1' AND u.status < 3 LIMIT 0, 1 Then user_load() never calls user_module_invoke() in the db_num_rows() if statement because blocked users don't return because of the LOWER(u.status) = '1' in the query. So when user_user does math on an empty $user object, the date comes out wrong when loading the view page on a blocked user. I don't know why the if statement of user_view() forces 'status' => 1, but if you remove it, the blocked user "Member since" date is corrected. function user_view($uid = 0) { global $user; if ($account = user_load(array('uid' => $uid))) { The only call I saw for user_view() in grep was in user_page(). One of the side effects of this bug was blocked users didn't have anything show under their History part of their View tab. For example, removing 'status' => 1 will show "view recent blog entries" if you have blog.module loaded. I don't really think that's my position to say if that's a desireable behavior or not, so I'll just leave this hanging. I also don't really know what status > 1 would mean, so it might instead be desireable to make a change so the query in user_load() grabs LOWER(u.status) <= '1'. ------------------------------------------------------------------------ Tue, 28 Jun 2005 21:26:53 +0000 : viksit Looking at it. ------------------------------------------------------------------------ Tue, 28 Jun 2005 21:33:45 +0000 : viksit Ah, assigned. ------------------------------------------------------------------------ Sat, 02 Jul 2005 19:38:50 +0000 : viksit Attachment: http://drupal.org/files/issues/user.module_4.patch (415 bytes) Well, I tried alternate approaches, but what seemed to work best was as suggested above. The patch's attached here.. Cheers, ------------------------------------------------------------------------ Sun, 03 Jul 2005 21:25:54 +0000 : viksit uploaded above.. ------------------------------------------------------------------------ Mon, 08 Aug 2005 10:42:49 +0000 : Bèr Kessels Hmm, I dislike the idea of this. Simply taking out that status =1 parameter, will show blocked users on certain areas, where you /dont/ want them to show up at all. The user page, for one, must not be accessible for users that are blocked.

1 0

[drupal-devel] [bug] comment preview "Required" is easily bypassed
by Jeremy 09 Aug '05

09 Aug '05

Issue status update for http://drupal.org/node/28420 Post a follow up: http://drupal.org/project/comments/add/28420 Project: Drupal Version: cvs Component: comment.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: Jeremy(a)kerneltrap.org Updated by: Jeremy(a)kerneltrap.org Status: patch (code needs review) Attachment: http://drupal.org/files/issues/comment.module_13.patch (1.33 KB) > I think it misses something, like some timestamp related hash, because > once you get the hash code you can post multiple comments with that. Using a timestamp will mean that the comment form "expires". That is, if you wait too long to preview your comment, it will generate an error when you try to post. Yes, technically a spammer could post one real comment, then based on what was in the session from that they could post the same identical comment over and over, so long as it was attached to the same node. But this is not what they do, they try and spread their spam throughout your webpage. Furthermore, the spam module is perfectly capable of detecting and preventing this. > Another problem I can think of is, what happens when a cron run happens > between the preview and the post?? I'm afraid comments would get lost The key is only generated once, that's what the first test is about. In any case, in the unlikely event that the key were to change between preview and post they would simply have to post a second time. My earlier patch wasn't quite right, I was testing the token in the wrong place. This patch fixes that. BTW: This is beneficial for maintaining high quality submissions too, as prior to this change someone could: 1) enter a comment 2) press preview 3) completely change their comment (introducing a mistake) 4) press submit and the comment (mistake and all) would go into the database unpreviewed After this change: 1) enter a comment 2) press preview 3) completely change their comment (introducing a mistake) 4) press submit and they get an error because they didn't preview their changes - forcing them to preview once after any change Jeremy(a)kerneltrap.org Previous comments: ------------------------------------------------------------------------ Mon, 08 Aug 2005 01:55:34 +0000 : Jeremy(a)kerneltrap.org Setting "Preview comment" to "Required" does not strictly require that the comment be previewed first. This is being abused by spammers to quickly and efficiently post spam comments. I discovered this after I added a new feature to my new spam module [1] to auto-blacklist spammer IP addresses, allowing me to block comment spammers when they preview a comment and thus preventing them from ever inserting their spam into my database. I configured my comment module to "require" comment previews, and yet found that the comments were slipping past my filter. I finally realized what the spammer is doing is setting $_POST['op'] to 'Post comment', effectively bypassing the preview phase. I'm currently looking for a clean solution to this. At the moment the only idea I have is to generate a token at the preview phase, and validate the token at the post phase. Unfortunately the token would have to be stored in the databse between the preview and the post, which adds overhead. Alternatively, I've considered using a time-based hash which would constantly update depending on the time of day. This could easily be validated without storing anything in the database. If too long has gone between the preview and the post, an additional preview step would be required... The down side here is that the time-based hash would be publically available, and thus the spammer could easily duplicate it in their script. A private key could solve for that, but increases the complexity as it adds a configuration step. I have the feeling I'm missing a simpler, cleaner solution. Suggestions? [1] http://kerneltrap.org/jeremy/drupal/spam/ ------------------------------------------------------------------------ Mon, 08 Aug 2005 02:26:21 +0000 : moshe weitzman even if you get this fixed, won't these bots just add a preview step? this 'preview required' feature is designed to maintain high quality submissions by forcing users to proof read. it isn;t designed for security. i think you want to hook into comment_validate(). just add a hook here - there is already a hook_comment() waiting for you to add an operation. ------------------------------------------------------------------------ Mon, 08 Aug 2005 08:49:30 +0000 : Eaton I posted a patch a few days ago (http://drupal.org/node/28255) that adds validation and form construction hooks for comments. It's similar to the one that the captcha module uses, though it adds comment form_pre and form_post hooks instead of a single comment form hook. ------------------------------------------------------------------------ Mon, 08 Aug 2005 13:30:34 +0000 : Jeremy(a)kerneltrap.org Attachment: http://drupal.org/files/issues/comment.module_11.patch (2.5 KB) > even if you get this fixed, won't these bots just add a preview step? Eventually, yes, but it drastically changes their ability to fling spam at a site. As is, they simply have a script that shoots data out at high speed without having to wait for messages to return from the server. It is the server that is doing all the work, thus making it simple for a spammer to DoS a site. If "preview required" really meant "preview required", they would be forced to first automate clicking "preview", and then wait for a response before clicking "submit". This requires more resources on their side, and allows us to add delays after clicking "preview" (if we detect that they are a spammer) further using their resources. > this 'preview required' feature is designed to maintain high quality > submissions by forcing users to proof read. it isn;t designed for security. Regardless of the intention, I was misled to believe that configuring my site to require previews would require that all comments were first previewed. As a site administrator, I would prefer to know that "required" really means "required". > i think you want to hook into comment_validate(). just add a hook here - > there is already a hook_comment() waiting for you to add an operation. Yes and no. Ultimately yes that will work and will allow my spam module to prevent the spam from ever being posted. But it still leaves the greatest burden on the web server, instead of on the spammer. The spammer can still use a very simple script that only pushes data, and thus can generate spam at an unbelievable rapid rate. Here is an example patch to enforce "preview required". It's one idea, I'm sure there are better ones. ------------------------------------------------------------------------ Mon, 08 Aug 2005 14:01:38 +0000 : Jeremy(a)kerneltrap.org Attachment: http://drupal.org/files/issues/comment.module_12.patch (1.4 KB) Here's a second version of the patch that doesn't require any manual configuration. ------------------------------------------------------------------------ Mon, 08 Aug 2005 16:27:27 +0000 : Jose A Reyero I like this idea, and the patch looks good Still, I think it misses something, like some timestamp related hash, because once you get the hash code you can post multiple comments with that. Another problem I can think of is, what happens when a cron run happens between the preview and the post?? I'm afraid comments would get lost For this second problem, I think a key generated only once after module activation could do. About the first one....mmm... I'll sit down for a while and think.....

1 0

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

09 Aug '05

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

4 4