- Development - lists.drupal.org

RE: [drupal-devel] Module Review: spam_mtblacklist
by Gerhard Killesreiter 27 Jan '05

27 Jan '05

On Thu, 27 Jan 2005, Michael Jervis wrote: > ---- > Since the module is apparently only usefull together with the spam module it > would be nice if it could either be integrated or at least distributed with > Jeremy's spam module. This way we would avoid the "yet another module" > thing. > ---- > > Jeremy agreed it should be done as a separate module: > > >> I've been thinking, I intend to implement this as a new module that > >> requires the spam module and works with it to keep the code modular > >> and separate. I think this is the right way to go as it allows the > >> functionality to be totally removed if people don't want it. > > > >I agree it should be a seperate module. > > Sadly drupal's contrib system doesn't allow to distribute them together. (I > don't think) You could always put it into a subdirectory of the spam module (if Jeremy agrees). See the ecommerce module. Cheers, Gerhard

1 0

[drupal-devel] [feature] Add configuration option to show blocks only on pages of certain node type
by andremolnar 27 Jan '05

27 Jan '05

Project: Drupal Version: cvs Component: block.module Category: feature requests Priority: normal Assigned to: andremolnar Reported by: andremolnar Updated by: andremolnar Status: patch Attachment: http://drupal.org/files/issues/block_module_1.patch (8.14 KB) This patch would allow adminstrators to configure blocks to show up only pages of a specified node type. This patch is being submitted in response to feedback on the proposed changes to the book module http://drupal.org/node/14120. Feedback indicated that if the block generation associated with books is changed, administrators will still require the ability to specify that newly created book blocks behave as the existing book blocks do (i.e. only show up on book pages). This patch goes one step further and would allow an admin to show a book block (or any block) on any type of page. While independent of 14120 - this patch in conjuntion with 14120 would allow the removal of a large piece of block generation code from the book module. Comments and feedback, as always, are welcome. andre andremolnar -- View: http://drupal.org/node/16074 Edit: http://drupal.org/project/comments/add/16074

7 26

[drupal-devel] Module Review: spam_mtblacklist
by Michael Jervis 27 Jan '05

27 Jan '05

Contributions/modules/spam_mtblacklist Adds to the spam module, one new field in spam_custom, provides import and updates of spam blacklists from the MT Blacklist project. First time I've done any DB/Cron/Settings etc, in fact all I've done before is two tiny auth modules, so please, have a good look. Cheers, Mike

1 0

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