May 2005 - Development - lists.drupal.org

[drupal-devel] [bug] Autocomplete HTTP errors don't stop throbber
by Thox 24 May '05

24 May '05

Issue status update for http://drupal.org/node/23506 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: Thox Updated by: Thox Status: patch Attachment: http://drupal.org/files/issues/autocomplete.js.patch (1.14 KB) When using an autocomplete field, the throbber icon does not dissapear after HTTP errors (e.g. 404 if the autocomplete url is not found). Attached patch fixes this and also makes it work in one of my modules where the same autocomplete javascript object (ACDB) is shared by many controls (they're all recipe ingredient fields, so they share the same cache). Thox

4 6

[drupal-devel] [bug] Make form_textarea() XHTML ready
by Robin Monks 24 May '05

24 May '05

Issue status update for http://drupal.org/node/23530 Project: Drupal Version: 4.6.0 Component: base system Category: bug reports Priority: normal Assigned to: Robin Monks Reported by: Robin Monks Updated by: Robin Monks Status: patch Attachment: http://drupal.org/files/issues/xhtml_form__textarea.patch (1.53 KB) This patch uses CSS formatting to format textboxes (as per XHTML standards) and removes the wrap artifact (which was no longer needed as of NS2.0 and IE4.0). This patch uses "em" to format by character, this is backwards compatible with previous calls (give or take a few pixels). Robin Robin Monks

2 2

[drupal-devel] [bug] non-standard form fields
by Robin Monks 24 May '05

24 May '05

Issue status update for http://drupal.org/node/23531 Project: Drupal Version: cvs Component: user.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: Alex Reisner Updated by: Robin Monks -Status: active +Status: patch Attachment: http://drupal.org/files/issues/hard.coded.form.fields.patch (2.19 KB) This patch should take care of that. I was unable to get someone to review it, so it may have a rough spot. Robin Robin Monks Previous comments: ------------------------------------------------------------------------ May 24, 2005 - 17:40 : Alex Reisner User.module manually creates several form fields (on lines 1091 and 1664) rather than calling the form_ functions in common.inc. The fields on line 1664 are lacking a class attribute and all are missing id attributes, making their appearances difficult to control. It strikes me as better if the form_ functions were used, but I don't know enough about user.module to know if this is possible. At least the class and id info should be added manually. Relevant code: *Line 1091* $group .= form_item(t('Password'), '<input type="password" class="form-password" name="edit[pass1]" size="12" maxlength="24" /> <input type="password" class="form-password" name="edit[pass2]" size="12" maxlength="24" />', t('Enter your new password twice if you want to change your current password, or leave it blank if you are happy with your current password.'), NULL, TRUE); *Line 1664* $rows[] = array('<input type="text" size="32" maxlength="64" name="edit[name]" />', '<input type="submit" name="op" value="'. t('Add role') .'" />');

1 0

[drupal-devel] Loved the newsletter!
by Gordon Heydon 24 May '05

24 May '05

Hi everyone, it's... I got the first newsletter today and I just loved it, it was really good. I am not just saying this, because I am in the first article. But it was very interesting and it was just great. I will be eagerly waiting for issue 2 next week ;-) The only thing that I was wondering is that is there a web version of the newsletter. Sometimes I find it a bit easer to read than email text versions. Also it is always easier when you want to do back to past issues. Keep up the great work. Gordon.

3 2

[drupal-devel] [feature] AJAX form_autocomplete() field
by Thox 24 May '05

24 May '05

Issue status update for http://drupal.org/node/22519 Project: Drupal Version: 4.6.0 Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Thox Updated by: Thox Status: patch Attachment: http://drupal.org/files/issues/form_autocomplete.patch (11.48 KB) As discussed on #drupal, I've created a patch to add an AJAX-based form_autocomplete() field to the Drupal core. The documentation of the autocomplete callback remains undocumented. See http://drupal.org/node/22471 for more details. Thox

9 32

[drupal-devel] XML-RPC docs
by Karoly Negyesi 24 May '05

24 May '05

Hi! Sorry for cross-posting but this really belongs to both lists. Yesterday I tried to code my first XML-RPC server and client. This was very much unlike anything true Drupal -- scarce examples, few documentation... closeau lended a hand, and I have written down my experiences -- the next Drupal coder may need them as well. So please review http://drupal.org/node/23501 as code and as docs. Thanks NK

1 0

[drupal-devel] [feature] AJAX Google Suggest feature for Folksonomy Module
by Steven 24 May '05

24 May '05

Issue status update for http://drupal.org/node/21116 Project: Drupal Version: cvs Component: taxonomy.module Category: feature requests Priority: normal Assigned to: killes(a)www.drop.org Reported by: factoryjoe Updated by: Steven Status: patch I've confirmed the "extra spaces after commas" problem occurs. The simplest fix is to just implode and explode the same and ignore whether spaces are correct. They will be trimmed off when the terms are saved anyway. Also, this bit of code could use a bit of commenting: // The user enters a comma-separated list of tags. We only autocomplete the last tag. Steven Previous comments: ------------------------------------------------------------------------ April 22, 2005 - 20:20 : factoryjoe When adding folksonomy terms to a node, drawing from existing terms would be a useful feature. There are two options worth considering: An initially hidden flat list of the most used 150 tags that you can click to add to your text input (see my demo [1]) A Google-suggest [2] like feature for pulling out of /all available/ tags [1] http://factorycity.net/demos/drupal/node_creation/ [2] http://www.google.com/webhp?complete=1&hl=en ------------------------------------------------------------------------ April 22, 2005 - 21:05 : factoryjoe This was intended for Morbus' freetagging code, which doesn't have a separate project. Thus, I'm moving it to the drupal project. ------------------------------------------------------------------------ May 21, 2005 - 01:03 : killes(a)www.drop.org I think that should be easy once Thox' Ajax code has hit core. See: http://drupal.org/node/22471 ------------------------------------------------------------------------ May 23, 2005 - 22:00 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/taxonomy_autocomplete.patch (2.41 KB) Ok, somebody please try this patch. You'll need to apply the ajax patch first. ------------------------------------------------------------------------ May 24, 2005 - 05:18 : Steven Good patch, some niggles: The check_plain() does nothing to either commas or pipes, so you can do it at the end after all the imploding. In fact, you also need to check_plain() the existing words again, so moving the check_plain() to the end fixes that too. The existing words are in plain-text form when they arrive and need to be inserted back into HTML. First you explode by ',' (no space), then you implode by ', ' (with space). It seems to me that each time you use an autocompletion suggestion, you get extra spaces after a comma. It's possible HTML's whitespace rules collapse the multiple spaces, but it needs to be tested. Like the other Ajax patch, we should hardcode $limit to prevent abuse.

1 0

[drupal-devel] [feature] Enable customizing of "Title" field on node forms
by gsperk 24 May '05

24 May '05

Issue status update for http://drupal.org/node/10056 Project: Drupal Version: cvs Component: node system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Anonymous Updated by: gsperk Status: patch I wonder if someone could help me with the following problem. After applying the patch I made the output for 'title' in my own_node.module this: $output .= form_hidden('title', $node->firstname . ' ' . $node->surname); When the form is first submitted I get the error 'You have to specify a title'. When I submit again the firstname/surname variables are obviously in $node, and the form submits with the desired title. So, I suppose my question is, how can get the values for firstname and surname into $node without submitting twice? (If it's not obvious I can confirm that I dont have much experience with this kind of stuff. Any suggestions would be a big help.) gsperk Previous comments: ------------------------------------------------------------------------ August 14, 2004 - 18:17 : Anonymous Attachment: http://drupal.org/files/issues/node.set-title-field.patch (2.02 KB) The default "title" field in a node object is useful but not always appropriate. For some node types it would be preferable to rename the field for display to users (e.g., from "title" to "name" for a record of an organization or business), while in others the title might be best drawn from a combination of other fields (e.g., first_name and last_name fields, for a record of an individual). This patch enables two new alternatives for node titles: renamingThe title field can be renamed, e.g., from "title" to "name". substutingOther fields can be substituted for the title field. The functionality is implemented through a new proposed node hook, _title_field($op). There are two possible values for $op: "action" (either "rename" or "substitute") and "names" (a list of field names to be used in the title field). Sample uses: [?PHP function example_title_field($node, $op) { switch ($op) { case 'action': $return = 'rename'; break; case 'names': $return = array('Name'); } return $return; } ?] In this case, since the requested action is "rename", the title field would be labelled "Name" (instead of "Title") in node add and edit forms for nodes of type "example". [?PHP function example_title_field($node, $op) { switch ($op) { case 'action': $return = 'substitute'; break; case 'names': $return = array('first_name', 'last_name'); } return $return; } ?] In this case, no "Title" field would be displayed in node add or node edit forms of node type "example". Instead, the fields "first_name" and "last_name" would be concatenated to form a title. Implementing this patch would significantly increase the flexibility of the node system, making it feasible to store information of many types not currently supported because they don't have a "title" attribute. ------------------------------------------------------------------------ August 15, 2004 - 16:39 : Dries This is best accomplished through the existing nodeapi hook, using a separate module. ------------------------------------------------------------------------ August 15, 2004 - 23:02 : nedjo Thanks for the suggestion. I did look for a way to accomplish this through _nodeapi (and other existing hooks), but couldn't see how. The "title" field is hard-coded into node.module. The _nodeapi hook allows various types of manipulations, but not, so far as I could see, changes to elements that have been generated by, e.g., form_textfield() calls. Are there possibilities I'm missing? Other approaches? Any specific suggestions as to means we could use to change the hard-coded "title" field? ------------------------------------------------------------------------ August 19, 2004 - 18:27 : nedjo Attachment: http://drupal.org/files/issues/node.set-title-field_0.patch (741 bytes) Drawing on Dries's suggestion, I've substantially revised this patch to enable node title field customization with only three additional lines of code in node.module. In place of the existing line in function node_form() <?php $output .= form_textfield(t('Title'), 'title', $edit->title, 60, 128, NULL, NULL, TRUE); ?> the patch substitutes a the following: <?php $title = variable_get('node_titlefield_'. $edit->type, 'Title'); if(!($title == 'none')) { $output .= form_textfield(t($title), 'title', $edit->title, 60, 128, NULL, NULL, TRUE); } ?> With this change in place, node modules will be able to override the standard node title label by setting a variable, node_titlefield_nodetype, where nodetype is the type of node. This could be done, e.g., in a _settings hook, so that the first time settings were accessed the module would set the variable: <?php if (variable_get('node_titlefield_example', '') == '') { // since none is already set, set this variable variable_set('node_titlefield_example', 'Name'); drupal_set_message('Example module initialization completed.'); } ?> The special value 'none' would suppress the title field altogether in node forms, used as follows: <?php if (variable_get('node_titlefield_example', '') == '') { // since none is already set, set this variable variable_set('node_titlefield_example', 'none'); drupal_set_message('Example module initialization completed.'); } ?> In this case, a _validate hook would be used to set the title field value. Assuming a module where a first name-last name combination was to be used for a title: <?php function example_validate(&$node) { if(!(isset($node->title))) { $node->title = $node->first_name . ' ' . node->last_name; } } ?> In short, this three-line addition to the node.module would significantly increase the flexibility of the node system by removing the hard-coded 'Title' field in node add and edit forms and instead enabling custom labelling or concatenation of the field from other sources. ------------------------------------------------------------------------ August 19, 2004 - 18:50 : moshe weitzman I like this functionality. But the implementation still seems unclean. I would prefer to simply remove the 'title' form field from node_form() and require that modules present this field in whatever way they please. in some cases, they will use a hidden form field because no customer interaction is required. This causes a break with backward compatibility, but cleanliness is facored over compatibilityness (when you must choose). I'm moving this back to 'Active', since I don't think this patch is committable as is. ------------------------------------------------------------------------ August 27, 2004 - 23:46 : nedjo Attachment: http://drupal.org/files/issues/node.set-title-field_1.patch (830 bytes) Thanks for looking at this. The suggestion - dropping the title field altogether and leaving this for module authors - has the advantage of simplicity. However, this change would imply significant new work as it would would require all or nearly all existing modules - core and contributed - be modified. While I think enabling title field customization is important for Drupal as a whole, and while this is a change I need for two modules I'm working on, I'm not immediately convinced that the benefits of this change justify this cost. Also, in most cases, the present title field works fine, so keeping it as a default option would I feel be desirable. Hence the following patch. In place of my (poorly conceived) initial hook proposals, above, this patch introduces a single very straightforward new node hook, _title_field. By setting this hook to return FALSE, node modules authors will suppress the default title field, and be free therefore to substitute what they wish or need. Returning TRUE, or not using the hook, will result in the default title field being used. Sample usage: <?php function example_title_field() { return FALSE; } ?> This is, I feel, a much better solution than the previous two I suggested--proof, if it's true, that the Drupal issue system works! ------------------------------------------------------------------------ September 6, 2004 - 15:50 : nedjo Are there any objections to or issues raised by this small patch (introducing a new hook to make the title field optional in node forms)? If not, can it be applied? ------------------------------------------------------------------------ September 7, 2004 - 13:46 : Anonymous I think I agree with Moshe's opinion that this should be accomplished by having node modules display the title field. In any event, this is a new feature and shouldn't go in during the feature freeze for 4.5. ------------------------------------------------------------------------ September 7, 2004 - 13:58 : ccourtne +1 for just moving the title field to be a responsibility of the implementing module instead of node_form. There is already to some extent "hook overload", in addition there may be several modules which don't want to even display a title module. Why add that only fixes some of the problems just to have to remove it later when you make a fix that address the whole problem. ------------------------------------------------------------------------ September 7, 2004 - 21:09 : nedjo Attachment: http://drupal.org/files/issues/node.remove-title-field.patch (636 bytes) Thanks for comments. As per feedback, the attached patch removes the title field from node forms, leaving this instead to node modules. Understood that possible approval of this patch this will need to wait until code unfrozen. ------------------------------------------------------------------------ October 24, 2004 - 12:06 : moshe weitzman please patch all core node modules as well. ------------------------------------------------------------------------ November 28, 2004 - 01:00 : nedjo Attachment: http://drupal.org/files/issues/node-move-form-title-field.patch (4.29 KB) Good point Moshe. This patch of node.module plus all core node modules simply moves the title field out of node.module and into the node modules, enabling (if desired) customization of the title field by a module. Patches to contributed modules will in most cases be as simple as adding the line <?php $output = form_textfield(t('Subject'), 'title', $node->title, 60, 128, NULL, NULL, TRUE); ?> at the beginning of a typename_form() function (and, if necessary changing an existing $output = to $output .=). In the attached patch, I've customized the title field for only one of the node types, calling the title of a forum topic the "Subject". We could consider calling the title of a blog a "Subject" or "Topic" as well. I feel this is a good solution (thanks for the feedback and discussion) and, for minimal work (minor updates to contributed modules), will have the significant benefit of enabling flexibility in content types beyond those that have "title" attributes. ------------------------------------------------------------------------ November 28, 2004 - 17:45 : nedjo Ability to customize title as provided in this patch was requested here [1]: "When adding/editing, the 'title' field is manditory, which is fine. Except that its label is hardcoded to 'title'. A custom node modelling, say, a 'Company' would much rather this field be presented to the user as 'Company Name'. " [1] http://drupal.org/node/13596 ------------------------------------------------------------------------ March 4, 2005 - 03:44 : nedjo Here's another patch that's sat for months without being either applied or turned down, although there was expressed support and, after several iterations, it addressed all issues that had been raised. The point is to remove the hard-coded "Title" field - inapprioriate for many node types, e.g., companies - from node forms, instead allowing node modules to treat this as appropriate (e.g., a "Subject", "Name" or "Topic", or nothing at all). Are there problems with this approach that were not raised? Is there a reason this wasn't accepted? ------------------------------------------------------------------------ March 4, 2005 - 03:54 : Steven nedjo: if you read the backlog you can see that this feature was delayed for after the 4.6 release. "I've customized the title field for only one of the node types, calling the title of a forum topic the "Subject". " This is really inconsistent, as what you call the title of a blog, story or forum node is purely subjective. "Subject" "Topic" and "Title" are pretty much interchageable and any subtle differences will surely be eroded by translation. The only thing I can agree on so far is naming a polls' title "Question". ------------------------------------------------------------------------ March 4, 2005 - 05:15 : nedjo Thanks for the note. I'm not sure what you mean by the "backlog". Where would I find this? I agree that a "Question" field would make sense for polls. ------------------------------------------------------------------------ March 4, 2005 - 14:12 : JonBob Actually UnConeD, it was postponed until after the 4.5 release, not 4.6, and looks like everyone forgot about it when the release happened. And no, Nedjo, I don't take this as proof that Drupal needs more bureaucracy. :-) Marking this active again; I'm sure the patch will have to be updated once the code branches. We had rolled this function into the needs for CCK, but in our discussions split it off again. ------------------------------------------------------------------------ April 3, 2005 - 05:28 : chx Attachment: http://drupal.org/files/issues/node-move-form-title-field_0.patch (4.59 KB) The patch applies to ucrrent HEAD with some offset. I have rerolled it so it applies cleanly. ------------------------------------------------------------------------ May 20, 2005 - 10:09 : chx Patch still applies (yes, with some offset, but applies). ANd yes, we need this very badly. ------------------------------------------------------------------------ May 20, 2005 - 10:18 : Thox I'd benefit greatly from having a feature like this. The example already given is one of the cases I need it: I'd like the title field to be a concatenation of two fields: "First name" and "Last name".

1 0

[drupal-devel] [feature] AJAX Google Suggest feature for Folksonomy Module
by Steven 24 May '05

24 May '05

Issue status update for http://drupal.org/node/21116 Project: Drupal Version: cvs Component: taxonomy.module Category: feature requests Priority: normal Assigned to: killes(a)www.drop.org Reported by: factoryjoe Updated by: Steven Status: patch Good patch, some niggles: The check_plain() does nothing to either commas or pipes, so you can do it at the end after all the imploding. In fact, you also need to check_plain() the existing words again, so moving the check_plain() to the end fixes that too. The existing words are in plain-text form when they arrive and need to be inserted back into HTML. First you explode by ',' (no space), then you implode by ', ' (with space). It seems to me that each time you use an autocompletion suggestion, you get extra spaces after a comma. It's possible HTML's whitespace rules collapse the multiple spaces, but it needs to be tested. Like the other Ajax patch, we should hardcode $limit to prevent abuse. Steven Previous comments: ------------------------------------------------------------------------ April 22, 2005 - 20:20 : factoryjoe When adding folksonomy terms to a node, drawing from existing terms would be a useful feature. There are two options worth considering: An initially hidden flat list of the most used 150 tags that you can click to add to your text input (see my demo [1]) A Google-suggest [2] like feature for pulling out of /all available/ tags [1] http://factorycity.net/demos/drupal/node_creation/ [2] http://www.google.com/webhp?complete=1&hl=en ------------------------------------------------------------------------ April 22, 2005 - 21:05 : factoryjoe This was intended for Morbus' freetagging code, which doesn't have a separate project. Thus, I'm moving it to the drupal project. ------------------------------------------------------------------------ May 21, 2005 - 01:03 : killes(a)www.drop.org I think that should be easy once Thox' Ajax code has hit core. See: http://drupal.org/node/22471 ------------------------------------------------------------------------ May 23, 2005 - 22:00 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/taxonomy_autocomplete.patch (2.41 KB) Ok, somebody please try this patch. You'll need to apply the ajax patch first.

1 0

[drupal-devel] Unit tests in Drupal.
by Adrian Rossouw 23 May '05

23 May '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I know there has been some discussion regarding this in the past, but I was wondering what it would actually take to get Drupal into a state where we take advantage of unit testing. As I have stated before, the most of my time spent maintaining the postgres port is spent testing every little thing in the system, and anything to automate that would help me, and by extension Drupal, immensely. Any thoughts ? - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCjxYCgegMqdGlkasRAtLLAJ4wy1XmaTGSLIx/82a7A5yB1s77gACfWGn/ WnsHfDt10emthkkRviRcy/o= =BwUV -----END PGP SIGNATURE-----

6 8