August 2005 - Development - lists.drupal.org

[drupal-devel] [feature] List of bloggers
by essig 25 Aug '05

25 Aug '05

Issue status update for http://drupal.org/node/17030 Post a follow up: http://drupal.org/project/comments/add/17030 Project: Drupal Version: cvs Component: blog.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Bèr Kessels Updated by: essig Status: patch (code needs review) I think 'DISTINCT' can be removed from the query in blog_bloggers_list_1.patch [1]. There is already a 'GROUP BY' clause over the same columns. George Essig [1] http://drupal.org/files/issues/blog_bloggers_list_1.patch essig Previous comments: ------------------------------------------------------------------------ Tue, 08 Feb 2005 23:27:27 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/blog_bloggers_list.patch (1.66 KB) Small patch to show a list of bloggers. We all should know that blog.module is not meant for personal blogging, but that set aside, we do not have a way to show all bloggers, on a site as a list. This patch ads a few lines that will allow you to show that overview of blogging users. It ads a menu item, disabled by default that shows such a list. ------------------------------------------------------------------------ Tue, 08 Feb 2005 23:31:49 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/blog_bloggers_list.png (4.02 KB) Here is a small screeny that shows what this is about. ------------------------------------------------------------------------ Tue, 08 Feb 2005 23:34:15 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/list_bloggers_2.png (2.25 KB) hmm. error in my png file. Here is a correct one. ------------------------------------------------------------------------ Sat, 19 Feb 2005 20:13:20 +0000 : Emiliano Hi Bèr Kessels! Thanks for the patch! It's really useful! :-) I just noticed what I think is a little mistake in this line: $items[] = l($row->name, 'blog/'.$row->uid)." ".theme('xml_icon', url('blog/'.$row->uid.'/feed'), TRUE); Which I believe should end like: $items[] = l($row->name, 'blog/'.$row->uid)." ".theme('xml_icon', url*('blog/feed/'.$row->uid)*, TRUE); Ah, and BTW, "db_rewrite_sql" didn't work for me... I just cut it off... ;-) Cheers, Emiliano. ------------------------------------------------------------------------ Thu, 17 Mar 2005 22:17:39 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/blog_bloggers_list_2.patch (1.81 KB) and here is the actual patch. (i think i really need some script that tells me i did not attach a patch ;) ) ------------------------------------------------------------------------ Thu, 17 Mar 2005 22:19:53 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/blog_bloggers_list_2_0.patch (1.71 KB) sigh. something tells me i should stop working.... a silly "F" sneaked into the previous patch. ------------------------------------------------------------------------ Thu, 24 Mar 2005 20:25:01 +0000 : Anonymous I applied the patch, reuploaded the blog.module and then deactivated and reactivated it. I cannot see a difference. How do I access the blog users page? Drupal 4.6rc thanks for the help. ------------------------------------------------------------------------ Thu, 24 Mar 2005 20:53:26 +0000 : Bèr Kessels look in the menu admin. ------------------------------------------------------------------------ Wed, 18 May 2005 13:38:39 +0000 : Bèr Kessels Nearly two months since the patch. If there is no need for this I will mark it won't fix. ------------------------------------------------------------------------ Wed, 18 May 2005 13:52:56 +0000 : tostinni I made a custom block for this, but it still need a little improvment (add "read more" for example). So I don't know if it's usefull but if anyone care : <?php $result = db_query("SELECT u.uid, u.name, COUNT(0) AS num FROM {node} n LEFT JOIN {users} u ON u.uid = n.uid WHERE n.type = 'blog' GROUP BY u.uid, u.name ORDER BY u.name ASC"); while ($blog = db_fetch_object($result)) { $output .= '<li />'.l($blog->name. ' ('.$blog->num.')', 'blog/'.$blog->uid); } return '<ul>'.$output.'</ul>'; ?> ------------------------------------------------------------------------ Wed, 18 May 2005 16:06:36 +0000 : Chris Johnson I think this is a useful feature. I've coded custom blocks in the past to provide it on my sites. ------------------------------------------------------------------------ Sat, 21 May 2005 05:23:11 +0000 : Andrzej7 I was a little afraid (poor PHP) to install the patch (March...), but I have made a block. And it's very nice. One question only. All the bloggers are shown, but the Admin (user No 1) is on the list and he has no blogs. What's that? ------------------------------------------------------------------------ Sun, 22 May 2005 16:24:08 +0000 : Bèr Kessels To avoid confusion: this patch ads no blocks, but shows the list inline: as content! ------------------------------------------------------------------------ Sat, 18 Jun 2005 22:07:42 +0000 : igrcic aaargh.....there is a problem when using PostgreSQL db. After I successfully patch blog.module and enable it in menu, click on it and following sql errors pop up: warning: pg_query(): Query failed: ERROR: function count(integer, character varying) does not exist HINT: No function matches the given name and argument types. You may need to add explicit type casts. in /web/www/htdocs/iaeste3/includes/database.pgsql.inc on line 45. user error: query: SELECT COUNT(DISTINCT u.uid, u.name) FROM users u LEFT JOIN node n ON n.uid = u.uid WHERE n.type = 'blog' AND n.status =1 ORDER BY n.created DESC in /web/www/htdocs/iaeste3/includes/database.pgsql.inc on line 62. warning: pg_query(): Query failed: ERROR: for SELECT DISTINCT, ORDER BY expressions must appear in select list in /web/www/htdocs/iaeste3/includes/database.pgsql.inc on line 45. user error: query: SELECT DISTINCT u.uid, u.name FROM users u LEFT JOIN node n ON n.uid = u.uid WHERE n.type = 'blog' AND n.status = 1 ORDER BY n.created DESC LIMIT 10 OFFSET 0 in /web/www/htdocs/iaeste3/includes/database.pgsql.inc on line 62 For first one its clear, there is no such fucntion in Postgresql, and second one is typical Postgresql/Mysql error, n.created isn't in select syntax. But if we put it in a select distinct syntax , it isn't DISTINCT anymore, so I get lots of lines with user and all of his blogs, with different time of course. So we must modify query a bit: SELECT DISTINCT u.name, u.uid, MAX(n.created) as time FROM users u LEFT JOIN node n ON n.uid = u.uid WHERE n.type = 'blog' AND n.status = 1 GROUP BY u.name,u.uid ORDER BY time DESC It works fine like this :) Didn't look for first one yet... will when I catch some time. Cheers! ------------------------------------------------------------------------ Sat, 18 Jun 2005 22:15:29 +0000 : igrcic Attachment: http://drupal.org/files/issues/blog_bloggers_list_0.patch (1.75 KB) Sorry, here is a patch for a blog_bloggers_list_2_0.patch :) ------------------------------------------------------------------------ Tue, 05 Jul 2005 09:08:19 +0000 : Bèr Kessels That doesz not seem a patch of a patch, but a regular patch. Igrirc, please note that the SQL contains unbracketed tablenames. That is unacceptible. If you don't want to fix it, please report it back here, So I can fix it otherwise :) ------------------------------------------------------------------------ Sun, 21 Aug 2005 19:46:13 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/blog_bloggers_list_1.patch (1.75 KB) Bingo! My own patch, brought to you by patchbingo!

1 0

[drupal-devel] CiviCRM - Updated v1.1 Beta Demo and Downloads Available
by Dave Greenberg 25 Aug '05

25 Aug '05

The CiviCRM team is happy to announce availability of an updated CiviCRM 1.1 Beta. This codebase has now been through our internal QA cycle and subsequent review and testing by our active community members in a variety of servers environments. We encourage interested CivicSpace and Drupal folks to: ** Try out our public demo 'sandbox' at : http://demo.openngo.org/civicrm/drupal-php5/ AND / OR ** Download and install the release, and try it out in your own environment. Grab the tarball file for php4 or php5 depending on which you are running: http://downloads.openngo.org/civicrm/ For those of you who checked out our 1.0 Beta release, you'll find that 1.1 includes lots of exciting new features and improvements, ranging from integrated geo-location and mapping support via the new Google Maps API, to smart groups and the CiviCRM Profile features. Most recently we've added support for the "Public User Pages and Listings" concept (modeled after the corresponding Drupal Profile functionality). Check out the demo site examples to get an idea of the implementation. Profile Configuration: http://demo.openngo.org/civicrm/drupal-php5/civicrm/admin/uf/group/field?re… Sample Listing Page Based on a Profile Value (contacts in California): http://demo.openngo.org/civicrm/drupal-php5/civicrm/profile?reset=1&state_p… Check out our v1.1 wiki page for a full list of new features: http://objectledge.org/confluence/display/CRM/CiviCRM+v1.1 By the way, we now have full support for most flavors of BOTH PHP 4.3 and PHP 5, as well as MySQL 4.0 and 4.1. This beta release still requires manual installation. We have created detailed installation documentation - which has now been test-driven by several members of the community - and should enable moderately technical folks to get through the installation succesfully. http://objectledge.org/confluence/pages/viewpage.action?pageId=3989 If you'd rather wait for an automated installer - the upcoming 0.8.2 CivicSpace installer will install CiviCRM 1.1 and should be available soon. If you have already installed a prior 1.1 snapshot - you will need to rebuild your SQL database tables as there have been some schema changes. Bugs should be entered into our bug-tracking system. You can check if a bug has already been reported here as well: http://objectledge.org/jira/browse/CRM?report=com.atlassian.jira.plugin.sys… We strongly encourage you to register with the bug-tracking system (rather than submitting anonymous bugs) - so we can contact you if needed about your issue. We hope you find the new version to be exciting and useful - and look forward to hearing your feedback. Best Regards, Dave Greenberg for the CiviCRM team

1 0

[drupal-devel] [bug] Title error in content-types settings
by tostinni 25 Aug '05

25 Aug '05

Issue status update for http://drupal.org/node/29593 Post a follow up: http://drupal.org/project/comments/add/29593 Project: Drupal Version: 4.6.0 Component: node.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: tostinni Updated by: tostinni Status: patch (ready to be committed) Attachment: http://drupal.org/files/issues/node_content-types_settings.patch (1001 bytes) There was a refactor of content menu, and now, content-types appears to be under settings menu. So there's a little bug in node_menu that avoid the display of the content-type we are configuring. See patch. tostinni

1 0

[drupal-devel] [feature] Enable customizing of "Title" field on node forms
by mathias 25 Aug '05

25 Aug '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: mathias Status: patch (ready to be committed) 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. mathias 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!

1 0

[drupal-devel] Results of the Drupal 4.7 Porting workshop
by Kieran Lal 24 Aug '05

24 Aug '05

Hello, on Saturday we had a workshop on porting modules to Drupal 4.7. A result of that workshop was identifying the must know issues, and the categorization issues. http://drupal.org/node/22218 We will post a IRC chat link on the above page in the near future. We are currently taking suggests for the next Drupal Porting Workshop. It has been suggest that it be trouble shooting workshop for people who are having problems porting. Cheers, Kieran

11 19

[drupal-devel] [bug] Incorrect access checking for username auto completion
by Morbus Iff 24 Aug '05

24 Aug '05

Issue status update for http://drupal.org/node/24617 Post a follow up: http://drupal.org/project/comments/add/24617 Project: Drupal Version: cvs Component: node.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: drumm Updated by: Morbus Iff Status: patch (code needs review) I'm not entirely sure what Dries is talking about in #5. However, I tend to think that "access user profiles" is the right way to go - I've been testing changing $admin_access to $view_access on NHPR.org, and it seems to work fine. By itself, being able to access those URLs isn't any sort of security concern - the places that depend on it for editing (such as 'administer nodes') is controlled by a much stronger permission. Thox's comment in #7 would be a problem, true, but I'm trying to figure out when someone would have 'administer nodes' permissions without having the ability to view a user profile (if they're able to edit the node of someone else, shouldn't they know as much public information about that user as possible?). Morbus Iff Previous comments: ------------------------------------------------------------------------ Thu, 09 Jun 2005 00:36:55 +0000 : drumm The auto completion for user name on node edit pages checks user_access('administer users') when it should be something more like node_access($node, 'edit'). ------------------------------------------------------------------------ Fri, 10 Jun 2005 15:32:58 +0000 : Thox -1 The current "Authored by" field is only for users "administer nodes" permission. ------------------------------------------------------------------------ Fri, 10 Jun 2005 15:35:53 +0000 : Thox Whoops, administer nodes != administer users. This makes things different. The true permission should be administer nodes... which almost suggests that the autocomplete function should be part of node.module, not user.module. It depends where else the autocomplete is used in the future. ------------------------------------------------------------------------ Fri, 10 Jun 2005 15:57:50 +0000 : killes(a)www.drop.org I think the function should stay in user.module, but node.module should get a menu callback that utilizes it. This is not a problem as user.module is a required module. ------------------------------------------------------------------------ Fri, 10 Jun 2005 19:40:57 +0000 : Thox Attachment: http://drupal.org/files/issues/access.patch (1.55 KB) Attached patch moves the menu entry from user.module into node.module and fixes the permission check. ------------------------------------------------------------------------ Tue, 05 Jul 2005 18:24:15 +0000 : Dries Say we wanted to make the Author-field on "edit comment" pages editable. I think the permissions would clash, and you'd be able to by-pass permissions if you have access to at least one (because they'd all share the same callback). So, I don't think this solution is sufficiently generic and possibly insecure. Not? ------------------------------------------------------------------------ Tue, 05 Jul 2005 18:55:17 +0000 : moshe weitzman I think some are compounding two separate idea. In my mind, the username autocomplete callback needs a very minimal permission like 'view user profile'. And that callback belongs in user.module. The decision about showing the author field and the responsibility for validating its contents belong to node.module and comment.module (in Dries' example). ------------------------------------------------------------------------ Thu, 07 Jul 2005 08:31:08 +0000 : Thox If the menu item stays in user.module and the permission changed to 'access user profiles', then any users that are 'administer nodes' but not 'access user profiles' would get errors trying to use the autocomplete. The following would work, but I'm not sure if it's the right way to go: <?php 'access' => user_access('access user profiles') || user_access('administer nodes') ?> I think the 'access user profiles' permission is best to use, possibly even going far enough to change the autocomplete field to a plain text field if the user doesn't have the permission.

1 0

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

24 Aug '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: nedjo -Status: patch (code needs review) +Status: patch (ready to be committed) 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! nedjo 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?)

1 0

[drupal-devel] [bug] Block regions not initiated for newly enabled theme, so theme unusable
by nedjo 24 Aug '05

24 Aug '05

Issue status update for http://drupal.org/node/29506 Post a follow up: http://drupal.org/project/comments/add/29506 Project: Drupal Version: cvs Component: system.module Category: bug reports Priority: critical Assigned to: nedjo Reported by: nedjo Updated by: nedjo -Status: active +Status: patch (code needs review) Attachment: http://drupal.org/files/issues/theme-region-error-catching.patch (5.73 KB) I'm still not quite sure what the issue is, but clearly better error handling is needed. A particular issue is the scenario where a site admin upgrades a Drupal install without removing non-upgraded themes, or, on a new install, tries to install non-upgraded themes. As things stand, either of these could lead to unusable themes being the default, and all blocks disappearing. The attached (initial, untested) patch adds error handling to both updates.inc and system.module. New for allinstalls: * theme region initiation return FALSE on failure TRUE on success. * on initiation failure, theme is disabled, and, if it was set to default theme, bluemarine is substituted, with message given Updating: * tests if current default theme has been upgraded, and if not sets bluemarine as the default, issuing a notice * tries to initialize blocks for each enabled theme and, on failure, disables the theme. This should help prevent upgrade problems. If anyone has a chance to review and test this, I'd appreciate it, as I don't at present have a test install to upgrade. nedjo Previous comments: ------------------------------------------------------------------------ Wed, 24 Aug 2005 03:10:30 +0000 : nedjo Following the introduction of extentendable regions, see this issue [1], several users have reported problems: "A fresh install of Drupal with bluemarine displays blocks correctly, but when I switch the default theme to pushbutton, all the blocks disappear. They do show up in ?q=admin/block, but just with the yellow helper boxes, no blocks are really displayed.--Goba " "Same problem as Goba. The "region" field in the blocks table is sometimes blank. This makes many themes almost unusable in a Drupal default install. I don't know how the fields are blank, but the following SQL helped me get back to theme development: UPDATE blocks SET region="left" WHERE region=""--Thox " "another confirmation. I found out about the exact same sql query as Thox to fix it:) We came across this in an update. The theme had the regions defined, but since it was a non-default theme the blocks dissapeared. A drupal site, without a navigation block is simply useless.--Ber " The issue suggests a bug in the initiation of theme blocks. When a new theme is enabled, it's supposed to be initiated with blocks based on the default theme's blocks. I'll post a fix ASAP. [1] http://www.drupal.org/node/16216 ------------------------------------------------------------------------ Wed, 24 Aug 2005 04:11:57 +0000 : nedjo I can't reproduce the reported issue with a clean install. Are the themes causing these problems "updated" (are they phptemplate-based or, if not, do they have _regions() functions)? The specific problem seems to be that the region field isn't being set when block regions are initiated. Here's the relevant portion of function system_initialize_theme_blocks(): <?php // If the region isn't supported by the theme, assign the block to the theme's default region. if (!array_key_exists($block['region'], $regions)) { $block['region'] = system_default_region($theme); } ?> This is executed if a newly-enabled theme doesn't have blocks already assigned to it. It gets the default region's settings--except the region. This code portion tests whether the default region's region is available in the newly-enabled theme, and, if not, substitutes the theme's default region. This would all fail if the theme wasn't returning any regions--but any phptemplate theme, or the core ones, should be.... Anyone see what's going wrong?

1 0

[drupal-devel] [task] Fix error reporting for failed mails to users
by nedjo 24 Aug '05

24 Aug '05

Issue status update for http://drupal.org/node/20139 Project: Drupal Version: cvs Component: user.module Category: tasks Priority: normal Assigned to: Anonymous Reported by: nedjo Updated by: nedjo Status: patch Attachment: http://drupal.org/files/issues/user-mail-error-messages.patch (7.2 KB) The user module has error handling for failed emails sent on password changing, but not yet in other cases, so that users may register and get a message that email has been sent when in fact it has not, an issue reported, e.g., here [1]. This patch adds tests for mails sent on user registration, generating appropriate user feedback (e.g., "Unable to send mail", etc.) and logs errors to the watchdog. [1] http://drupal.org/node/20026 nedjo

3 6

[drupal-devel] [bug] Undefined variable in bootstrap.inc
by kumo 24 Aug '05

24 Aug '05

Issue status update for http://drupal.org/node/29555 Post a follow up: http://drupal.org/project/comments/add/29555 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: kumo Updated by: kumo Status: patch (code needs review) Attachment: http://drupal.org/files/issues/bootstrap_undefined_variable_session.patch (529 bytes) Testing the new database error screens I got a 'Undefined variable: _SESSION in .../bootstrap.inc on line 775. Attached patch fixes this by moving the $_SESSION['messages'] declaration to the beginning of the drupal_set_messages() function. kumo

1 0