April 2005 - Development - lists.drupal.org

[drupal-devel] [bug] updates.inc - missing db prefix braces
by robertDouglass 16 Apr '05

16 Apr '05

Issue status update for http://drupal.org/node/20615 Project: Drupal Version: 4.6.0 Component: base system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: robertDouglass Updated by: robertDouglass Status: patch Attachment: http://drupal.org/files/issues/updateinc.txt (912 bytes) the sessions table update is missing {} robertDouglass

1 0

[drupal-devel] Re: Drupal 4.6.0 released
by K B 16 Apr '05

16 Apr '05

Congrats everyone! This is a great release with great features. > Problem is that no theme engines and translations are listed, although > the phptemplate engine is already released for 4.6, and the translation > templates and the hungarian translation is relesed since some days now. > They are not listed on the download page under 4.6! No themes are > released so far, which is interesting, since (basic) themes only need > some small fixes. Goba is right. I tagged three themes (Lincoln's Revenge, SpreadFireFox, and Democratica) with the DRUPAL-4-6, but now I can't see the tag. I retagged them. My contrib modules I have tagged in the past show up fine though.

2 1

[drupal-devel] Re: Database analysis of CivicSpace/Drupal
by Kieran Lal 16 Apr '05

16 Apr '05

I'd be happy to debate anyone in the community on the merits of relational databases versus other data stores for applications. It's not just the relational structure but the overwhelming infrastructure of developers, design tools, data reporting capabilities, and widely available expertise that overwhelms other data management methods. The evolution from hierarchical, to relational, to network databases(Object, XML) has been run through multiple times over the last 4 decades. Every time relational wins hands down. Cheers, Kieran On Apr 15, 2005, at 7:39 PM, Anselm Hook wrote: > > I had the pleasure of working with an rdf based datastore on another > project and one of the things that strikes me about the difference > between > relational databases and rdf datastores is the surprising elegance of > rdf > in terms of back end queries for a developer. > > In an rdf datastore such as redland there is only one 'table' in a > sense - > or best thought of as just a list of subjects. You might have subjects > that describe posts, stories, people, other objects - but these do not > require separate tables. You can decorate any subject (or 'key') with > any > field - and all fields are first class citizens - wheras in drupal many > fields are tacked into a kind of varchar bucket. Reconstituting an > object > in drupal involves calling methods that know about that object. In > redland you just ask for all the values with the given subject key. > > Just a comment in any case; not meant to be a troll that incites > lengthy > aimless discussion... :-) Feel free to mail me directly though if you > think this is a horrible generalization on my part - since I do not > want > to bog the list with what is effectively a troll. I agree it is > obviously not possible to change architectures at this low a level in > drupal - although I do note that IndyVoter is going the RDF route. > > - a > > > On Fri, 15 Apr 2005, Kieran Lal wrote: > >> How about that 68 fields involved in JOINs are not indexed? >> >> So every time there is a join operation the database has to do search >> through every record on that field. Of course, if I had just waited >> until people thought it was a problem we wouldn't know it was a >> problem >> ;-) >> >> Kieran >> On Apr 15, 2005, at 6:36 PM, Dan Robinson wrote: >> >>> what problem are we trying to solve here? >>> >>> Dan >>> >>>> There are currently 107 database tables in the latest release of >>>> CivicSpace. I believe there are 55 in Drupal core. One of the most >>>> important things you can do in improving database performance is to >>>> make sure you have the right indicies for your database. Currently >>>> we >>>> do not use foriegn keys to enforce relationships between database >>>> tables. I did an analysis of the CivicSpace code base and found >>>> that >>>> there was 156 SQL statements with at least one JOIN. We can consider >>>> these as application level relationships between tables. Here is a >>>> visual representation of those JOINs: >>>> http://civicspacelabs.org/home/files/schema.png I also analysed the >>>> indicies of the current database schema. There are 182 indicies. >>>> >>>> The question was do they match? The answer was no. >>>> >>>> There are at least 68 fields that are joined which do not have >>>> indicies from my initial analysis. Here are the fields in my blog >>>> post: >>>> http://civicspacelabs.org/home/node/12245 >>>> >>>> The scientific method teaches us that results are useless, unless >>>> you >>>> have a repeatable method. I am going to explain in this book( >>>> http://civicspacelabs.org/home/node/12246 ), Drupal-Docs folks, how >>>> I >>>> conducted this analysis and it needs to be repeated and verified >>>> before being acted upon. I built several tools with help from Drumm, >>>> Ankur, Tom Eliaz, and Chris Johnson(cxj). It's possible those tools >>>> ran amok. >>>> >>>> This is the first step in what I hope will be a continued analysis >>>> of >>>> the database layer in Drupal. The next step will be to extend >>>> devel.module to do batch updates of page executions times and mysql >>>> query times. I have several theories about how to do this properly >>>> and would appreciate your input. The final stage will be to create a >>>> documented database schema that allows for external application >>>> integration with common labels. If we want to integrate with >>>> non-drupal applications we will have to allow for semantic mapping >>>> of >>>> our database schema to a common database bus architecture(See Ralph >>>> Kimball http://www.rkimball.com/) But I'lll leave that for another >>>> discussion. >>>> >>>> Cheers, >>>> Kieran >>>> >>>> P.S. I am off to go mountain biking, hiking, and kayaking in Hawaii >>>> for a week so don't expect too many responses from me. >>>> >>>> >>>> -------------------------------------------------------------------- >>>> - >>>> To unsubscribe, e-mail: >>>> civicspace-dev-unsubscribe(a)civicspacelabs.org >>>> For additional commands, e-mail: >>>> civicspace-dev-help(a)civicspacelabs.org >>>> >>>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: civicspace-dev-unsubscribe(a)civicspacelabs.org >> For additional commands, e-mail: >> civicspace-dev-help(a)civicspacelabs.org >> >> > >

1 0

[drupal-devel] [bug] Create forum topic not inserting in forum
by joe 15 Apr '05

15 Apr '05

Issue status update for http://drupal.org/node/19562 Project: Drupal Version: cvs Component: forum.module Category: bug reports Priority: normal Assigned to: joe(a)www.joepilot.net Reported by: joe(a)www.joepilot.net Updated by: joe(a)www.joepilot.net Status: active This is a problem I've been trying to figure out for a while, but have gotten almost nowhere. For starters, I am using PostgreSQL in case that is an issue. In any case, when I create a forum topic using the link in that forum, the tid is not recorded when the topic is created. Thus, the topic is created with a tid of 0 and doesn't appear in any forum. I fixed this issue by adding the following code to the top of the "forum_validate" function. if (!$node->nid) { // new topic $node->taxonomy[] = arg(3); } else { $node->taxonomy = array($node->tid); } This takes care of adding topics to forums using the link on the forum page. It is just a little hack for now and is not meant to fix the core issue. Unfortunately, the taxonomy selector is still not shown and if the user selects "forum topic" from the "create content" menu, they may create a forum topic that isn't in a forum. This may stem from a PostgreSQL issue with the taxonomy module. This seems to be an issue with any module that deals with it's own "private" taxonomy, as in the forum module and the new image module. joe(a)www.joepilot.net

4 5

[drupal-devel] [bug] Error with file api and open_basedir restriction
by mpd 15 Apr '05

15 Apr '05

Issue status update for http://drupal.org/node/5961 Project: Drupal Version: cvs Component: node system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: Jose A Reyero Updated by: mpd Status: patch Attachment: http://drupal.org/files/issues/file.inc-file_relocate.patch (3.87 KB) I gave your patch a try. It applies fine but doesn't address several issues, particularily with the image module. The attached patch makes attachments work, along with image (from cvs). I haven't seen any ill effects yet, but I believe that file_delete must be used to avoid getting a build-up of dead files in the local temporary directory (set to getcwd().'/tmp'). This isn't a problem with my install, but it might be a problem with other modules. In order for the patched code to work, $drupal/tmp must exist and be writable by the web server. mpd Previous comments: ------------------------------------------------------------------------ February 20, 2004 - 11:45 : Jose A Reyero Attachment: http://drupal.org/files/issues/file-open-basedir.patch (1018 bytes) I get this error when uploading a file through the file api, and the upload fails: warning: open_basedir restriction in effect. File is in wrong directory in... This happens when open_basedir restriction is activated and the temporary directory is not in the allowed directories. There's a related bug in the profile.module: http://drupal.org/node/view/2648 [1] FIX: The solution is to upload files using php's 'move_uploaded_file' -which works even when open_basedir restriction is in effect. This patch checks for the error conditions in 'file.inc::file_check_upload', and then uses move_uploaded_file to upload the file to the temporary folder with a random name. Otherwise -if the error conditions are not met-, does nothing. RESTRICTIONS: This patch introduces one additional restriction for the file api: Once you have called 'file_check_upload', you have to use the returned object when calling later 'file.api::file_save_upload'. This shouldn't be a problem, as the right way to upload files should be -I think, please correct me if I'm wrong-: - $file=file_check_upload(); - (Perform validations with $file) - file_save_upload($file,.....) I will post also a very simple patch for profile.module to work with this one. Anyway, as mentioned above, if the error conditions are not met, the patch does nothing, so I think it should be applied first and then check for other modules (profile.module) to use the file api the right way and then be able to upload files when open_basedir restriction in effect. [1] http://drupal.org/node/view/2648 ------------------------------------------------------------------------ November 28, 2004 - 09:38 : Goba This seems to be an interesting alternate fix to my dump patch for locale.module [2], which is the very same issue... Moving the file out of the upload folder right away to the Drupal temp folder seems to be a good idea to me. The only caveat is that files in the upload folder get removed automatically, while one needs to remove the file from the Drupal temp folder, once it is not needed anymore! [2] http://drupal.org/node/13285 ------------------------------------------------------------------------ December 8, 2004 - 11:26 : Goba Please look at this stuff. We need to solve open_basedir problems at least in core before the next point release. There are quite a few users trying to use Drupal on shared hosting here, where open_basedir is in effect. ------------------------------------------------------------------------ February 17, 2005 - 17:55 : clydefrog This functionality gets a +1 from me, the user. We solved this problem by changing upload_tmp_dir in the server config, but a fix in Drupal would be more elegant. ------------------------------------------------------------------------ March 13, 2005 - 11:41 : killes(a)www.drop.org Doesn't apply anymore. ------------------------------------------------------------------------ March 14, 2005 - 03:05 : Jose A Reyero Attachment: http://drupal.org/files/issues/file-open-basedir_02.patch (810 bytes) Just resubmitted the patch. The problem is, from the time I sent the first patch , I've moved all my sites, no shared webhosting anymore, so I don't have that upload trouble anymore, and also cannot test it myself. That's also why I'm unassigning this issue to me. So please, somebody else test it.

1 0

[drupal-devel] [feature] Misleading wget pseudo url for 'Download Drupal' step in INSTALL.txt
by grohk 15 Apr '05

15 Apr '05

Issue status update for http://drupal.org/node/20580 Project: Drupal Version: 4.6.0 Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: grohk Updated by: grohk -Status: active +Status: patch oops...forgot to set to patch. grohk Previous comments: ------------------------------------------------------------------------ April 15, 2005 - 13:58 : grohk Attachment: http://drupal.org/files/issues/pseudo-url-fix.patch (481 bytes) A misleading url example exists in the INSTALL.txt the instructions for step one. The pseudo url (wget http://drupal.org/files/project/drupal-x.x.x.tgz) can give the user a 404 error or an invalid file. These examples do not work, they give 404 file not found errors: wget http://drupal.org/files/project/drupal-4.6.0.tgz wget http://drupal.org/files/projects/drupal-4.6.0.tgz This example downloads an strange html page: wget http://drupal.org/files/project/drupal-4.6.0.tar.gz This example succeed in downloading the tarball: wget http://drupal.org/files/projects/drupal-4.6.0.tar.gz A patch is attached.

1 0

[drupal-devel] [bug] Request New Password Security
by bloggator 15 Apr '05

15 Apr '05

Issue status update for http://drupal.org/node/18719 Project: Drupal Version: cvs Component: user.module -Category: feature requests +Category: bug reports Priority: critical Assigned to: Anonymous Reported by: neofactor Updated by: bloggator Status: patch 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. bloggator Previous comments: ------------------------------------------------------------------------ March 10, 2005 - 18: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 10, 2005 - 20: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 10, 2005 - 20: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 - 00: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 - 12: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 - 12:41 : chx Very nice patch. Please consider for 4.6. ------------------------------------------------------------------------ March 30, 2005 - 14: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 30, 2005 - 15: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 30, 2005 - 17: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 30, 2005 - 21: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 30, 2005 - 22: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 30, 2005 - 23: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 - 02: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 - 03: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 - 09: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 - 11: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 - 10: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 - 12: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 - 01:22 : Dries factoryjoe: you can't reset your password when you are logged in. ------------------------------------------------------------------------ April 3, 2005 - 05: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 4, 2005 - 16: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 4, 2005 - 16: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 - 11: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 - 08: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 - 02:32 : jacusah Will this patch be added to the core?

1 0

[drupal-devel] Drupal 4.6.0 released
by Dries Buytaert 15 Apr '05

15 Apr '05

Hello world, the Drupal team is proud to announce Drupal 4.6.0! More information about the Drupal 4.6.0 release is available at: http://drupal.org/drupal-4-6-0 Kudos to all Drupal contributors for making this release possible. -- Dries Buytaert :: http://www.buytaert.net/

4 3

[drupal-devel] [bug] Blocks with no title kill Drupal
by Steven 15 Apr '05

15 Apr '05

Issue status update for http://drupal.org/node/19965 Project: Drupal Version: cvs Component: block.module Category: bug reports Priority: critical Assigned to: Robin Monks Reported by: budda Updated by: Steven Status: patch That patch was already committed. So the code I added back then is now redundant as $block['info'] must always be set. The MySQL problem just seems to be that you're keying on the title or description. Why not have a block id? We do this everywhere else... Steven Previous comments: ------------------------------------------------------------------------ April 4, 2005 - 19:03 : budda When setting more than one block's title to '' (blank) Drupal dies, and doesn't catch the SQL query error nicely. The error is as follows: user error: Duplicate entry '' for key 2 query: UPDATE boxes SET title = '', body = ' ...<cut>... in /var/www/html/drupal-cvs/includes/database.mysql.inc on line 66. Using 4.6 build from 4/4/2005 The page ends with: warning: Cannot modify header information - headers already sent by (output started at /var/www/html/drupal-cvs/includes/common.inc:384) in /var/www/html/drupal-cvs/includes/common.inc on line 192. ------------------------------------------------------------------------ April 8, 2005 - 10:08 : robertDouglass There should be a check before the insert is attempted and if the block title already exists the user should be notified with form_error(). ------------------------------------------------------------------------ April 8, 2005 - 11:46 : Poolio this certainly doesn't solve the problem, but I've worked around this issue by using html tags in the title field for blocks that I don't want to show a title. ------------------------------------------------------------------------ April 9, 2005 - 02:31 : Robin Monks Attachment: http://drupal.org/files/issues/block.module.blank.title.patch (955 bytes) A small patch that checks to ensure the title does not already exit in the Blocks list. Also, if the field was left blank, in adds an HTML comment with the current date to the second to ensure that a duplicate title isn't created. This is my first patch, so I probably did something wrong, but I'm willing to fix it too. Robin Monks MozNetwork.org ------------------------------------------------------------------------ April 9, 2005 - 03:22 : Morbus Iff I'm, personally, fine with how you've fixed the blank block title. You've really solved two problems in one: duplicate titles (which is the cause of this Issue), and the desire to have blank (or no) titles (which is the reason for this Issue) for the end user. With that said, I'm not a fan of your error message (but, then again, anal wording is my specialty, so don't think I'm picking on you): I'd rename it to "That block title is already in use; please choose another." The goals here: The user may not remember all the previous titles he's used. Using "unique" starts forcing him to remember. We shouldn't do that. The user already knows he entered it - we don't have to repeat that to him. It's active, not passive (no use of "have"). Use a semi-colon, not a comma. It's much shorter and concise. ------------------------------------------------------------------------ April 9, 2005 - 08:27 : chx Attachment: http://drupal.org/files/issues/box_title.patch (1.49 KB) Why display any message at all? ------------------------------------------------------------------------ April 9, 2005 - 16:11 : Morbus Iff Displaying no message at all would only work if the user wasn't typing in ANY title whatsoever (since then we'd make one for them based on the date). But, if a user names a block "Users" one week, and then creates another block called "Users" three weeks later, than an whoopsidaisy error needs to be shown - we shouldn't modify the text randomly. ------------------------------------------------------------------------ April 9, 2005 - 17:10 : chx Well, let's discuss the main point: why shoiuld be the title unique? ------------------------------------------------------------------------ April 9, 2005 - 17:38 : Morbus Iff Are you asking why Drupal enforces them being unique, or why, visually and to the end-user, they should be unique? ------------------------------------------------------------------------ April 9, 2005 - 17:43 : chx I guess Drupal forces them 'cos for some reasons it is thought that for the users they should be unique. This is not the case, however. Yes, it's confusing if they are on the same page. But I can think on circumstances where they would not be on the same page, so the force from Drupal seems unnecessary. ------------------------------------------------------------------------ April 9, 2005 - 21:00 : robertDouglass agree with chx on the unique point. Like the functionality of adding html comments and timestamp (why timestamp? why not a block id?) if left blank if they must be uniqe. Would be in favor of making the visible title completely optional. Administrators have description to keep them separate on the admin screen. ------------------------------------------------------------------------ April 9, 2005 - 21:48 : Robin Monks Attachment: http://drupal.org/files/issues/drupal_0.patch (3.67 KB) This new patch no longer requires a unique value for title, and also checks to ensure the Block Description is not a duplicate or empty value. Big thanks go out to chx for assistance. Robin ------------------------------------------------------------------------ April 11, 2005 - 16:20 : Anonymous Shouldn't we add a test too to check info unicity ? ------------------------------------------------------------------------ April 11, 2005 - 16:38 : chx <?php if (empty($edit['info']) || db_num_rows(db_query("SELECT info FROM {boxes} WHERE info='%s'", $edit['info']))) { ?> To me, this seems like a check for info unicity... not to mention that the UNIQUE(info) DB constraint is not touched. ------------------------------------------------------------------------ April 11, 2005 - 16:46 : tostinni Ups, sorry for the anonymous and the message, I didn't saw this verification, I was only remembering block.module code. That's all fine for me. ------------------------------------------------------------------------ April 11, 2005 - 18:27 : njivy +1 to Robin Monks' patch. When I install Drupal, the first thing I always do is remove the /unique key/ constraint on block titles. I have not tested the other parts of Monks' patch, though, including the uniqueness constraint on block descriptions. ------------------------------------------------------------------------ April 11, 2005 - 21:04 : drumm Code looks okay. +1 "You must enter unique data into the block description field." doesn't sound like the friendliest of error messages. ------------------------------------------------------------------------ April 11, 2005 - 21:16 : Dries I'm OK with this patch but suggest that we look into improving the error message. Small nit: fix the spacing around '=' in the SQL query that checks for duplicates. ------------------------------------------------------------------------ April 12, 2005 - 01:40 : Robin Monks Attachment: http://drupal.org/files/issues/drupal_1.patch (3.97 KB) Here is a new patch with the changes and with the updates.inc file changed to reflect patchs applied after the original patch was made. Robin ------------------------------------------------------------------------ April 12, 2005 - 20:52 : Dries Committed to HEAD. Thanks. The patch did not apply against DRUPAL-4-6. Possibly needs to get backported. ------------------------------------------------------------------------ April 13, 2005 - 17:36 : Robin Monks Attachment: http://drupal.org/files/issues/4.6 blank title (3.63 KB) Here is the patch backported for 4.6. Robin MozNetwork.org ------------------------------------------------------------------------ April 13, 2005 - 17:45 : Robin Monks Attachment: http://drupal.org/files/issues/4_0.6 blank title (3.62 KB) That patch had a bug in it, new patch attached. Robin ------------------------------------------------------------------------ April 14, 2005 - 13:38 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/block-fix.patch (673 bytes) The patch got apparently into core. It introduces a problem with php 5. $edit is not defined as an array if the form is called for the fiest time (default in switch). This patch fixes this. ------------------------------------------------------------------------ April 15, 2005 - 17:28 : Steven Sorry for dropping in so late, but I disagree that block descriptions should be filled in. A while ago I even made a patch to display the block title in the admin list if the description was empty: I never fill in descriptions for my own blocks, I know what they are. It seems a big usability hit to force people to enter descriptions. Also, the updates seem to re-add the index on (title) but not on (info). I think the two versions (database.sql and updates.inc) are now out of sync. ------------------------------------------------------------------------ April 15, 2005 - 18:58 : RobinMonks(a)moznetwork.org >Sorry for dropping in so late, but I disagree that block descriptions should be filled in. >A while ago I even made a patch to display the block title in the admin list if the description was empty: I never >fill in descriptions for my own blocks, I know what they are. Then please submit it! But from a usibility standpoint, it's better to show a kind error now (when 4.6 is going out the door), then to argue about this and have this bug still in 4.6. > It seems a big usability hit to force people to enter descriptions. Point taken, but ATM entering two blank descriptions makes MySQL go mad, and that seems worse to me. We can always remove then need of a unique info later. >Also, the updates seem to re-add the index on (title) but not on (info). I think the two versions (database.sql >and updates.inc) are now out of sync. The title was never remove from info if you look closely, and as a matter 'o fact, that index is just left there from redundancy as the module check for dupes on-the-fly. Robin

1 0

[drupal-devel] [bug] Blocks with no title kill Drupal
by RobinMonks 15 Apr '05

15 Apr '05

Issue status update for http://drupal.org/node/19965 Project: Drupal Version: cvs Component: block.module Category: bug reports Priority: critical Assigned to: Robin Monks Reported by: budda Updated by: RobinMonks(a)moznetwork.org Status: patch >Sorry for dropping in so late, but I disagree that block descriptions should be filled in. >A while ago I even made a patch to display the block title in the admin list if the description was empty: I never >fill in descriptions for my own blocks, I know what they are. Then please submit it! But from a usibility standpoint, it's better to show a kind error now (when 4.6 is going out the door), then to argue about this and have this bug still in 4.6. > It seems a big usability hit to force people to enter descriptions. Point taken, but ATM entering two blank descriptions makes MySQL go mad, and that seems worse to me. We can always remove then need of a unique info later. >Also, the updates seem to re-add the index on (title) but not on (info). I think the two versions (database.sql >and updates.inc) are now out of sync. The title was never remove from info if you look closely, and as a matter 'o fact, that index is just left there from redundancy as the module check for dupes on-the-fly. Robin RobinMonks(a)moznetwork.org Previous comments: ------------------------------------------------------------------------ April 4, 2005 - 17:03 : budda When setting more than one block's title to '' (blank) Drupal dies, and doesn't catch the SQL query error nicely. The error is as follows: user error: Duplicate entry '' for key 2 query: UPDATE boxes SET title = '', body = ' ...<cut>... in /var/www/html/drupal-cvs/includes/database.mysql.inc on line 66. Using 4.6 build from 4/4/2005 The page ends with: warning: Cannot modify header information - headers already sent by (output started at /var/www/html/drupal-cvs/includes/common.inc:384) in /var/www/html/drupal-cvs/includes/common.inc on line 192. ------------------------------------------------------------------------ April 8, 2005 - 08:08 : robertDouglass There should be a check before the insert is attempted and if the block title already exists the user should be notified with form_error(). ------------------------------------------------------------------------ April 8, 2005 - 09:46 : Poolio this certainly doesn't solve the problem, but I've worked around this issue by using html tags in the title field for blocks that I don't want to show a title. ------------------------------------------------------------------------ April 9, 2005 - 00:31 : Robin Monks Attachment: http://drupal.org/files/issues/block.module.blank.title.patch (955 bytes) A small patch that checks to ensure the title does not already exit in the Blocks list. Also, if the field was left blank, in adds an HTML comment with the current date to the second to ensure that a duplicate title isn't created. This is my first patch, so I probably did something wrong, but I'm willing to fix it too. Robin Monks MozNetwork.org ------------------------------------------------------------------------ April 9, 2005 - 01:22 : Morbus Iff I'm, personally, fine with how you've fixed the blank block title. You've really solved two problems in one: duplicate titles (which is the cause of this Issue), and the desire to have blank (or no) titles (which is the reason for this Issue) for the end user. With that said, I'm not a fan of your error message (but, then again, anal wording is my specialty, so don't think I'm picking on you): I'd rename it to "That block title is already in use; please choose another." The goals here: The user may not remember all the previous titles he's used. Using "unique" starts forcing him to remember. We shouldn't do that. The user already knows he entered it - we don't have to repeat that to him. It's active, not passive (no use of "have"). Use a semi-colon, not a comma. It's much shorter and concise. ------------------------------------------------------------------------ April 9, 2005 - 06:27 : chx Attachment: http://drupal.org/files/issues/box_title.patch (1.49 KB) Why display any message at all? ------------------------------------------------------------------------ April 9, 2005 - 14:11 : Morbus Iff Displaying no message at all would only work if the user wasn't typing in ANY title whatsoever (since then we'd make one for them based on the date). But, if a user names a block "Users" one week, and then creates another block called "Users" three weeks later, than an whoopsidaisy error needs to be shown - we shouldn't modify the text randomly. ------------------------------------------------------------------------ April 9, 2005 - 15:10 : chx Well, let's discuss the main point: why shoiuld be the title unique? ------------------------------------------------------------------------ April 9, 2005 - 15:38 : Morbus Iff Are you asking why Drupal enforces them being unique, or why, visually and to the end-user, they should be unique? ------------------------------------------------------------------------ April 9, 2005 - 15:43 : chx I guess Drupal forces them 'cos for some reasons it is thought that for the users they should be unique. This is not the case, however. Yes, it's confusing if they are on the same page. But I can think on circumstances where they would not be on the same page, so the force from Drupal seems unnecessary. ------------------------------------------------------------------------ April 9, 2005 - 19:00 : robertDouglass agree with chx on the unique point. Like the functionality of adding html comments and timestamp (why timestamp? why not a block id?) if left blank if they must be uniqe. Would be in favor of making the visible title completely optional. Administrators have description to keep them separate on the admin screen. ------------------------------------------------------------------------ April 9, 2005 - 19:48 : Robin Monks Attachment: http://drupal.org/files/issues/drupal_0.patch (3.67 KB) This new patch no longer requires a unique value for title, and also checks to ensure the Block Description is not a duplicate or empty value. Big thanks go out to chx for assistance. Robin ------------------------------------------------------------------------ April 11, 2005 - 14:20 : Anonymous Shouldn't we add a test too to check info unicity ? ------------------------------------------------------------------------ April 11, 2005 - 14:38 : chx <?php if (empty($edit['info']) || db_num_rows(db_query("SELECT info FROM {boxes} WHERE info='%s'", $edit['info']))) { ?> To me, this seems like a check for info unicity... not to mention that the UNIQUE(info) DB constraint is not touched. ------------------------------------------------------------------------ April 11, 2005 - 14:46 : tostinni Ups, sorry for the anonymous and the message, I didn't saw this verification, I was only remembering block.module code. That's all fine for me. ------------------------------------------------------------------------ April 11, 2005 - 16:27 : njivy +1 to Robin Monks' patch. When I install Drupal, the first thing I always do is remove the /unique key/ constraint on block titles. I have not tested the other parts of Monks' patch, though, including the uniqueness constraint on block descriptions. ------------------------------------------------------------------------ April 11, 2005 - 19:04 : drumm Code looks okay. +1 "You must enter unique data into the block description field." doesn't sound like the friendliest of error messages. ------------------------------------------------------------------------ April 11, 2005 - 19:16 : Dries I'm OK with this patch but suggest that we look into improving the error message. Small nit: fix the spacing around '=' in the SQL query that checks for duplicates. ------------------------------------------------------------------------ April 11, 2005 - 23:40 : Robin Monks Attachment: http://drupal.org/files/issues/drupal_1.patch (3.97 KB) Here is a new patch with the changes and with the updates.inc file changed to reflect patchs applied after the original patch was made. Robin ------------------------------------------------------------------------ April 12, 2005 - 18:52 : Dries Committed to HEAD. Thanks. The patch did not apply against DRUPAL-4-6. Possibly needs to get backported. ------------------------------------------------------------------------ April 13, 2005 - 15:36 : Robin Monks Attachment: http://drupal.org/files/issues/4.6 blank title (3.63 KB) Here is the patch backported for 4.6. Robin MozNetwork.org ------------------------------------------------------------------------ April 13, 2005 - 15:45 : Robin Monks Attachment: http://drupal.org/files/issues/4_0.6 blank title (3.62 KB) That patch had a bug in it, new patch attached. Robin ------------------------------------------------------------------------ April 14, 2005 - 11:38 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/block-fix.patch (673 bytes) The patch got apparently into core. It introduces a problem with php 5. $edit is not defined as an array if the form is called for the fiest time (default in switch). This patch fixes this. ------------------------------------------------------------------------ April 15, 2005 - 15:28 : Steven Sorry for dropping in so late, but I disagree that block descriptions should be filled in. A while ago I even made a patch to display the block title in the admin list if the description was empty: I never fill in descriptions for my own blocks, I know what they are. It seems a big usability hit to force people to enter descriptions. Also, the updates seem to re-add the index on (title) but not on (info). I think the two versions (database.sql and updates.inc) are now out of sync.

1 0