- Development - lists.drupal.org

[drupal-devel] [bug] Fix search box in phptemplate core themes
by kbahey 06 May '05

06 May '05

Issue status update for http://drupal.org/node/22127 Project: Drupal Version: cvs Component: theme system Category: bug reports Priority: normal Assigned to: kbahey Reported by: kbahey Updated by: kbahey Status: patch Attachment: http://drupal.org/files/issues/phptemplate-core-themes.patch (1.86 KB) Both core phptemplate themes use name="keys" instead of name="edit[keys]", which was introduced since 4.6. This would cause the search box not to work. The attached patch fixes this. kbahey

1 0

[drupal-devel] [bug] menu error line 974 with MBstring
by Robin Monks 06 May '05

06 May '05

Issue status update for http://drupal.org/node/22026 Project: Drupal -Version: 4.6.0 +Version: cvs Component: menu system Category: bug reports Priority: normal -Assigned to: Anonymous +Assigned to: Robin Monks Reported by: hendler Updated by: Robin Monks -Status: active +Status: patch Attachment: http://drupal.org/files/issues/menu.inc_0.patch (908 bytes) We apparently don't check if the object exists before we work on it. Robin Robin Monks Previous comments: ------------------------------------------------------------------------ May 5, 2005 - 00:15 : hendler Menu.inc on line 974 the do {}while() causes an error if $parent is empty because strrpos, (I have mbstring enabled) may be null to fix my problem I have this if statement wrapping it, which I understand is logically equivlent to just doing a while loop. if ($parent){ do { $parent = substr($parent, 0, strrpos($parent, '/')); } while ($parent && !array_key_exists($parent, $_menu['path index'])); } This happens just after a new install.

1 0

[drupal-devel] [bug] Section depth for printer-friendly output off-by-one error
by puregin 06 May '05

06 May '05

Issue status update for http://drupal.org/node/22123 Project: Drupal Version: cvs Component: book.module Category: bug reports Priority: critical Assigned to: puregin Reported by: puregin Updated by: puregin Status: patch Attachment: http://drupal.org/files/issues/book_printer_friendly_depth.patch (583 bytes) Proper subsections of a top-level section in printer-friendly output have level equal to the parent. That is, we have Structure: Expected depth Actual depth section 1 1 1 section 1.1 2 1 section 1.1.1 3 2 section 1.2 2 1 The attached patch is a one-line change. It increments $depth before calling book_print_recurse() from book_print(). I'm marking this as critical since it is interfering with generation of PDF from the Handbook. Djun puregin

1 0

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

06 May '05

Issue status update for http://drupal.org/node/1898 Project: Drupal Version: cvs Component: book.module Category: bug reports -Priority: normal +Priority: critical -Assigned to: al +Assigned to: puregin Reported by: kika Updated by: puregin -Status: active +Status: patch Attachment: http://drupal.org/files/issues/book_printer_friendly_div.patch (1.57 KB) I am attaching a patch which fixes improper printer-friendly output, as discussed. The patch fixes book_print and book_print_recurse() to insert a <div> start tag before emitting the header, and to close this after subsections have been recursively generated. The <div> tag has an id attribute of the form id="sect-123", where the node's nid is 123, and a class attribute of form class="sect/n/" where the depth of the section is /n/. I'm marking this issue as critical, since the present HTML output plays havoc with any attempts at sane PDF generation. I will address the issue of where printer-friendly subsections should be 'rooted' in a follow-up. Djun puregin Previous comments: ------------------------------------------------------------------------ June 9, 2003 - 14:06 : kika Snippet from book_render(): $output .= "<dt>". l($node->title, "node/view/$node->nid") ."</dt><dd>". book_body($node) ."<br /><br /></dd>"; Is using definition list here is really correct? This should be replaced with appropiate div's or even better, funnel through theme() Same goes for the function book_print(): $output .= "$node->title"; if ($node->body) { $output .= "<ul>". book_body($node) ."</ul>"; } Why wrap body inside <ul>? ------------------------------------------------------------------------ June 10, 2003 - 16:31 : al Yeah, it's all nasty. I patched this ages ago, but no one seemed interested. The patch now won't apply due to all the changes since then. I'm on this - expect a new patch to hit my sandbox shortly. ------------------------------------------------------------------------ June 10, 2003 - 22:03 : ax please remove the superfluous <ul>s and <li> [1], too. to solve the problem of invalid nested <hx> tags, maybe we should change <h$depth> to <h1 class="book-h$depth">? this way, we could use <h2> - <h6> in book pages. alternatively, we should only use <h5> and <h6> in book pages - we shouldn't have nestings deeper than 4 in printed books, then. additionally, i think it would be a good idea to add id's to all book headings so they can be jumped to via fragment identifiers (url#fragment-identifier). i often wish this would be possible when referencing the last paragraph of a long page of documentation ... these id's should be of the form <hx id="foo" name="foo"> [2], with foo probably being the node-id of the single book page. adding id's to headings would also be a good idea for headings / sections in single book nodes. for example, it would be nice if i could link to list point 10 in the drupal installation instructions [3] via something like url#10. these id's had to be added manually. the question is: how can these id's be named to be unique within a /printed/ book? probably <node_id>_<section_id> ... [1] [ [drupal-devel] Drupal handbook formatting and heading tags | http://lists.drupal.org/pipermail/drupal-devel/2003-June/025860.html ] [2] [ XHTML Spec, HTML Compatibility Guidelines, Fragment Identifiers | http://www.w3.org/TR/xhtml1/#C_8 ] [3] http://drupal.org/node/view/260 ------------------------------------------------------------------------ June 15, 2003 - 06:23 : al Fixed in latest CVS. Uses all of Ax's suggestions: - <h1 class="depthX"> - Fixed to use CSS rather than tables. - Changes link at top to standard "breadcrumb" style, rather than hierarchy in tree view. - Removes odd and superfluous <ul> tags and the like. - Makes printed docs have proper <html> and <body> wrapping, etc. ------------------------------------------------------------------------ May 4, 2005 - 23:20 : puregin I'm re-opening this, because the problem persists in CVS. 1) The current CVS version (1.288.2.4) of book module still wraps $node->body in an <ul> element in book_print_recurse(). This produces non-conformant HTML. I'm not sure why this was done in the first place - I'm guessing someone wanted to insulate from having bad markup in a book page throw off the enclosing page. Getting rid of the offending UL tags is a one-line solution, but what is the right thing to do here? I'd like to see something very structural - wrapping the /entire/ output (including the generated sectional header) of the book_print_recurse() wrapped in a <div> element. This will properly nest true structural sections, making the structure accessible to applications via DOM. It will also make it easier to use XSLT, for example, to transform into various XML based export formats, for example. Any reason not to do so? Also... when we get the 'printer-friendly' version of a page, the subtree rooted at that page is returned, and the root page is marked up with a class="book-h1". Is there any reason why we don't compute the depth of the root page, and use that to generate the "in-place" header? In other words, if a section is "book-h3" relative to the top-level book, shouldn't it be "book-h3" whenever it is viewed? In this case, we could apply the same principal to generating the <div> tags around each section.

1 0

[drupal-devel] [bug] 404 when file_transfer(.,.) fails
by Robin Monks 06 May '05

06 May '05

Issue status update for http://drupal.org/node/22118 Project: Drupal Version: cvs Component: file system Category: bug reports Priority: normal Assigned to: Robin Monks Reported by: Robin Monks Updated by: Robin Monks Status: patch Attachment: http://drupal.org/files/issues/404 on file not found.patch (699 bytes) "The image module uses file_transfer and if for any reason the file is gone, then you'll get an infinte number of error messages which -- because they are in a -- are invisible..." Chx_ told me about this bug, so volia! patch attached. This patch checks to ensure that the file can be accessed and generenates a drupal_not_found if it hits a snag. Robin Robin Monks

1 1

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

05 May '05

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

1 0

[drupal-devel] [bug] Error with file api and open_basedir restriction
by nedjo 05 May '05

05 May '05

Issue status update for http://drupal.org/node/5961 Project: Drupal Version: cvs Component: node system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: Jose A Reyero Updated by: nedjo Status: patch It seems likely that the image module issue - with using file_copy() directly - can be addressed by adding a file_check_upload() call in the file_copy() function by changing <?php // Process a file upload object. if (is_object($source)) { $file = $source; ?> to <?php // Process a file upload object. if (is_object($source)) { $file = file_check_upload($source); ?> I can't immediately test this. Do you want to, mpd? nedjo Previous comments: ------------------------------------------------------------------------ February 20, 2004 - 15:45 : Jose A Reyero Attachment: http://drupal.org/files/issues/file-open-basedir.patch (1018 bytes) I get this error when uploading a file through the file api, and the upload fails: warning: open_basedir restriction in effect. File is in wrong directory in... This happens when open_basedir restriction is activated and the temporary directory is not in the allowed directories. There's a related bug in the profile.module: http://drupal.org/node/view/2648 [1] FIX: The solution is to upload files using php's 'move_uploaded_file' -which works even when open_basedir restriction is in effect. This patch checks for the error conditions in 'file.inc::file_check_upload', and then uses move_uploaded_file to upload the file to the temporary folder with a random name. Otherwise -if the error conditions are not met-, does nothing. RESTRICTIONS: This patch introduces one additional restriction for the file api: Once you have called 'file_check_upload', you have to use the returned object when calling later 'file.api::file_save_upload'. This shouldn't be a problem, as the right way to upload files should be -I think, please correct me if I'm wrong-: - $file=file_check_upload(); - (Perform validations with $file) - file_save_upload($file,.....) I will post also a very simple patch for profile.module to work with this one. Anyway, as mentioned above, if the error conditions are not met, the patch does nothing, so I think it should be applied first and then check for other modules (profile.module) to use the file api the right way and then be able to upload files when open_basedir restriction in effect. [1] http://drupal.org/node/view/2648 ------------------------------------------------------------------------ November 28, 2004 - 13:38 : Goba This seems to be an interesting alternate fix to my dump patch for locale.module [2], which is the very same issue... Moving the file out of the upload folder right away to the Drupal temp folder seems to be a good idea to me. The only caveat is that files in the upload folder get removed automatically, while one needs to remove the file from the Drupal temp folder, once it is not needed anymore! [2] http://drupal.org/node/13285 ------------------------------------------------------------------------ December 8, 2004 - 15:26 : Goba Please look at this stuff. We need to solve open_basedir problems at least in core before the next point release. There are quite a few users trying to use Drupal on shared hosting here, where open_basedir is in effect. ------------------------------------------------------------------------ February 17, 2005 - 21:55 : clydefrog This functionality gets a +1 from me, the user. We solved this problem by changing upload_tmp_dir in the server config, but a fix in Drupal would be more elegant. ------------------------------------------------------------------------ March 13, 2005 - 15:41 : killes(a)www.drop.org Doesn't apply anymore. ------------------------------------------------------------------------ March 14, 2005 - 07:05 : Jose A Reyero Attachment: http://drupal.org/files/issues/file-open-basedir_02.patch (810 bytes) Just resubmitted the patch. The problem is, from the time I sent the first patch , I've moved all my sites, no shared webhosting anymore, so I don't have that upload trouble anymore, and also cannot test it myself. That's also why I'm unassigning this issue to me. So please, somebody else test it. ------------------------------------------------------------------------ April 15, 2005 - 16:49 : mpd Attachment: http://drupal.org/files/issues/file.inc-file_relocate.patch (3.87 KB) I gave your patch a try. It applies fine but doesn't address several issues, particularily with the image module. The attached patch makes attachments work, along with image (from cvs). I haven't seen any ill effects yet, but I believe that file_delete must be used to avoid getting a build-up of dead files in the local temporary directory (set to getcwd().'/tmp'). This isn't a problem with my install, but it might be a problem with other modules. In order for the patched code to work, $drupal/tmp must exist and be writable by the web server. ------------------------------------------------------------------------ May 5, 2005 - 13:33 : nedjo Attachment: http://drupal.org/files/issues/file_open_basedir_03.patch (817 bytes) +1 for Jose's patch (I've attached an updated version, which I've tested successfully. The new version uses $file->filepath rather than $file->path and cleans up the code a bit.) While the larger patch suggested may have merit, I don't fully follow it (not knowing what the image module issues are). I'd like to see the identified problem fixed first, and quickly. Later cleanup and further patches can follow. This is a significant issue, meaning many in hosted environments can't use Drupal's file uploading. This has come up at least twice in the help forums. Jose's solution is simple. Let's apply it! This same changes work for 4.6. ------------------------------------------------------------------------ May 5, 2005 - 15:07 : mpd I'll describe the issue that I found with file.inc concerning image.module. >From what I've seen, image.module calls file_copy() directly from _image_insert(). file_copy() doesn't call file_check_upload(), so the open_basedir problem remains because file_copy() attempts to access the file while it's still in the restricted directory. I'm sure that there's a cleaner way to do it, but the patch that I submitted does the trick for my purposes by addressing problems with both file_copy() and file_check_upload(). I'll have a go at making a smaller patch that only addresses the issue with file_copy(), since Nedjo's patch neatly fixes file_check_upload().

1 0

Re: [drupal-devel] [drupal:dries] /modules comment.module tracker.module
by Dries Buytaert 05 May '05

05 May '05

On 05 May 2005, at 22:12, drupal-devel(a)drupal.org wrote: > Modified files: > /modules comment.module tracker.module > > Log message: > - Patch #21221 by Robert: make status values in comment.module > defined constants for readability. TODO: do the same for nodes. -- Dries Buytaert :: http://www.buytaert.net/

1 0

[drupal-devel] [bug] Error with file api and open_basedir restriction
by mpd 05 May '05

05 May '05

Issue status update for http://drupal.org/node/5961 Project: Drupal Version: cvs Component: node system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: Jose A Reyero Updated by: mpd Status: patch I'll describe the issue that I found with file.inc concerning image.module. >From what I've seen, image.module calls file_copy() directly from _image_insert(). file_copy() doesn't call file_check_upload(), so the open_basedir problem remains because file_copy() attempts to access the file while it's still in the restricted directory. I'm sure that there's a cleaner way to do it, but the patch that I submitted does the trick for my purposes by addressing problems with both file_copy() and file_check_upload(). I'll have a go at making a smaller patch that only addresses the issue with file_copy(), since Nedjo's patch neatly fixes file_check_upload(). mpd Previous comments: ------------------------------------------------------------------------ February 20, 2004 - 11:45 : Jose A Reyero Attachment: http://drupal.org/files/issues/file-open-basedir.patch (1018 bytes) I get this error when uploading a file through the file api, and the upload fails: warning: open_basedir restriction in effect. File is in wrong directory in... This happens when open_basedir restriction is activated and the temporary directory is not in the allowed directories. There's a related bug in the profile.module: http://drupal.org/node/view/2648 [1] FIX: The solution is to upload files using php's 'move_uploaded_file' -which works even when open_basedir restriction is in effect. This patch checks for the error conditions in 'file.inc::file_check_upload', and then uses move_uploaded_file to upload the file to the temporary folder with a random name. Otherwise -if the error conditions are not met-, does nothing. RESTRICTIONS: This patch introduces one additional restriction for the file api: Once you have called 'file_check_upload', you have to use the returned object when calling later 'file.api::file_save_upload'. This shouldn't be a problem, as the right way to upload files should be -I think, please correct me if I'm wrong-: - $file=file_check_upload(); - (Perform validations with $file) - file_save_upload($file,.....) I will post also a very simple patch for profile.module to work with this one. Anyway, as mentioned above, if the error conditions are not met, the patch does nothing, so I think it should be applied first and then check for other modules (profile.module) to use the file api the right way and then be able to upload files when open_basedir restriction in effect. [1] http://drupal.org/node/view/2648 ------------------------------------------------------------------------ November 28, 2004 - 09:38 : Goba This seems to be an interesting alternate fix to my dump patch for locale.module [2], which is the very same issue... Moving the file out of the upload folder right away to the Drupal temp folder seems to be a good idea to me. The only caveat is that files in the upload folder get removed automatically, while one needs to remove the file from the Drupal temp folder, once it is not needed anymore! [2] http://drupal.org/node/13285 ------------------------------------------------------------------------ December 8, 2004 - 11:26 : Goba Please look at this stuff. We need to solve open_basedir problems at least in core before the next point release. There are quite a few users trying to use Drupal on shared hosting here, where open_basedir is in effect. ------------------------------------------------------------------------ February 17, 2005 - 17:55 : clydefrog This functionality gets a +1 from me, the user. We solved this problem by changing upload_tmp_dir in the server config, but a fix in Drupal would be more elegant. ------------------------------------------------------------------------ March 13, 2005 - 11:41 : killes(a)www.drop.org Doesn't apply anymore. ------------------------------------------------------------------------ March 14, 2005 - 03:05 : Jose A Reyero Attachment: http://drupal.org/files/issues/file-open-basedir_02.patch (810 bytes) Just resubmitted the patch. The problem is, from the time I sent the first patch , I've moved all my sites, no shared webhosting anymore, so I don't have that upload trouble anymore, and also cannot test it myself. That's also why I'm unassigning this issue to me. So please, somebody else test it. ------------------------------------------------------------------------ April 15, 2005 - 12:49 : mpd Attachment: http://drupal.org/files/issues/file.inc-file_relocate.patch (3.87 KB) I gave your patch a try. It applies fine but doesn't address several issues, particularily with the image module. The attached patch makes attachments work, along with image (from cvs). I haven't seen any ill effects yet, but I believe that file_delete must be used to avoid getting a build-up of dead files in the local temporary directory (set to getcwd().'/tmp'). This isn't a problem with my install, but it might be a problem with other modules. In order for the patched code to work, $drupal/tmp must exist and be writable by the web server. ------------------------------------------------------------------------ May 5, 2005 - 09:33 : nedjo Attachment: http://drupal.org/files/issues/file_open_basedir_03.patch (817 bytes) +1 for Jose's patch (I've attached an updated version, which I've tested successfully. The new version uses $file->filepath rather than $file->path and cleans up the code a bit.) While the larger patch suggested may have merit, I don't fully follow it (not knowing what the image module issues are). I'd like to see the identified problem fixed first, and quickly. Later cleanup and further patches can follow. This is a significant issue, meaning many in hosted environments can't use Drupal's file uploading. This has come up at least twice in the help forums. Jose's solution is simple. Let's apply it! This same changes work for 4.6.

1 0

[drupal-devel] [bug] Error with file api and open_basedir restriction
by nedjo 05 May '05

05 May '05

Issue status update for http://drupal.org/node/5961 Project: Drupal Version: cvs Component: node system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: Jose A Reyero Updated by: nedjo Status: patch Attachment: http://drupal.org/files/issues/file_open_basedir_03.patch (817 bytes) +1 for Jose's patch (I've attached an updated version, which I've tested successfully. The new version uses $file->filepath rather than $file->path and cleans up the code a bit.) While the larger patch suggested may have merit, I don't fully follow it (not knowing what the image module issues are). I'd like to see the identified problem fixed first, and quickly. Later cleanup and further patches can follow. This is a significant issue, meaning many in hosted environments can't use Drupal's file uploading. This has come up at least twice in the help forums. Jose's solution is simple. Let's apply it! This same changes work for 4.6. nedjo Previous comments: ------------------------------------------------------------------------ February 20, 2004 - 15:45 : Jose A Reyero Attachment: http://drupal.org/files/issues/file-open-basedir.patch (1018 bytes) I get this error when uploading a file through the file api, and the upload fails: warning: open_basedir restriction in effect. File is in wrong directory in... This happens when open_basedir restriction is activated and the temporary directory is not in the allowed directories. There's a related bug in the profile.module: http://drupal.org/node/view/2648 [1] FIX: The solution is to upload files using php's 'move_uploaded_file' -which works even when open_basedir restriction is in effect. This patch checks for the error conditions in 'file.inc::file_check_upload', and then uses move_uploaded_file to upload the file to the temporary folder with a random name. Otherwise -if the error conditions are not met-, does nothing. RESTRICTIONS: This patch introduces one additional restriction for the file api: Once you have called 'file_check_upload', you have to use the returned object when calling later 'file.api::file_save_upload'. This shouldn't be a problem, as the right way to upload files should be -I think, please correct me if I'm wrong-: - $file=file_check_upload(); - (Perform validations with $file) - file_save_upload($file,.....) I will post also a very simple patch for profile.module to work with this one. Anyway, as mentioned above, if the error conditions are not met, the patch does nothing, so I think it should be applied first and then check for other modules (profile.module) to use the file api the right way and then be able to upload files when open_basedir restriction in effect. [1] http://drupal.org/node/view/2648 ------------------------------------------------------------------------ November 28, 2004 - 13:38 : Goba This seems to be an interesting alternate fix to my dump patch for locale.module [2], which is the very same issue... Moving the file out of the upload folder right away to the Drupal temp folder seems to be a good idea to me. The only caveat is that files in the upload folder get removed automatically, while one needs to remove the file from the Drupal temp folder, once it is not needed anymore! [2] http://drupal.org/node/13285 ------------------------------------------------------------------------ December 8, 2004 - 15:26 : Goba Please look at this stuff. We need to solve open_basedir problems at least in core before the next point release. There are quite a few users trying to use Drupal on shared hosting here, where open_basedir is in effect. ------------------------------------------------------------------------ February 17, 2005 - 21:55 : clydefrog This functionality gets a +1 from me, the user. We solved this problem by changing upload_tmp_dir in the server config, but a fix in Drupal would be more elegant. ------------------------------------------------------------------------ March 13, 2005 - 15:41 : killes(a)www.drop.org Doesn't apply anymore. ------------------------------------------------------------------------ March 14, 2005 - 07:05 : Jose A Reyero Attachment: http://drupal.org/files/issues/file-open-basedir_02.patch (810 bytes) Just resubmitted the patch. The problem is, from the time I sent the first patch , I've moved all my sites, no shared webhosting anymore, so I don't have that upload trouble anymore, and also cannot test it myself. That's also why I'm unassigning this issue to me. So please, somebody else test it. ------------------------------------------------------------------------ April 15, 2005 - 16:49 : mpd Attachment: http://drupal.org/files/issues/file.inc-file_relocate.patch (3.87 KB) I gave your patch a try. It applies fine but doesn't address several issues, particularily with the image module. The attached patch makes attachments work, along with image (from cvs). I haven't seen any ill effects yet, but I believe that file_delete must be used to avoid getting a build-up of dead files in the local temporary directory (set to getcwd().'/tmp'). This isn't a problem with my install, but it might be a problem with other modules. In order for the patched code to work, $drupal/tmp must exist and be writable by the web server.

1 0