- Development - lists.drupal.org

[drupal-devel] [feature] Single step account creation and login
by robertDouglass 19 Sep '05

19 Sep '05

Issue status update for http://drupal.org/node/4942 Post a follow up: http://drupal.org/project/comments/add/4942 Project: Drupal Version: cvs Component: user.module Category: feature requests Priority: normal Assigned to: amanuel Reported by: mathias Updated by: robertDouglass Status: patch (code needs review) I'd just like to mention that I recently needed a slightly different modification to the user creation workflow. The site was of the nature where all of the content was behind a splash screen that required registration before the visitors could get to it. My client needed his users to be taken to the content area immediately upon filling out the registration form and not have to wait for the mail and use their password etc to log in. I bring this up because there are probably 3-4 more workflows for account creation that we could support, if we wanted to, the current password creation issue being one of them. I would be supportive of adding more configuration options because I see that many sites have different needs. Options to add would include: 1) Should the user receive a generated password or should they get to choose their own? 2) If the user gets a generated password, it will be mailed; should they have to wait to log on, or should registering intitiate their session? 3) If the user chooses his or her own password, there is no way to confirm that they own the email address they entered. Should they be sent a 1-time URL confirmation mail and be required to click the link in order to confirm their mail? I would be very supportive of letting users create their own password if they were sent a 1-time URL to confirm their mail. How much interest is there for adding all of these options? -Robert robertDouglass Previous comments: ------------------------------------------------------------------------ Sat, 03 Jan 2004 23:49:54 +0000 : mathias Under special circumstances, i would like a new user to be able to choose their own password and be automatically logged into the site without needing to check their email. I feel this is necessary for my ecommerce module, where after anonymous users are ready to "Proceed to checkout", they need to create an user account to continue. It is tedious for the customer if they have to stop, check their email, log into the site and then resume the checkout process. I'm game to code this (if this has potential to be part of the core), i just need some feedback on the best way to tweak user_register. ------------------------------------------------------------------------ Sun, 04 Jan 2004 06:18:07 +0000 : moshe weitzman +1 for this. I don't think you will get much objection to this much needed usability enhancement. ------------------------------------------------------------------------ Thu, 08 Jan 2004 05:48:40 +0000 : mathias Attachment: http://drupal.org/files/issues/user.module-quick_acount.patch (7.11 KB) This is a prototype patch to make sure i'm going in the right direction. I feel this patch is about 95% complete, the outstanding issue being page redirection after quick-account creation. It introduces and new option under the user admin settings "Public registrations" called "Visitors can create accounts and sign in immediately.", allowing visitors to submit their own passwords upon account creation. This is important in an ecommerce site where a new customer wants to the checkout process to be as easy and seamless as possible. ------------------------------------------------------------------------ Thu, 08 Jan 2004 10:22:09 +0000 : moshe weitzman i read through the patch. looks good to me. a few notes - we should still send a password via email to users who choose their ow password. with some text tweaking, we should be able to send the same welcome email to 'generated password' registratants, and 'user specified password' registrants. - I think we need a setting for minimum length of a password. the password textfield should inform users of this requirement. - you don't actually relinquish control after saying "/* Let the developer control where the user is redirected. */". i assume this part isn't finished yet. nice work. ------------------------------------------------------------------------ Thu, 08 Jan 2004 13:46:07 +0000 : flevour Are there any anti-bot checks around, e.g. randomly generated images that contain text or numbers to insert in a box? Congrats for your work :p // flevour ------------------------------------------------------------------------ Thu, 08 Jan 2004 13:54:19 +0000 : Bèr Kessels I had another idea. that would be to filter all emailadresses (in content too) into a link to the feedback module. thus http://www.mysite.org/feedback/mailto/me/mysite.org the feedback can then print a form that can send the message to me(a)mysite.org. Would this be a good feature or not? Ber ------------------------------------------------------------------------ Thu, 08 Jan 2004 13:56:36 +0000 : Bèr Kessels sorry folks. placed this in the wrong box. Was updating another feature, and reading this one (to see if it was the same one) i then, by accident, filled replyed here. :( Ber ------------------------------------------------------------------------ Thu, 08 Jan 2004 16:49:56 +0000 : Dries Showing an image with random generated text that a user is supposed to copy, makes your website inaccessible for visually impaired: they can't be read by a screen reader. ------------------------------------------------------------------------ Thu, 08 Jan 2004 17:07:02 +0000 : mathias Responding to Moshe's comments: - we should still send a password via email to users who choose their own password. with some text tweaking, we should be able to send the same welcome email to 'generated password' registratants, and 'user specified password' registrants. That is a good point. I'll update the patch. - I think we need a setting for minimum length of a password. the password textfield should inform users of this requirement. Agreed. In my patch i checked to make sure the password was at least six characters long, but this should be an element that can be tweaked by the admin. It might be best to make this a global password length system variable. - you don't actually relinquish control after saying "/* Let the developer control where the user is redirected. */". i assume this part isn't finished yet. Yep, that's the part i'm still working on. Thanks for the critical eyes. ------------------------------------------------------------------------ Wed, 14 Jan 2004 04:31:06 +0000 : mathias Attachment: http://drupal.org/files/issues/user_0.module-quick_acount.patch (7.95 KB) The patch has been updated and is ready for final review, and commit. ------------------------------------------------------------------------ Wed, 14 Jan 2004 22:37:53 +0000 : Dries Not sure. Wouldn't it make more sense (and result in better/less code) to let the user *always* choose his password and to introduce a admin setting to control whether e-mail addresses should be validated by e-mail? ------------------------------------------------------------------------ Sun, 15 Feb 2004 17:02:38 +0000 : moshe weitzman moving out of patch queue until a cleaner implementation is submitted ... this feature is still quite valuable. ------------------------------------------------------------------------ Fri, 05 Nov 2004 19:21:49 +0000 : Nick Nassar I agree with Dries that it makes a lot of sense to always let the user choose her password. It's a pain to copy and paste in a randomly generated password, then change it. Hash link based verification is much easier. That's really a seperate issue from an option to disable verification. ------------------------------------------------------------------------ Fri, 22 Jul 2005 22:11:42 +0000 : amanuel Attachment: http://drupal.org/files/issues/user4.6.2.patch (4.25 KB) Following Dries's suggestion, I have implemented a "Enable Email Verification" option to user.module. The attached patch does the job. With this patch the system by default will ask for a password. If Email Verification is turned on in the settings, the system will send the password via email. $edit['destination'] is carried so as to allow the user to return where they were (shopping cart etc.) Any comments? Amanuel ------------------------------------------------------------------------ Sat, 23 Jul 2005 05:48:08 +0000 : mathias I want users to be able to enter their own passwords upon account creation, but this patch still needs some work. - The email verification checkbox in user admin settings is confusing. I'm assuming that it applies to any of the selected registration options? However when I select that only site admins can create new user accounts, the accounts I create don't get any emails sent for the user to verify. - When a user signs up and enters his/her own password I think they should be logged in automatically rather than taken to a screen asking them to click the login button. - User entered passwords aren't validated. We should check to make sure they're at least six characters and verify the password strength level to some degree (i.e. same characters, all lowercase letters.) ------------------------------------------------------------------------ Fri, 29 Jul 2005 05:09:30 +0000 : Steven I agree with Dries. Random-generated passwords are hard to use. We already have optional hash-link functionality on signup, so I think we should always use it. ------------------------------------------------------------------------ Sun, 07 Aug 2005 17:02:45 +0000 : killes(a)www.drop.org I actually disagree with Dries and Steven. I let firefox maintain all my passwords and couldn't care less what my actual pw for any Drupal based website is. If we let the user provide a password then I at least woudl want to havd Drupal suggest one for me. ------------------------------------------------------------------------ Mon, 19 Sep 2005 00:35:55 +0000 : Uwe Hermann I agree with killes here. Asking the user to choose a password usually results in _very_ insecure passwords. Give them random passwords per default in order to keep most of the accounts secure. If a user then changes the password to his pet's name, that's his problem...

1 0

[drupal-devel] [feature] Dependency system to solve forum without comment problem
by chx 19 Sep '05

19 Sep '05

Issue status update for http://drupal.org/node/18447 Project: Drupal Version: cvs Component: system.module Category: feature requests Priority: normal Assigned to: chx Reported by: chx Updated by: chx Status: patch Attachment: http://drupal.org/files/issues/depend.patch (3.22 KB) As discussed on the developer list. This was surprisingly easy. There is still an issue: t('The configuration options have been saved.') is displayed more than once if there is a dependency forced module switch on. I have tried something (you'll see) for some reason it does not work. Number of page reloads can be decreased if Drupal could be reinitialized after system_listing_save instead of redirecting but I doubt this would be feasible. Although I marked this is feature request, this is more a usability issue (for the forum-comment dependency) and as a side effect it is a useful feature, too (for any other module "bundles"). I want criticism! I'd like to get torn apart by wild animals. Heavy! Eaten by some squirrels. chx

14 45

[drupal-devel] [task] Admin help in core modules
by Robin Monks 19 Sep '05

19 Sep '05

Issue status update for http://drupal.org/node/26139 Project: Drupal Version: 4.6.2 Component: other Category: tasks Priority: normal Assigned to: Robin Monks Reported by: Robin Monks Updated by: Robin Monks Status: patch Attachment: http://drupal.org/files/issues/4-6-2-helptext.patch (126.02 KB) This patch adds help text to all core modules per the information at http://drupal.org/node/24768. This patch should be applied to 4.6.x and CVS HEAD. Robin Robin Monks

9 23

[drupal-devel] [bug] 301 redirects in aggregator broken
by vwX 19 Sep '05

19 Sep '05

Issue status update for http://drupal.org/node/31591 Post a follow up: http://drupal.org/project/comments/add/31591 Project: Drupal Version: cvs Component: aggregator.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: vwX Updated by: vwX Status: patch (code needs review) Attachment: http://drupal.org/files/issues/aggregator_fix_301.patch (659 bytes) Searched for this issue before submitting this and didn't find anything. " Log message claims that Feed url is updated upon 301 redirect, but break in switch statment prevents that from happening. Attached patch fixes that. Tested on /. rss feeds which do a redirect.(20:59:43) Amazon: Anyone around? (20:59:49) Amazon: trying to debug my aggregator (21:02:34) linuxcolumbus: what is it doing? (21:04:16) Amazon: http://slashdot.org/index.rss (21:04:24) Amazon: I added slashdot as my aggregator (21:04:28) Amazon: as my feed (21:04:38) Amazon: and I added a category (21:04:44) Amazon: then I hit cron.php (21:04:56) Amazon: it doesn't add up (21:05:06) Amazon: it doesn't get the feeds (21:06:12) Oadae left the room (quit: Remote closed the connection). (21:07:33) linuxcolumbus: Did you try going into the aggregator link under administration and using the update feeds option? (21:08:01) linuxcolumbus: update feeds = update items. (21:08:26) Amazon: clicked on update items: nothing (21:08:45) linuxcolumbus: Hum.... I'll try it on my site. (21:09:56) linuxcolumbus: ditto here, I get nothing. (21:10:37) Amazon: really (21:10:57) filhocf left the room. (21:10:59) Amazon: linuxcolumbus: I am updating the aggregator documenation (21:11:13) Amazon: http://drupal.org/handbook/modules/aggregator (21:11:20) Amazon: because there are 18 comments (21:11:26) Amazon: some over two years old (21:11:37) Amazon: so I need a working aggregator to sort through the comments (21:11:39) linuxcolumbus: looks like there is a redirect getting in the way. Try http://rss.slashdot.org/Slashdot/slashdot (21:13:15) Amazon: ok, that worked thanks (21:15:10) linuxcolumbus: I just cut and pasted an rss link from /. for a particular category and it did the same thing. must be a bug in aggregator. If you get a chance could you check, if not I can. (21:21:24) Amazon: I have two feeds (21:21:34) Amazon: that's good enough to write documentation (21:22:25) linuxcolumbus: Yep, I looked through the bug list and didn't see anything. " vwX

1 0

[drupal-devel] [bug] Queue module does not count the last submitted vote correctly
by leongtd 19 Sep '05

19 Sep '05

Issue status update for http://drupal.org/node/27303 Post a follow up: http://drupal.org/project/comments/add/27303 Project: Drupal Version: 4.6.2 Component: queue.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: leongtd Updated by: leongtd Status: patch Attachment: http://drupal.org/files/issues/drupal-4.6.2-queue-vote-fix.patch (438 bytes) Queue module does not count the last submitted vote correctly. After the user has submitted a vote, it wouldn't count as the vaild vote until another user vote in. Steps of reproduce: - If the promotion threshold is set as 1. - First user press +1 vote Actual results: - The vote just submitted won't get counted and the post won't be promoted until second user vote +1 again. Expected results: - The vote should count and the promotion should be immediate. Attached is the code to fix the problem. leongtd

2 1

[drupal-devel] [feature] Improved styling of autocomplete matches
by Thox 19 Sep '05

19 Sep '05

Issue status update for http://drupal.org/node/24932 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Thox Updated by: Thox Status: patch Attachment: http://drupal.org/files/issues/autocomplete_8.patch (1.39 KB) I'd like the autocomplete matches to be underlined (or styled in some way) so that users can see which part of the strings returned was actually matched. See Screenshot [1]. [1] http://photos14.flickr.com/19139302_0acb27f00d_o.png Thox

6 10

[drupal-devel] [feature] Separate mail backend
by killes 19 Sep '05

19 Sep '05

Issue status update for http://drupal.org/node/28604 Post a follow up: http://drupal.org/project/comments/add/28604 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Dries Updated by: killes(a)www.drop.org Status: patch (code needs review) Ok, changed and tested. Some more changes, taken some concepts from massmailer.module. Included hacked copies of simplenews and contact module for testing purposes. We need to discuss if this should be a module or a part od system.module. depending on the outcome we need to put the functions in mail.module and mail.inc into different files. Testers welcome. killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ Wed, 10 Aug 2005 12:35:37 +0000 : Dries It was suggested that we separate the mail backend from the front-end. We might want to include the mail backend in core as includes/mail.inc. Then, other modules like massmailer, subscriptions, notify, pm (private messages), project (project issues), contact, etc. could reuse this component. The mail.inc file would implement some kind of mail queue functionality, and modules just add a mail to the mail queue using a simple /mail API/. In future, the mail backend could deal with bounces and report back proper status codes. Moreover, mail.inc would be pluggable so it could be replaced by a more powerful one, or one that is build specifically for the underlying mail transport (SMTP server). Furthermore, this would solve issues with how many mails get send within a specified interval. Like, when more than one module sends out e-mails it is hard to enforce limitations/restrictions imposed by the hosting company. I'm posting this here so you can keep this in mind when working on simplenews, and to solicit for feedback. Chances are we'll setup an IRC meeting to discuss this further. Details to follow. ------------------------------------------------------------------------ Wed, 10 Aug 2005 16:15:16 +0000 : Amazon A good place to start would be to look at existing Mail API's Pear Mail: http://pear.php.net/package/Mail Pear Mail tutorial: http://www.zend.com/pear/tutorials/Mail.php#Heading2 ------------------------------------------------------------------------ Wed, 10 Aug 2005 20:21:57 +0000 : walkah um. +1 and then some. I think this is good... and some good references from Amazon. I'll throw in one other : http://phpmailer.sf.net/ - has great mime handling (i've run into issues with PEAR::Mail's mime handilng in the past, but that was around 2 years ago, and things may have gotten better since then). Oh - and you don't mention it - but support for multipart / mime messages would be lovely :) I'd be interested in / happy to sit in on any IRC discussion as well. ------------------------------------------------------------------------ Wed, 10 Aug 2005 21:40:34 +0000 : robertDouglass phpmailer++ I've used it and like how easy it is to send both text and html mail. Did I say html mail? You bet! It's time that we had the option. ------------------------------------------------------------------------ Thu, 11 Aug 2005 05:47:01 +0000 : cyberchucktx I'm definitely interested. Hopefully by adding a post to this I'll get notified on new postings (?) If not I may miss the IRC .. I've been doing a lot of work with safe_mode PHPLIST (have posted to the drupal site somewhee, can dig out the reference if anyone is interested). Charlie in TX ------------------------------------------------------------------------ Wed, 17 Aug 2005 08:42:34 +0000 : Dries It was suggested that mail.inc also provides a HTML to text services. Lots of modules (newsletter, notify, project) try converting HTML to text. Having a reusable function makes sense, and will lead to better conversion routines. XSLT anyone? ------------------------------------------------------------------------ Wed, 17 Aug 2005 12:31:27 +0000 : Grugnog2 +1 for phpmailer I found it very easy to use - and most importantly for me - it supports SMTP authentication. As many ISP's will not let you send mail without using SMTP-auth nowadays it may be worth this feature is incorporated into the mail.inc API. - Grug ------------------------------------------------------------------------ Wed, 17 Aug 2005 15:08:43 +0000 : Robert Castelo For about a year now I've been working on an email newsletter and announcement module [1]. There's a version in my sandbox commited about 2 months ago which works fairly well. Dan Robinson and Varr Willis at CivicActions, Moshe Weitzman plus a few others have been testing it, and I've had lots of positive feedback and feature and bug reports from them. A few months ago a realised that there's not much point in putting so much effort into creating all this functionality, only for it to be locked away in my module. Better to Better to create discreet component modules which provide a particular service, such as bounced email handling, but which can be used by any other module that also needs that service. For the last two months I've been working to split functionality into component services modules and make these services available to all modules. One of the biggest challenges was to make these component modules independent of each other. The only area where I haven't managed this is some of the database calls - but thanks to a chat with chx I realised that db_rewrite_sql could be used to handle this very nicely. This is what I have: * bounced_email.module - process bounced emails * html2text.module - convert HTML to plain text equivalent (e.g. list item becomes "* item") * identity_hash.module - manages full and partial loggin based on hash which can be used in email links * publication.module - defines and packages content of publication, which could be any kind of publication * schedule.module - defines and manages schedules, e.g. email sending schedule * subscribed.module - manages subscriptions to publications * templates.module - manage and define templates What's great is that the component modules are not limited to email, they could be used to quickly create RSS newsletters, PDF newsletters, text message newsletters, or even personalised/filtered website sections. I haven't made the new component modules available anywhere yet, but I'll be happy to upload them to contrib and let others get involved. What would be the best way to commit them - as a single directory? or each component module in it's own directory? [1] http://www.cortextcommunications.com/development/newsletter/features ------------------------------------------------------------------------ Thu, 15 Sep 2005 02:05:18 +0000 : vwX Attachment: http://drupal.org/files/issues/mailqueue.tar.gz (3.71 KB) This is a very basic mail queue system I would like to contribute. There are some changes to other modules that will have to be made such as changing user.module to use this instead of directly calling the php mail function and moving mime_header_encoding to mail.inc. ------------------------------------------------------------------------ Thu, 15 Sep 2005 15:25:11 +0000 : killes(a)www.drop.org Note: I am moving this to the main project. VwX: What I see looks very nice for a start. Some polishing is certainly needed, but I'd like to try this. If I only had the time... ------------------------------------------------------------------------ Fri, 16 Sep 2005 22:10:19 +0000 : killes(a)www.drop.org Ok, I've been doing some clean-up on this one and made contact.module use it. The module and the .inc file work. I've put the files into my sandbox for now. I plan to work on them over the weekend (unless Dries tells me they are too late for 4.7). http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/killes/mail/ But I could use some input: - the sql file defines a column to store the module that generated the mail. Do we want this? If yes, we need to fix it. - Do we need a throttle for only sending x mails per cron run? - can somebody try the files with php5? - what else do we need? Please give input, links and what not. ------------------------------------------------------------------------ Sat, 17 Sep 2005 20:34:04 +0000 : Dries Some of my comments might be false. If so, sorry. I only looked at it for 5 minutes: * I wonder why we need per-module settings. I can't think of concrete use cases. * For consistency, mailid needs to be mid. * I don't see an option to send mails immediately? * I don't see any "messages per hour" accounting? * I don't understand why mail.inc should be node system aware? * mailid = '%s' should be mailid = %d. * Incorrect use of t(): don't translate user input. * The coding style needs work; inconsistent variable names, inconsistent spacing, etc. * Some PHPDoc is rather cryptic: /Updates table mail queue address table sets sent flag to 1 for a queued msg./. ------------------------------------------------------------------------ Sun, 18 Sep 2005 04:28:11 +0000 : killes(a)www.drop.org I've fixed a number of things. needs testing.

1 0

[drupal-devel] [feature] Speed up Drupal and improve scalability: On demand module loading
by Jose A Reyero 19 Sep '05

19 Sep '05

Issue status update for http://drupal.org/node/27901 Post a follow up: http://drupal.org/project/comments/add/27901 Project: Drupal Version: cvs Component: module system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Jose A Reyero Updated by: Jose A Reyero Status: patch (code needs review) Attachment: http://drupal.org/files/issues/on_demand_module_loading.patch (7.8 KB) As Drupal grows bigger, there is too much code not really needed parsed for each request. Also, installing more and more modules presents serious scalability issues, as all the enabled modules are included always for each non cached page. This is a first attempt to keep track of *all* module hooks, and only load modules when they're really needed. I guess it may need some polishing but the idea is simple enough. Currently, as the hook_menu is implemented by most of the modules, and it is called most of the times, the potential performance improvement introduced by this mechanism may be small. But the thing is, once he have some system for on demand module loading, hooks can be reworked in the future, to have some real performance boost. I.e. hook_menu could be easily split in two 'hook_menu' and 'hook_menu_dynamic', thus really reducing acually loaded modules. As I said, this is a first step. If there's some interest in this kind of features, I have some other things in the works aimed at performance and scalability, like: - (Simple) Rework of menu system to take real advantage of on demand module loading - Expand menu items to be able to include some file where the callback is in - Extend module loading for 'loading on path', and maybe 'loading split modules' - Some API loader, kind of api_invoke.... Jose A Reyero

6 10

[drupal-devel] [feature] Add Referrer Banning
by Robin Monks 19 Sep '05

19 Sep '05

Issue status update for http://drupal.org/node/27787 Post a follow up: http://drupal.org/project/comments/add/27787 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Robin Monks Reported by: Robin Monks Updated by: Robin Monks Status: patch Attachment: http://drupal.org/files/issues/referring_banning_with_stat_fix.patch (7.9 KB) The attached patch adds the following features to Drupal HEAD: - Setting Access Permissions by referrer. The attached patch fixes the following bugs: - Port numbers on same domain cause Drupal to mark an external referrer This patch changes the following modules, by function: - user.module -- user_admin_access_check Now allows checking based on referrer. -- _user_admin_access_form Now has options for banning based on referrer. -- user_admin_access Now lists referrer bans. -- user_help Show referrer banning in documentation. - bootstrap.inc -- _drupal_bootstrap Checks to ensure user is not banned by referrer. - statistics.module -- statistics_top_referrers Has "quick-links" for banning referring domain. Fixes port issue. I have tested this module and it works correctly on Drupal HEAD. Robin Robin Monks

11 16

[drupal-devel] [feature] Book Menu Navigation needs Theming
by merlinofchaos 19 Sep '05

19 Sep '05

Issue status update for http://drupal.org/node/28198 Post a follow up: http://drupal.org/project/comments/add/28198 Project: Drupal Version: 4.6.2 Component: book.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: merlinofchaos Updated by: merlinofchaos Status: patch (code needs review) Attachment: http://drupal.org/files/issues/book-theme-menu.patch (1.88 KB) In one of my Drupal sites I re-themed a minor issue in the menus, and discovered that the book navigation system just uses code that looks similar to the menu themes, but isn't actually themed. This very small patch adds a function theme_book_menu_item modeled closely on theme_menu_item from the menu system, and lets me theme this output as necessary; I believe it's incompatible with the other book menu patch floating around (and hopefully not necessary, but I haven't looked too closely at what that patch actually does). Hopefully I didn't break anything with it! merlinofchaos

2 2