August 2005 - Development - lists.drupal.org

[drupal-devel] [bug] Blocks showing up when module disabled
by drumm 12 Aug '05

12 Aug '05

Issue status update for http://drupal.org/node/13802 Post a follow up: http://drupal.org/project/comments/add/13802 Project: Drupal Version: cvs Component: module system Category: bug reports Priority: minor Assigned to: drumm Reported by: Jose A Reyero Updated by: drumm Status: patch (code needs review) Here is some hook documentation: <?php /** * This hook is called on every module for when each new module is enabled. The * module will be loaded at this point so the module's own hook will be called * and other modules may use module_invoke() to call functions in the module. * * @param $module * The name of the module which has just been enabled. */ hook_module_enabled($module) { } /** * This hook is called on every module for when each new module is disabled. * The module will still be loaded at this point so the module's own hook will * be called and other modules may use module_invoke() to call functions in the * module. * * @param $module * The name of the module which has just been disabled. T */ hook_module_disabled($module) { } ?> drumm Previous comments: ------------------------------------------------------------------------ Thu, 02 Dec 2004 13:19:31 +0000 : Jose A Reyero This only happens in the module administration page. To reproduce this behaviour: 1. enable a module and one block provided by it - I.e. 'archive' module 2. disable the module The block still shows up in the module administration page I find this more funny than annoying and it happens only in module admin page. Anyway, think it's and undesirable behaviour and should be addressed, maybe at the block management level. ------------------------------------------------------------------------ Thu, 16 Jun 2005 04:37:45 +0000 : deekayen I verified this in HEAD for the archive module. ------------------------------------------------------------------------ Thu, 11 Aug 2005 20:49:44 +0000 : tostinni This still apply to HEAD, the procedure to reproduce the bug is the right one. However, I don't understand exactly why the block keep appears on this page, and not on the others pages. The problem is that looking at the blocks table, "archive" block stay there even if it doesn't appear on other pages (on module page yes it does). When I enter a new page, saying home, archive block isn't there but is still on the db. The cache is flushed, because archive seems not to appear on the entry giving me the menu, but the current page keep the old cache entry (well I guess). Ok so I proposed a radical way to correct this : rehashing blocks after saving the module configuration. So I just add a _block_rehash(); after the menu_rebuild();, it's a little dirty but do the trick. If you have any suggestion about a better way to do this ;) <?php function system_listing_save($edit = array()) { $op = $_POST['op']; $edit = $_POST['edit']; if ($op == t('Save configuration')) { db_query("UPDATE {system} SET status = 0 WHERE type = '%s'", $edit['type']); foreach ($edit['status'] as $name => $status) { // Make certain that the default theme is enabled to avoid user error if (($edit['type'] == 'theme') && ($edit['theme_default'] == $name)) { $status = 1; } db_query("UPDATE {system} SET status = %d, throttle = %d WHERE type = '%s' AND name = '%s'", $status, $edit['throttle'][$name], $edit['type'], $name); } if ($edit['type'] == 'theme') { variable_set('theme_default', $edit['theme_default']); } menu_rebuild(); _block_rehash(); drupal_set_message(t('The configuration options have been saved.')); drupal_goto($_GET['q']); } } ?> ------------------------------------------------------------------------ Thu, 11 Aug 2005 22:17:26 +0000 : drumm I can work on this. ------------------------------------------------------------------------ Fri, 12 Aug 2005 00:20:14 +0000 : drumm Attachment: http://drupal.org/files/issues/system.module_5.diff (3.54 KB) I decided to implement a hook system for this. As a side effect: - system_listing_save() only does database things. The UI things such as drupal_set_message() are now separated into the calling function. - The status message for saving module is now: * The aggregator module has been disabled. * The archive module has been enabled. instead of "The configuration options have been saved." - The theme-specific things in system_listing_save() are not there anymore. - There is also a hook called when modules are enabled. I think I'll go write some documentation for the two new hooks now.

1 0

[drupal-devel] [bug] Users with 'maintain books' or 'edit own book pages' permission cannot delete book pages
by lgarfiel 12 Aug '05

12 Aug '05

Issue status update for http://drupal.org/node/21559 Post a follow up: http://drupal.org/project/comments/add/21559 Project: Drupal Version: cvs Component: book.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: clydefrog Updated by: lgarfiel Status: patch (code needs review) /I think it's clear that "maintain books" implies the ability to edit and delete book pages./ I'm afraid I have to disagree with clydefrog on this one. The words "administer" and "maintain" and "manage" don't give any firm indication of what they mean, in and of themselves. They could vary depending on the context. Some nodes are deleteable in the fist place, some aren't. In that case, "maintain" means two different things, as would anything else you put in there unqualified. This isn't just a problem with the books module, but in general. It is not intuitively obvious what "administer nodes" or "administer X" means. That's a problem, especially when, as I said, it can vary from one node type to another. I see, generally, the following types of operations on nodes: - Create - Change Ownership - View Anyone's - View Own - Edit Anyone's - Edit Own - Delete Anyone's - Delete Own Which of those is covered by "administer" or "maintain"? And what if I want to allow someone to, say, edit their own nodes, but not delete them? Or allow a given class of administrator to edit anyone's nodes but not delete any but their own? I'd actually be much in favor of more fine-grained control over nodes access rights, both for the greater power it offers and for the clearer UI, system-wide. Whether that's best done via a central node API system or via a "recommended permission breakdown" I don't know, and will leave that to those who have spent more time with core than I have. :-) I do believe it's a good idea, however, both for greater flexibility and greater learnability. lgarfiel Previous comments: ------------------------------------------------------------------------ Fri, 29 Apr 2005 04:32:19 +0000 : clydefrog Attachment: http://drupal.org/files/issues/delete_own_book_pages.patch (626 bytes) AFAICT, only 'administer nodes' permission allows deletion of book pages. This patch allows users with 'maintain books' or 'edit own book pages' permission to delete book pages. The logic doesn't check if the node has updates pending. Should it? ------------------------------------------------------------------------ Fri, 29 Apr 2005 14:10:22 +0000 : clydefrog It's a patch, duh. ------------------------------------------------------------------------ Fri, 29 Apr 2005 14:21:27 +0000 : rivena If maintain books is a permission that overlaps other permissions, it should say so. For example, /maintain books (create, edit, and delete all book pages)/. While I agree that someone who has been given maintainer status should be able to delete pages, I wonder if 'delete own pages' should be made into a seperate permission. I could see a situation where I would not want someone to be able to delete their own pages. Do these permissions affect things that are not book pages but have been put into books? Anisa. It's /Golden Week/! ------------------------------------------------------------------------ Sat, 30 Apr 2005 03:43:17 +0000 : clydefrog I think it's clear that "maintain books" implies the ability to edit and delete book pages. No other node module provides a "delete own " permission, so it would be inconsistent for book.module to provide it. Can you provide some examples to justify the inconsistency? These permissions do not affect nodes which aren't book pages but are in a book. Those nodes are controlled by their respective type-specific permissions, but only users with "maintain books" permission can add or remove those nodes from books. I believe this is the correct behavior. ------------------------------------------------------------------------ Sat, 30 Apr 2005 11:03:47 +0000 : rivena Hmm... But, you just said that until this patch, it *didn't* include the delete pages permission. Right? So, now you are changing it's behavior, but leaving the wording the same. How will people know? Or does it not matter, because you presume they didn't really know it didn't include delete in the first place? I don't know that I can defend my idea of having a seperate delete own pages permission against a standard of consistency. If all the other edit own permissions include the delete pages permission, then I have no quibbles. :) Except it would be more userfriendly if I knew what the permissions meant before I granted them to someone, without having to look at the code. But I do realize that is completely out of the scope of the patch. :) Where do all these little changes *go*, anyway? The changelog just says things like... refractored the search module. Anisa. ------------------------------------------------------------------------ Sat, 30 Apr 2005 16:04:14 +0000 : clydefrog I believe that "maintain books" permission implies the ability to delete book pages, so this patch fixes that bug. Other node modules include deletion in the "edit own" permission. For example, page.module: <?php if ($op == 'update' || $op == 'delete') { if (user_access('edit own pages') && ($user->uid == $node->uid)) { return TRUE; } } ?> I agree that it would be better if permissions were clearer about what they implied. There was a discussion started by killes [1] a while ago: "One problem with Drupal is the way it handles user permissions. The permissions are attached to the user object but nobody really knows what they do. To find out what a particular permission allows you to do, you often need to have a look at the code. " I don't know if it ever lead to any code. I think the changelog is meant to list the changes since the previous version without too much technical detail. If you want to see every last change, take a look at the cvs messages [2]. [1] http://lists.drupal.org/archives/drupal-devel/2005-04/msg00704.html [2] http://drupal.org/project/cvs/3060 ------------------------------------------------------------------------ Mon, 23 May 2005 17:33:18 +0000 : rivena I've been looking at the book module permissions recently, and did a bit of testing. I wanted to know what was the minimum permissions needed to create a new book. I assumed based on this discussion, and a similar discussion on the drupal support list that this was 'maintain books' and 'administer nodes'. I ran into a problem, then added 'access nodes' to this. So now my user has no other permissions other than 'maintain books', 'administer nodes' and 'access nodes'. You'd think this is more than sufficient to do something simple like create a new book, but in fact, with just these permissions, you do not have access to create a book page. You can edit other pages, and move them into a new book. Once you have create pages permission, you appear to finally have all the permissions needed, edit own pages is not needed. So, since, the point of this patch was that not having delete permission was odd, might I suggest adding create permission to maintain books? ;p Anisa. ------------------------------------------------------------------------ Mon, 08 Aug 2005 10:37:49 +0000 : Bèr Kessels I would say this is a "by design". Maybe we need to rename the two book permissions into: "create books" and "edit own book pages". None of the other nodes can be deleted by the roles with "edit own Foo" permissions, nor should the books. ------------------------------------------------------------------------ Mon, 08 Aug 2005 16:59:30 +0000 : clydefrog Thanks for your review, Ber. story.module [3] allows users with "edit own stories" permission to delete stories. <?php if ($op == 'update' || $op == 'delete') { if (user_access('edit own stories') && ($user->uid == $node->uid)) { return TRUE; } } ?> Therefore it is not inconsistent for the same behavior to apply to book nodes. If "maintain books" really means "create books", then the name should be changed and existing code in book.module needs to be updated. However, I think "maintain books" should allow more than just that. In my situation, I want to be able to give someone the permissions to create books and to create, edit, and delete all book pages. With my patch, "maintain books" and "create book pages" does that. [3] http://cvs.drupal.org/viewcvs/drupal/drupal/modules/story.module?rev=1.167&… ------------------------------------------------------------------------ Mon, 08 Aug 2005 19:16:35 +0000 : Bèr Kessels What i see from story, that is specific to story.module too. We should really settle for a consistent behaviour for *all* nodes, one that is "enforced" from node.module. These things should really not be decided per node-type and per-module. Thats a recipe for a mess. ------------------------------------------------------------------------ Mon, 08 Aug 2005 19:25:27 +0000 : Eric Scouten I agree that the current system is a mess. I disagree that there should be one consistent policy enforced by node.module. Sites may have quite legitimate reasons to have different policies for different node types. ------------------------------------------------------------------------ Mon, 08 Aug 2005 20:35:59 +0000 : Bèr Kessels What i was aiming at is to let node module take care of the following: * edit $node_type * administer $node_type * delete $node_type (but would that not better be in 'administer';: users who can administer can delete) * create $node_type That way the modules need not cre about this. ut they /can/ take care of it, if they wish, and add more rules and permissions. ------------------------------------------------------------------------ Mon, 08 Aug 2005 20:36:32 +0000 : Bèr Kessels oh, and -forgot- : * view $node_type ------------------------------------------------------------------------ Mon, 08 Aug 2005 20:49:31 +0000 : Eric Scouten Thanks for the clarification, Bèr. I was afraid that you meant that there would be a single policy applied to *all* node types, not a policy *per* node type. Now I think we're in complete agreement on this subject. ------------------------------------------------------------------------ Mon, 08 Aug 2005 20:51:13 +0000 : puregin I think it's important to keep a clean separation between content and structure (e.g., what's inside of the node, versus how the node is associated with other nodes) I think that there will likely be other explicit structures in Drupal over time, so these concerns affect more than just book module. Deleting a node from a book is potentially a problem, since this operation affects the structure of a book. We also need to think about other interactions with structure - for example, what happens if someone unpublished a node in a book? Should all children also be unpublished? Should the node contents be hidden, while children remain available in navigation? ------------------------------------------------------------------------ Mon, 08 Aug 2005 21:08:01 +0000 : Bèr Kessels puregrin. I think you are gettnig OT here, Thought it is a very valid (and problematic) issue, It really belongs in a new thread. ------------------------------------------------------------------------ Mon, 08 Aug 2005 22:57:34 +0000 : puregin What I was saying is that whether a user should be able to delete a node from a structure should really be enforced by the module which is responsible for the structure. For example, imagining a simple linear list structure - let's say for a "wish list" - composed of nodes owned by a bunch of different users. In this example, a user could delete his own node with no problem. For the book module, a users node may have children authored by other users. Letting an arbitrary user delete his own node would be, I think, a mistake, since the children would then be orphaned. I suppose one could imagine other modules which rely on a hierarchy, which might have a different policy (e.g., automatically attach children to the parent of the deleted node, if such a node exists). Perhaps eventually two 'tree-based' structure modules might inherit from a tree structure module, each enforcing separate policies regarding node operations. The point is, that one should not have to modify node module when a new structure is defined. Node module should not have to know about how composites of nodes work. ------------------------------------------------------------------------ Tue, 09 Aug 2005 00:45:07 +0000 : Boris Mann puregin: I was talking about this today, so I created a task [4] to remind us to build a generalized node relationship module/schema. [4] http://drupal.org/node/28480

1 0

[drupal-devel] [bug] Blocks showing up when module disabled
by drumm 12 Aug '05

12 Aug '05

Issue status update for http://drupal.org/node/13802 Post a follow up: http://drupal.org/project/comments/add/13802 Project: Drupal Version: cvs Component: module system Category: bug reports Priority: minor Assigned to: drumm Reported by: Jose A Reyero Updated by: drumm -Status: patch (code needs work) +Status: patch (code needs review) Attachment: http://drupal.org/files/issues/system.module_5.diff (3.54 KB) I decided to implement a hook system for this. As a side effect: - system_listing_save() only does database things. The UI things such as drupal_set_message() are now separated into the calling function. - The status message for saving module is now: * The aggregator module has been disabled. * The archive module has been enabled. instead of "The configuration options have been saved." - The theme-specific things in system_listing_save() are not there anymore. - There is also a hook called when modules are enabled. I think I'll go write some documentation for the two new hooks now. drumm Previous comments: ------------------------------------------------------------------------ Thu, 02 Dec 2004 13:19:31 +0000 : Jose A Reyero This only happens in the module administration page. To reproduce this behaviour: 1. enable a module and one block provided by it - I.e. 'archive' module 2. disable the module The block still shows up in the module administration page I find this more funny than annoying and it happens only in module admin page. Anyway, think it's and undesirable behaviour and should be addressed, maybe at the block management level. ------------------------------------------------------------------------ Thu, 16 Jun 2005 04:37:45 +0000 : deekayen I verified this in HEAD for the archive module. ------------------------------------------------------------------------ Thu, 11 Aug 2005 20:49:44 +0000 : tostinni This still apply to HEAD, the procedure to reproduce the bug is the right one. However, I don't understand exactly why the block keep appears on this page, and not on the others pages. The problem is that looking at the blocks table, "archive" block stay there even if it doesn't appear on other pages (on module page yes it does). When I enter a new page, saying home, archive block isn't there but is still on the db. The cache is flushed, because archive seems not to appear on the entry giving me the menu, but the current page keep the old cache entry (well I guess). Ok so I proposed a radical way to correct this : rehashing blocks after saving the module configuration. So I just add a _block_rehash(); after the menu_rebuild();, it's a little dirty but do the trick. If you have any suggestion about a better way to do this ;) <?php function system_listing_save($edit = array()) { $op = $_POST['op']; $edit = $_POST['edit']; if ($op == t('Save configuration')) { db_query("UPDATE {system} SET status = 0 WHERE type = '%s'", $edit['type']); foreach ($edit['status'] as $name => $status) { // Make certain that the default theme is enabled to avoid user error if (($edit['type'] == 'theme') && ($edit['theme_default'] == $name)) { $status = 1; } db_query("UPDATE {system} SET status = %d, throttle = %d WHERE type = '%s' AND name = '%s'", $status, $edit['throttle'][$name], $edit['type'], $name); } if ($edit['type'] == 'theme') { variable_set('theme_default', $edit['theme_default']); } menu_rebuild(); _block_rehash(); drupal_set_message(t('The configuration options have been saved.')); drupal_goto($_GET['q']); } } ?> ------------------------------------------------------------------------ Thu, 11 Aug 2005 22:17:26 +0000 : drumm I can work on this.

1 0

[drupal-devel] [bug] Author information block seems to be broken
by tostinni 12 Aug '05

12 Aug '05

Issue status update for http://drupal.org/node/27948 Post a follow up: http://drupal.org/project/comments/add/27948 Project: Drupal Version: cvs Component: profile.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: robertDouglass Updated by: tostinni -Status: active +Status: patch (code needs review) Attachment: http://drupal.org/files/issues/profile.module_2.patch (1.09 KB) This little patch does the trick. The bug came from the fact that the query retrieving user profiles, didn't take all public fields. tostinni Previous comments: ------------------------------------------------------------------------ Mon, 01 Aug 2005 12:27:39 +0000 : robertDouglass This needs confirmation but I am unable to get fields to be shown in the author information block. The 'Link to full user profile' will work, but when I deselect 'Link to full user profile' from admin/block/configure/profile/0 and select the other fields instead, the block fails to materialize.

1 0

[drupal-devel] [bug] settings for multiple sites with port
by pbcomm 12 Aug '05

12 Aug '05

Issue status update for http://drupal.org/node/28719 Post a follow up: http://drupal.org/project/comments/add/28719 Project: Drupal Version: 4.6.0 Component: base system Category: bug reports Priority: normal Assigned to: pbcomm Reported by: pbcomm Updated by: pbcomm Status: patch (ready to be committed) I have 2 sites running on port 85 (I can not have them on port 80 because of the provider) and can not create settings directory for any of them, ":" is not a valid char for directory name (Windows Host). Example: http://name.domain.com:81/site/ My suggestion is to change the following line: $server = explode('.', rtrim($_SERVER['HTTP_HOST'], '.')); to: $tmp = parse_url(rtrim($_SERVER['HTTP_HOST'], '.')); $server = explode('.', $tmp['host']); pbcomm

1 0

[drupal-devel] [bug] Blocks showing up when module disabled
by drumm 12 Aug '05

12 Aug '05

Issue status update for http://drupal.org/node/13802 Post a follow up: http://drupal.org/project/comments/add/13802 Project: Drupal Version: cvs Component: module system Category: bug reports Priority: minor -Assigned to: Anonymous +Assigned to: drumm Reported by: Jose A Reyero Updated by: drumm Status: patch (code needs work) I can work on this. drumm Previous comments: ------------------------------------------------------------------------ Thu, 02 Dec 2004 13:19:31 +0000 : Jose A Reyero This only happens in the module administration page. To reproduce this behaviour: 1. enable a module and one block provided by it - I.e. 'archive' module 2. disable the module The block still shows up in the module administration page I find this more funny than annoying and it happens only in module admin page. Anyway, think it's and undesirable behaviour and should be addressed, maybe at the block management level. ------------------------------------------------------------------------ Thu, 16 Jun 2005 04:37:45 +0000 : deekayen I verified this in HEAD for the archive module. ------------------------------------------------------------------------ Thu, 11 Aug 2005 20:49:44 +0000 : tostinni This still apply to HEAD, the procedure to reproduce the bug is the right one. However, I don't understand exactly why the block keep appears on this page, and not on the others pages. The problem is that looking at the blocks table, "archive" block stay there even if it doesn't appear on other pages (on module page yes it does). When I enter a new page, saying home, archive block isn't there but is still on the db. The cache is flushed, because archive seems not to appear on the entry giving me the menu, but the current page keep the old cache entry (well I guess). Ok so I proposed a radical way to correct this : rehashing blocks after saving the module configuration. So I just add a _block_rehash(); after the menu_rebuild();, it's a little dirty but do the trick. If you have any suggestion about a better way to do this ;) <?php function system_listing_save($edit = array()) { $op = $_POST['op']; $edit = $_POST['edit']; if ($op == t('Save configuration')) { db_query("UPDATE {system} SET status = 0 WHERE type = '%s'", $edit['type']); foreach ($edit['status'] as $name => $status) { // Make certain that the default theme is enabled to avoid user error if (($edit['type'] == 'theme') && ($edit['theme_default'] == $name)) { $status = 1; } db_query("UPDATE {system} SET status = %d, throttle = %d WHERE type = '%s' AND name = '%s'", $status, $edit['throttle'][$name], $edit['type'], $name); } if ($edit['type'] == 'theme') { variable_set('theme_default', $edit['theme_default']); } menu_rebuild(); _block_rehash(); drupal_set_message(t('The configuration options have been saved.')); drupal_goto($_GET['q']); } } ?>

1 0

[drupal-devel] [bug] Blocks showing up when module disabled
by tostinni 11 Aug '05

11 Aug '05

Issue status update for http://drupal.org/node/13802 Post a follow up: http://drupal.org/project/comments/add/13802 Project: Drupal Version: cvs Component: module system Category: bug reports Priority: minor Assigned to: Anonymous Reported by: Jose A Reyero Updated by: tostinni -Status: active +Status: patch (code needs work) This still apply to HEAD, the procedure to reproduce the bug is the right one. However, I don't understand exactly why the block keep appears on this page, and not on the others pages. The problem is that looking at the blocks table, "archive" block stay there even if it doesn't appear on other pages (on module page yes it does). When I enter a new page, saying home, archive block isn't there but is still on the db. The cache is flushed, because archive seems not to appear on the entry giving me the menu, but the current page keep the old cache entry (well I guess). Ok so I proposed a radical way to correct this : rehashing blocks after saving the module configuration. So I just add a _block_rehash(); after the menu_rebuild();, it's a little dirty but do the trick. If you have any suggestion about a better way to do this ;) <?php function system_listing_save($edit = array()) { $op = $_POST['op']; $edit = $_POST['edit']; if ($op == t('Save configuration')) { db_query("UPDATE {system} SET status = 0 WHERE type = '%s'", $edit['type']); foreach ($edit['status'] as $name => $status) { // Make certain that the default theme is enabled to avoid user error if (($edit['type'] == 'theme') && ($edit['theme_default'] == $name)) { $status = 1; } db_query("UPDATE {system} SET status = %d, throttle = %d WHERE type = '%s' AND name = '%s'", $status, $edit['throttle'][$name], $edit['type'], $name); } if ($edit['type'] == 'theme') { variable_set('theme_default', $edit['theme_default']); } menu_rebuild(); _block_rehash(); drupal_set_message(t('The configuration options have been saved.')); drupal_goto($_GET['q']); } } ?> tostinni Previous comments: ------------------------------------------------------------------------ Thu, 02 Dec 2004 13:19:31 +0000 : Jose A Reyero This only happens in the module administration page. To reproduce this behaviour: 1. enable a module and one block provided by it - I.e. 'archive' module 2. disable the module The block still shows up in the module administration page I find this more funny than annoying and it happens only in module admin page. Anyway, think it's and undesirable behaviour and should be addressed, maybe at the block management level. ------------------------------------------------------------------------ Thu, 16 Jun 2005 04:37:45 +0000 : deekayen I verified this in HEAD for the archive module.

1 0

[drupal-devel] [bug] drupal base and E_NOTICE
by Thomas Ilsche 11 Aug '05

11 Aug '05

Issue status update for http://drupal.org/node/28540 Post a follow up: http://drupal.org/project/comments/add/28540 Project: Drupal Version: 4.6.0 Component: base system Category: bug reports Priority: minor Assigned to: Anonymous Reported by: hlslaughter Updated by: Thomas Ilsche Status: patch (code needs review) About the newlines at eof: Sorry didn't notcied this as phped removed them manually, is there any reason for them, I got them in many drupal files? Maybe worth a fix aswell? Thomas Ilsche Previous comments: ------------------------------------------------------------------------ Tue, 09 Aug 2005 19:19:33 +0000 : hlslaughter ok, instead of whining in the forums, i'll submit a ticket. i'm sure i'm not the first person to bring this up, and i apologize in advance if this issue is already decided/closed. but my issue is this: would it be possible to review the core modules and clean up code to the point that it would be feasible to run drupal with notices turned on (at least in a dev environment)? i think it would be pretty trivial to clean most/all of these errors from the code base. the cost of this effort would be relatively teeny, and the benefits would be great. admins would no longer panic if they happen to see these messages; with an option added to the settings screen, developers could turn on notices and would write cleaner code, which would probably result in fewer bugs in 3rd party modules; etc... you know the routine 8*) after turning on E_NOTICE in common.inc, i see the following notice messages when accessing the homepage of my site: occurences - message ----V--------------V-------- 12 notice: Undefined index: field in /var/www/html/includes/tablesort.inc on line 114. 10 notice: Undefined variable: teaser in /var/www/html/modules/opt/attachment.module on line 37. 6 notice: Undefined variable: count in /var/www/html/modules/opt/attachment.module on line 120. 6 notice: Undefined index: field in /var/www/html/includes/tablesort.inc on line 176. 4 notice: Undefined variable: rows in /var/www/html/modules/opt/attachment.module on line 352. 4 notice: Undefined variable: count in /var/www/html/modules/opt/attachment.module on line 123. 4 notice: Undefined variable: attachments in /var/www/html/modules/opt/attachment.module on line 279. 1 notice: Undefined variable: node in /var/www/html/modules/node.module on line 1950. 1 notice: Undefined offset: 0 in /var/www/html/includes/pager.inc on line 59. 1 notice: Undefined index: op in /var/www/html/modules/node.module on line 1636. 1 notice: Undefined index: node.taxonomy in /var/www/html/themes/engines/xtemplate/xtemplate.inc on line 164. 1 notice: Undefined index: node.picture in /var/www/html/themes/engines/xtemplate/xtemplate.inc on line 164. 1 notice: Undefined index: header.title in /var/www/html/themes/engines/xtemplate/xtemplate.inc on line 164. 1 notice: Undefined index: header.site_slogan in /var/www/html/themes/engines/xtemplate/xtemplate.inc on line 164. 1 notice: Undefined index: header.mission in /var/www/html/themes/engines/xtemplate/xtemplate.inc on line 164. 1 notice: Undefined index: header.help in /var/www/html/themes/engines/xtemplate/xtemplate.inc on line 164. 1 notice: Undefined index: from in /var/www/html/includes/pager.inc on line 53. 1 notice: Undefined index: footer.message in /var/www/html/themes/engines/xtemplate/xtemplate.inc on line 164. 1 notice: Undefined index: footer.blocks in /var/www/html/themes/engines/xtemplate/xtemplate.inc on line 164. 1 notice: Undefined index: edit in /var/www/html/modules/node.module on line 1637. 1 notice: Undefined index: 2 in /var/www/html/modules/filter.module on line 629. 1 notice: Undefined index: in /var/www/html/includes/common.inc on line 506. 1 notice: Trying to get property of non-object in /var/www/html/modules/node.module on line 1950. again, no offense, and sorry if i'm trying to bring a dead horse back to life. ------------------------------------------------------------------------ Tue, 09 Aug 2005 19:22:44 +0000 : killes(a)www.drop.org This is being worked on for the next Drupal version. Please install yourself a test site on cvs and submit individual patches. ------------------------------------------------------------------------ Tue, 09 Aug 2005 19:32:57 +0000 : hlslaughter thanks, i'll do this. i take it patches are just posted here? do i just post a diff -N, title it patch and mark the component appropriately? ------------------------------------------------------------------------ Tue, 09 Aug 2005 19:39:08 +0000 : killes(a)www.drop.org Yes, attach here or create new issue. diff -up is what we usually use. Thanks. ------------------------------------------------------------------------ Tue, 09 Aug 2005 20:24:16 +0000 : hlslaughter Attachment: http://drupal.org/files/issues/test.patch (25.21 KB) attached is results of: harry@penny:~/cvs/third_party/drupal/drupal> diff -Naurp . /var/www/html/drupal_cvs/ > ../test.patch ok, would this type of patch be suitable? it includes fixes for all the E_NOTICE messages generated when accessing the homepage of a new, unmodified drupal installation straight from CVS (as of Aug 9 13:14) ------------------------------------------------------------------------ Tue, 09 Aug 2005 21:01:37 +0000 : killes(a)www.drop.org You are almost there. How to best prepare patches is to run Drupal directly from a cvs checkout. then you can fix the checkout and then run cvs diff -up This way the unrelated files in the patch won't be included. ------------------------------------------------------------------------ Thu, 11 Aug 2005 16:29:12 +0000 : Thomas Ilsche Attachment: http://drupal.org/files/issues/node.user.e_notice.path.txt (1.79 KB) I have a small patch for node.module and user.module that fixes 3 notices in the current HEAD. Please especially have a look at node_access_view_all_nodes, I simply do not get the current use of $node->nid (do I need some more sleep or is this really bogus?)

1 0

[drupal-devel] [bug] drupal base and E_NOTICE
by Thomas Ilsche 11 Aug '05

11 Aug '05

Issue status update for http://drupal.org/node/28540 Post a follow up: http://drupal.org/project/comments/add/28540 Project: Drupal Version: 4.6.0 Component: base system Category: bug reports Priority: minor Assigned to: Anonymous Reported by: hlslaughter Updated by: Thomas Ilsche -Status: patch (code needs work) +Status: patch (code needs review) Attachment: http://drupal.org/files/issues/node.user.e_notice.path.txt (1.79 KB) I have a small patch for node.module and user.module that fixes 3 notices in the current HEAD. Please especially have a look at node_access_view_all_nodes, I simply do not get the current use of $node->nid (do I need some more sleep or is this really bogus?) Thomas Ilsche Previous comments: ------------------------------------------------------------------------ Tue, 09 Aug 2005 19:19:33 +0000 : hlslaughter ok, instead of whining in the forums, i'll submit a ticket. i'm sure i'm not the first person to bring this up, and i apologize in advance if this issue is already decided/closed. but my issue is this: would it be possible to review the core modules and clean up code to the point that it would be feasible to run drupal with notices turned on (at least in a dev environment)? i think it would be pretty trivial to clean most/all of these errors from the code base. the cost of this effort would be relatively teeny, and the benefits would be great. admins would no longer panic if they happen to see these messages; with an option added to the settings screen, developers could turn on notices and would write cleaner code, which would probably result in fewer bugs in 3rd party modules; etc... you know the routine 8*) after turning on E_NOTICE in common.inc, i see the following notice messages when accessing the homepage of my site: occurences - message ----V--------------V-------- 12 notice: Undefined index: field in /var/www/html/includes/tablesort.inc on line 114. 10 notice: Undefined variable: teaser in /var/www/html/modules/opt/attachment.module on line 37. 6 notice: Undefined variable: count in /var/www/html/modules/opt/attachment.module on line 120. 6 notice: Undefined index: field in /var/www/html/includes/tablesort.inc on line 176. 4 notice: Undefined variable: rows in /var/www/html/modules/opt/attachment.module on line 352. 4 notice: Undefined variable: count in /var/www/html/modules/opt/attachment.module on line 123. 4 notice: Undefined variable: attachments in /var/www/html/modules/opt/attachment.module on line 279. 1 notice: Undefined variable: node in /var/www/html/modules/node.module on line 1950. 1 notice: Undefined offset: 0 in /var/www/html/includes/pager.inc on line 59. 1 notice: Undefined index: op in /var/www/html/modules/node.module on line 1636. 1 notice: Undefined index: node.taxonomy in /var/www/html/themes/engines/xtemplate/xtemplate.inc on line 164. 1 notice: Undefined index: node.picture in /var/www/html/themes/engines/xtemplate/xtemplate.inc on line 164. 1 notice: Undefined index: header.title in /var/www/html/themes/engines/xtemplate/xtemplate.inc on line 164. 1 notice: Undefined index: header.site_slogan in /var/www/html/themes/engines/xtemplate/xtemplate.inc on line 164. 1 notice: Undefined index: header.mission in /var/www/html/themes/engines/xtemplate/xtemplate.inc on line 164. 1 notice: Undefined index: header.help in /var/www/html/themes/engines/xtemplate/xtemplate.inc on line 164. 1 notice: Undefined index: from in /var/www/html/includes/pager.inc on line 53. 1 notice: Undefined index: footer.message in /var/www/html/themes/engines/xtemplate/xtemplate.inc on line 164. 1 notice: Undefined index: footer.blocks in /var/www/html/themes/engines/xtemplate/xtemplate.inc on line 164. 1 notice: Undefined index: edit in /var/www/html/modules/node.module on line 1637. 1 notice: Undefined index: 2 in /var/www/html/modules/filter.module on line 629. 1 notice: Undefined index: in /var/www/html/includes/common.inc on line 506. 1 notice: Trying to get property of non-object in /var/www/html/modules/node.module on line 1950. again, no offense, and sorry if i'm trying to bring a dead horse back to life. ------------------------------------------------------------------------ Tue, 09 Aug 2005 19:22:44 +0000 : killes(a)www.drop.org This is being worked on for the next Drupal version. Please install yourself a test site on cvs and submit individual patches. ------------------------------------------------------------------------ Tue, 09 Aug 2005 19:32:57 +0000 : hlslaughter thanks, i'll do this. i take it patches are just posted here? do i just post a diff -N, title it patch and mark the component appropriately? ------------------------------------------------------------------------ Tue, 09 Aug 2005 19:39:08 +0000 : killes(a)www.drop.org Yes, attach here or create new issue. diff -up is what we usually use. Thanks. ------------------------------------------------------------------------ Tue, 09 Aug 2005 20:24:16 +0000 : hlslaughter Attachment: http://drupal.org/files/issues/test.patch (25.21 KB) attached is results of: harry@penny:~/cvs/third_party/drupal/drupal> diff -Naurp . /var/www/html/drupal_cvs/ > ../test.patch ok, would this type of patch be suitable? it includes fixes for all the E_NOTICE messages generated when accessing the homepage of a new, unmodified drupal installation straight from CVS (as of Aug 9 13:14) ------------------------------------------------------------------------ Tue, 09 Aug 2005 21:01:37 +0000 : killes(a)www.drop.org You are almost there. How to best prepare patches is to run Drupal directly from a cvs checkout. then you can fix the checkout and then run cvs diff -up This way the unrelated files in the patch won't be included.

1 0

Re: [drupal-devel] More profiling code - the server this time
by Mike Gifford 11 Aug '05

11 Aug '05

Hi John, John VanDyk <jvandyk(a)iastate.edu> wrote: > Mike, I am very interested in having a benchmarking suite for Drupal. > I'd like to get metrics to see how various code changes affect > performance characteristics. Like the idea of a benchmarking suite. The code I posted would only look at benchmarking the servers though. The server code could sit nicely as a stand alone module I think. However, the module memory profiling code I sent to the list earlier would certainly be part of the benchmarking module I would think. You'd also want to have ways to patch in the profiling code into key places in the core code... Again you'd want to extend that to look at timing issues, so the script timing class I suggested might also come in handy (unless there is a standard drupal way to measure execution time). Mike -- Mike Gifford, OpenConcept Consulting Free Software for Social Change -> http://www.openconcept.ca Latest launch Canadian Labour Congress / Congrès du travail du Canada http://canadianlabour.ca / http://congresdutravail.ca

1 0