April 2005 - Development - lists.drupal.org

[drupal-devel] [feature] Enable multiple block regions (not just "left" and "right" sidebars)
by nedjo 21 Apr '05

21 Apr '05

Issue status update for http://drupal.org/node/16216 Project: Drupal Version: cvs Component: block.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: paragkenia Updated by: nedjo Status: patch Attachment: http://drupal.org/files/issues/block-dynamic-regions3.patch (15.69 KB) The main issue raised, if I'm understanding well: if a theme or theme engine is present that offers regions other than those available in the default theme, any blocks assigned to those regions will be invisible to most users. Here's a revised patch addressing the concern. I've added a test for each region to see whether it's also available in the current default theme. (Actually, I'm realizing as I write this, I've used the theme engine--so it would need to be updated to test first if an engine is being used.) In any case, any regions not available by default are starred, and a message text appears (only if necessary). If there's support for the approach, I'd be happy to finish the patch. Remaining work: * extend to work with non-engine themes * finalize base set of regions to implement * implement common region set in all core themes (for now I've only done xtemplate) * work on CSS display (how blocks in each region should look) This last point I'm not too confident on and would look for help/suggestions. Screenshot to come. nedjo Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 06:27 : paragkenia I read the comparision discussion between *Drupal* and *Mambo*. In several messages it was outlined that Drupal can place blocks only in right and left and not flexible to put them on anywhere where one want. It will be great if this can be changed in upcoming versions. I am no pro at PHP, so don't know how much time this task will take, but I think it is very important. parag ------------------------------------------------------------------------ April 14, 2005 - 21:44 : nedjo This issue was apparently partially addressed in issue http://drupal.org/node/19694 [1]. [1] http://drupal.org/node/19694 ------------------------------------------------------------------------ April 16, 2005 - 20:24 : nedjo Attachment: http://drupal.org/files/issues/block-dynamic-regions.patch (8.17 KB) This much-requested functionality - to have the ability to place blocks in more than the two predefined regions - was partially addressed in issue http://drupal.org/node/19694. [2]. But "blocks" are still limited to the "left" and "right" sidebars (hard-coded in block.module). This patch is a first step designed to enable multiple (eventually, admin-definable) regions for blocks. I've moved the existing "left" and "right" block regions to a 'region' table (with ids of 0 and 1, as currently used in themes). Then all references to the regions are drawn dynamically from the table. This way, if further records are added, they will appear in the list of available regions for block placement. Doing this actually reduces some duplicated code, since it's no longer necessary to repeat code blocks for each of "left" and "right". As it stands, the patch doesn't add any new functionality--but I don't think it breaks anything either. New functionality would need (a) new regions defined, and (b) changes to themes. A simple first step might be, e.g., to add a "footer" region and then add a call in the footer generation to append any blocks assigned to the footer region there. I'm setting this to patch, but I'm aware that it needs some discussion and refining before it'll be ready to apply. [2] http://drupal.org/node/19694. ------------------------------------------------------------------------ April 16, 2005 - 21:05 : nedjo Attachment: http://drupal.org/files/issues/block_regions.png (5.65 KB) Here's a screenshot showing the block admin page, with drop-downs for region placement (the options are dynamically generated based on defined regions). ------------------------------------------------------------------------ April 16, 2005 - 22:57 : adrian The biggest problem with this is that you can have multiple themes, and each of these themes can have different regions available. Also, the method of defining which regions are available needs to be standardised. Some of the work that me and Vlado are working on for the install system would go towards solving that problem (ie: meta information for modules, themes and styles). This has been discussed to death, but the general consensus has been that we _want_ to do this, but we need to solve a few other problems properly first, the most pertinent being the interface issue. Chris (factoryjoe) recently did a whole mess of workflows for something related to this. ------------------------------------------------------------------------ April 17, 2005 - 00:09 : syscrusher The first paragraph of adrian [3]'s post is a point that occurred to me also, as I read this thread. One suggestion would be to separate the definition and configuration of blocks, on one hand, from the placement of those blocks, on the other hand. In other words, Drupal core provides a mechanism defining what blocks exist, which of these are on by default or off by default and user-selectable vs. which are forced on for all users, and the configuration (if applicable) of specialized blocks defined by particular modules. Each theme provides a standard hook function that returns an array of region names and help/description text, e.g., array('left'=>t('This vertical region is left of the main content area'), 'right'=>t('This vertical region is right of the main content area'), 'footer'=>t('The footer is below the left, right, and main content areas of the page')). The theme part of Drupal core (i.e., theme.module itself, not the individual themes) provides a standard UI that is displayed within config of *each theme* (but is one physical code base within theme.module) that allows the administrator to map blocks defined by Drupal core into regions defined by the theme, and storing that mapping as an theme-to-block_ID-to-region_ID (with weight) table in the database. From there, the actual page rendering is similar to what's being done now, but there is more of it. I guess what I'm trying to say is that the key to solving this problem is breaking it along its degrees of orthogonality, and there are three -- two in Drupal core and one in the individual theme. Scott [3] http://drupal.org//user/1517 ------------------------------------------------------------------------ April 17, 2005 - 03:14 : Dries Scott, is right. The theme should export its available regions. Then the administrator's task is to assign blocks to regions (not to setup regions). A theme could have configurable regions, but that internal to the theme. To me, the real challenge is the UI and the interaction design. Configuring blocks could easily become a real pain (while most themes continue to use 'left' and 'right'.) Of course, we can implement all the functionality, default everything to 'left' and 'right', and worry about the UI later. This should be fairly straightforward to implement and nedjo's patch looks like a first step in the right direction. ------------------------------------------------------------------------ April 17, 2005 - 17:09 : nedjo I agree with the suggested approach of themes registering their regions. I'd see this happening when a particular theme is activiated (or upgraded). Regions would be an array of names (e.g., 'left', 'right', 'footer'). New records would be created in the region table only for region names not previously registered. Some areas I'm not clear on, or that need further work: Table naming Should a new table be 'region' or 'regions' (I've used 'region')? I don't see a convention among existing table names, some of which are singular and others plural. Default values I've kept the existing '0' and '1' ids for regions (left and right, respectively), for backward compatibility. But this means we can't use autoincrement for the region id (rid), since autoincrements seem to begin with 1. Likely we should change to autogenerated ids. Initial records Using the INSERT INTO statements as I've done for the initial region entries is probably counterproductive, since sooner or later they'll have to be dynamically generated. I was hoping this could be a preliminary patch, with the main work coming later, but likely we need to solve region registration by themes before this patch is applied. I don't have a good idea of how region registration by themes would be implemented (a hook on theme activation?), and invite suggestions or implementations. Theme system changes Besides region registration, the other change I'm seeing that would be needed in the theme system is loading blocks by region name, rather than region id. This is because the ids currently used ('0' and '1') in theory might be diffferent on a particular install. ------------------------------------------------------------------------ April 17, 2005 - 17:18 : syscrusher Instead of having themes "register" their regions, why not just add a theme API hook called them_regions() that returns an associative array of $region_name=>t($region_helptext)? This would be in keeping with other similar API functions, such as those that return what permissions apply to a module or what node types are defined by a module. Most themes are going to define only a small number of regions (two being the typical case now, but I could see five or six in a complex theme), so returning a constant array will be faster than querying SQL to obtain an array of rows. There could be (optionally, at the discretion of whoever builds this thing) another API hook like theme_region_properties($region_name) that returns an associative array with detailed info for a given region, such as extended help text with recommended usage instructions for the region. Scott ------------------------------------------------------------------------ April 17, 2005 - 17:19 : syscrusher s/them_regions/theme_regions/g ------------------------------------------------------------------------ April 17, 2005 - 18:47 : adrian Because. The most common 'theme' is a phptemplate theme. And there needs to be a generic method for specifying the regions available, in a non hook_function format.. Themes get their names from the directory in which they are contained.. when copying the theme to another directory, there must be _no_ modifications necessary to allow normal usage. This is one of the tenets of the new template system I designed. You would need a standard way to define meta-information for themes, that does not need to be modified when copied to a new directory. We are working on this in the install system work, as you need a way external of Drupal to define the module dependencies and some other things. My approach would be to add a theme.dsc text file to the directory, which would allow you to specify meta-information. For instance : ---- regions: left, right, footer, center, mountie author: Johnny McAngstyPants ---- ------------------------------------------------------------------------ April 17, 2005 - 22:00 : syscrusher Adrian wrote: " Themes get their names from the directory in which they are contained.. when copying the theme to another directory, there must be _no_ modifications necessary to allow normal usage. This is one of the tenets of the new template system I designed. " A very good point. But region names don't have to be unique across different themes, so my hook function wouldn't have to be modified. The suggestion I made for the mapping metadata was three factors: theme ID or name, region ID or name, and block ID (plus one non-key weight value to order the blocks within a region, but this is not relevant here). I'm not familiar enough with PHP template to be able to respond to your comments on that one, so if you say it's not feasible to work with my schema, then I'll take your word for it. :-) Scott ------------------------------------------------------------------------ April 17, 2005 - 22:03 : syscrusher Oh, wait.....I see now what you mean! It's not the output of the function that is the problem, but the *name* of the function. Never mind. I concede your point. Scott ------------------------------------------------------------------------ April 18, 2005 - 03:44 : Jaza I'm probably jumping ahead a bit here... but something that this patch will have to eventually account for, is how to allow regions to be defined as inline. Allowing a theme to define a region's position as being anywhere on the edge of the page (i.e. top, left, right, bottom, corners, etc) is relatively easy. But what about having a region that's in the middle of a node's body, or somewhere else that's not the edge of the page? What I'm thinking of, is eventually allowing the custom region system to integrate with the CCK. Like I said, I admit that I'm jumping ahead into the future - the CCK still has a long way to go before it's ready. But ultimately, it would be cool if a theme could define a region as being after, say, the "rating" field in nodes of type "movie review". This would make the region (and the blocks in it) truly inline and in context with the actual content of the node. This would be a huge step forward compared to the current block system, which doesn't allow you to mix the presentation of blocks and nodes at all. In Drupal ATM, blocks and "the rest of the page" are totally separate, and really you have no choice but to display them as such. The result of this is that information in blocks that really should be displayed as part of a node, gets literally "pushed to the side", and always seems secondary to the actual content. Often the block has content that is just as important as the content of the node itself. Another option (of less merit, IMO - because of the extra maintenance work, and lack of enforced consistency) would be to have a region filter. You could then choose where to place an inline region on a per-node basis, by entering text such as [region:2] (example based on image_filter syntax) into the node body. Anyway, just thought I'd throw that idea into the open. I don't expect it will be implemented any time soon, but it's something to think about. Jeremy ------------------------------------------------------------------------ April 18, 2005 - 04:54 : stefan nagtegaal Attachment: http://drupal.org/files/issues/regions---possibility-1.png (1.29 KB) Imo the 'regions' are more than you guys name here.. FOr example I attached 2 screens which only shows you the regions.. What I think is that it should always be possible to have free names for the regions. No matter if i call - the region where my content appears in - 'content' or 'site items'.. See attached screens.. ------------------------------------------------------------------------ April 18, 2005 - 04:56 : stefan nagtegaal Attachment: http://drupal.org/files/issues/regions---possibility-2.png (1.39 KB) And the second... See these links: - http://drupal.org/files/issues/regions---possibility-1.png - http://drupal.org/files/issues/regions---possibility-2.png ------------------------------------------------------------------------ April 18, 2005 - 11:22 : nedjo Attachment: http://drupal.org/files/issues/block-dynamic-regions2.patch (13.39 KB) Here's a revised patch implementing some of the ideas so far. I've used the theme engine - rather than individual themes - to generate the list of available regions. I know this isn't ideal, but e.g. for xtemplate it's at present the only option--no logic is possible in the individual theme. region is changed to a varchar field from the current tinyint. I've roughed in several regions--really just for demo purposes. More thought and work would be needed to refine them (e.g., styling, etc.). But this maybe moves the conversation forward. ------------------------------------------------------------------------ April 18, 2005 - 17:26 : Dries This patch enables different regions to be used. That is a good thing. The next question is: should we take into account that different themes could assign blocks to different regions? Lots of problems would be solved if (i) there could only be one active theme on a website or (ii) if all themes would have a common set of regions. (This "let users select their own theme"-thing is a left-over from the early days, except for WAP stuff maybe.) ------------------------------------------------------------------------ April 18, 2005 - 17:37 : killes(a)www.drop.org Giving up multiple theme support would be a great thing. People could still select from multiple style sheets. WAP shoud not be a user preference setting, but automatically detected and redirected to a special site with a WAP theme. ------------------------------------------------------------------------ April 18, 2005 - 17:48 : adrian You would then lose the ability to make a special front page theme for use with the sections module, for instance. Also, currently styles exist in the same namespace as themes, and we would have to make more a distinction of styles vs templates (or themes), but I do think this could help simplify things.

1 0

[drupal-devel] [bug] Missing <div> container on HTML output
by moshe weitzman 21 Apr '05

21 Apr '05

Issue status update for http://drupal.org/node/20079 Project: Drupal Version: cvs Component: book.module Category: bug reports Priority: minor Assigned to: Anonymous Reported by: budda Updated by: moshe weitzman Status: patch Stefan - menus can be used anywhere. the user block is just the most common place to see one. that div is appropriate. moshe weitzman Previous comments: ------------------------------------------------------------------------ April 6, 2005 - 12:46 : budda Line 588 should be made to output the tree navigation within a container the same as the core navigation block - to keep consistent. new line 588: return '<div class="menu"><ul>'. $tree .'</ul></div>'; You are still able to format the book tree navigation different to the core navigation block as this tree is a child of css class 'book-block'. ------------------------------------------------------------------------ April 6, 2005 - 12:48 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/book_28.patch (558 bytes) Here's the patch. ------------------------------------------------------------------------ April 6, 2005 - 14:34 : Dries Where does Drupal core emit a class="menu" ? ------------------------------------------------------------------------ April 6, 2005 - 14:43 : jhriggs Line 89 of menu.module in menu_block(): $data['content'] = '<div class="menu">'. theme('menu_tree', $delta) .'</div>' ; Should the change maybe be made to theme_menu_tree() instead to take care of all of them at once? And if so, should the class be called "tree" rather than "menu"? ------------------------------------------------------------------------ April 7, 2005 - 04:26 : budda Class "tree" would be good. But would this change break any existing themes? Also - the tree menu is used within the book pages at the footer to show nested pages - so would you want that to be within the same class? ------------------------------------------------------------------------ April 7, 2005 - 07:23 : stefan nagtegaal Why don't we remove the menu-<div>?? We can style it using .block-user etc, right? Stefan.

1 0

[drupal-devel] Make image module an extension of upload module
by Robert Douglass 21 Apr '05

21 Apr '05

I love the new image modue. Is there any reason why it is adventageous to have images be nodes, and if so why don't we extend this to all of the files that we upload? A proposal: from my casual and not exhaustive reading of the image module code, it seems like the coupling to the node table is only very superficial. It would therefore be possible to extend the image module to respond to any images which come in as attachments via the upload module and process them in the same way that the image files attached to image nodes are processed. The two major changes which would need to be done to enable this are: 1) accept the file_api patch[1] which is in the queue and has a relatively strong amount of support 2) rewrite the image module queries which select on node.type='image' to files.filemime in (image/gif, image/png, image/jpeg). The advantages of doing this would be a more logical workflow, the end of images coming into the system but not being recognized as such, one fewer content types that users need to deal with and better support of mass uploading. The last point merits a little more attention as that is actually my impetus for bringing this up. I'm working on ways to upload multiple files from one screen, either via multiple upload forms or by uploading a .zip file which gets unpacked. While this should be relatively straightforward for attachments, for images it is hairier as the concept of an image node only accomodates 1 image. Welcoming thoughts and comments! Any advantages or disadvantages that I haven't thought of? Any technical problems that I haven't forseen? cheers, Robert [1] http://drupal.org/node/18934

5 6

[drupal-devel] lock tables not allowed by hosting
by Maykel Moya 21 Apr '05

21 Apr '05

My hosting doesn't allow me to lock tables in the mysql server. How much harmful will be to remove ever {LOCK,UNLOCK} TABLE in the code? Regards, maykel

2 1

[drupal-devel] [feature] Additional permissions for page module
by Syntoad 21 Apr '05

21 Apr '05

Issue status update for http://drupal.org/node/20977 Project: Drupal Version: 4.6.0 Component: page.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Syntoad Updated by: Syntoad -Status: active +Status: patch Forgot to set status to patch. Syntoad Previous comments: ------------------------------------------------------------------------ April 20, 2005 - 23:21 : Syntoad Attachment: http://drupal.org/files/issues/page_perms.diff (619 bytes) I am using drupal as a semi-wiki, and wanted all users to be able to edit any page, but didn't want to allow them to administer pages (gives access to too many other things such as configuring the front page) This patch will add the permission 'edit others pages' to the page module.

1 0

[drupal-devel] [bug] Request New Password Security
by Jose A Reyero 21 Apr '05

21 Apr '05

Issue status update for http://drupal.org/node/18719 Project: Drupal Version: cvs Component: user.module Category: bug reports Priority: critical Assigned to: Anonymous Reported by: neofactor Updated by: Jose A Reyero Status: patch Attachment: http://drupal.org/files/issues/user_one_time_login_5.patch (20.35 KB) Patch updated for HEAD Some changes: - Removed 'Last changed' field in user overview - Added some comments - Better wording for password recovery e-mail About e-mailing passwords, yes, we are e-mailing passwords, but only on user registration, so the user has both possibilities for first time login. And anyway it's up to the site admin to remove that password from the e-mail. Jose A Reyero Previous comments: ------------------------------------------------------------------------ March 11, 2005 - 03:52 : neofactor Problem: Any user can force another user's password to change... simply by selecting "request new password" and putting in their username. The user gets an email with the new.. but this feels like a violation to the user... and a pain. Solution? If someone requests a new password... Don't blindly change it... send an email that says...."Is this a real request authorized by you? Click here to confirm otherwise disregard this message" Please consider this critical for user by-in to Drupal as a secure system. I appreciate your consideration. http://drupal.org/node/18689 ------------------------------------------------------------------------ March 11, 2005 - 05:05 : neofactor I added some code to prevent the admin account from being reset... Please add as a patch. if ($account->uid == 1 { unset($account); form_set_error('name', t('Sorry. The username %name is not allowed to be changed.', array('%name' => '<em>'. $edit['name'] .'</em>'))); } // Just above this code on line 911: if ($account) { $from = variable_get('site_mail', ini_get('sendmail_from')); $pass = user_password(); ------------------------------------------------------------------------ March 11, 2005 - 05:08 : killes(a)www.drop.org Please only set to "patch" if you are actually submitting one. The solution you proposed is rather a workaround and will not be acceptable for core. ------------------------------------------------------------------------ March 11, 2005 - 09:21 : Deno I was in charge of a web site with >10000 paying customers for some time, and the "customers care" was constantly troubled with pasword change requests, until we switched to a system that worked in the following way: 1) "I forgot the password" function accepts either users email, or users login name, generates a random phrase, and adds an entry to "pasword_change_request" table. This entry consists of: - User ID (corresponding to email or login) - random phrase - datestamp User ID is unique key, and the entries in this table older than MAX_TIME are regularly purged by a cron job. 2) System sends an email with a link to "change forgotten password" page with this random phrase as argument to the user. That would be something like: https://drupal.org/user/cfp/d438rwiuodw894732ehdw 3) When user follows the link, "cfp" page checks if the random phrase exists in the table, allows the user to immediately change the password, and sends another email with "your password was changed on RIGHT_NOW ... " note to the user in question. - Password change automatically triggers deleting of the corresponding entry in pasword_change_request table. - Password change automatically logs-in the user as well. This way, users weren't bothered by accidental password changes, and they also understood the system better than the one with automatically generated passwords. For additional security, we also built some brakes that assured that the number of attempts to change the password, such as: - "An email with instructions was sent to you X minutes ago. In case you don't receive it within N hours, please contact the site administrator" - "According to our logs, you have visited the CFP page more than NMAX times within last 24 hours. For security reasons, you will be denied access to this page for the next 24 hours. Please contact the site administrator." hope this helps... ------------------------------------------------------------------------ March 30, 2005 - 21:01 : Jose A Reyero Attachment: http://drupal.org/files/issues/user_one_time_login.patch (6.52 KB) This patch for -cvs- addresses this issue. It generates an *only one use* URL to login into user account, instead of a new password. Then the user clicks on the URL, logs in, and may change his old password if desired. It is a only one use URL, and has some additional security measures, like a configurable time-out -can be confgured in admin/user/settings- and also, if somebody uses it or password is changed in the meanwhile, previously generated login URLs of this type won't work. About how it works, it creates a new url with: - user id, - timestamp - a hash of current timestamp, changed date for account, and the old password hashed With this patch, this wont work for admin accounts, which I think is better, you never know... It has a number of features like: - User can be ignoring these emails if somebody else is requesting access, a new password request wont change current password. However, the user will be warned when seeing the emails - It reveals no sensible information about the user account in the URL itself - the generated hash is not predictable at all if you dont know the old password, as it depends on user's old password - there's a configurable timeout - The URL's are only one use, as they depend on two timestamps, one of which will be changing in case this login is used -or in case user logs in for other means - Any 'new password' request is independent of others, so no one can be interfering with one user asking for his password back. Also doesn't require any new db field nor keeping track of requested passwords. ------------------------------------------------------------------------ March 30, 2005 - 21:41 : chx Very nice patch. Please consider for 4.6. ------------------------------------------------------------------------ March 30, 2005 - 23:16 : drumm Couldn't those nested if statements be made into one with a bit cleaner indentation? It looks like the page which the user arrives at after getting the new login information is their user page, not a page to set the password. The "Time out for password recovery e-mail" configuration is very unfriendly. It should be a drop down select of the most used human readable durations. Or we could just decide on one timeout and leave that hard coded in; who actually needs to use that setting? The url is quite long, what could be done to make it shorter? ------------------------------------------------------------------------ March 31, 2005 - 00:50 : Jose A Reyero /Couldn't those nested if statements be made into one with a bit cleaner indentation?/ Maybe, but I had to split that if conditions in two parts because the $account var didn't get the value before the rest of the conditions -latest two- where evaluated. Someone can help with PHP here? /It looks like the page which the user arrives at after getting the new login information is their user page, not a page to set the password. The "Time out for password recovery e-mail" configuration is very unfriendly. It should be a drop down select of the most used human readable durations. Or we could just decide on one timeout and leave that hard coded in; who actually needs to use that setting?/ Agreed, will be polishing this a little bit, just wating for some more suggestions... For the duration, I'll change to 'hours', ok? Just don't like to restrict options using unneccessary dropdowns, it's only intended for administrators anyway. Maybe I add also a '0' for unlimited. Hardcoding it, would need anyway to be mentioned in the module help, so it's about the same overhead, both for coding and for the admin interface, and harcoding in two places in code is not good anyway. And I like having options, am I the only one? / The url is quite long, what could be done to make it shorter?/ Well, the url has to be long, it has neccessary params and an MD5 hash, which yes, could be cut someway, but that adding inneccessary code and also reducing security -though half an MD5 hash may be secure enough- but I see no point in that. ------------------------------------------------------------------------ March 31, 2005 - 02:18 : FactoryJoe(a)civicspacelabs.org "Or we could just decide on one timeout and leave that hard coded in; who actually needs to use that setting? " +1 for making this *not* configurable! C'mon, Drupal should have standards about security -- and if best practices say that, say, 8 hours, is a good amount of time for that URL to be active, then do that. Cut out the confusion and extra brain juice it takes to decide... "Gee, is 4 hours better than 5?" Additionally, there's a simple way to make this workflow better for the user. If you visit an outdated change password URL, you should be told, "Sorry, but that link you followed to change your password has expired. If you would like to reset your password, please fill out this form: [form] If you did not request to change your password, please notify [administrator's name w/ PM link]". This way, if you missed your change password deadline, you can request your password again right from the timeout page. If you didn't request the change, it will be obvious that someone else was trying to change it, and then you can contact the administrator and find out who it was that was messin' with your account. ------------------------------------------------------------------------ March 31, 2005 - 06:55 : chx Attachment: http://drupal.org/files/issues/user_one_time_login_0.patch (4.72 KB) I cleaned up the patch a bit. I hope code style is OK. So may -- there are no checks against the arguments? There is no need. user_load uses %d for 'uid', so that's dealt with. Comparison by < and > means an implicit cast to integer, so $timestamp is also dealt with automatically. I do not think timeout needs to be configured. Please comment on not letting uid 1 using this one. I am not sure whether this is necessary. ------------------------------------------------------------------------ March 31, 2005 - 07:12 : chx Attachment: http://drupal.org/files/issues/user_one_time_login_1.patch (6.21 KB) Implemented Chris' idea, so if you use a one time URl which is expired, you are sent to user/password with a message to ask for another. I changed a few messages and deleted the "not for admin" feature. Do we really want one gazillion support requests "I locked myself out of my site, user/password tells me not for admin, what now"? ------------------------------------------------------------------------ March 31, 2005 - 08:24 : chx One more point on uid 1. Yes, uid 1 can reset his pwd over the database. But then we would need to lock out administer users privileged users. Then administer nodes, 'cos of XSS. Then administer comments... then administer filters... OK, this is pointless. If someone can eavesdrop on your emails, everything is lost, I think. This is not something Drupal shall address. Maybe we could employ a security question -- secret answer pair. ------------------------------------------------------------------------ March 31, 2005 - 11:52 : Bèr Kessels Eventhough I am a less-settings advocate, I think this must remain a setting :). Why? Sites on Drupal differ a lot, and have a very differnet userbase. I run very low level sites, where it sometimes takes days before someone will read his/her mail. But I also know sites (drupal.org) where days would certainly be too long. Sorry Chris et al, I +1 on configurable duration. (hell, we really need some about:config alike screen in drupal) ------------------------------------------------------------------------ March 31, 2005 - 12:46 : Dries IMO, that setting has nothing to do with a site being "low level". If you request a new password, you probably want to login ASAP. I vote against a configuration option. Either way, this patch needs work: 1. We don't glue words together (eg. $hashedpass, $currenttime, $loginurl). Similarly, I suggest to change 'user/newpassword' to 'user/reset' or 'user/request-password'. 2. The patch exposes technical details to the user; terminology like "one time login URL" is likely to confuse many users. 3. The login URL is not clean URL safe, I think. 4. Please rename the variable $pass1 in user_pass_rehash(). 5. The code comments are often inconsistent. Some end with a punctuation, some don't. Some span two lines, others don't. On a related note, can't we reuse this system for the initial password? That is, instead of mailing a password, we mail an URL and force the user to enter a password. ------------------------------------------------------------------------ March 31, 2005 - 18:20 : Jose A Reyero Attachment: http://drupal.org/files/issues/user_one_time_login_2.patch (12.77 KB) Ok, I've started with chx's reviewed patch, and done most of Dries suggestions Main changes are: ----------------------- - Rewording, variable names, path, etc... as pointed out by Dries. Now it's user/reset. And yes, it was not clean-URL safe; it is now. - Allowed also for admin account, I dont like it though, but seem to be the only one :( - Used also for user registration, but I also kept old style login/password, think it can be some use and anyway, it's up to the site admin to remove it from the welcome e-mail. However it is only for 'no admin approval', see below about this.... - Added back in the config option for time-out, though reworked completely for usability. Default is '1 day' which I think should be reasonable. However, there's no time out for firts time users. About this, read below, please... ----------------------- Using this for first time login has some problems when admin aproval is required, as the hashed pass depends on 'changed' timestamp, and it changes when the admin approves an account. Actually, there's no way to know -or I didn't find it- when it is the first login for an approved account. For no admin approval, I just used 'changed' == 'created' as a criterium. I think we should be separating this changed date and last login date creating a new field in the user table, but that maybe for a future patch. That would also increase security, as the Administrator's info would be more accurate, and 'last login date' could be shown when user logs in, which is also security+ Related with this I've experienced problems, as administrator, when editing user accounts, then last login info for the users gets lost -is reset-... About the config option for time out, though I agree that enforcing security can be good in general, this is one of this cases where more security means less usability. And that decission should be left to Site administrators -each site has its own security requirements-. So I think the target here should be a 'reasonable' default, and then some flexibility for site admins. IMHO this latest patch is quite well balanced. So... everybody happy? ------------------------------------------------------------------------ March 31, 2005 - 20:43 : Dries "So ... everyone happy?" Not quite. The patch is an improvement but it uses tabs, incorrect spacing, incorrect placement of brackets, and does not use theme('placeholder'). If a new database column is required to implement this properly, please add one. This patch won't get committed until it is implemented properly. I still vote to remove the configuration option. We're getting there ... ------------------------------------------------------------------------ April 2, 2005 - 19:45 : factoryjoe I’m going to have to stick by my earlier assertion on this one, and, and, as with most usability issues, none of us are “correct” until we test it 50 times and see whether anyone actually uses the option. Just like with my folksonomy review [1], more options is *not always better* nor does it always help people *get things done*! To further expand this point, Jose says [2]: About the config option for time out, though I agree that enforcing security can be good in general, this is one of this cases where more security means less usability. And that decission should be left to Site administrators -each site has its own security requirements. " But this is a misuse of the term “usability”. What you’re talking about is *functionality*—since usability has more to do with focusing single-mindedly on the task at hand and reducing distraction than it does with providing extraneous options that might be useful for a fraction of all Drupal admins. To speak to Ber’s point [3], I cannot imagine a situation where, if I want to change my password because I’ve forgotten it, that it will take more than a few hours to get the email and fulfill the process. And even still, if it does — for whatever reason — take me a week to get around to resetting my password, then starting the process over again isn’t all that time consuming. Plus, I have the added sense of security that Drupal doesn’t let things like password resetting links stay active forever! So again, I agree that we need a reasonable default—24 hours is very generous for the singular task that we’re trying to serve here, which is, to my knowledge, to make the process for resetting your password easier and more secure. Lastly, about the patch itself: I noticed a couple <em> tags strewn around in lines 38, 43, 54 and 72 (as well as a <strong> on 54). Until we have a style guide for marking up usernames, should we really be using HTML like this? It seems to be that it would be better to use a span with a class of… say… “username” and let the themer determine whether the username should be bold, italicized, red, all caps and so on.*/ [1] http://drupal.org/node/19697#comment-25599 [2] http://drupal.org/node/18719#comment-25480 [3] http://drupal.org/node/18719#comment-25463 ------------------------------------------------------------------------ April 2, 2005 - 21:29 : factoryjoe One other quick question. How does this patch interact with distributed authentication? If I'm logged in with a remote account and ask to reset my password, what happens? ------------------------------------------------------------------------ April 3, 2005 - 10:22 : Dries factoryjoe: you can't reset your password when you are logged in. ------------------------------------------------------------------------ April 3, 2005 - 14:03 : Jose A Reyero About usability I've written this piece [4], so I really prefer to discuss it on the forums... That patch, I'll be cleaning it up a little bit, adding that last login field, and maybe go for that 'reasonable default', which anyway is not worth so much discussion.... [4] http://drupal.org/node/19918 ------------------------------------------------------------------------ April 5, 2005 - 01:20 : Jose A Reyero Attachment: http://drupal.org/files/issues/user_one_time_login_3.patch (20.26 KB) Ok, lets try to make people happy, which will be good for my karma, I hope so ;-) So, changes: - Added 'lastlogin' field to user table. Now there's one timestamp for when an account is edited and another one for login. Of course, I've also taken care of the user's admin page. - Some small detail like help text for e-mail fields and that. - Now it can be used also for accounts with admin approval. - And yes, removed config option, 1 day time out for password recovery, no time out for first login. By the way, I've also patched db files for PostgreSQL, please someone review it, I don't know too much about it. The default e-mails may need better wording. Specially the one for password recovery which just says 'You have requested a new password', but I dont want users get too worried in case someone else has requested that password and the old one that said something like 'This is your new login information..' which may suggest it has been sent by the admin maybe updating accounts..... Anyway, every site admin can configure that email... As an idea for the future or for someone else - I've had enough for now with logging in 100 times to try this-, now that we can know when it is the first login for an user, a nice welcome message or welcome screen would be great :-) Or if someone wants to go for better security *nix style, some message telling the user when last logged in wouldn't be bad... So... ? ------------------------------------------------------------------------ April 5, 2005 - 01:51 : factoryjoe +1 lastlogin time. Also, I just lost my admin password for WP and these are the emails I received at each stage of the process (email titles in bold): *[FactoryCity] Password Reset* "Someone has asked to reset a password for the login this site http://www.factorycity.net/blog [5] Login: admin To reset your password visit the following address, otherwise just ignore this email and nothing will happen. http://www.factorycity.net/blog/wp-login.php?action=resetpass&key=XXXXXf4xx… " *[FactoryCity] Your new password* " Login: admin Password: XxXxXxX http://www.factorycity.net/blog/wp-login.php " *[FactoryCity] Password Lost/Change* "Password Lost and Changed for user: admin " [5] http://www.factorycity.net/blog ------------------------------------------------------------------------ April 6, 2005 - 20:39 : Dries Good job. Some more remarks: - Don't glue words together. Please use 'login' instead of 'lastlogin'. - Write 'administrator' not 'admin'. - You capitalized some random 'subjects' (eg. those in the form's help text). ------------------------------------------------------------------------ April 7, 2005 - 17:30 : Jose A Reyero Attachment: http://drupal.org/files/issues/user_one_time_login_4.patch (20.28 KB) Replaced 'lastlogin' by 'login', 'admin' by 'administrator' Dries, about the "You capitalized some random 'subjects'", no clue what you are talking about... ? ------------------------------------------------------------------------ April 14, 2005 - 11:32 : jacusah Will this patch be added to the core? ------------------------------------------------------------------------ April 15, 2005 - 20:08 : bloggator I can't seem to get this patch to work without problems. Once I've installed it, when I try to go to my account, I get a 404 error. I'm running 4.52 and I tried both the file versions of user.module and updates.inc mentioned in the patch and the latest versions in the cvs and no dice. Everything seems to be fine with the database change and the updates.inc file. When I add the new user.module, that's when things go wonky. ------------------------------------------------------------------------ April 16, 2005 - 12:24 : Jose A Reyero bloggator, this is not a patch for 4.5 !!! ------------------------------------------------------------------------ April 16, 2005 - 12:38 : Dries One more round of revisions before this patch can go in: - The patch no longer applies because of earlier changes. - Don't add a column to the user overview page. The overview should show when the user has been 'last seen' (last activity). - From looking at the patch, it seems we are still e-mailing passwords? - Some status messages could do with being made simpler -- not critical at this point. - Some of the new functions could do with having some minimal phpdoc. Thanks. ------------------------------------------------------------------------ April 17, 2005 - 06:33 : bloggator /bloggator, this is not a patch for 4.5 !!! Thanks, Jose. I'm still getting used to how everything works around here. Best regards, Jeff

1 0

[drupal-devel] Path system scaleability
by Adrian Rossouw 21 Apr '05

21 Apr '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've recently found myself incredibly impressed with the autopath module, but I realize that there is an inherent scaleability issue with how we do paths at the moment. On every page load, the entire url_alias table is loaded into memory, and enabling the autopath module on a site like Drupal.org with thousands upon thousands of nodes, is just impractical. Does anyone have an idea of how we could make the path system easier to use for large sites? - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCZPIagegMqdGlkasRAsYLAJ0TBqKVHU+3QL9J2TgdVar/r2LHqgCfbmWu zINs3OqZ7AO3lHFYCIMDHOY= =7IEu -----END PGP SIGNATURE-----

5 8

[drupal-devel] Drupal.org infrastructure
by Dries Buytaert 21 Apr '05

21 Apr '05

As you might have seen, we occasionally get "too many connections" problems on drupal.org. During peak hours the load of the machine occasionally spikes to 10+. After such a burst, the load drops back below 2-3. Most of the day, the load is just below 1 though. I haven't investigated the problem yet but I figured I would let you know. For a few days now, I tried to get hold of Kjartan who administers the machine. It looks like he is traveling so I hope he gets back to us shortly. Know that we haven't properly configured the machine yet (it uses all the default settings) so chances are we get a long way by properly tuning the various configuration parameters. In fact, I don't even know whether we have PHP cache/optimizing installed. Clearly, we will have to look into that ASAP. -- Dries Buytaert :: http://www.buytaert.net/

5 7

[drupal-devel] Release critical bugs for April 21, 2005
by drupal-devel＠drupal.org 21 Apr '05

21 Apr '05

Bbcode / bug reports email spam filtering does not "see" email addresses when they are NOT preceded by a word age: 13 weeks 4 days url: http://drupal.org/node/15654 Drupal / bug reports Teaser problem assigned: childhood age: 1 day 15 hours url: http://drupal.org/node/20843 Comment.module fails to automatically extract the subject from the body. age: 2 days 19 hours url: http://drupal.org/node/20736 UTF-8 node title gets truncated at wrong position age: 5 days 21 hours url: http://drupal.org/node/20537 database table "term_node" not updated when removing a term from a node under editing and submitting age: 1 week 2 days url: http://drupal.org/node/20315 Attached files can not be deleted age: 1 week 2 days url: http://drupal.org/node/20307 Reassigning a node to a different term does not work properly age: 1 week 3 days url: http://drupal.org/node/20278 4.6 aggregator showing/not interpreting HTML tags age: 2 weeks 4 days url: http://drupal.org/node/19874 Search ranking broken on pgsql age: 3 weeks 1 day url: http://drupal.org/node/19629 New submit error, non-admin user, postgresql database assigned: adrian age: 6 weeks 1 day url: http://drupal.org/node/18552 When I delete a user, any forum in which s/he has commented also disappears. assigned: Jill6q age: 9 weeks 7 hours url: http://drupal.org/node/17428 Published poll doesnt show up in poll block if in submission queue age: 10 weeks 6 days url: http://drupal.org/node/16671 Change to sesssion.inc violates UID database constraint age: 13 weeks 4 days url: http://drupal.org/node/15666 forum.module problem with postgresql v7.4.1 age: 14 weeks 2 days url: http://drupal.org/node/15411 PHP 5 gives error when session table has no session assigned: adschar age: 14 weeks 2 days url: http://drupal.org/node/15399 postgresql error age: 15 weeks 2 hours url: http://drupal.org/node/15175 Entering an empty title broke drupal age: 22 weeks 2 days url: http://drupal.org/node/12974 Argument NOT must be type boolean age: 22 weeks 2 days url: http://drupal.org/node/12950 Comments in approval queue still show up in tracker age: 26 weeks 4 days url: http://drupal.org/node/11647 Twin problems with comments assigned: Junyor age: 27 weeks 6 days url: http://drupal.org/node/11366 Drupal / feature requests Add a footer that is specific to a particular book, shown only on certain pages age: 2 weeks 6 days url: http://drupal.org/node/19757 moving pages en masse age: 2 weeks 6 days url: http://drupal.org/node/19754 Taxonomy module should use nodeapi 'load' age: 6 weeks 7 hours url: http://drupal.org/node/18631 Auto PHP memory maximisation age: 8 weeks 2 days url: http://drupal.org/node/17663 Don't reset existing password on request, prevent DoS password reset abuse age: 10 weeks 2 days url: http://drupal.org/node/16909 User info exposed to anonymous user age: 20 weeks 5 days url: http://drupal.org/node/13545 Allow named anchors to work without specifying full path to node age: 1 year 21 weeks url: http://drupal.org/node/4213 Drupal / support requests Fatal error: Call to undefined function: pg_query() in /includes/database.pgsql.inc on line 104 age: 1 hour 8 min url: http://drupal.org/node/20969 Fatal error: Unknown column 'headers' in 'field list' query assigned: Eagle-i age: 5 weeks 1 day url: http://drupal.org/node/18928 Strange session behavior age: 5 weeks 3 days url: http://drupal.org/node/18821 user redirected to homepage when logging in age: 6 weeks 5 days url: http://drupal.org/node/18381 Problem with Forums age: 14 weeks 4 days url: http://drupal.org/node/15299 Drupal / tasks atom.module working version to 4.5.0 assigned: hugoromano age: 24 weeks 10 hours url: http://drupal.org/node/12496 Consistency assigned: stefan nagtegaal age: 29 weeks 5 days url: http://drupal.org/node/11045 Drupal.org maintenance / bug reports www.drupal.org - Too many connections error. age: 1 week 1 day url: http://drupal.org/node/20370 Website search broken with some terms age: 2 weeks 2 days url: http://drupal.org/node/19956 drupaldocs.org and large fonts age: 6 weeks 5 days url: http://drupal.org/node/18367 Drupal.org print preview crashes Mozilla age: 7 weeks 12 hours url: http://drupal.org/node/18248 Konqueror problem age: 10 weeks 2 days url: http://drupal.org/node/16913 screenshots : page not found age: 10 weeks 5 days url: http://drupal.org/node/16752 Large Fonts problems age: 10 weeks 6 days url: http://drupal.org/node/16664 Drupal.org maintenance / feature requests Plain text posting age: 9 weeks 2 days url: http://drupal.org/node/17335 Drupal.org maintenance / tasks Prune the viewCVS display of Contrib repository age: 1 year 47 weeks url: http://drupal.org/node/1734 Event / bug reports Events show in wrong month age: 1 week 1 day url: http://drupal.org/node/20378 Timezone improperly applied to new events age: 1 week 4 days url: http://drupal.org/node/20239 Convert node type on upgrade assigned: crunchywelch age: 1 week 4 days url: http://drupal.org/node/20234 Events for March 31, 2005 not showing up in calendar view age: 5 weeks 2 days url: http://drupal.org/node/18885 search over fields.inc fields conceptual error age: 24 weeks 6 days url: http://drupal.org/node/12259 fields.inc screws up with multible multiselect fields age: 24 weeks 6 days url: http://drupal.org/node/12257 Still GMT/TZ issues with CVS age: 25 weeks 6 days url: http://drupal.org/node/11870 Time entry is GMT even when site default is not age: 26 weeks 4 days url: http://drupal.org/node/11630 Start Time of Event is NOT Preserved age: 43 weeks 6 days url: http://drupal.org/node/8565 Feature / bug reports Menu item not showing age: 28 weeks 5 days url: http://drupal.org/node/11210 File / bug reports segmentation fault related to filestore age: 1 year 29 weeks url: http://drupal.org/node/3001 Filestore / support requests File store module - Overwriting Filename....Help needed assigned: harishkm age: 1 year 2 weeks url: http://drupal.org/node/6827 Unserialize error at line 104 age: 1 year 9 weeks url: http://drupal.org/node/5857 Filestore module- sql errors rectified assigned: harishkm age: 1 year 10 weeks url: http://drupal.org/node/5619 Filestore Module Problems unaddressed assigned: harishkm age: 1 year 12 weeks url: http://drupal.org/node/5365 Gallery / bug reports no images displayed in drupal 4.6-RC but they are displayed by gallery2 age: 3 weeks 5 days url: http://drupal.org/node/19467 Fatal Error: variable_get() age: 4 weeks 3 days url: http://drupal.org/node/19189 No Gallery Image Block age: 4 weeks 6 days url: http://drupal.org/node/19045 Mini applet can't find gallery at url / age: 5 weeks 4 days url: http://drupal.org/node/18785 Fatal error: Undefined class name 'galleryembed' age: 8 weeks 1 day url: http://drupal.org/node/17746 Gallery / support requests Can't Embed Gallery into Drupal age: 7 weeks 3 days url: http://drupal.org/node/18029 Groups / bug reports Drupal-4.4-rc breaks registration setups and groups.module age: 1 year 5 weeks url: http://drupal.org/node/6392 Image / bug reports Cannot upload .jpgs age: 7 weeks 3 days url: http://drupal.org/node/18076 Wrongly formed html in image gallery age: 8 weeks 6 days url: http://drupal.org/node/17462 Image.Module does not know the correct filename age: 22 weeks 1 day url: http://drupal.org/node/13032 SAFE MODE Restriction in effect... age: 25 weeks 6 days url: http://drupal.org/node/11843 Uploading jpeg makes Imagemagick do high compression age: 27 weeks 3 days url: http://drupal.org/node/11445 Image module failing on Preview because of a blank node id age: 29 weeks 4 days url: http://drupal.org/node/11069 Similar problem with Directory Upload Slow age: 29 weeks 4 days url: http://drupal.org/node/11064 Members / bug reports Suggested Menu Item empty age: 7 hours 8 min url: http://drupal.org/node/20940 Node (key)words / bug reports Fatal error on logout - only when "cache" enabled age: 1 week 5 days url: http://drupal.org/node/20174 Node Aggregator / bug reports Please update Node_Aggregator age: 4 weeks 5 days url: http://drupal.org/node/19096 Import doesn't like XML/RSS feeds with no Title element age: 46 weeks 4 days url: http://drupal.org/node/8128 Node Aggregator / feature requests RSS items overwriting edited items age: 44 weeks 5 days url: http://drupal.org/node/8455 Notify / feature requests Notify.module ignores the true submission queue age: 1 year 25 weeks url: http://drupal.org/node/3765 Online / support requests Need Help age: 8 weeks 6 days url: http://drupal.org/node/17475 Pdfview / feature requests Internationalization support for PDF assigned: TheLibrarian age: 1 year 3 weeks url: http://drupal.org/node/6795 Project / bug reports Date for latest is incorrect age: 6 days 18 hours url: http://drupal.org/node/20485 Invalid link to release files age: 8 weeks 3 days url: http://drupal.org/node/17625 blank page after install age: 11 weeks 1 day url: http://drupal.org/node/16575 "Page Not Found" when trying to view issues or add new release age: 19 weeks 6 days url: http://drupal.org/node/13815 Project pages display only title and description age: 22 weeks 5 hours url: http://drupal.org/node/13082 Fatal error: Cannot use string offset as an array in includes/tablesort.inc on line 113 assigned: publian age: 28 weeks 6 days url: http://drupal.org/node/11187 Can't create new project with issue tracker age: 35 weeks 19 hours url: http://drupal.org/node/10148 Project / support requests Help with everything - nothing seems to work in the latest build age: 21 weeks 2 days url: http://drupal.org/node/13310 Taxonomy dhtml / bug reports MySQL Error age: 3 weeks 5 days url: http://drupal.org/node/19413 javascrip downloads square.gif for every category age: 9 weeks 1 day url: http://drupal.org/node/17366 TrackBack / bug reports Sends trackbacks for unpublished nodes age: 12 weeks 6 hours url: http://drupal.org/node/16239 trackback borks google and every other search engine age: 24 weeks 2 days url: http://drupal.org/node/12388 User experience / bug reports user interface problem http://drupal.org/forum/1?from=25 age: 7 weeks 17 hours url: http://drupal.org/node/18237 User experience / tasks WorkFlow and Action Module age: 8 weeks 5 days url: http://drupal.org/node/17517 Weblink / bug reports drupal special chars error age: 3 days 8 hours url: http://drupal.org/node/20687

1 0

[drupal-devel] Drupal.org: updates
by Dries Buytaert 20 Apr '05

20 Apr '05

Hello world, thanks to Steven and James, I could upgrade the image.module on drupal.org. As a result, the screenshot repository is back. In addition, I've made a 'themes gallery' where we can showcase themes. Adrian provided some screenshots. Check it out at: http://drupal.org/image/tid/39 Also, the CVS tracker for the Drupal project should be fixed. We still have to import the missing commit messages but at least you can keep track of new changes. -- Dries Buytaert :: http://www.buytaert.net/

1 0