January 2005 - Development - lists.drupal.org

Re: [drupal-devel] Hook_settings() confusion
by Gabor Hojtsy 27 Jan '05

27 Jan '05

> According to the API (http://drupaldocs.org/api/head/function/hook_settings) > > "This hook provides an administrative interface for controlling various > settings for this module. A menu item for the module under "site > configuration > modules" will appear in the administrative menu when this > hook is implemented." > > However, in my mt-blacklist module I'm working on, I have defined the > function, but there is no link anywhere on the menu for the admin. Nor for > spam.module which also defines it. > > Directly entering the url to the settings page for the module however works > fine. > > Any idea what I've missed? > > (4.5.2 install, CVS Spam) It should be administer >> settings >> modulename, so I fixed the docs too. Goba

2 1

[drupal-devel] [bug] Changing roles for a user requires menu cache invalidate
by Dries 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: Dries Status: patch I think the user module needs more work (last two chunks added by me): diff -r1.434 user.module 199a200,202 > > // Rebuild this user's menu to account for possibly changed permissions. > menu_rebuild($user->uid); 1135,1136d1137 < // Delete that user's menu cache. < cache_clear_all('menu:'. $account->uid); 1442d1442 < cache_clear_all(); Please verify/update as necessary. (I, for one, wouldn't expect menu_rebuild() to flush the page cache.) Dries Previous comments: ------------------------------------------------------------------------ December 31, 2004 - 20: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 - 19: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 - 21:01 : Anonymous Don't we also need some code in user.module to call menu_rebuild? ------------------------------------------------------------------------ January 27, 2005 - 21:05 : JonBob Yes, the patch does that. -- View: http://drupal.org/node/14977 Edit: http://drupal.org/project/comments/add/14977

1 0

[drupal-devel] [feature] A patch to allow users to easily work on unpublished content.
by mcd 27 Jan '05

27 Jan '05

Project: Drupal Version: cvs Component: user system Category: feature requests Priority: normal Assigned to: gordon Reported by: gordon Updated by: mcd Status: patch I'd put the tab under Recent Posts, which already has a similar tab for My Recent Posts. mcd Previous comments: ------------------------------------------------------------------------ September 6, 2004 - 20:12 : gordon Attachment: http://drupal.org/files/issues/user_9.patch (1.84 KB) This is a patch that I have wanted for a while, and esp. with the added menu tabs it has come together very well. What this patch does is add an additional tab to the "my account" page called unpublished. This tab displays exactly like the front page, but only displays unpublished content that belongs to the user. This allows the user to work on content over multiple editing sessions and then be able to come back and easily find the content. that they were working on, and resume editing. I find this useful if your are content is over multiple pages and you want to add the links. One thing that i would like to add is being able to not only seeing your unpublished content but the content of other users that give you permission to review/collaborate on before it is published. Maybe it would be handy to be able to have multiple authors on a single node. ------------------------------------------------------------------------ September 6, 2004 - 20:23 : killes(a)www.drop.org I think that this could well be implemented as a "personal workflow" module. There are endless possibilities with the new access controll lists. ------------------------------------------------------------------------ September 6, 2004 - 20:49 : gordon Yes the possiblities are endless. I would like to see something more, but at this stage I think this would really help alot of people, I know that it has helped for me. ------------------------------------------------------------------------ September 13, 2004 - 05:55 : moshe weitzman seems useful. consider making it a contrib module so folks can easily check it out, and we don't wait for core in order to use it. ------------------------------------------------------------------------ September 14, 2004 - 08:11 : gordon I do feel that this should be something that is in core. In its present form, creating a module for it would be feely easy, but there is not very much functionality in it, so it would be a very small module. But turning it into a module maybe a good idea, if the idea is going to be expanded further, I would maybe like to see colaboration on a document between multiple users before it gets published. maybe something like an invitation system, that then users the node permisions to allow other users to access and edit your document before it is published. ------------------------------------------------------------------------ November 15, 2004 - 11:22 : elias1884 as far as I am concerned, this strongly belongs to core. for me this improvement goes hand in hand with http://drupal.org/node/7939 as it gives the unexperienced user a way to verify if their node really got submitted, since they might get confused by the "access denied" message they retrieve when published is turnd of in default workflow. ------------------------------------------------------------------------ November 15, 2004 - 11:33 : moshe weitzman It seems like this functionality is part of the workspace.module in Contrib. The UI may be different, but the idea persists. Perhaps folks could keep on improving workspace .... ------------------------------------------------------------------------ November 17, 2004 - 22:23 : tostinni A little correction of the patch due to new node_acces function : Replace : by And now unpublished tab will really appear ;) ------------------------------------------------------------------------ November 17, 2004 - 22:40 : gordon Attachment: http://drupal.org/files/issues/user_11.patch (1.84 KB) Here is a fixed version of the patch. ------------------------------------------------------------------------ November 17, 2004 - 22:57 : jvandyk This seems to duplicate the functionality of the workspace module. ------------------------------------------------------------------------ November 18, 2004 - 03:32 : Dries The tabs on the user page represents actions one can perform on a user: one can 'view', 'edit', 'track' or 'contact' a user. Adding a tab called 'unpublished' is a bad idea. ------------------------------------------------------------------------ November 18, 2004 - 06:38 : gordon Attachment: http://drupal.org/files/issues/user_12.patch (1.78 KB) Yes looking at this, I agree with you. The way that this menu has developed it is no longer appropiate to add this tab here. My next option was to put it under the either the view or edit tabs. I am leaning more towards the view than the edit. I think that it is a view function because you are not actually editing anything. Also this is an operation that a user can only use on thier user, so it is a private function. What do you think? I also did a bit more investigation of the patch, and had to make some more changes as the call to the node_access() has changed, and the information that I need is no longer accessible that way. -- View: http://drupal.org/node/10611 Edit: http://drupal.org/project/comments/add/10611

1 0

[drupal-devel] [bug] "my account" menu item oddities
by Dries 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: Dries Status: patch The patch did not apply cleanly against DRUPAL-4-5. I modified the patch and committed it to DRUPAL-4-5 and to HEAD. I'm leaving this issue open for a couple more days. Dries Previous comments: ------------------------------------------------------------------------ November 19, 2004 - 23: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 - 13: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 - 08:05 : jasper anybody? ------------------------------------------------------------------------ January 27, 2005 - 21: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. ------------------------------------------------------------------------ January 27, 2005 - 21:50 : Steven 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. -- View: http://drupal.org/node/13184 Edit: http://drupal.org/project/comments/add/13184

1 0

[drupal-devel] [feature] Adjustable username crop
by Dries 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: Dries Status: patch This should be done in the theme. Dries Previous comments: ------------------------------------------------------------------------ January 27, 2005 - 18: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. ------------------------------------------------------------------------ January 27, 2005 - 22:32 : com2 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; ------------------------------------------------------------------------ January 27, 2005 - 23:00 : Bèr Kessels IMO this should be done in a theme, not with yet another config option. what about theme_username() ? ------------------------------------------------------------------------ January 27, 2005 - 23:07 : killes(a)www.drop.org theme_username++ format_name is one of the functions I always need to modify. theme_date would be nice, too. -- View: http://drupal.org/node/16299 Edit: http://drupal.org/project/comments/add/16299

1 0

[drupal-devel] [feature] Adjustable username crop
by killes 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: killes(a)www.drop.org Status: patch theme_username++ format_name is one of the functions I always need to modify. theme_date would be nice, too. killes(a)www.drop.org 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. ------------------------------------------------------------------------ January 27, 2005 - 21:32 : com2 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; ------------------------------------------------------------------------ January 27, 2005 - 22:00 : Bèr Kessels IMO this should be done in a theme, not with yet another config option. what about theme_username() ? -- View: http://drupal.org/node/16299 Edit: http://drupal.org/project/comments/add/16299

1 0

[drupal-devel] [feature] Adjustable username crop
by Bèr Kessels 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: Bèr Kessels Status: patch IMO this should be done in a theme, not with yet another config option. what about theme_username() ? Bèr Kessels 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. ------------------------------------------------------------------------ January 27, 2005 - 21:32 : com2 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; -- View: http://drupal.org/node/16299 Edit: http://drupal.org/project/comments/add/16299

1 0

[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