- Development - lists.drupal.org

[drupal-devel] [feature] Menu fast edit node links
by mathias 27 Jan '05

27 Jan '05

Project: Drupal Version: cvs Component: menu system Category: feature requests Priority: minor Assigned to: mathias Reported by: mathias Updated by: mathias Status: patch Attachment: http://drupal.org/files/issues/menu_quick_link_0.patch (4.12 KB) Okay, here's the latest patch, footloose and javascript free. mathias Previous comments: ------------------------------------------------------------------------ July 9, 2004 - 12:15 : mathias Attachment: http://drupal.org/files/issues/menu_fast_edit.patch (1.18 KB) When developers are creating custom menus, the process of adding content becomes twofold: 1. Create content 2. Navigate to administer > menus > add menu item and add the latest node entry This patch adds a link hook to the menu module. Specifically if a node does not have a menu entry the 'add menu item' link appears. If a menu item exists, the 'edit menu item' and 'delete menu item' are displayed thereby speeding up the publishing workflow. Note: This feature is only present when the menu module is enabled. Status: Waiting for JonBobs blessing ... ------------------------------------------------------------------------ July 10, 2004 - 12:21 : JonBob This is interesting. I do have a couple reservations. This adds a bunch of queries to node listing pages, since it has to check for every node whether that node has a menu item set. I also wonder how much time this saves the user in reality. It saves navigating to the menu admin screen, sure, but provides little other help. It seems that if we are to provide a link to the menu item add page, we should at least be pre-filling in the path and title fields for the user. The provided method is little better than having the menu admin page open in another browser tab. Maybe a node link isn't the right interface for this, anyway? Possibly a tab, or a hook_nodeapi('form admin') injection? If done right, this could finally replace that aging "link title" field in page.module nodes. ------------------------------------------------------------------------ January 24, 2005 - 16:23 : mathias Attachment: http://drupal.org/files/issues/menu_quick_link.patch (5.91 KB) This new patch gives users the ability to define menu items on any node creation/editing form. Screenshot here: http://asitis.org/tmp/menu_quick_link_form.png [1] It does this through nodeapi (as suggested by Jonbob), which means that any node has access to these fields unless specified otherwise via the new menu configuration settings. The functionality lives in menu.module, and users with 'administer menus' permission are allowed to edit the menu item fields inside the node form. One more note. I'm also proposing the addition of a misc/drupal.js [2] file to Drupal core (* gasp *). Currently it includes javascript functions to hide regions of a page. When a link is clicked on for a collapsed region, the region unfolds revealing the additional parts of a page. In this case the menu item fields are displayed after clicking the 'Menu item settings' link. I think it helps make best use of screen real estate, but we'll leave that verdict up to the usability experts. Let's remove the js file if it's the only thing stopping this patch from being submitted. I thought it might be worth exploring, especially for form pre and form post regions of the node form. [1] http://asitis.org/tmp/menu_quick_link_form.png [2] http://asitis.org/tmp/drupal.js ------------------------------------------------------------------------ January 24, 2005 - 16:34 : mathias Woops. Setting status to 'patch'. ------------------------------------------------------------------------ January 25, 2005 - 08:17 : Bèr Kessels +1 on the feature, I use menu_otf all the time. -1 for the javascript. Not that i am against it, ion contrary. I think we should not start implementing JS on a per-case basis, but we should introduce a javascript system that can do your accordeon-magick on any element. So it should wait IMO. ------------------------------------------------------------------------ January 25, 2005 - 10:07 : Dries I agree with Ber: +1 for the feature, -1 for the Javascript. This would (or should) be easy to implement/integrate as soon the new node forms are done. Both the new node forms, and this feature are crucial. -- View: http://drupal.org/node/9178 Edit: http://drupal.org/project/comments/add/9178

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 +Assigned to: walkah Reported by: ccourtne Updated by: walkah Status: patch Attachment: http://drupal.org/files/issues/forumadmin5.patch (22.5 KB) here's another slight update: * fixes the updates.inc conflict * some documentation / help cleanup * fixed an inconsistency in 'forum' vs. 'forums' for the vocabulary module * check for an existing forum vocabulary in _forum_get_vid, in case something happens to the variable. 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. ------------------------------------------------------------------------ January 27, 2005 - 14:34 : walkah Attachment: http://drupal.org/files/issues/forumadmin4.patch (22.04 KB) updated patch. now applies to HEAD. -- View: http://drupal.org/node/10425 Edit: http://drupal.org/project/comments/add/10425

1 0

[drupal-devel] [feature] Adjustable username crop
by com2 27 Jan '05

27 Jan '05

Project: Drupal Version: 4.5.2 Component: node system Category: feature requests Priority: normal Assigned to: com2 Reported by: com2 Updated by: com2 Status: patch Attachment: http://drupal.org/files/issues/common_1.diff (544 bytes) I had the numbers wrong. In the original code it was cropped at 15, not at 10 like in my diff. I also changed it a bit to avoid negative argaments. Attached the new diff from version 4.5.2. if ($object->uid && $object->name) { // Shorten the name when it is too long or it will break many tables. if (strlen($object->name) > variable_get('user_name_crop', 15)+5) { $name = truncate_utf8($object->name, variable_get('user_name_crop', 15)) .'...'; } else { $name = $object->name; com2 Previous comments: ------------------------------------------------------------------------ January 27, 2005 - 17:11 : com2 Attachment: http://drupal.org/files/issues/common_0.diff (546 bytes) Some people might not like it when long usernames are cropped in the node haeder. This patch can be applied to includes/common.inc version 4.5.2 and creates a new variable 'user_name_crop' to adjust the crop length. -- View: http://drupal.org/node/16299 Edit: http://drupal.org/project/comments/add/16299

1 0

[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