September 2005 - Development - lists.drupal.org

[drupal-devel] Code freeze, usability and performance
by Dries Buytaert 19 Sep '05

19 Sep '05

Hello world, just a quick update on the code freeze. The next few days I'll work my way through the pending patches. CVS will be frozen once I managed to review some of the important patches that are currently pending. I'll try to review patches tonight and during the weekend. As always, you can help review patches. If you do, make sure to review them well. Bad reviews are merely a waste of time. As of Monday, I'd like us to focus on both usability and performance improvements. - Usability: one of the most common complaints about Drupal relate to the out-of-the-box experience. For many people, this is either due to (i) the terminology or (ii) the awkward navigation structure. Many people feel lost and don't know where to start. As such, some people think of Drupal as "too complex" or "different than other systems". In the next few weeks, I want you to investigate how we can continue to improve the Drupal exerpience. - Performance: Drupal being used on bigger and bigger site, performance becomes more and more important. Also, because more and more complex sites are being built, memory usage is often a bottleneck. In the next few weeks, I want you to investigate how we can improve performance and reduce memory usage. Fire up your favorite profiling tool, benchmark scripts, and try to squeeze more out of Drupal. -- Dries Buytaert :: http://www.buytaert.net/

10 11

[drupal-devel] [feature] Allow descriptions for permissions
by timcn 19 Sep '05

19 Sep '05

Issue status update for http://drupal.org/node/30984 Post a follow up: http://drupal.org/project/comments/add/30984 Project: Drupal Version: cvs Component: user.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: timcn Updated by: timcn Status: patch (code needs review) Attachment: http://drupal.org/files/issues/user_32.patch (1.59 KB) I extended the user.module in order to allow descriptions for permissions because it is sometimes difficult to figure out what a certain permission really does. In hook_perm() you can now return an array like that (example taken from node.module): <?php function node_perm() { return array( 'administer nodes' => 'Allows editing and deleting of all nodes', 'access content' => 'Allows to view content' ); } ?> You can also freely mix "described" permissions with old/regular ones; i.e. it does not break the current permission system. timcn

3 2

[drupal-devel] [feature] Single step account creation and login
by Kobus 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: Kobus Status: patch (code needs review) I believe that a one-time url is a good solution, and that it is a MUST add if you add the "own password" option. If you generate the password, just add the "log in" button and redirect to the page the user requested/requires. Mozilla 1.7 has a password security meter built in. If you allow users to generate their own password, couldn't something like this be implemented with AJAX (which, of course, is unavailable if degraded?) Regards, Kobus Kobus 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... ------------------------------------------------------------------------ Mon, 19 Sep 2005 05:51:15 +0000 : robertDouglass 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 ------------------------------------------------------------------------ Mon, 19 Sep 2005 06:35:20 +0000 : Crell The password should always be emailed to the user. They will forget their information otherwise. :-) I too would like to have the option of email-less account creation. I just finished part 1 of a project for a client where we're using Drupal more as an app framework for an intranet app than as a CMS. Avoiding the "now check your email" step was a mandatory requirement of the system, so I ended up hacking user.module to give all users the same auto-generated login button that the first user gets. For an intranet application (or pseudo-intranet in this case, silly as it is), that's acceptable. For a public site, that is begging for spambots. Even with CAPTCHAs or similar verification techniques, it opens the site up to spam. However, if a site doesn't have user-generated content but does have a need for registration (ecommerce, for instance), skipping that email step is also very important. An email should still be sent, as I said, but you're going to lose your customers if they have to go to their email twice (once to create an account, once to get their receipt). Perhaps an admin option to allow users to log in immediately upon account creation, defaulting to no, with a big message pointing out to the admin that it's a potential security hole if the "registered users" role has any content-creation capability at all. That would be an entirely different question from letting users enter their own password. Given how easy it is to get a new password in Drupal already, I'd say we should still just auto-generate in all cases. They can change it if they want.

1 0

[drupal-devel] [bug] hook_delete_confirm -- custom controls for modules during delete cycle
by thehunmonkgroup 19 Sep '05

19 Sep '05

Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: 4.6.2 Component: base system Category: bug reports Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: thehunmonkgroup Status: patch Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [1] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [1] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG thehunmonkgroup

14 40

[drupal-devel] [feature] Single step account creation and login
by Crell 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: Crell Status: patch (code needs review) The password should always be emailed to the user. They will forget their information otherwise. :-) I too would like to have the option of email-less account creation. I just finished part 1 of a project for a client where we're using Drupal more as an app framework for an intranet app than as a CMS. Avoiding the "now check your email" step was a mandatory requirement of the system, so I ended up hacking user.module to give all users the same auto-generated login button that the first user gets. For an intranet application (or pseudo-intranet in this case, silly as it is), that's acceptable. For a public site, that is begging for spambots. Even with CAPTCHAs or similar verification techniques, it opens the site up to spam. However, if a site doesn't have user-generated content but does have a need for registration (ecommerce, for instance), skipping that email step is also very important. An email should still be sent, as I said, but you're going to lose your customers if they have to go to their email twice (once to create an account, once to get their receipt). Perhaps an admin option to allow users to log in immediately upon account creation, defaulting to no, with a big message pointing out to the admin that it's a potential security hole if the "registered users" role has any content-creation capability at all. That would be an entirely different question from letting users enter their own password. Given how easy it is to get a new password in Drupal already, I'd say we should still just auto-generate in all cases. They can change it if they want. Crell 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... ------------------------------------------------------------------------ Mon, 19 Sep 2005 05:51:15 +0000 : robertDouglass 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

1 0

[drupal-devel] [feature] Separate mail backend
by Peter Apockotos 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: Peter Apockotos Status: patch (code needs review) Dries, Are you talking about something like I request here http://drupal.org/node/28079 ? Peter Apockotos 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. ------------------------------------------------------------------------ Mon, 19 Sep 2005 02:28:25 +0000 : killes(a)www.drop.org 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.

1 0

[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