January 2005 - Development - lists.drupal.org

[drupal-devel] release info, introspection and debug
by Chris Johnson 27 Jan '05

27 Jan '05

Once upon a time, like around release 4.1 or 4.2, I started coding a module which would enable several debug features, both locally and remotely. One part of that was an XML RPC which could be turned on administratively which would allow a query to return some information about the Drupal installation. The information was intended to be items which would help debugging a problem, providing support or reporting bugs/problems in the software. The module would gather the information and send it as a returned array from the RPC. Unfortunately, I accidentally deleted my work before it got backed up or committed to my local CVS. One of the roadblocks I had at the time was no good way of knowing which versions of the various pieces of the Drupal software were being used. Since then, partly because of my asking for it, all (most?) Drupal files have a $Id$ CVS keyword in them, in a comment line. At a minimum, that would allow an fopen() or similar to be used to find out what versions of files were being used. Not the most beautiful way of handling this issue, but at least workable. Another problem that I was trying to solve then, and that I still run into often now while managing half a dozen or so Drupal-based sites in my so-called spare time is knowing which version of software they are currently running. I can figure this out eventually via one method or another, but it would be so nice to be able to just view it from the admin options. This piece of information would also be useful for the previously mentioned debug/reporting module, too. To that end, is there any chance we could make it convention that all Drupal files would, in addition to the $Id$ keyword, include the $Name$ keyword? And if all that sounds reasonable, I'd like to mention briefly a common coding pattern for handling just this kind of question, and one which I also use in most source files. That is, make these version and release strings available to the program itself without file reading (fopen()) introspection tricks. Extremely common example from C (source code to most Unixes): #if 0 static char sccsid[] = "@(#)w.c 8.4 (Berkeley) 4/16/94"; #endif static const char rcsid[] = "$FreeBSD: src/usr.bin/w/w.c,v 1.38.2.7 2003/08/15 21:58:14 rwatson Exp $"; Similarly, in PHP: $version = "\$Revision: 1.6 $"; $release = "\$Name: build_1_2_19 $"; Any chance of doing something like that with Drupal? If not in all files, maybe just the release in common.inc? -- Chris Johnson

3 5

[drupal-devel] [bug] "my account" menu item oddities
by Steven 27 Jan '05

27 Jan '05

Project: Drupal Version: 4.5.0 Component: menu system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: jasper Updated by: Steven Status: patch Perhaps we could change the path for "my account" to "user/me" or something? Link-wise it's not too hard to implement, just do "user/". ($account->uid == $user->uid ? "me" : $account->uid) or something when linking to that page. Steven Previous comments: ------------------------------------------------------------------------ November 19, 2004 - 22:03 : jasper 1. "my account" link can not be given "weight" 2. If edited, "my account" link behaves strangely: appears as separate menu in admin screen, disappears from navigation menu, etc. 3. Subitems can't be added under my account, or, strange things happen if you try to do that. ------------------------------------------------------------------------ November 25, 2004 - 12:36 : jasper Reproduce the error: 1. Assign sub-menus to "my account" menu item 2. edit "my account" menu item - capitalize "My Account" result: 1. sub-menus disappear from navigation block 2. "My Account" becomes separate Menu at the bottom of the menu administration page. I would really like to capitalize the "my account" link. Any way to do that without bugging out the menus? ------------------------------------------------------------------------ December 18, 2004 - 07:05 : jasper anybody? ------------------------------------------------------------------------ January 27, 2005 - 20:36 : JonBob Attachment: http://drupal.org/files/issues/user_13.patch (705 bytes) The "my account" menu item includes the user ID, so really cannot be customized. This is unfortunate. The attached patch corrects the mentioned bug by locking the menu item as it should be, but doesn't address the usability issue of not being able to customize the menu item. I suggest we move ahead with this patch for the 4.5 branch and, since time is short, likely 4.6. Any suggestions for how to make this item editable? I think we'd need some way to have multiple paths for a single menu item... wildcards or something. But an implementation escapes me. -- View: http://drupal.org/node/13184 Edit: http://drupal.org/project/comments/add/13184

1 0

[drupal-devel] [bug] "my account" menu item oddities
by JonBob 27 Jan '05

27 Jan '05

Project: Drupal Version: 4.5.0 Component: menu system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: jasper Updated by: JonBob -Status: active +Status: patch Attachment: http://drupal.org/files/issues/user_13.patch (705 bytes) The "my account" menu item includes the user ID, so really cannot be customized. This is unfortunate. The attached patch corrects the mentioned bug by locking the menu item as it should be, but doesn't address the usability issue of not being able to customize the menu item. I suggest we move ahead with this patch for the 4.5 branch and, since time is short, likely 4.6. Any suggestions for how to make this item editable? I think we'd need some way to have multiple paths for a single menu item... wildcards or something. But an implementation escapes me. JonBob Previous comments: ------------------------------------------------------------------------ November 19, 2004 - 16:03 : jasper 1. "my account" link can not be given "weight" 2. If edited, "my account" link behaves strangely: appears as separate menu in admin screen, disappears from navigation menu, etc. 3. Subitems can't be added under my account, or, strange things happen if you try to do that. ------------------------------------------------------------------------ November 25, 2004 - 06:36 : jasper Reproduce the error: 1. Assign sub-menus to "my account" menu item 2. edit "my account" menu item - capitalize "My Account" result: 1. sub-menus disappear from navigation block 2. "My Account" becomes separate Menu at the bottom of the menu administration page. I would really like to capitalize the "my account" link. Any way to do that without bugging out the menus? ------------------------------------------------------------------------ December 18, 2004 - 01:05 : jasper anybody? -- View: http://drupal.org/node/13184 Edit: http://drupal.org/project/comments/add/13184

1 0

[drupal-devel] [feature] Forum admin screen updates
by walkah 27 Jan '05

27 Jan '05

Project: Drupal Version: cvs Component: forum.module Category: feature requests Priority: normal Assigned to: ccourtne Reported by: ccourtne Updated by: walkah Status: patch Attachment: http://drupal.org/files/issues/forumadmin4.patch (22.04 KB) updated patch. now applies to HEAD. walkah Previous comments: ------------------------------------------------------------------------ August 29, 2004 - 01:50 : ccourtne Attachment: http://drupal.org/files/issues/forumadmin.patch (18.5 KB) Added admin screens to maintain forums instead of forcing the user to add a taxonomy. In addition the patch hides the forum taxonomy from the categories screen since the forum module does not support all features of taxonomies. The patch still needs clean up work for comments and the delete function needs to remove forum topics when you remove a forum, but I wanted to get it out for review. This patch requires the latest forum speed up patch found here http://drupal.org/node/view/10308. Craig ------------------------------------------------------------------------ September 8, 2004 - 18:25 : ccourtne Attachment: http://drupal.org/files/issues/forumadmin2.patch (22.84 KB) New patch that properly deletes forum topics when the forum is deleted, has all code comments, and updates the help text. ------------------------------------------------------------------------ September 8, 2004 - 18:40 : ccourtne some screen shots of the admin screens http://homepage.mac.com/ccourtne/drupal/forum_add_forum.png http://homepage.mac.com/ccourtne/drupal/forum_add_forum.png http://homepage.mac.com/ccourtne/drupal/forum_add_container.png http://homepage.mac.com/ccourtne/drupal/forum_config.png ------------------------------------------------------------------------ September 8, 2004 - 18:42 : ccourtne One more screenshot. http://homepage.mac.com/ccourtne/drupal/forum_overview.png ------------------------------------------------------------------------ September 8, 2004 - 19:21 : ccourtne updating to patch status ------------------------------------------------------------------------ September 9, 2004 - 00:17 : Dries Looks good! ------------------------------------------------------------------------ September 15, 2004 - 00:08 : ccourtne Attachment: http://drupal.org/files/issues/forumadmin3.patch (22.77 KB) Screenshots have a new home. http://www.dawnsedge.com/ccourtne/drupal/forum_add_forum.png http://www.dawnsedge.com/ccourtne/drupal/forum_overview.png http://www.dawnsedge.com/ccourtne/drupal/forum_add_container.png http://www.dawnsedge.com/ccourtne/drupal/forum_config.png Also updated the patch for current CVS head. ------------------------------------------------------------------------ September 20, 2004 - 09:19 : walkah not only do i think this looks very good, but i also think image.module folks should maybe take notice :) (hint hint). oh, and weren't we gonna split taxonomy.module into taxonomy.inc + taxonomy.module at one point? ------------------------------------------------------------------------ September 21, 2004 - 13:47 : Dries I'm going to commit as soon CVS HEAD is opened up for development. In the mean time, keep refining this patch so other modules can learn from it. ------------------------------------------------------------------------ January 26, 2005 - 20:14 : Boris Mann Is this going to get committed? Talk about it on CS developers list. Also: can this separate multiple forums? Can it be extended to support multiple forums? ------------------------------------------------------------------------ January 27, 2005 - 11:01 : Dries I'm afraid it does no longer apply. It's probably fairly easy to update though. -- View: http://drupal.org/node/10425 Edit: http://drupal.org/project/comments/add/10425

1 0

[drupal-devel] [bug] Changing roles for a user requires menu cache invalidate
by JonBob 27 Jan '05

27 Jan '05

Project: Drupal Version: cvs Component: user.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: moshe weitzman Updated by: JonBob Status: patch Yes, the patch does that. JonBob Previous comments: ------------------------------------------------------------------------ December 31, 2004 - 13:46 : moshe weitzman When you remove a user from a given role, the effect is often not seen for a long time since the user's menu remains in cache. we should invaidate the menu cache for a user whenh is roles change (or anytime the $user is saved?). This same bug is apparent when you grant new roles to a user. ------------------------------------------------------------------------ January 27, 2005 - 12:34 : JonBob Attachment: http://drupal.org/files/issues/menu_18.patch (1.51 KB) Fixed by adding ability to invalidate cache only for one user. ------------------------------------------------------------------------ January 27, 2005 - 14:01 : Anonymous Don't we also need some code in user.module to call menu_rebuild? -- View: http://drupal.org/node/14977 Edit: http://drupal.org/project/comments/add/14977

1 0

[drupal-devel] [bug] Changing roles for a user requires menu cache invalidate
by Anonymous 27 Jan '05

27 Jan '05

Project: Drupal Version: cvs Component: user.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: moshe weitzman Updated by: Anonymous Status: patch Don't we also need some code in user.module to call menu_rebuild? Anonymous Previous comments: ------------------------------------------------------------------------ December 31, 2004 - 18:46 : moshe weitzman When you remove a user from a given role, the effect is often not seen for a long time since the user's menu remains in cache. we should invaidate the menu cache for a user whenh is roles change (or anytime the $user is saved?). This same bug is apparent when you grant new roles to a user. ------------------------------------------------------------------------ January 27, 2005 - 17:34 : JonBob Attachment: http://drupal.org/files/issues/menu_18.patch (1.51 KB) Fixed by adding ability to invalidate cache only for one user. -- View: http://drupal.org/node/14977 Edit: http://drupal.org/project/comments/add/14977

1 0

[drupal-devel] [feature] themeable pager pieces
by Jeremy 27 Jan '05

27 Jan '05

Project: Drupal Version: cvs Component: other Category: feature requests Priority: minor Assigned to: Anonymous Reported by: Jeremy(a)kerneltrap.org Updated by: Jeremy(a)kerneltrap.org Status: patch Attachment: http://drupal.org/files/issues/pager.inc_1.patch (8.65 KB) Is there anything gained from making the pager.inc pager pieces themeable? I'm no longer sure, but the attached patch does so. Jeremy(a)kerneltrap.org -- View: http://drupal.org/node/16273 Edit: http://drupal.org/project/comments/add/16273

4 7

[drupal-devel] [bug] xtemplate mission does not work with an alias
by Anonymous 27 Jan '05

27 Jan '05

Project: Drupal Version: 4.4.1 Component: theme system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: kbahey Updated by: Anonymous -Status: duplicate +Status: patch This was not fixed by the patch to the other issue. What needs to happen here is: variable_get("site_frontpage", "node") needs to become drupal_get_normal_path(variable_get("site_frontpage", "node")) I'm not on a workstation where I can post a real patch at the moment, but this is a very simple change, so I'm changing the status. Anonymous Previous comments: ------------------------------------------------------------------------ May 11, 2004 - 02:18 : kbahey When using xtemplate, and setting "xtemplate_mission" to a value (under "Message on front page" on /admin/system/themes/xtemplate), the mission does not appear if the /admin/system "Default front page" is set to a url alias. So, if the front page should be set to "node/view/8" for example, and there is a url alias for that node (say: "index.html"), then the mission will not show up. The culprit code is in xtemplate.theme [?php // only parse the mission block if we are on the frontpage ... if ($_GET["q"] == variable_get("site_frontpage", "node") && ($mission = variable_get("xtemplate_mission", "edit mission"))) { $xtemplate->template->assign("mission", $mission); $xtemplate->template->parse("header.mission"); } ?] _GET["q"] does not contain the alias ("index.html"), but the original node ("node/view/8") Of course, the workaround is easy (put the node and not the alias as the front page) However, it is best to be consistent across the entire system, and treat the alias exactly as the original node. ------------------------------------------------------------------------ July 27, 2004 - 16:15 : JonBob Folded into http://drupal.org/node/view/9477. -- View: http://drupal.org/node/7685 Edit: http://drupal.org/project/comments/add/7685

1 0

[drupal-devel] [feature] Proposed change to menu.inc that would allow modules to create custom menus
by JonBob 27 Jan '05

27 Jan '05

Project: Drupal Version: cvs Component: menu system Category: feature requests Priority: normal Assigned to: andremolnar Reported by: andremolnar Updated by: JonBob Status: patch I'd prefer a solution that allowed modules to declare such menu items using the menu hook, but haven't been able to come up with such a solution. I'm okay with this approach until such time as someone has a brilliant idea to make the menu hook more powerful. JonBob Previous comments: ------------------------------------------------------------------------ January 6, 2005 - 02:13 : andremolnar Attachment: http://drupal.org/files/issues/menu_inc_2.patch (2.65 KB) See http://drupal.org/node/15153 and http://drupal.org/node/14120 for discussion on this proposed change. Patch is included here for further discussion (with the changes suggested by Dries). A patch is forthcoming for topics discussed in http://drupal.org/node/14120 which would make use of this patch. Status to be changed to patch later if there are no objections following discussion. andre ------------------------------------------------------------------------ January 8, 2005 - 16:16 : andremolnar Patch making use of this is now added to http://drupal.org/node/14120. andre ------------------------------------------------------------------------ January 10, 2005 - 02:29 : andremolnar Just realising that the rules for setting status to patch would allow this to be patch since its technically ready to go. (and it might actually get noticed if its on the dev list and patch queue). andre ------------------------------------------------------------------------ January 11, 2005 - 01:47 : Dries I'm OK with this patch but won't commit it yet until the book module patch is ready. ------------------------------------------------------------------------ January 19, 2005 - 21:07 : andremolnar I've uploaded the latest version of the patch to book. http://drupal.org/node/14120 andre -- View: http://drupal.org/node/15198 Edit: http://drupal.org/project/comments/add/15198

1 0

[drupal-devel] [bug] Changing roles for a user requires menu cache invalidate
by JonBob 27 Jan '05

27 Jan '05

Project: Drupal Version: cvs Component: user.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: moshe weitzman Updated by: JonBob -Status: active +Status: patch Attachment: http://drupal.org/files/issues/menu_18.patch (1.51 KB) Fixed by adding ability to invalidate cache only for one user. JonBob Previous comments: ------------------------------------------------------------------------ December 31, 2004 - 13:46 : moshe weitzman When you remove a user from a given role, the effect is often not seen for a long time since the user's menu remains in cache. we should invaidate the menu cache for a user whenh is roles change (or anytime the $user is saved?). This same bug is apparent when you grant new roles to a user. -- View: http://drupal.org/node/14977 Edit: http://drupal.org/project/comments/add/14977

1 0