May 2005 - Development - lists.drupal.org

[drupal-devel] [bug] Konqueror 3.3.x problems with forms input inside fieldset tags
by Steven 21 May '05

21 May '05

Issue status update for http://drupal.org/node/16729 Project: Drupal Version: cvs Component: node system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: syscrusher Updated by: Steven -Status: fixed +Status: patch This patch was never tested on IE6 windows! It completely breaks the node admin forms. I suggest re-adding it with: * html .node-form fieldset { display: inline; } This will make it kick in in IE only, and is not a CSS parser hack. IE simply thinks there is something above <html>. Steven Previous comments: ------------------------------------------------------------------------ February 4, 2005 - 07:33 : syscrusher Certain versions of the Konqueror browser have a serious problem with form input in Drupal 4.4.x and 4.5.x. The symptoms are that keyboard and mouse input is completely ignored in the affected "text" and "textarea" fields. The symptoms only occur on textual fields that occur within a <fieldset>...</fieldset> tag set. This occurs, for example, when the form_group() API function is invoked. I have tested several variants on the fieldset attributes, and as far as I can tell it doesn't matter what attributes are applied. I also tried it with a manually-created <fieldset><input type="text" ... /></fieldset> sequence, to eliminate the subtags such as legend, description, and title. The problem occurs even with a bare fieldset, and immediately goes away when the form elements are used without being in a fieldset. I further tested to ensure that the <table> tag was not involved, because a Google search suggested that there were problems with tables and fieldsets in Konqueror. Again, the problem is duplicable with no table in the fieldset. It took a lot of digging, but I have finally traced the problem to the file misc/drupal.css. Specifically, the following clause appears to be at fault: .node-form fieldset { display: inline; } If I comment out the "display: inline;" attribute, then the fields work correctly. There does not appear to be any ill effect from this so far, but I haven't tested extensively nor have I tested to see if this patch breaks any other browsers. I can duplicate this problem across several patch levels of Konqueror 3.3.0, and across Drupal 4.5.0 through 4.5.2. ------------------------------------------------------------------------ February 4, 2005 - 08:14 : syscrusher I've verified that the patch doesn't break Firefox 1.0, and also that it /does/ fix the problem with Konqueror 3.3.0 in Drupal 4.4, on one of my production sites. Incidentally, the problem doesn't occur with older Konqueror versions, as far as I can tell. ------------------------------------------------------------------------ March 26, 2005 - 21:15 : Steven I believe that piece of CSS is there for IE5, but I can't remember if it was for Windows or Mac. I'll do some testing later. ------------------------------------------------------------------------ March 26, 2005 - 22:00 : Junyor Works fine in Safari and Opera with or without that rule. IE 5 seems to have the same problem with or without it. In 4.5.2, the fieldsets aren't displayed at all. In HEAD, they cross the screen, pushing everything else down. In other words, it doesn't seem to have any bad effects on Mac browsers with or without that rule. ------------------------------------------------------------------------ March 26, 2005 - 22:09 : syscrusher BTW, I can also duplicate this bug with the CVS version of Drupal 4.6 as of 2005-03-24. ------------------------------------------------------------------------ March 27, 2005 - 14:28 : stefan nagtegaal I can verify that this works flawlesly with drupal 4.6 and any Mac browser.. It would be nice if this would be applied.. ------------------------------------------------------------------------ March 28, 2005 - 06:06 : syscrusher The bug also bit me on the drupal.org site. I finished a new module and tried to create a project to announce it, but one of the required fields in the node/add/... page for Project has the CSS bug. I had to switch to Firefox in order to create the project, because I couldn't enter the data from Konqueror. ------------------------------------------------------------------------ March 28, 2005 - 16:35 : frjo I had the same problem as syscrusher when I tried to add a new project with Safari (v125.12). It was not possible to enter anything to the field "CVS directory". With Mozilla it worked OK. ------------------------------------------------------------------------ May 18, 2005 - 21:42 : andremolnar Attachment: http://drupal.org/files/issues/drupal-css1.patch (451 bytes) This is not tested - I'm not a khtml user... But, I am taking everyone's word for it that this is what is needed to fix a problem. Here is a patch that removes the offending declaration. andre ------------------------------------------------------------------------ May 19, 2005 - 00:05 : syscrusher This patch works for me, and is in fact almost identical to my suggested change. +1, and thanks for moving the commit process one step further along. Scott ------------------------------------------------------------------------ May 21, 2005 - 13:54 : Dries Committed to HEAD and DRUPAL-4-6. Thanks for the round-up.

1 0

[drupal-devel] [bug] fix empty form elements
by chx 21 May '05

21 May '05

Issue status update for http://drupal.org/node/18663 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: critical Assigned to: chx Reported by: killes(a)www.drop.org Updated by: chx Status: patch Attachment: http://drupal.org/files/issues/fix_form_3.patch (3.24 KB) chx Previous comments: ------------------------------------------------------------------------ March 10, 2005 - 03:51 : killes(a)www.drop.org If you select nothing from a set of checkboxes an empty string is save to the variables table. This is a problem if the calling code assumes, it would get an array. We should make it save an empty array. The problem is the form_hidden field that we add. even if we replace form_hidden($name, 0) by form_hidden($name, array()) it isn't going to work, because the empty array is eaten by htmlspecialchars. redLED found this bug and he does not like it: 02:53 < redLED> i just like things saying 'CRITICAL' in red 02:53 < redLED> it gives this warm impending doom feeling 02:53 < redLED> and is generally associated with nuclear reactors in people's subconsciousness Suggestions welcome. ------------------------------------------------------------------------ March 12, 2005 - 20:47 : Steven There is no way to fix it in form_checkboxes() itself afaik, because even without htmlspecialchars, it would still come out as "Array". You can only create arrays indirectly through form submissions, by naming your values "foo[]". But you can not create empty arrays this way. So it is really up to the module which uses form_checkboxes() to handle this. A simple is_array() should do the trick. ------------------------------------------------------------------------ March 28, 2005 - 18:27 : chx Attachment: http://drupal.org/files/issues/checkboxes.patch (1.71 KB) system_settings_save can not really cope with this situation. This makes a problem with empty node options. And the fact that we have a check everywhere we use form_checkboxes is error prone, too. Here is a patch. If this accepted I'll comb the core for dead code. For eg. the first three lines of taxonomy_save_vocabulary and so. ------------------------------------------------------------------------ March 28, 2005 - 18:32 : chx Attachment: http://drupal.org/files/issues/checkboxes_0.patch (1.71 KB) Oh NO! One strayed space! I fixed it before steven beheads me.... ------------------------------------------------------------------------ March 28, 2005 - 19:36 : chx Attachment: http://drupal.org/files/issues/checkboxes_1.patch (1.64 KB) Among other changes, I have moved the hidden field form_checkboxes[] out of $edit. I have included HTML code, yes, but this is a very special thing, so it does not merit changing form_input just 'cos of this. And you won't need to theme a hidden field... ------------------------------------------------------------------------ April 8, 2005 - 09:19 : chx Attachment: http://drupal.org/files/issues/form_checkboxes_2.patch (1.9 KB) killes did not like the previous version. ------------------------------------------------------------------------ April 12, 2005 - 01:15 : chx Dries? ------------------------------------------------------------------------ April 12, 2005 - 21:15 : chx Attachment: http://drupal.org/files/issues/form_checkboxes_3.patch (1.64 KB) ------------------------------------------------------------------------ April 12, 2005 - 21:39 : jhriggs I have to agree with Steven that it is up to the calling code...and I hardly think this is critical. Code that is expecting an array from form_checkboxes() should ensure that it is dealing with an array (i.e. is_array()). As for dealing with variables set through things like system_settings_save(), the same thing applies. The code that is retrieving the variable should ensure that it is working with an array. With regards to your patch, what's the difference if the calling code has to remember to check via is_array() or remember to call fix_checkboxes()? This method is no less error prone as it's just as easy to forget this call as it is to check for an array. That is unless you are suggesting that fix_checkboxes() gets called for every page load which seems rather crufty. I wrote the original patch to add form_checkboxes() -- which didn't exist -- and if I remember, this was the desired behavior if nothing was selected. Isn't this the same behavior one would see using a multiple form_select() if the user chooses nothing? They should behave the same. A single select widget is the same as a radio group, and a multiple select widget is the same as a group of checkboxes. They should behave the same; the select types just take up less realestate. ------------------------------------------------------------------------ April 12, 2005 - 23:23 : chx Attachment: http://drupal.org/files/issues/form_checkboxes_4.patch (2.06 KB) Previous patch had index.php missing. jhriggs, the current problem is that a form_checkboxes expected to be an array. Currently, empty form_checkboxes is a string. That's bad. ------------------------------------------------------------------------ April 13, 2005 - 00:51 : jhriggs -1 on this patch. I still don't understand the problem. What do you mean by "form_checkboxes expected to be an array"? Is there code in core that assumes it is an array but it is not checked with is_array()? If so, let's add the missing checks. The same goes for contrib. This seems like swatting a fly with a sledge hammer to me. If we do go ahead and make this change, however, then we will need to change form_select() also (when multiple = TRUE). Radios and single select should be consistent, as should checkboxes and multiple select. ------------------------------------------------------------------------ April 23, 2005 - 13:35 : chx Attachment: http://drupal.org/files/issues/fix_form.patch (4.71 KB) See Gordon's complaint http://lists.drupal.org/archives/drupal-devel/2005-04/msg00934.html ------------------------------------------------------------------------ April 23, 2005 - 13:38 : chx Forgot to change the title. ------------------------------------------------------------------------ April 23, 2005 - 13:46 : chx It seems that it's not obvious why this is necessary. The calling code can not always handle itself the situation if the save is done by system_save_settings. The edge case is: I set up something, so variable_get no longer falls to its default value, later I decide to empty it. If we do not do something like this patch, system_save_settings can not know there is something to be set to 0/array() because it is just not in $_POST. ------------------------------------------------------------------------ April 23, 2005 - 15:23 : chx Attachment: http://drupal.org/files/issues/fix_form_0.patch (4.72 KB) Small bugfix. ------------------------------------------------------------------------ April 23, 2005 - 16:53 : chx doh. still has serious problems when the name is an array. stay tuned. ------------------------------------------------------------------------ April 24, 2005 - 11:13 : chx Attachment: http://drupal.org/files/issues/fix_form_1.patch (4.97 KB) Recursive version. ------------------------------------------------------------------------ April 24, 2005 - 14:51 : Dries Patch looks good but I would add some phpdoc to document what and why we are doing this. ------------------------------------------------------------------------ May 21, 2005 - 18:43 : chx Attachment: http://drupal.org/files/issues/fix_form_2.patch (3.23 KB) People told me that form_radios does not need this because we can reasonably expect that a radio is checked, that's different between a bunch of checkboxes and a bunch of radios. form_select submits an empty array (as also told by some). So we are back to checkbox and checkboxes which need the fix.

1 0

[drupal-devel] drupal.org front page should be for potential users, not developers
by Nedjo Rogers 21 May '05

21 May '05

I'm thinking we need to fundamentally rethink drupal.org. As things stand, the front page (indeed, the site as a whole) reads as if it were primarily aimed at two groups: (a) drupal developers, and (b) drupal users. What's missing is the obvious: potential drupal users. The main reason people come to drupal.org for the first time is, I assume, because they have heard of drupal and want to evaluate it for potential use. It's true that there is a one-sentence summary and an "about drupal" link near the top of the page. But that's it. The rest is drupal techies. * "Drupal 4.6.0 released" and a bunch of specific technical info. * The nodes promoted to the front page, which is a mish-mash of, mainly, highly internal-interest posts. * Side panel blocks that are at first glance almost incomprehensible. - "Navigation" that starts with "CVS messages", whatever that means. - Forum topics that are full of technical jargon and give the impression there's a ton of thorny problems in the software. - And "Drupal talk", culled from who knows where, which is full of random musings often not about Drupal at all. - By the time you get to "Support Drupal" at the bottom, the average first-time user is probably asking, "Why?" And then look at the page title. "Community plumbing". Pardon? I'm not saying the info we present isn't useful (okay, except the "Drupal talk", which I'd put in the "eccentric curiosity" category). But it's not what we should have as a public face. I'm suggesting we need: * a front page that provides people with the information to make a decision "Why would I choose Drupal". * sections, linked from the front page (e.g., through top-of-page links) for (a) developers (module development, core development, etc.) and (b) users (tips, questions, etc.). In practice, have a look at plone.org. They, I believe, are doing this right. In the short term, I suggest: * move the recent nodes listing to a side block of titles, ideally broken down by subject (e.g., one block for "news", etc.) * dedicate most of the content space to highlighting the features and advantages of drupal * change to the page title to something catchy and understandable Thoughts? Nedjo

7 6

[drupal-devel] [bug] fix empty form elements
by chx 21 May '05

21 May '05

Issue status update for http://drupal.org/node/18663 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: critical Assigned to: chx Reported by: killes(a)www.drop.org Updated by: chx Status: patch Attachment: http://drupal.org/files/issues/fix_form_2.patch (3.23 KB) People told me that form_radios does not need this because we can reasonably expect that a radio is checked, that's different between a bunch of checkboxes and a bunch of radios. form_select submits an empty array (as also told by some). So we are back to checkbox and checkboxes which need the fix. chx Previous comments: ------------------------------------------------------------------------ March 10, 2005 - 03:51 : killes(a)www.drop.org If you select nothing from a set of checkboxes an empty string is save to the variables table. This is a problem if the calling code assumes, it would get an array. We should make it save an empty array. The problem is the form_hidden field that we add. even if we replace form_hidden($name, 0) by form_hidden($name, array()) it isn't going to work, because the empty array is eaten by htmlspecialchars. redLED found this bug and he does not like it: 02:53 < redLED> i just like things saying 'CRITICAL' in red 02:53 < redLED> it gives this warm impending doom feeling 02:53 < redLED> and is generally associated with nuclear reactors in people's subconsciousness Suggestions welcome. ------------------------------------------------------------------------ March 12, 2005 - 20:47 : Steven There is no way to fix it in form_checkboxes() itself afaik, because even without htmlspecialchars, it would still come out as "Array". You can only create arrays indirectly through form submissions, by naming your values "foo[]". But you can not create empty arrays this way. So it is really up to the module which uses form_checkboxes() to handle this. A simple is_array() should do the trick. ------------------------------------------------------------------------ March 28, 2005 - 18:27 : chx Attachment: http://drupal.org/files/issues/checkboxes.patch (1.71 KB) system_settings_save can not really cope with this situation. This makes a problem with empty node options. And the fact that we have a check everywhere we use form_checkboxes is error prone, too. Here is a patch. If this accepted I'll comb the core for dead code. For eg. the first three lines of taxonomy_save_vocabulary and so. ------------------------------------------------------------------------ March 28, 2005 - 18:32 : chx Attachment: http://drupal.org/files/issues/checkboxes_0.patch (1.71 KB) Oh NO! One strayed space! I fixed it before steven beheads me.... ------------------------------------------------------------------------ March 28, 2005 - 19:36 : chx Attachment: http://drupal.org/files/issues/checkboxes_1.patch (1.64 KB) Among other changes, I have moved the hidden field form_checkboxes[] out of $edit. I have included HTML code, yes, but this is a very special thing, so it does not merit changing form_input just 'cos of this. And you won't need to theme a hidden field... ------------------------------------------------------------------------ April 8, 2005 - 09:19 : chx Attachment: http://drupal.org/files/issues/form_checkboxes_2.patch (1.9 KB) killes did not like the previous version. ------------------------------------------------------------------------ April 12, 2005 - 01:15 : chx Dries? ------------------------------------------------------------------------ April 12, 2005 - 21:15 : chx Attachment: http://drupal.org/files/issues/form_checkboxes_3.patch (1.64 KB) ------------------------------------------------------------------------ April 12, 2005 - 21:39 : jhriggs I have to agree with Steven that it is up to the calling code...and I hardly think this is critical. Code that is expecting an array from form_checkboxes() should ensure that it is dealing with an array (i.e. is_array()). As for dealing with variables set through things like system_settings_save(), the same thing applies. The code that is retrieving the variable should ensure that it is working with an array. With regards to your patch, what's the difference if the calling code has to remember to check via is_array() or remember to call fix_checkboxes()? This method is no less error prone as it's just as easy to forget this call as it is to check for an array. That is unless you are suggesting that fix_checkboxes() gets called for every page load which seems rather crufty. I wrote the original patch to add form_checkboxes() -- which didn't exist -- and if I remember, this was the desired behavior if nothing was selected. Isn't this the same behavior one would see using a multiple form_select() if the user chooses nothing? They should behave the same. A single select widget is the same as a radio group, and a multiple select widget is the same as a group of checkboxes. They should behave the same; the select types just take up less realestate. ------------------------------------------------------------------------ April 12, 2005 - 23:23 : chx Attachment: http://drupal.org/files/issues/form_checkboxes_4.patch (2.06 KB) Previous patch had index.php missing. jhriggs, the current problem is that a form_checkboxes expected to be an array. Currently, empty form_checkboxes is a string. That's bad. ------------------------------------------------------------------------ April 13, 2005 - 00:51 : jhriggs -1 on this patch. I still don't understand the problem. What do you mean by "form_checkboxes expected to be an array"? Is there code in core that assumes it is an array but it is not checked with is_array()? If so, let's add the missing checks. The same goes for contrib. This seems like swatting a fly with a sledge hammer to me. If we do go ahead and make this change, however, then we will need to change form_select() also (when multiple = TRUE). Radios and single select should be consistent, as should checkboxes and multiple select. ------------------------------------------------------------------------ April 23, 2005 - 13:35 : chx Attachment: http://drupal.org/files/issues/fix_form.patch (4.71 KB) See Gordon's complaint http://lists.drupal.org/archives/drupal-devel/2005-04/msg00934.html ------------------------------------------------------------------------ April 23, 2005 - 13:38 : chx Forgot to change the title. ------------------------------------------------------------------------ April 23, 2005 - 13:46 : chx It seems that it's not obvious why this is necessary. The calling code can not always handle itself the situation if the save is done by system_save_settings. The edge case is: I set up something, so variable_get no longer falls to its default value, later I decide to empty it. If we do not do something like this patch, system_save_settings can not know there is something to be set to 0/array() because it is just not in $_POST. ------------------------------------------------------------------------ April 23, 2005 - 15:23 : chx Attachment: http://drupal.org/files/issues/fix_form_0.patch (4.72 KB) Small bugfix. ------------------------------------------------------------------------ April 23, 2005 - 16:53 : chx doh. still has serious problems when the name is an array. stay tuned. ------------------------------------------------------------------------ April 24, 2005 - 11:13 : chx Attachment: http://drupal.org/files/issues/fix_form_1.patch (4.97 KB) Recursive version. ------------------------------------------------------------------------ April 24, 2005 - 14:51 : Dries Patch looks good but I would add some phpdoc to document what and why we are doing this.

1 0

Re: [drupal-devel] [contributions(DRUPAL-4-6):pablobm] contributions/modules/ldap_integration
by Stefan Nagtegaal 21 May '05

21 May '05

Why do I get this message 15 times??? Op 21-mei-2005, om 16:57 heeft drupal-cvs(a)drupal.org het volgende geschreven: > User: pablobm Branch: DRUPAL-4-6 Date: Sat, 21 May 2005 > 14:57:47 +0000 > > Log message: > > - Added DRUPAL-4-6. > > -- > [ Drupal cvs list | http://list.drupal.org/ ]

1 0

[drupal-devel] New CVS accounts
by Dries Buytaert 21 May '05

21 May '05

Hello world, I approved a bunch of new CVS accounts. This brings the grand total of CVS accounts to 294. There are a fair number of inactive accounts which I'll disable shortly. Please welcome our new contributors, and assist them as necessary. -- Dries Buytaert :: http://www.buytaert.net/

1 0

[drupal-devel] Translation coordinator
by Dries Buytaert 21 May '05

21 May '05

I'd like to propose having a "Drupal translation coordinator". I have two candidates in mind: Gerhard (killes) and Gabor (goba). Both Gerhard and Gabor have a track record guiding new translators, and Gabor is mostly responsible for the current locale module. I think both have what it takes. -- Dries Buytaert :: http://www.buytaert.net/

3 2

[drupal-devel] [bug] theme_image doesn't accept html attributes
by Dries 21 May '05

21 May '05

Issue status update for http://drupal.org/node/21397 Project: Drupal Version: cvs Component: theme system Category: bug reports Priority: critical Assigned to: Anonymous Reported by: jjeff Updated by: Dries Status: patch Do you still get that error? If it is specific to the image.module, we might have to move this bug report. Dries Previous comments: ------------------------------------------------------------------------ April 27, 2005 - 04:45 : jjeff Here's the theme_image function from theme.inc <?php function theme_image($path, $alt = '', $title = '', $attr = '', $getsize = true) { if (!$getsize || (file_exists($path) && (list($width, $height, $type, $attr) = @getimagesize($path)))) { return "<img src=\"$path\" $attr alt=\"$alt\" title=\"$title\" />"; } } ?> Any arguments sent to the function for $attr get clobbered by the getimagesize() call. And $getsize defaults to true, so in a call to: <?php theme_image('files/images/foo', 'alt_text', 'title_text', 'align="left"') ?> the 'align="left"' never makes it to the page. The two attribute values really should be able to coexist, allowing for both getsize attributes and additional 'argumented' attributes as well. I recommend changing the $attr in the second line to $imgattr, then adding $imgattr to the tag returned in the third. -Jeff ------------------------------------------------------------------------ May 2, 2005 - 17:44 : jjeff Attachment: http://drupal.org/files/issues/theme_image-attr_fix.patch (1.51 KB) Okay, here's a patch to fix the theme_image attribute problem. I've also added a handler so that attributes can either be a string (as they were in the past - although it wasn't working) or an associative array. I've marked this issue as critical because the current version of theme_image() does not accept attributes at all. -Jeff ------------------------------------------------------------------------ May 2, 2005 - 17:47 : jjeff Attachment: http://drupal.org/files/issues/theme_image-attr_fix_0.patch (1.51 KB) Whoops... Found a mistake in my code... Here's the correction. -Jeff ------------------------------------------------------------------------ May 2, 2005 - 18:04 : jjeff Attachment: http://drupal.org/files/issues/theme_image-attr_fix_1.patch (1.51 KB) It's amazing how many mistakes one person can make in two lines of code. New patch... this one works! -jeff ------------------------------------------------------------------------ May 2, 2005 - 18:16 : Steven Attributes should be consistently passed as an array, and rendered with drupal_attributes(). This is to ensure data is escaped correctly. ------------------------------------------------------------------------ May 5, 2005 - 17:09 : jjeff Attachment: http://drupal.org/files/issues/theme_image-attr_fix_2.patch (1.34 KB) Now the $attr argument requires an array. And the $attr argument gets sent through drupal_attributes(). Simple and easy, really. -Jeff ------------------------------------------------------------------------ May 6, 2005 - 11:02 : Dries Tidied up the code a little, and committed it to HEAD and DRUPAL-4-6. Thanks. ------------------------------------------------------------------------ May 8, 2005 - 18:26 : jjeff Attachment: http://drupal.org/files/issues/theme-img_attr_fix.patch (1 KB) Oops... the new fix sets the default value for $attributes to NULL. It should at least be array(), now that $attributes is an array. This patch fixes the default value and adds some other error checking that should help this error that people may be seeing when they load a page with images: Invalid argument supplied for foreach() in /Users/jeff/Sites/drupal/includes/common.inc on line 1536 -Jeff ------------------------------------------------------------------------ May 8, 2005 - 23:10 : Dries AFAIK, we always use $attributes = NULL without special error-checking (see form_ functions in common.inc, for example). Does this fix a bug? If so, how can we reproduce it? I'd love to test it. ------------------------------------------------------------------------ May 13, 2005 - 14:47 : hatseflats I also get this error: Invalid argument supplied for foreach() in /includes/common.inc on line 1536 When using image.module CVS and drupal CVS. When viewing an image no tag is outputted.

1 0

[drupal-devel] [bug] file_check_location is not working on Windows 2000
by Dries 21 May '05

21 May '05

Issue status update for http://drupal.org/node/10885 Project: Drupal Version: cvs Component: file system Category: bug reports Priority: critical Assigned to: Anonymous Reported by: ccourtne Updated by: Dries Status: patch This patch no longer applies against HEAD or DRUPAL-4-6. Could someone try reproducing this problemwith the latest version in either branch, and provide an updated patch. (I think the problem still needs fixing but I'm not sure and can't reproduce the problem.) Dries Previous comments: ------------------------------------------------------------------------ September 16, 2004 - 15:46 : ccourtne Currently file_check_location is always returning false when passed a file as the $source path. If a directory is passed in $soruce file_check_location works. I've tracked this down to realpath returning an empty string when passed a relative path which points to a file. This probably goes unnoticed if you are using the file.api's to construct relative paths to the druapl file directory since check_location failing just causes the durpal file directory to get added which is what you wanted in the first place. Replacing this line $source = realpath(dirname($source)); with this $source = realpath(dirname($source)); fixes it on my windows box using PHP 4.3.8. I don't have things set up to do patches on my windows boxes here at work yet. I'll submit a formal patch tonight. ------------------------------------------------------------------------ September 16, 2004 - 15:47 : ccourtne Dag nabit. Replace $source = realpath($source); with $source = realpath(dirname($source)); Craig ------------------------------------------------------------------------ September 16, 2004 - 15:56 : Anonymous Attachment: http://drupal.org/files/issues/file-inc-file_check_location.patch (639 bytes) The sooner there are patches, the better it is... I tested this approach on my server and it works. Steef ------------------------------------------------------------------------ September 17, 2004 - 03:34 : ccourtne Attachment: http://drupal.org/files/issues/checklocation.patch (666 bytes) Here is the patch. ------------------------------------------------------------------------ February 23, 2005 - 02:30 : dan90(a)drupal.org This also fixed my file upload problems with some nonstandard paths under Linux/apache, php 4.3.4 drupal 4.5.2. maybe we should remove mention of windows 2000? ------------------------------------------------------------------------ March 1, 2005 - 19:32 : killes(a)www.drop.org Still applies. ------------------------------------------------------------------------ April 18, 2005 - 13:10 : ec Is this patch still to be use with actual Drupal 4.6.0 ? Thanks. eric ------------------------------------------------------------------------ May 7, 2005 - 12:35 : Wes Cowley I hand applied the patch to my Linux based installation and it solved the problem I was having with filemanager/attachment. I assume it would fix the same problem I had with upload.module since the symptoms were identical. ------------------------------------------------------------------------ May 7, 2005 - 12:36 : Wes Cowley Meant to add, that was a 4.6.0 Linux installaion that this patch cleared up. ------------------------------------------------------------------------ May 14, 2005 - 09:59 : larryjhs Thanks, still, I'm a bit of a php newbie -- where do I put the patch -- into which bit of script? If it's not too obvious, tell me and I won't try! But if it's obvious, please give me the location L ------------------------------------------------------------------------ May 14, 2005 - 10:19 : ec This patch seem still to apply to 4.6 (I'm using it on my linux box too and it solve my problem with upload.module) it apply on "file.inc" that you will find in includes directory on top of your drupal root. Put the patch in the same directory as file.inc go in this directory too and apply the patch like this "patch -p0 < the_patch_to_apply" where patch is the command on *nix box. If you're not confortable you can either edit the file.inc by hand and make the change yourself, in the patch file, line beginning with "-" is the one to remove, line beginning with "+" is the one to add, other lines are the context so you're sure to find the right line. Hope this help. Regards. ------------------------------------------------------------------------ May 14, 2005 - 10:23 : ec BTW, IMHO this patch should be committed ASAP as it's solve the problem with upload.module that can't handle private directory outside drupal root. Tested on my sites ans work (for now ;-) like a charm. Regards. ------------------------------------------------------------------------ May 15, 2005 - 13:51 : Dries Don't we use file_create_path for that (it appends the 'files'-bit)? ------------------------------------------------------------------------ May 15, 2005 - 22:19 : ec On my linux box, I make an other test with the latest stock release of file.inc. I setup files directectory, with "private" check, outside drupal root and drupal complains The directory does not exist (I know this directory exists and is working because I'm using it !). It only works with the patch below. Sorry, I'm not confortable enought to answer your question Dries, but sure this patch is the only I found to have a real private directory working. Regards, eric. PS : I don't why but got an error each time I want to upload a file here ??? so here is the text against the latest release of file.inc i.e 1.39.2.2 --- ./file.inc 2005-05-15 21:52:40.758531811 +0200 +++ ./file_mod_ec.inc 2005-05-15 22:03:41.869608738 +0200 @@ -169,7 +169,7 @@ * @return 0 for invalid path or the real path of the source. */ function file_check_location($source, $directory = 0) { - $source = realpath($source); + $source = realpath(dirname($source)); $directory = realpath($directory); if ($directory && strpos($source, $directory) !== 0) { return 0; >/code> ------------------------------------------------------------------------ May 21, 2005 - 07:00 : Rick Cogley The patch fixed uploads for me as well on 4.6.0.

1 0

[drupal-devel] Admin access to user tabs
by Dan Robinson 21 May '05

21 May '05

Hey, I've got the following code in my module - if ($may_cache) { $access_user = user_access('edit own forum mail settings'); $items[] = array('path' => "user/$user->uid/forummail", 'title' => t("my forum mail settings"),'callback' => forummail_page, 'callback arguments' => $user->uid,'access' => $access_user, 'type' => MENU_LOCAL_TASK); } When I got to user/<number> when I'm logged in (as whomever) I see the tab "my forum mail settings" - everything works fine. However I want to have "admin" users be able to edit the "my forum mail settings" of other users. So when logged in as admin then I want t see this tab for "dan" - currently it won't show up. As always - help/hints appreciated. Dan

1 0