- Development - lists.drupal.org

[drupal-devel] [feature] Administration Control Panel suggestion
by syllance 19 Sep '05

19 Sep '05

Issue status update for http://drupal.org/node/31326 Post a follow up: http://drupal.org/project/comments/add/31326 Project: Drupal Version: cvs Component: system.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: der Updated by: syllance Status: patch (code needs review) i think there's a problem with your latest patch. it seems to display all icons as a vertical list. it may be a problem with my setup, but i'm using basic themes that comes with head. the administer page is thus very long, and this is not very useful. previous version was better, imho :) thanks syllance Previous comments: ------------------------------------------------------------------------ Thu, 15 Sep 2005 17:50:52 +0000 : der Attachment: http://drupal.org/files/issues/system_9.patch (4.27 KB) New feature suggestion: I would like to suggest a couple of enhancments to administration pages. First, add a new general settings option to allow the user to specify the admin home page. Currently the watchdog log view is the default home page. Second, add a new control panel page that can be used as the default admin start page. I've attached a suggested patch to the CVS head version of the system.module that implements these two enhancements. The patch does the following. Adds a new "default admin page" text field to the general settings group (just after the "default front page"). It also changes the admin menu entry to call a new function that examines the default "admin page" variable and redirects to the appropriate path. For the control panel, the patch adds a new function (system_admin_controlpanel). This function basically looks for the admin entry in the menu structure and then iterates through the child menu items and builds a control panel page using the path and title information returned from the menu structure. For the control panel icons it looks for an icon file in the misc directory that matches the name of the menu item (e.g. user.png, access.png etc) If it doesn't find an icon it uses a default. I've also included some 48/48 icons that I borrowed from my usr/share/icon/gnome directory of my local Linux box. I believe these are gnome GPL'ed icons but any 48/48 icons could be used. This patch allows users who prefer the current functionality to keep it as their default. It provides the option for others to make any admin page they want to be their admin "home page" including using a graphical control panel. Module developers that add new admin menu options can add their own custom icons for the control panel but they are not "required" to do so as a default will be used if they don't provide one. ------------------------------------------------------------------------ Thu, 15 Sep 2005 17:52:15 +0000 : der Attachment: http://drupal.org/files/issues/drupal_controlpanel_icons.zip (39.09 KB) 48x48 icons attached ------------------------------------------------------------------------ Fri, 16 Sep 2005 14:30:16 +0000 : der Attachment: http://drupal.org/files/issues/system_2_0.patch (4.5 KB) updated patch. slightly changed the formatting of the control panel page ------------------------------------------------------------------------ Sat, 17 Sep 2005 00:37:24 +0000 : moggy I quite like this. It certainly goes some way to making Drupal easier on the eyes for first time users. I noticed there's a lot of hard coded style. Would this not be better in a stylesheet and the code just containing classes and ids? Also would a dropdown box of possible admin pages be better than trying to remember how to spell controlpanel (something I'm having trouble with tonight ;-) ) ------------------------------------------------------------------------ Sat, 17 Sep 2005 13:02:08 +0000 : syllance Nice job :) the default admin page is a nice feature, and the controlpanel is a very good idea. This goes in the good direction to make Drupal more user friendly. i agree with the dropdown menu and stylesheet additions, but i already really appreciate the current version. hope this will go into core soon, as it really makes the first admin pages contact better :) i don't mind scrolling through the nav menu and i rarely goes into admin without checking the logs, but that definitely will help me converting my wife's site to drupal :p thanks ! ------------------------------------------------------------------------ Sat, 17 Sep 2005 16:09:43 +0000 : der I'll move the styles off to a style sheet but I'm uncertain about whether or not make make the default admin page a dropdown. It's an easy change and it eliminates any typos by the user but it also restricts the user to a current visible admin menu item. If by chance someone wanted to write their own admin start page (ie their own control panel) they would have to hack the core system.module to do it. Anyone else want to weigh in with their preference? Also, anyone up for creating drupalized versions of the control panel icons? ------------------------------------------------------------------------ Sat, 17 Sep 2005 16:16:15 +0000 : chx Maybe just because I created it, I like my control panel module better. ------------------------------------------------------------------------ Sat, 17 Sep 2005 16:25:30 +0000 : der If I would have known there was a module I wouldn't have written this patch although I do think this would be good for core Drupal as the default. Is your modules a recent creation? I don't see it on drupal.org nor could I find in the contribs section of CVS (either the modules or sandbox sections). I'm I missing something? Is it called something different? ------------------------------------------------------------------------ Sat, 17 Sep 2005 18:20:15 +0000 : syllance chx control panel is located in his sandbox (cp.module), and thanks to him for letting us know there's one :) it's working fine (tested on HEAD) and provide interesting concept for navigating through the admin, instead of just add a frontend. the settings part is the better one, listing all elements in the page makes quickly forget the standard menu. der's one looks nice and provide a more immediate access to admin pages, but the standard menu is still mandatory to access some elements (dba or store settings for example, still needs to be accessed via left menu). to be honest, i like them both :) being able to change the default admin page is very nice, and icons make admin looks a lot better, raising the Woman Acceptance Factor by a huge amount (my wife loves it :). but i also really like the more in depth admin navigation offered by chx module. mixing both on my head setup gives a nice result, so may be it would be a good idea to join forces and mix the 2 panels. chx, is your module somewhat official and scheduled to hit the core ? ------------------------------------------------------------------------ Sat, 17 Sep 2005 19:24:11 +0000 : Amazon Hi, I asked Karoly to create the control panel module. It important that the control panel be tied into the navigation menu block so that it does not create inconsistent navigation. The goal is to start a user experience grouping exercise to help the community categorize administration tasks. The first thing that has to happen is that administration must be considered a seperate situation from creating personal content in Drupal. To support this seperation of personal tasks and administration tasks we broke out administration to have a separate theme in the CivicSpace theme. Through research interviews into Drupal administration we need to discover what the goals and tasks of administrators are. Some early feedback is that site developers need modules to be evaluated on Drupal.org. They have also indicated they need better and consistent administration help ,with incontext list, which we have been adding. We have also heard administrators want a quick overview. Any change to provide a control panel like overview must have a dashboard like overview. You should assume that we will identify a list of 5-7 top goals for administrators. Once those those 5-7 top goals are identified we need to ensure administrators can acommplish tasks to achieve those goals. Some of those tasks will completed by clicking through to icons or admin interface links. Sub-goals will be accomplished by providing effective navigation. We need to consider 4 types of navigation to be added to the control panel: Global navigation, local navigation, contextual navigation, and situational navigation. Some of this navigation can be accomplished through a theme or blocks. Some will need to be in the page and some need to be added in otherways, such as interaction techniques. Keep all this in mind when creating a control panel solution. It also must respond to the fact that every site will have different permissions set and different modules. This is a complex problem and it's going to research and experimentation to get it right. But this is a big step in the right direction. Cheers, Kieran ------------------------------------------------------------------------ Sat, 17 Sep 2005 19:47:55 +0000 : der Attachment: http://drupal.org/files/issues/system.module_11.patch (5.61 KB) This has sparked a lot of good discussion. I've taken a look at cp.module and I think it really is complimentary with my proposed patch. I've taken my patch one step further and provided the settings icons in a collapsable group below the main control panel. This would allow access to all admin functions without referring to the traditional menu. Syllance, do you think this addresses the gap you saw in my solution? ------------------------------------------------------------------------ Sat, 17 Sep 2005 20:33:10 +0000 : der Kieran, I'm glad to see some serious thought going into the user experience for site administrators. I think separating the user and admin sections of the site is critical. It will not only allow extensive usability work to be done for site admins it will also make it much easier for theme creators as they will be able to focus on the end user experience. I like the admin theme for civicspace. My only dislike about the approach is that it's template driven which causes a sites template to be larger and more complex due to handling all the logic for user and admin themes. I think a better approach may be to use a module such as the sections module. This allows you to have smaller templates focused on user or admin themes. I agree with your point about making sure the control panel ties into them menu system. My approach uses the existing menu structure so modules are added dynamically and all permissions are enforced. ------------------------------------------------------------------------ Sat, 17 Sep 2005 22:21:05 +0000 : chx <?php function _system_adminpage () { drupal_goto($path = variable_get('site_adminpage', 'admin/controlpanel'), $query = NULL, $fragment = NULL); } ?> no way. Use menu !$may_cache and set the path based on the variable. Adding in-line style elements is also a no-go. The code style is not kept. Never a space between full stop and apostrophe, always otherwise. It's not $menuvisible but $menu_visible I must be blind (it's 0:17am) but // Build the settings section of the control panel does not seem to differ from the previous section. A function may be appropriate. ------------------------------------------------------------------------ Sat, 17 Sep 2005 22:39:40 +0000 : der Thanks for the code feedback. I'm assuming the extracted style info would get patched to drupal.css? Your right about the duplicate code. A function would make more sense, I'll make the change. I'm not sure about the comment to use "$may_cache" I've never used it before. What's it's purpose? How should I use it in this situation. I'll dig around and see if I can figure it out but I thought you might be able to give me a little insight. Thanks! ------------------------------------------------------------------------ Sun, 18 Sep 2005 10:41:00 +0000 : syllance der, i've checked the new version of your control panel, and it does simplify access to the settings menu (although with a complex setup, the site config collapsable menu goes a lot more down than the menu, but this a page and not a small menu so its still better) however, there other case settings like, such as the ecommerce modules, which provides a more complex menu tree (ex : store->settings->payment->adjustments, each with their own admin pages). these are not taken into account by your panel, leaving the menu mandatory. chx control panel handles this nicely with page navigation. going through the store menu with chx panel is a real pleasure while its a real pain with the menu. So i think the best would be to mix the two panels, chx one handling page navigation, and yours providing a frontend for basic admin pages, and collapsable site config items. instead of linking to the standard admin pages, icons might link to chx nav pages where there are sub entries. i'm running both today, and this already makes the admin really better, but i'm often switching from der panel to chx one (for store), so mixing both would be, for me, a very nice solution :p thanks for the good work :) ------------------------------------------------------------------------ Sun, 18 Sep 2005 12:54:55 +0000 : der Attachment: http://drupal.org/files/issues/control_panel.patch (5.61 KB) Here's a new patch with the code reworked per chx's comments with the exception of his objection to my use of drupal_goto function. chx, I'm probably missing something really obvious but I'm not understanding your suggestion. Are you suggesting I use some menu function to do the redirect? If so, I could not find one that suits my needs. Or are you suggesting to use the drupal_goto function in a different manner than I am using it. Like I said, I'm probably missing something really obvious here but for the life of me I don't know what it is. Any further advice would be greatly appreciated. The offending code below: <?php function _system_adminpage () { drupal_goto($path = variable_get('site_adminpage', 'admin/controlpanel'), $query = NULL, $fragment = NULL); } ?>

1 0

[drupal-devel] [feature] On taxonomy overview page, make term names link to their respective taxonomy/term/(x) page.
by Zach Harkey 19 Sep '05

19 Sep '05

Issue status update for http://drupal.org/node/31014 Post a follow up: http://drupal.org/project/comments/add/31014 Project: Drupal Version: cvs Component: taxonomy.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Zach Harkey Updated by: Zach Harkey Status: patch (code needs review) Attachment: http://drupal.org/files/issues/taxonomy_12.patch (823 bytes) On the administrative categories page(a.k.a. taxonomy overview page: admin/taxonomy), this patch makes each term link to its respective taxonomy/term/(x) page. This is a very simple change that really increases the utility of the overview page as a navigational aid to the admin. Zach Harkey

3 3

[drupal-devel] file (image) handling in flexinode
by Bèr Kessels 19 Sep '05

19 Sep '05

Hi, Drupals core image and file handling is *very* limited. I think this is a very good design choice. But the fact that in contribs there is no proper handling is a bad thing. In other words: Contribs all try to improve the core file handling system, yet don't manage to get a default -working- system going. I plan t get a default idea and system in flexinode going. Looking at http://drupal.org/node/21979 http://drupal.org/node/27310 I conclude that there is enough manpower for this, yet too little centralisation and agreement on how to deal with this. Thererfore, I would like to see a thread on drupal-devel going on this. Possibly followed by a short IRC meeting to get this all rolling. If need arises, we can follow this up on drupalCON in amsterdam. Here is what (IMO° needs to be agreed upon: * How will a general file handling system look like. (hooks, apis, layers, etc?) * What improvements do we need in core to get this sorted out, if any? * Who wants to help? * Must this be flexinode-only, or just flexinode aware, or not at all linked or related to flexinode? Note to drupalART readers, please keep this centralised and reply to drupal-devel mailinglist. Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]

1 0

[drupal-devel] [task] introduce node autofill
by Bèr Kessels 19 Sep '05

19 Sep '05

Issue status update for http://drupal.org/node/27530 Post a follow up: http://drupal.org/project/comments/add/27530 Project: Drupal Version: cvs Component: node system Category: tasks Priority: normal Assigned to: Bèr Kessels Reported by: Bèr Kessels Updated by: Bèr Kessels Status: patch Attachment: http://drupal.org/files/issues/node_autocomplete.patch (1.25 KB) This patch introduces an autofill for node titles. It is not yet used anywhere, but at least we have the node/autofill url available where contribs &c can query for node titles. Bèr Kessels

5 9

[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