- Development - lists.drupal.org

[drupal-devel] OpenId-compatible encryption in PHP
by Mark 22 May '05

22 May '05

Greetings all, I've been following the development of OpenId (http://www.danga.com/openid/) and I have a few questions regarding the practical implementation of it for Drupal. I realize that one of the goals of Drupal is that it can run on a variety of PHP installations/configurations. With that in mind, I'm wondering how common variouos encryption libraries are in the realm of PHP installations. Some of the technologies used by OpenId (or under consideration): DSA encryption (using PEM key formatting) RSA encryption (under consideration) SHA1 encryption DER encoding BASE64 encoding I'm vaguely familiar with many of these technologies, and have even used several of them. SHA1 is natively supported by PHP >= 4.3.0. BASE64 is natively supported by PHP As for RSA and DSA, I know that these key types are supported by OpenSSL. Is OpenSSL commonly supported in PHP? I know that it's fairly easy to install, but I also realize that many users don't have control over what their server supports. I suppose I'm doing a survey here to see if an OpenSSL requirement is beyond the scope of a Drupal core installation. If there are PHP-based alternatives to OpenSSL that could be bundled with (or linked to from) Drupal, please inform me about them. Thanks for your time, -Mark

4 6

[drupal-devel] [feature] List of bloggers
by Bèr Kessels 22 May '05

22 May '05

Issue status update for http://drupal.org/node/17030 Project: Drupal Version: cvs Component: blog.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Bèr Kessels Updated by: Bèr Kessels Status: patch To avoid confusion: this patch ads no blocks, but shows the list inline: as content! Bèr Kessels Previous comments: ------------------------------------------------------------------------ February 9, 2005 - 00:27 : Bèr Kessels Attachment: http://drupal.org/files/issues/blog_bloggers_list.patch (1.66 KB) Small patch to show a list of bloggers. We all should know that blog.module is not meant for personal blogging, but that set aside, we do not have a way to show all bloggers, on a site as a list. This patch ads a few lines that will allow you to show that overview of blogging users. It ads a menu item, disabled by default that shows such a list. ------------------------------------------------------------------------ February 9, 2005 - 00:31 : Bèr Kessels Attachment: http://drupal.org/files/issues/blog_bloggers_list.png (4.02 KB) Here is a small screeny that shows what this is about. ------------------------------------------------------------------------ February 9, 2005 - 00:34 : Bèr Kessels Attachment: http://drupal.org/files/issues/list_bloggers_2.png (2.25 KB) hmm. error in my png file. Here is a correct one. ------------------------------------------------------------------------ February 19, 2005 - 21:13 : Emiliano Hi Bèr Kessels! Thanks for the patch! It's really useful! :-) I just noticed what I think is a little mistake in this line: $items[] = l($row->name, 'blog/'.$row->uid)." ".theme('xml_icon', url('blog/'.$row->uid.'/feed'), TRUE); Which I believe should end like: $items[] = l($row->name, 'blog/'.$row->uid)." ".theme('xml_icon', url*('blog/feed/'.$row->uid)*, TRUE); Ah, and BTW, "db_rewrite_sql" didn't work for me... I just cut it off... ;-) Cheers, Emiliano. ------------------------------------------------------------------------ March 17, 2005 - 23:17 : Bèr Kessels Attachment: http://drupal.org/files/issues/blog_bloggers_list_2.patch (1.81 KB) and here is the actual patch. (i think i really need some script that tells me i did not attach a patch ;) ) ------------------------------------------------------------------------ March 17, 2005 - 23:19 : Bèr Kessels Attachment: http://drupal.org/files/issues/blog_bloggers_list_2_0.patch (1.71 KB) sigh. something tells me i should stop working.... a silly "F" sneaked into the previous patch. ------------------------------------------------------------------------ March 24, 2005 - 21:25 : Anonymous I applied the patch, reuploaded the blog.module and then deactivated and reactivated it. I cannot see a difference. How do I access the blog users page? Drupal 4.6rc thanks for the help. ------------------------------------------------------------------------ March 24, 2005 - 21:53 : Bèr Kessels look in the menu admin. ------------------------------------------------------------------------ May 18, 2005 - 14:38 : Bèr Kessels Nearly two months since the patch. If there is no need for this I will mark it won't fix. ------------------------------------------------------------------------ May 18, 2005 - 14:52 : tostinni I made a custom block for this, but it still need a little improvment (add "read more" for example). So I don't know if it's usefull but if anyone care : <?php $result = db_query("SELECT u.uid, u.name, COUNT(0) AS num FROM {node} n LEFT JOIN {users} u ON u.uid = n.uid WHERE n.type = 'blog' GROUP BY u.uid, u.name ORDER BY u.name ASC"); while ($blog = db_fetch_object($result)) { $output .= '<li />'.l($blog->name. ' ('.$blog->num.')', 'blog/'.$blog->uid); } return '<ul>'.$output.'</ul>'; ?> ------------------------------------------------------------------------ May 18, 2005 - 17:06 : Chris Johnson I think this is a useful feature. I've coded custom blocks in the past to provide it on my sites. ------------------------------------------------------------------------ May 21, 2005 - 06:23 : Andrzej7 I was a little afraid (poor PHP) to install the patch (March...), but I have made a block. And it's very nice. One question only. All the bloggers are shown, but the Admin (user No 1) is on the list and he has no blogs. What's that?

1 0

[drupal-devel] [task] theme_user_list is useless for advanced themeing. Patch changes that.
by Bèr Kessels 22 May '05

22 May '05

Issue status update for http://drupal.org/node/23383 Project: Drupal Version: 4.6.0 Component: theme system Category: tasks Priority: normal Assigned to: Anonymous Reported by: Bèr Kessels Updated by: Bèr Kessels -Status: active +Status: patch forgot status patch Bèr Kessels Previous comments: ------------------------------------------------------------------------ May 22, 2005 - 16:18 : Bèr Kessels Attachment: http://drupal.org/files/issues/user_module_theme_list.patch (1.88 KB) Since the function currently only receives a string of HTML there is no way to add inormation to a user list. You cannot do a user_load to add additional information, like the avatar. Pattern matching the UID from the url in the html is not an option, since a username could be aliassed, thus in order to get the UID you need a lot of quite heavy code. This patch changes the passed argument into an array of user objects. By default the objects need only to contain the name and UID. This patch also cleans up the online user list block, which had some inconsistent code. After his patch you can have fancy users lists like on my development ste: http://84.244.1.246

1 0

[drupal-devel] Bug#310084: drupal: Update Japanese po-debconf template trasnlation
by Hilko Bengen 22 May '05

22 May '05

Hideki Yamane <henrich(a)samba.gr.jp> writes: > I've updated ja.po to fix untranslated lines. > Could you apply it, please? [x] done. Do you want write access to the CVS repository at alioth.debian.org? Cheers, -Hilko

1 0

[drupal-devel] [feature] Replace $_SERVER["REMOTE_ADDR"] with a function which understands X-Forwarded-For
by Dries 22 May '05

22 May '05

Issue status update for http://drupal.org/node/20471 Project: Drupal Version: 4.6.0 Component: base system Category: feature requests Priority: normal Assigned to: degerrit Reported by: degerrit Updated by: Dries Status: patch Couple comments: Drupal supports non-Apache webservers: apache_request_headers() might not always be available. Does this patch need input checking? Depends on how/when/where the remote address data is used. Fact is that we don't want people to inject XSS-stuff through HTTP headers. Make sure to double-check this. I'd rename the function to remote_address(). We usually don't abbreviate words like 'address'. The word 'via' can't be translated. We write } else { and not } else {Just thinking up loud. Is it easy to fake or spoof X-Forwarded-For-headers? If it is, it would be easy to trick Drupal (eg. in the statistics.module's log pages we group by remote address). For the watchdog it doesn't matter, but for the statistics module it does. Maybe we need a toggle so remote_address() can be told not to return the 'true IP address'. Dries Previous comments: ------------------------------------------------------------------------ April 14, 2005 - 01:42 : degerrit In several modules, replace $_SERVER["REMOTE_ADDR"] with a function which understands X-Forwarded-For. Proxy servers often (sometimes, always?) insert "X-Forwarded-For" headers which contains the "real" client IP address. I think it is useful to log the client IP address in that situation. This little snippet works for me, and I'd suggest something similar be made into a function? $headers = apache_request_headers(); if (array_key_exists('X-Forwarded-For', $headers)){ $hostname=$headers['X-Forwarded-For'] . ' via ' . $_SERVER["REMOTE_ADDR"]; } else { $hostname=$_SERVER["REMOTE_ADDR"]; } I can make a patch proposal if people like the idea. ------------------------------------------------------------------------ May 21, 2005 - 23:44 : degerrit Attachment: http://drupal.org/files/issues/remote_addr.diff (6.07 KB) Here's my proposal for showing user IP addresses behind proxy servers, especially in log files. It adds a function remote_addr() and replaces all the uses of $_SERVER["REMOTE_ADDR"] with that function. This is my first patch for Drupal, don't be too harsh one me :-) A few notes: - I patched session.inc because $_SERVER["REMOTE_ADDR"] is also called in session.inc and common.inc is not available at that time it seems - maybe I replaced too vigorously in common.inc and sessions.inc, it works for me though - maybe it should be renamed http_remote_addr or apache_remote_addr

1 0

[drupal-devel] [feature] Replace $_SERVER["REMOTE_ADDR"] with a function which understands X-Forwarded-For
by degerrit 21 May '05

21 May '05

Issue status update for http://drupal.org/node/20471 Project: Drupal -Version: 4.5.2 +Version: 4.6.0 Component: base system Category: feature requests Priority: normal -Assigned to: Anonymous +Assigned to: degerrit Reported by: degerrit Updated by: degerrit -Status: active +Status: patch Attachment: http://drupal.org/files/issues/remote_addr.diff (6.07 KB) Here's my proposal for showing user IP addresses behind proxy servers, especially in log files. It adds a function remote_addr() and replaces all the uses of $_SERVER["REMOTE_ADDR"] with that function. This is my first patch for Drupal, don't be too harsh one me :-) A few notes: - I patched session.inc because $_SERVER["REMOTE_ADDR"] is also called in session.inc and common.inc is not available at that time it seems - maybe I replaced too vigorously in common.inc and sessions.inc, it works for me though - maybe it should be renamed http_remote_addr or apache_remote_addr degerrit Previous comments: ------------------------------------------------------------------------ April 14, 2005 - 00:42 : degerrit In several modules, replace $_SERVER["REMOTE_ADDR"] with a function which understands X-Forwarded-For. Proxy servers often (sometimes, always?) insert "X-Forwarded-For" headers which contains the "real" client IP address. I think it is useful to log the client IP address in that situation. This little snippet works for me, and I'd suggest something similar be made into a function? $headers = apache_request_headers(); if (array_key_exists('X-Forwarded-For', $headers)){ $hostname=$headers['X-Forwarded-For'] . ' via ' . $_SERVER["REMOTE_ADDR"]; } else { $hostname=$_SERVER["REMOTE_ADDR"]; } I can make a patch proposal if people like the idea.

1 0

[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