April 2005 - Development - lists.drupal.org

[drupal-devel] [bug] fix empty form elements
by chx 23 Apr '05

23 Apr '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_0.patch (4.72 KB) Small bugfix. chx Previous comments: ------------------------------------------------------------------------ March 10, 2005 - 02: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 - 19: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 - 17: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 - 17: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 - 18: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 - 08: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 - 00:15 : chx Dries? ------------------------------------------------------------------------ April 12, 2005 - 20:15 : chx Attachment: http://drupal.org/files/issues/form_checkboxes_3.patch (1.64 KB) ------------------------------------------------------------------------ April 12, 2005 - 20: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 - 22: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 12, 2005 - 23: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 - 12: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 - 12:38 : chx Forgot to change the title. ------------------------------------------------------------------------ April 23, 2005 - 12: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.

1 0

[drupal-devel] [bug] fix empty form elements
by chx 23 Apr '05

23 Apr '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 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. chx Previous comments: ------------------------------------------------------------------------ March 10, 2005 - 02: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 - 19: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 - 17: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 - 17: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 - 18: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 - 08: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 - 00:15 : chx Dries? ------------------------------------------------------------------------ April 12, 2005 - 20:15 : chx Attachment: http://drupal.org/files/issues/form_checkboxes_3.patch (1.64 KB) ------------------------------------------------------------------------ April 12, 2005 - 20: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 - 22: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 12, 2005 - 23: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 - 12: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 - 12:38 : chx Forgot to change the title.

1 0

[drupal-devel] [bug] fix empty form elements
by chx 23 Apr '05

23 Apr '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 Forgot to change the title. chx Previous comments: ------------------------------------------------------------------------ March 10, 2005 - 02: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 - 19: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 - 17: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 - 17: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 - 18: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 - 08: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 - 00:15 : chx Dries? ------------------------------------------------------------------------ April 12, 2005 - 20:15 : chx Attachment: http://drupal.org/files/issues/form_checkboxes_3.patch (1.64 KB) ------------------------------------------------------------------------ April 12, 2005 - 20: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 - 22: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 12, 2005 - 23: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 - 12: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

1 0

[drupal-devel] [bug] form_checkboxes saves "no selection" as string
by chx 23 Apr '05

23 Apr '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.patch (4.71 KB) See Gordon's complaint http://lists.drupal.org/archives/drupal-devel/2005-04/msg00934.html chx Previous comments: ------------------------------------------------------------------------ March 10, 2005 - 02: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 - 19: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 - 17: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 - 17: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 - 18: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 - 08: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 - 00:15 : chx Dries? ------------------------------------------------------------------------ April 12, 2005 - 20:15 : chx Attachment: http://drupal.org/files/issues/form_checkboxes_3.patch (1.64 KB) ------------------------------------------------------------------------ April 12, 2005 - 20: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 - 22: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 12, 2005 - 23: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.

1 0

[drupal-devel] Re: [drupal.org] LaTeX content
by puregin 23 Apr '05

23 Apr '05

On 20 Apr 2005, at 8:47 PM, Matt Schwartz wrote: > Djun, > > My goal is to eventually have drupal books exportable in a variety of > formats, including LaTeX. I haven't had time to look into the LaTeX > exporting yet. Since I want to literally output a book from generic > drupal nodes I'm not sure how we'd handle mathematics. I don't want to > have to rely on a special input format (i.e. drupal filter). If I understand you, your intention to store source as HTML, and convert to your export formats on the fly. Is this correct? I don't know what kind of applications you actually have in mind. In my experience, though, if you want to produce a high quality printed book that works as a book, you need to start with markup that supports print intentions. This isn't a problem if you intend to take an existing Drupal book, export it, and edit it heavily in the exported format. Probably life will be easier for the editor with this task if certain conventions can be enforced on the source text, either explicitly by the book module or implicitly through the cooperation of your contributors. > So unfortunately I don't currently have any code that can help you. I'm interested in a slightly different problem, namely having nodes contain LaTeX (to start with, perhaps later also MathML and other sources.) There's a certain amount of interest in using DocBook XML as a native format for Drupal Documentation, so perhaps there will be some overlap with this project, if it gets off of the ground. The LaTeX input would then be transformed into various output formats including HTML, which would be put back into a Drupal 'proxy' node for the source. This gives a kind of 'WYSIWYG' arrangement. A bit kludgy, but hopefully good enough. > What are your thoughts on how it might work? How would you like > authors > to input their mathematical content into drupal? I think that there's a number of projects which attempt to convert HTML to LaTeX. I've not looked closely at these - search for html2tex and you'll be on your way. Unfortunately, this transformation is basically 'just guessing'. Still, it's probably a good way to start. 'Better than nothing!' . And certainly an interesting problem/process. I've been doing some work trying to go directly from HTML to PDF, and this might be a way to achieve more control, so I'm keen to look into it further. Regarding mathematical input, TeX/LaTeX is pretty standard among people with serious mathematics editing / publishing requirements.' MathML is intended for machine generation/transformation. It's way too painful to type much of this. However, there's some tools for MathML to TeX/LaTeX, so supporting some kind of import is probably a good idea. This would allow people to edit in a convenient GUI on their desktop, and upload to Drupal via MathML. > > - Matt > > puregin(a)puregin.org wrote: >> Salve Veridicus, >> >> How is your work on LaTeX content management coming along? What are >> your >> envisioned use cases? Do you have a prototype or demo page? >> I'm interested in community authorship of mathematics. I'd like to >> have >> TeX/LaTeX content with full versioning, merging and diffs, chapters >> and >> section structures handled via Drupal books. >> >> Looking forward to hearing from you... >> >> Djun >> -- Djun M. Kim, Director djun.kim(a)cielosystems.com Cielo Systems Inc. http://www.cielosystems.com Strategic Software Research Tel: (604) 739-3941 302 - 1298 10th Avenue West FAX: (604) 739-3943 Vancouver, BC, V6H 1J4 Mobile:(778) 895-1379

2 1

[drupal-devel] [task] Consistent return 'passive voice' in form_set_error() and drupal_set_message()
by stefan nagtegaal 23 Apr '05

23 Apr '05

Issue status update for http://drupal.org/node/15595 Project: Drupal Version: cvs Component: base system Category: tasks Priority: normal Assigned to: stefan nagtegaal Reported by: bertboerland(a)www.drop.org Updated by: stefan nagtegaal -Status: active +Status: patch Setting status to Patch. stefan nagtegaal Previous comments: ------------------------------------------------------------------------ January 14, 2005 - 15:59 : bertboerland(a)www.drop.org *My* drupal not *Yours*! I think that when one addresses the user or the administrator of a site, it is best to do this outside in instead of inside out. So when in the documentation the coder is referring to the site of the administrator, this site should be called "your site" (/inside out/) but "my site" (/outside in/). There are numours examples where the text in referring to "your"where "my"would be apopriate [1] There used to be some "your" in the userinterface for the enduser as well, but that has been solved in 4.5. Before that you had "my account", but "track your postings". This has now all beens replaced by "my"and "mine". If everybody agrees, lets also corect this for the administrator as well; my administrator, not yours ;-) [1] examples: admin/logs/referrers "...that point to your web site." admin/settings "General configuration options for your site" ------------------------------------------------------------------------ April 19, 2005 - 18:36 : stefan nagtegaal We should consistently use the 'passive voice', when returning messages using form_set_error() and drupal_set_message(). ------------------------------------------------------------------------ April 22, 2005 - 14:05 : stefan nagtegaal Attachment: http://drupal.org/files/issues/drupal_set_message consistency part 1 of 2 (51.16 KB) first patch of 2 to make the drupal_set_message(), form_set_error() and watchdog() messages more consistent. please review/comment and apply..

3 2

[drupal-devel] [task] Consistent return 'passive voice' in form_set_error() and drupal_set_message()
by puregin 23 Apr '05

23 Apr '05

Issue status update for http://drupal.org/node/15595 Project: Drupal Version: cvs Component: base system Category: tasks Priority: normal Assigned to: stefan nagtegaal Reported by: bertboerland(a)www.drop.org Updated by: puregin Status: patch A big -1 from me on replacing "you" with "me" :) Regarding the use of the first person - I find it extremely awkward and confusing to see usage such as 'My Account', "Here are my recent posts", etc. From my perspective as a native speaker of English, I find that this kind of usage violates conventional "conversational context". To clarify, if I am communicating with another person *via* the medium of a program then I expect that person to follow the normal conventions of conversation, in particular, to say "me, my, I" when referring to him/herself, and "you, your, etc." when referring to me. If I am communicating with a program, I *also* expect it to follow conversational conventions. Particularly obsequious programs may always refer to themselves in an indirect second person: "This unworthy program was unable to execute your most excellent command, and will henceforth terminate itself" I have to say I really don't like this kind of interaction. I like a program that tells me straight up "I can't find my configuration files! Sorry, I'm giving up!" People like, understand, and are extremely good at direct conversational interaction. It's intuitively clear who is speaking and what the relation to the listener is. I might tolerate a page with title "My Account", but really, a message such as 'This page shows my site-wide referrer statistics. I can optionally view just the "external referrers" or the "internal referrers". Referrers are web pages, both local and on other sites, that point to your my site.' is just plain confusing and unclear. To quote Sendmail: "I refuse to talk to myself" Please don't inflict this gratuitous use of first person on us! Djun puregin Previous comments: ------------------------------------------------------------------------ January 14, 2005 - 05:59 : bertboerland(a)www.drop.org *My* drupal not *Yours*! I think that when one addresses the user or the administrator of a site, it is best to do this outside in instead of inside out. So when in the documentation the coder is referring to the site of the administrator, this site should be called "your site" (/inside out/) but "my site" (/outside in/). There are numours examples where the text in referring to "your"where "my"would be apopriate [1] There used to be some "your" in the userinterface for the enduser as well, but that has been solved in 4.5. Before that you had "my account", but "track your postings". This has now all beens replaced by "my"and "mine". If everybody agrees, lets also corect this for the administrator as well; my administrator, not yours ;-) [1] examples: admin/logs/referrers "...that point to your web site." admin/settings "General configuration options for your site" ------------------------------------------------------------------------ April 19, 2005 - 08:36 : stefan nagtegaal We should consistently use the 'passive voice', when returning messages using form_set_error() and drupal_set_message(). ------------------------------------------------------------------------ April 22, 2005 - 04:05 : stefan nagtegaal Attachment: http://drupal.org/files/issues/drupal_set_message consistency part 1 of 2 (51.16 KB) first patch of 2 to make the drupal_set_message(), form_set_error() and watchdog() messages more consistent. please review/comment and apply.. ------------------------------------------------------------------------ April 22, 2005 - 04:05 : stefan nagtegaal Setting status to Patch.

1 0

Re: [drupal-devel] Event changes
by Ber Kessels 23 Apr '05

23 Apr '05

> Let's be sure that we don't inadvertently limit that with a narrow view of what an "event" is. Yes. On the event sprint meeting, we agreed that an event is anything with a date. In better wording, anything that has a date as metadata, can be treated as event. Let us indeed not narrow this down to case specific (i.e. event must hold location start and end etc) events. Ber --

1 0

Re: [drupal-devel] Event changes
by Ber Kessels 23 Apr '05

23 Apr '05

Hello > Since flexinode is a very usefull and popular module, I don't think it is a problem to depend on it. I agree. And I think -in contrary to Adrians idea- that flexinode is not complex. For users, that is! When you look at the code, yes, its overly complex, but for end-users its not hard at all to use. +1 for depending on it. Ber --

1 0

[drupal-devel] [bug] Cannot delete users
by asimmonds 23 Apr '05

23 Apr '05

Issue status update for http://drupal.org/node/19750 Project: Drupal -Version: cvs +Version: 4.6.0 Component: user.module Category: bug reports Priority: critical Assigned to: Anonymous Reported by: AtomicMaestro Updated by: asimmonds Status: patch I'm reopening this for 4.6.0, as the bug still exists in the released 4.6.0 and I can't find moshe's patch being committed to the 4.6 branch. A number of people in the forum (http://drupal.org/node/20970) have also found it doesn't work as expected. asimmonds Previous comments: ------------------------------------------------------------------------ March 31, 2005 - 21:33 : AtomicMaestro I can't seem to delete users. To reproduce: 1. Create a user. 2. View the user created in 1. 3. Click Delete I would expect to be told I have to block the user first, but instead, I'm sent back to the user report. There's no message, nothing in the log. ------------------------------------------------------------------------ April 1, 2005 - 19:40 : asimmonds Attachment: http://drupal.org/files/issues/fix_delete_user.patch (581 bytes) Patch attached to fix this, the delete code in node.module works the same way ------------------------------------------------------------------------ April 4, 2005 - 02:15 : moshe weitzman when one deletes a user from list of users in admin, he expects to return back to that list after successfully deleting. thats the intent of the $_REQUEST['destination']. I think this patch will defeat that behavior. There certainly is a bug here, but I don't think we have found the right fix yet. I suggest testing a delete from both admin and user/edit pages. make sure you arrive at the expected page after a successful delete. ------------------------------------------------------------------------ April 4, 2005 - 19:19 : asimmonds There are two methods to enter the user edit page as a admin: 1/ View a user, then select the edit tab. 2/ Click 'edit' for the user in the admin/user list. The 2nd method sets destination=admin/user in the URL, when the user edit page is shown. If the Delete button is clicked, it calls drupal_goto("user/$account->uid/delete") (the code's comment mentions this is done to make the tabs disappear). As destination is already set, drupal_goto() redirects to that ie. "admin/user" instead of "user/$account->uid/delete" If after successfully deleting a user, the code calls drupal_goto("admin/user"). I looked at how node.module does the node delete/confirm sequence and it has this unset($_REQUEST['destination']) in there as well. Maybe this delete/confirm sequence pattern needs a re-think for 4.7 ------------------------------------------------------------------------ April 6, 2005 - 16:01 : moshe weitzman Attachment: http://drupal.org/files/issues/user_15.patch (1020 bytes) here is an alternative. this one properly maintains the destination parameter which is useful especially when you are not on the 1st page of your user listing. the redirect insures that you return to the page you were on. another advantage is that i was able to delete a few lines of code which were performing a drupal_goto(). the downside is that the pupose of the drupal_goto() was to get rid of the tabs. I don't mind the tabs on the delete confirm page, so I think my patch is better, and removes a couple lines of code. either patch presented here would work ok. ------------------------------------------------------------------------ April 6, 2005 - 17:13 : moshe weitzman Attachment: http://drupal.org/files/issues/menu_set_location.patch (2.23 KB) here is a different patch suggested by UnConed. Uses menu_set_location() to remove the tabs on the delete confirmation page for both nodes and users. ------------------------------------------------------------------------ April 7, 2005 - 07:28 : Dries Mmm, Steven's patch fixes the tabs but still is a bit of a hack. (Also, parts of the strings can't be translated, the use of arg(1) vs $edit['nid'] looks a bit weird.) Can't we fix this properly? ------------------------------------------------------------------------ April 9, 2005 - 00:50 : Dries Could this be fixed properly by making a stand-alone callback for the delete view? ------------------------------------------------------------------------ April 13, 2005 - 07:43 : Dries Last patch committed to DRUPAL-4-6. Still waiting for a better fix for HEAD.

1 0