September 2005 - Development - lists.drupal.org

[drupal-devel] [feature] Enable customizing of "Title" field on node forms
by Robrecht Jacques 12 Sep '05

12 Sep '05

Issue status update for http://drupal.org/node/10056 Post a follow up: http://drupal.org/project/comments/add/10056 Project: Drupal Version: cvs Component: node system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Anonymous Updated by: Robrecht Jacques Status: patch (ready to be committed) Attachment: http://drupal.org/files/issues/title-validation_1.patch (6.23 KB) +1 I need this too: I want to be able to set the title of a node automatically. Patch still applies with offset (rerolled patch attached). Robrecht Jacques Previous comments: ------------------------------------------------------------------------ Sat, 14 Aug 2004 18:17:11 +0000 : 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. ------------------------------------------------------------------------ Sun, 15 Aug 2004 16:39:37 +0000 : Dries This is best accomplished through the existing nodeapi hook, using a separate module. ------------------------------------------------------------------------ Sun, 15 Aug 2004 23:02:13 +0000 : 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? ------------------------------------------------------------------------ Thu, 19 Aug 2004 18:27:15 +0000 : 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. ------------------------------------------------------------------------ Thu, 19 Aug 2004 18:50:42 +0000 : 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. ------------------------------------------------------------------------ Fri, 27 Aug 2004 23:46:45 +0000 : 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! ------------------------------------------------------------------------ Mon, 06 Sep 2004 15:50:38 +0000 : 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? ------------------------------------------------------------------------ Tue, 07 Sep 2004 13:46:29 +0000 : 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. ------------------------------------------------------------------------ Tue, 07 Sep 2004 13:58:34 +0000 : 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. ------------------------------------------------------------------------ Tue, 07 Sep 2004 21:09:53 +0000 : 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. ------------------------------------------------------------------------ Sun, 24 Oct 2004 12:06:46 +0000 : moshe weitzman please patch all core node modules as well. ------------------------------------------------------------------------ Sun, 28 Nov 2004 01:00:31 +0000 : 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. ------------------------------------------------------------------------ Sun, 28 Nov 2004 17:45:35 +0000 : 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 ------------------------------------------------------------------------ Fri, 04 Mar 2005 03:44:55 +0000 : 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? ------------------------------------------------------------------------ Fri, 04 Mar 2005 03:54:02 +0000 : 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". ------------------------------------------------------------------------ Fri, 04 Mar 2005 05:15:03 +0000 : 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. ------------------------------------------------------------------------ Fri, 04 Mar 2005 14:12:56 +0000 : 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. ------------------------------------------------------------------------ Sun, 03 Apr 2005 05:28:08 +0000 : 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. ------------------------------------------------------------------------ Fri, 20 May 2005 10:09:50 +0000 : chx Patch still applies (yes, with some offset, but applies). ANd yes, we need this very badly. ------------------------------------------------------------------------ Fri, 20 May 2005 10:18:49 +0000 : 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". ------------------------------------------------------------------------ Tue, 24 May 2005 03:39:40 +0000 : gsperk 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.) ------------------------------------------------------------------------ Wed, 25 May 2005 04:23:41 +0000 : Steven To make this patch work you also need to move the title validation out of node.module and into the node modules. I don't think this is that much of a problem, it is code that is not going to be touched much. Also, in light of the upcoming CCK it makes sense to do it like this. ------------------------------------------------------------------------ Sat, 02 Jul 2005 17:02:26 +0000 : hanoii Nice thread. I have come up with a slightly different approach I think that would need less patching/updating of other modules. Drupal 4.6.2 node.module:1275 <?php // Get the node-specific bits. // We can't use node_invoke() because $param must be passed by reference. $function = node_get_module_name($edit) .'_form'; $param = array(); if (function_exists($function)) { $form .= $function($edit, $param, $title); } ?> Notice the $title param on the hook_form invoke. This was what I added. As that hook is called like this an not with the node_invoke() I can define on my custom node module, or patch any module I need to modify the title description with the following hook: <?php function budget_form(&$node, &$params, &$title) { ?> and modify the $title argument there, as it is by reference, It will me modified on node.module. Then again on node.module:1319 I added/changed the following: <?php if ( ! $title ) { $title = t('Title') ; } $output .= form_textfield($title, 'title', $edit->title, 60, 128, NULL, NULL, TRUE); ?> So, if the module modify the title var, it uses that, if not, it uses the default one. Worked for me so far, nice to post on drupal. Greetings, a.= ------------------------------------------------------------------------ Sat, 02 Jul 2005 18:10:28 +0000 : hanoii I posted too soon the thing before... :) I did further patches because of the validation keep telling that I have tu put a "title". I was happy with the previous patch, not so much with this one, but I let you know what I did... on the node.module, node_validate() function I move the title validation block just after the <?php // Do node-type-specific validation checks. node_invoke($node, 'validate'); node_invoke_nodeapi($node, 'validate'); ?> and added another parameter to the form_set_error() <?php // Validate the title field. if (isset($node->title)) { if (trim($node->title) == '') { form_set_error('title', t('You have to specify a title.'), TRUE); } } ?> then, on the form_set_error function in common.inc I did the following: <?php /** * File an error against the form element with the specified name. */ function form_set_error($name, $message, $checkexistance = FALSE ) { if ( !$checkexistance || $checkexistance && !isset($GLOBALS['form'][$name]) ) { $GLOBALS['form'][$name] = $message; drupal_set_message($message, 'error'); } } ?> So now, if any previous title error was added, and the $checkexistance flag is TRUE, no error will be added to the message queue. The moving place of the validation block was to let the modules validate first than the node module. Errrr.. I don't like it, but again, it worked :) a.= ------------------------------------------------------------------------ Mon, 01 Aug 2005 00:54:22 +0000 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/title_0.patch (4.56 KB) I've updated the patch to apply to current cvs. As progress on the CCK has been rather slow, I'd appreciate if somebody could address Steven's concerns and the patch could be applied. ------------------------------------------------------------------------ Tue, 16 Aug 2005 19:19:23 +0000 : Thox Attached is a patch with an attempt to move the title validation code into the node modules (from node.module). ------------------------------------------------------------------------ Tue, 16 Aug 2005 19:20:21 +0000 : Thox Attachment: http://drupal.org/files/issues/title-validation.patch (6.22 KB) attached again (issue preview seems busted?) ------------------------------------------------------------------------ Wed, 24 Aug 2005 18:57:26 +0000 : nedjo Thanks chx, killes, and Thox for updates and fixes on the patch. I've applied and tested it and Thox's changes seem to address the title validation issue. It's a couple of releases later--it would be great to see this fix applied! ------------------------------------------------------------------------ Wed, 24 Aug 2005 23:17:25 +0000 : mathias Attachment: http://drupal.org/files/issues/title-validation_0.patch (6.04 KB) +1 I've needed to change the name of the title field or even altogether hide it for custom modules. Issue preview was working for me. We should document for module developers the implications title-less nodes (e.g., less informative watchdog entries, harder to edit nodes, node title lists become buggy, etc). I couldn't get the patch to apply cleanly to HEAD so here's a new one.

1 0

[drupal-devel] Tag performance
by Dries Buytaert 12 Sep '05

12 Sep '05

See http://pui.ch/phred/ for some interesting articles on the performance of tag-systems. Well worth a read if you plan to use Drupal to maintain thousands of tags. -- Dries Buytaert :: http://www.buytaert.net/

1 0

[drupal-devel] [bug] theme_image() doesn't actually output width and height of image
by Souvent22 12 Sep '05

12 Sep '05

Issue status update for http://drupal.org/node/30935 Post a follow up: http://drupal.org/project/comments/add/30935 Project: Drupal Version: cvs Component: theme system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: m3avrck Updated by: Souvent22 Status: patch (ready to be committed) Used the patch, and did a quick test. Worked well for me. +1. Souvent22 Previous comments: ------------------------------------------------------------------------ Sun, 11 Sep 2005 16:22:28 +0000 : m3avrck Function theme_image() doesn't actually return a width and height for an image like it claims to do. ------------------------------------------------------------------------ Sun, 11 Sep 2005 19:30:35 +0000 : m3avrck Attachment: http://drupal.org/files/issues/drupal_11.patch (2.74 KB) Ok patched attached, which fixes this issue. Also, included a patch for system.module which sets the screen shots to 'TRUE' so image dimensions will also be outputted there as well (which they should be!). ------------------------------------------------------------------------ Sun, 11 Sep 2005 19:33:41 +0000 : m3avrck Attachment: http://drupal.org/files/issues/drupal_12.patch (2.75 KB) Fixed a tab issue. ------------------------------------------------------------------------ Sun, 11 Sep 2005 19:35:46 +0000 : m3avrck Attachment: http://drupal.org/files/issues/drupal_13.patch (2.75 KB) Fixed a spacing issue.

1 0

[drupal-devel] code freeze
by Dries Buytaert 12 Sep '05

12 Sep '05

Just a quick reminder that the Drupal 4.7 code freeze is only 3 days away. -- Dries Buytaert :: http://www.buytaert.net/

1 0

[drupal-devel] [bug] Teaser always truncated at 600 characters
by Goba 12 Sep '05

12 Sep '05

Issue status update for http://drupal.org/node/28211 Post a follow up: http://drupal.org/project/comments/add/28211 Project: Drupal Version: cvs Component: node.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: neale Updated by: Goba Status: patch (code needs review) Excuse me, I have not seen that you actually used strrpos() in your patch. You are right that the previous version might have broken tags, but the intention was to search for typical block tags, which are not supposed to be enclosed in inline tags or anything, since it is not valid markup. Your code might break any tag, block tags and inline tags alike. Goba Previous comments: ------------------------------------------------------------------------ Thu, 04 Aug 2005 19:18:23 +0000 : neale Attachment: http://drupal.org/files/issues/diff_27 (1.16 KB) The truncation code in node_teaser doesn't make any sense to me: <?php foreach ($breakpoints as $point => $charnum) { if ($length = strpos($body, $point, $size)) { return substr($body, 0, $length + $charnum); } } ?> I don't understand: why is the offset given to strpos the maximum teaser size? This would cause teasers to only be nicely split if they are enough longer than the max. teaser size to have one of the special characters. But this guarantees the teaser will either be abruptly truncated, or over the max. teaser size! In fact, this is what I'm seeing on my installation. Attached is a patch that makes it work the way I think it was intended. At least, it makes more sense to me. ------------------------------------------------------------------------ Sun, 21 Aug 2005 19:49:15 +0000 : killes(a)www.drop.org changing version and status. ------------------------------------------------------------------------ Mon, 22 Aug 2005 11:36:11 +0000 : Goba Neale, your code does not reflect the intentions in Drupal. The problem with this patch is that it forces a truncate call on the body, regardless of content, and then reduces the teaser size even more, to the first paragraph, first sentence, etc. Problems with your approach are: * If the first paragraph is too short, it will be the teaser, regardless of the set size. * If there are no paragraph or break tags in the truncated teaser part, the first sentence will be used (regardless of how short is it). * On the other hand, if the first paragraph is too long, and the closing tag is out of the initial truncated part, you will end up with broken HTML. Now all these are not the intention of the teaser generation code. Having the exact set length or shorter is sacrificed for having valid HTML, and complete content. While the current Drupal code might produce too long teasers, your code can easily end up producing too short ones. A teaser for this text with your patch would be: /Neale, your code does not reflect the intentions in Drupal./ ------------------------------------------------------------------------ Mon, 22 Aug 2005 18:06:22 +0000 : neale (Oddly, previewing this gives no trimmed version and no full version. I hope the formatting here looks okay.) Goba, I'm not sure I understand your objections. You say: * "If the first paragraph is too short, it will be the teaser, regardless of the set size. " I presume you mean that an article with two paragraphs (one short, one long) would be split at the end of the first paragraph. Currently, if I write an article with three paragraphs (short, long, long), the teaser will be the first two (short, long) even if the second paragraph runs over the max. teaser size. In fact, unless the entire article is under the max. size, it is *guaranteed* that the teaser will be over the max., since the code only looks for a breakpoint *after* $size. I'm not sure this is in line with what drupal wants, since the help for the max. teaser size states (emphasis mine) it is "The *maximum* number of characters used in the trimmed version of a post." My patch addresses this by looking for a split character in the characters before the max. length. * " If there are no paragraph or break tags in the truncated teaser part, the first sentence will be used (regardless of how short is it). " This is untrue. My patch applies after the code that looks for the break tag, and does not alter the existing logic. Unfortunately, the patch doesn't show the (unmodified) part of the code you mention, so it might be worthwhile to look at the patch alongside the original code to see exactly what it does. * " On the other hand, if the first paragraph is too long, and the closing tag is out of the initial truncated part, you will end up with broken HTML. " This is a different problem already present in the code. My patch doesn't try to address this. (Try it: create a new book page right here, and begin it with an em tag, then paste the same sentence over and over, and close the em tag. The teaser will have an unclosed tag.) I humbly suggest the reviewer look over the patch again. ------------------------------------------------------------------------ Mon, 22 Aug 2005 18:22:02 +0000 : neale It just occurred to me that when you said "break tag" you may have meant the "br" tag and not the "!--break--" thing. In that case, your second point is a little closer to true, but still not quite correct. My patch will use as many sentences as it can before it hits the max. size (note the change from strpos to strrpos). Perhaps the help for the "size" should be changed to read *minimum* size of a teaser, instead of maximum size for a teaser, if the current behavior is what drupal is supposd to do. Currently, the teaser will always be larger than the "maximum size" unless the !--break-- thing is used. You can test this here by creating a new book page with a very short paragraph followed by an incredibly long one, maybe 16000 characters in multiple paragraphs. The incredibly long one is always part of the "trimmed version". If you'd like to see my patch in action, head on over to , where it is currently running.

1 0

[drupal-devel] Re: [contributions:MegaGrunt] /modules/publication publication.module publication.mysql readme.txt
by Sheldon Rampton 12 Sep '05

12 Sep '05

Robert Castelo wrote: > 1) This is a 'component' module. For the sake of avoiding confusion, I should mention that Robert's publication.module is completely different from a module by the same name that we have been developing (and which I have discussed with folks on the Civicspace website during our module's beta development). We recently discovered that Robert's module has the same name as ours when our webmaster attempted to add our module to Drupal contributions and found that Robert's module had already been uploaded. (Unfortunately, she realized this after she had already uploaded our files on top of Robert's.) To avoid any future confusion or naming conflicts, we have decided to rename our project to "epublish.module." We're planning to add it to Drupal contribs as soon as we've finished testing the code of the renamed module (hopefully later this week). -------------------------------- | Sheldon Rampton | Research director, Center for Media & Democracy (www.prwatch.org) --------------------------------

1 0

[drupal-devel] Re: [contributions:MegaGrunt] /modules/publication publication.module publication.mysql readme.txt
by Dries Buytaert 12 Sep '05

12 Sep '05

On 19 Aug 2005, at 02:04, drupal-cvs(a)drupal.org wrote: > User: MegaGrunt Branch: HEAD Date: Fri, 19 Aug 2005 00:04:08 > +0000 > > Added files: > /modules/publication publication.module publication.mysql readme.txt > > Log message: > Handles data, logic, and UI of publication(s). > > Component module which provides service to other modules. - This does mean what? I guess I'll have to read the readme.txt (which should be README.txt really). - I'm afraid the subtle differences in your modules' names are somewhat confusing: + There is already a scheduleR module. How does your schedule module differ? + There is already a subscription module. How does your subscribe module differ? Doesn't JonBob have a subscribe module too? (I want a subscription.module in core (e-mail notifications) but don't want to ship both a subscribe and subscription module. I want a single-file module with or without additional .inc files.) - What other modules are going to re-use the scheduler and subscribe modules? - The e-commerce module groups its modules in modules/ecommerce. In general I like that better, because it makes for one well-defined project. -- Dries Buytaert :: http://www.buytaert.net/

4 3

[drupal-devel] [feature] Authentication hook for local users
by naudefj 12 Sep '05

12 Sep '05

Issue status update for http://drupal.org/node/29147 Post a follow up: http://drupal.org/project/comments/add/29147 Project: Drupal Version: cvs Component: user.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: naudefj Updated by: naudefj Status: patch (code needs work) > Why? Without it, it would be impossible to have a single userid/password for your entire site. It would be silly to ask users to log in to Drupal using their forumid@local. Surely there must be a way to authenticate them without having to type the "@local" part? > So, when drupal.module is enabled, there is a third user login field, "site" or "domain", that would include "local" and any registered associates. Not sure I understand - I'm not using drupal.module, but are trying to implement my own authentication module without the need to hack into user.module (or any other module for that sake). naudefj Previous comments: ------------------------------------------------------------------------ Thu, 18 Aug 2005 20:46:57 +0000 : naudefj Please implement a hook to authenticate local users - similar to what hook_auth does for remote users. Alternatively, extend hook_auth to authenticate both local and remote users. Current behaviour: - If a user logs in with "user@domain", hook_auth gets activated; - If a user logs in with "user", hook_auth is bypassed. More details: http://drupal.org/node/27959 ------------------------------------------------------------------------ Sat, 20 Aug 2005 20:11:29 +0000 : killes(a)www.drop.org use hook_user(login) ------------------------------------------------------------------------ Sat, 20 Aug 2005 20:38:53 +0000 : naudefj I just tried hook_user(login), but it only fires when a valid drupal userid/password is entered. ------------------------------------------------------------------------ Sat, 20 Aug 2005 21:03:38 +0000 : naudefj I found the reason why hook_auth only works for remote users. Look at this code from users.module: // Try each external authentication source in series. Register user if // successful. else if (!$user->uid && $server) { Is this something that should be fixed, or should I just comment out the the "&& $server" part myself? ------------------------------------------------------------------------ Sun, 28 Aug 2005 19:03:24 +0000 : naudefj Attachment: http://drupal.org/files/issues/user_31.patch (1.7 KB) Here is a patch that will allow HOOK_AUTH to work for both local and remote users. If would be great if it can be reviewed and applied to HEAD. ------------------------------------------------------------------------ Sun, 11 Sep 2005 05:32:55 +0000 : moshe weitzman hook_auth deliberately is ineffective for local logins. if you enable it for all logins, you will slow down the experience for many people who guess their passwords wrong on login page. in that case, code would call all remote auth modules an dthey in turn would contact their home base. thats too slow. we want to return a 'sorry try again' message very quickly. what are you trying to accomplish here? ------------------------------------------------------------------------ Sun, 11 Sep 2005 06:59:52 +0000 : naudefj Hi, > hook_auth deliberately is ineffective for local logins. Not true. HOOK_AUTH cannot be used for local logins. Look at this line in user.module: else if (!$user->uid && $server) { > what are you trying to accomplish here? I would like my users to use their existing forum userids and passwords to login to Drupal. However, I quickly discovered that external authentication only works if you append a domain/servername to your userid. For example, if a username like "user*@domain*" is entered, HOOK_AUTH gets activated. Problem is that if a userid like "user" is used, HOOK_AUTH will be bypassed. This fix allows local users (i.e. just "user") to be authenticated against an external source. Any other solutions/ suggestions would be greatly appreciated! Best regards. Frank ------------------------------------------------------------------------ Sun, 11 Sep 2005 14:49:15 +0000 : nedjo "The fix allows local users (i.e. just "user") to be authenticated against an external source. " Why? I assume authentication should be either local or external--not both. Therefore, we need a way to distinguish between the two. Currently, the username@domain convention is used. Removing the @domain part of the DrupalID would remove this disctinction. Is the issue just that this convention is confusing for new users? In this case, I'd suggest pulling the domain part out into a different field. So, when drupal.module is enabled, there is a third user login field, "site" or "domain", that would include "local" and any registered associates.

1 0

[drupal-devel] [bug] taxonomy_save_vocabulary() should check for 'tags' not set
by Cvbge 12 Sep '05

12 Sep '05

Issue status update for http://drupal.org/node/30956 Post a follow up: http://drupal.org/project/comments/add/30956 Project: Drupal Version: cvs Component: taxonomy.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: Cvbge Updated by: Cvbge Status: patch (code needs review) Attachment: http://drupal.org/files/issues/taxonomy_save_vocabulary-tags.diff (1 KB) I've found a problem when using postgresql: when going to admin/forum *for the first time* the module adds a taxonomy term or category "Forum", using taxonomy_save_vocabulary() function [it's done in _forum_get_vid()]. But it does not set "tags" in the array and then in taxonomy_save_vocabulary() you get error in sql: pg_query(): Query failed: ERROR: invalid input syntax for integer: "" query: INSERT INTO vocabulary (name, description, help, multiple, required, hierarchy, relations, tags, weight, module, vid) VALUES ('Forums', '', '', 0, 1, 1, 0, '', 0, 'forum', '1') I've fixed this by changing taxonomy_save_vocabulary so it check if "tags" is set and if not it sets it to default. This function already does similar checks for "nodes" and "weight". Cvbge

2 2

[drupal-devel] [feature] More granular user management permissions
by budda 11 Sep '05

11 Sep '05

Issue status update for http://drupal.org/node/25530 Project: Drupal Version: cvs Component: user.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: budda Updated by: budda Status: patch Attachment: http://drupal.org/files/issues/accesscontrol.patch (3.48 KB) When a user role is granted 'administer users' permission this allows them to not only edit any users profile, but also amend the access control list, even for their own role. This means a moderator could actually increase their own permissions to enable further access to Drupal site settings. To prevent this I have split the user module permissions further to provide a new permission setting for each role - "administer permissions". Enabling this permission for any role will provide the user with access to the "access control" pages and functionality. Patch attached to add additional permission and change menu access checks as needed. budda

9 11