March 2005 - Development - lists.drupal.org

[drupal-devel] [feature] introduce a "cron" user to fix various cron related issues
by killes 13 Mar '05

13 Mar '05

Issue status update for http://drupal.org/node/5380 Project: Drupal Version: cvs Component: user system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: ax Updated by: killes(a)www.drop.org Status: patch I like the idea, some comments, though: +if (!$cron_is_running) { + session_start(); +} Is this neccessary? 'User ID '.$cron_uid.' does not exist' killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ January 24, 2004 - 00:33 : ax we currently have some problems caused by the undefined state of $user in the cause of cron runs. sometimes it's "Anonymous", sometimes it picks up the currently logged in user (i think). I stumbled upon this when reading issues closed by "Anonymous" caused by the automatic cron closure when issues are fixed. i always think "isn't it strange that "Anonymous" can close issues just as she feels like?" there are quite some related issues - search this site for "cron user". couldn't a cron user solve these problems? a la if (REQUEST_URI) == cron.php then $user = <cron_user>, with <cron_user> having some special properties such as showing "Automatically" for closed issues, being possible to excluded in statistics, putting the rss author from imported rss nodes into nodes author field, having special access checks etc. i didn't think about this much, but thought it is worth filing here. please discuss, elaborate - and don't flame me if i'm too off ;) ------------------------------------------------------------------------ February 11, 2004 - 06:04 : Chris Johnson Sounds like a good idea to me. It's one of many things I'd like to change if I get time to work on it. ------------------------------------------------------------------------ September 27, 2004 - 20:25 : Philippe Couln't we just write this in cron.php: <?php $cronuser = variable_get('cron_cronuser','nobody'); if ($cronuser = 'nobody'){ $user = user_load(array()); //I believe this results in Anonymous?? }else{ $user = user_load(array('name' => $cronuser)); } ?> We can set the variable cron_cronuser in a page like admin/cron. If the site administrator doesn't set a value, cron uses Anonymous for everything (not some user that happens to be logged on). If a valid user name is set, the site admin can give the cron user special privileges. ------------------------------------------------------------------------ October 1, 2004 - 19:41 : Philippe Setting the user like this in cron.php sends a cookie. (How? Where? Can we prevent this?) So everybody can get "cron" privileges by loading cron.php once. We could fix this by making cron.php accessible only from localhost (in .htaccess). Any ideas? ------------------------------------------------------------------------ October 1, 2004 - 22:11 : Philippe Attachment: http://drupal.org/files/issues/cron_uid.patch (3.62 KB) This patch lets the admin select a UID for cron in the admin/settings page. The variable name in which this is stored is 'cron_uid'. When cron.php is loaded, it sets a variable $cron_is_running. If this variable is set, no session will be opened (and no cookies will be sent). The cron page will use the Anonymous user (uid==0) if cron_uid is not set. Note that the site admin should create a "cron" user before setting the UID. ------------------------------------------------------------------------ March 13, 2005 - 20:18 : Chris Johnson Attachment: http://drupal.org/files/issues/cron_uid2.patch (3.19 KB) Previous patch still applies cleanly to HEAD and code algorith looks good on inspection. However, there are some style problems and one ugly bit using StdClass(), so I have re-rolled the patch.

1 0

[drupal-devel] [feature] introduce a "cron" user to fix various cron related issues
by Chris Johnson 13 Mar '05

13 Mar '05

Issue status update for http://drupal.org/node/5380 Project: Drupal Version: cvs Component: user system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: ax Updated by: Chris Johnson Status: patch Attachment: http://drupal.org/files/issues/cron_uid2.patch (3.19 KB) Previous patch still applies cleanly to HEAD and code algorith looks good on inspection. However, there are some style problems and one ugly bit using StdClass(), so I have re-rolled the patch. Chris Johnson Previous comments: ------------------------------------------------------------------------ January 23, 2004 - 17:33 : ax we currently have some problems caused by the undefined state of $user in the cause of cron runs. sometimes it's "Anonymous", sometimes it picks up the currently logged in user (i think). I stumbled upon this when reading issues closed by "Anonymous" caused by the automatic cron closure when issues are fixed. i always think "isn't it strange that "Anonymous" can close issues just as she feels like?" there are quite some related issues - search this site for "cron user". couldn't a cron user solve these problems? a la if (REQUEST_URI) == cron.php then $user = <cron_user>, with <cron_user> having some special properties such as showing "Automatically" for closed issues, being possible to excluded in statistics, putting the rss author from imported rss nodes into nodes author field, having special access checks etc. i didn't think about this much, but thought it is worth filing here. please discuss, elaborate - and don't flame me if i'm too off ;) ------------------------------------------------------------------------ February 10, 2004 - 23:04 : Chris Johnson Sounds like a good idea to me. It's one of many things I'd like to change if I get time to work on it. ------------------------------------------------------------------------ September 27, 2004 - 13:25 : Philippe Couln't we just write this in cron.php: <?php $cronuser = variable_get('cron_cronuser','nobody'); if ($cronuser = 'nobody'){ $user = user_load(array()); //I believe this results in Anonymous?? }else{ $user = user_load(array('name' => $cronuser)); } ?> We can set the variable cron_cronuser in a page like admin/cron. If the site administrator doesn't set a value, cron uses Anonymous for everything (not some user that happens to be logged on). If a valid user name is set, the site admin can give the cron user special privileges. ------------------------------------------------------------------------ October 1, 2004 - 12:41 : Philippe Setting the user like this in cron.php sends a cookie. (How? Where? Can we prevent this?) So everybody can get "cron" privileges by loading cron.php once. We could fix this by making cron.php accessible only from localhost (in .htaccess). Any ideas? ------------------------------------------------------------------------ October 1, 2004 - 15:11 : Philippe Attachment: http://drupal.org/files/issues/cron_uid.patch (3.62 KB) This patch lets the admin select a UID for cron in the admin/settings page. The variable name in which this is stored is 'cron_uid'. When cron.php is loaded, it sets a variable $cron_is_running. If this variable is set, no session will be opened (and no cookies will be sent). The cron page will use the Anonymous user (uid==0) if cron_uid is not set. Note that the site admin should create a "cron" user before setting the UID.

1 0

Re: [drupal-devel] Random: Drupal Relationships
by Boris Mann 13 Mar '05

13 Mar '05

On Sat, 12 Mar 2005 09:25:37 +0100, Dries Buytaert <dries(a)buytaert.net> wrote: > Difficult to say without proper benchmarking. I'm sure some relations > are better captured in separate tables, while for some relations it > might be beneficial to use a single table. It all depends on how you > want to use (query) the data, and how frequent. Sounds a bit like a relationship API. Certain modules would define relationships, and depending on the needs/scale, would either use a "shared" relationship table or design their own optimized table. > Personally, I'd start off with extending taxonomy for folksonomies and > nothing more. Yes, please! -- Boris Mann http://www.bryght.com

2 2

[drupal-devel] [feature] Trim username at login
by killes 13 Mar '05

13 Mar '05

Issue status update for http://drupal.org/node/11791 Project: Drupal Version: cvs Component: user.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: kps Updated by: killes(a)www.drop.org Status: patch The patch still applies. Apart from Ber everybody liked it. I also like it. killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ October 20, 2004 - 18:29 : kps They create an account. They get a password by email. They select the password plus the preceding blank or following newline. They paste it into the 'Password' box. They can't log in. They write to me complaining. I get tired of complaints and patch user.module to strip leading and trailing blanks. ------------------------------------------------------------------------ October 20, 2004 - 18:39 : kps Attachment: http://drupal.org/files/issues/user.module_0.patch (766 bytes) I claim I'm not *really* dumber myself. Drupal timed out on me.... ------------------------------------------------------------------------ October 20, 2004 - 19:02 : moshe weitzman makes sense to me ------------------------------------------------------------------------ October 20, 2004 - 22:54 : rkendall +1 FWIW - I could see this being useful, and don't really see any practical drawbacks. I does smell of hack, but is that really an issue? I mean, it might not be the 'done' thing to mess with passwords, however, I can't imagine any regular user intentionally putting leading or trailing whitespace on a password, but I can imagine it being done accidentally fairly often (either when setting a password, or when logging in). To be consistent, it would make sense to trim passwords when setting them as well. ------------------------------------------------------------------------ October 21, 2004 - 00:09 : Bèr Kessels -1 from me. I think we should nstart meddling with passwords by trim()ing them. If you have dumb users, you should fix it in the mail that is send to them. That is really easy. For example: add a word after the passwords: your password is WKDKAFAJ34 please mind capital letters. or so. Bèr ------------------------------------------------------------------------ October 21, 2004 - 00:36 : Steven I don't agree with Bèr... copy/pasting is a fiddly business, especially because when pasting a password all you see is asterisks and you don't notice if there is an extra character. Trimming the password won't hurt, I very much doubt that there are people who consciously use a space at the beginning or end of their password. +1 on trimming, it is a usability improvement. ------------------------------------------------------------------------ October 21, 2004 - 00:51 : chx +1 here. Bèr, if you write a sentence around it, you can still copy-paste the whitespace before and after it. ------------------------------------------------------------------------ October 21, 2004 - 02:18 : Uwe Hermann I'm unsure if I really like this, but if this really gets applied, please make it a configuration option. Do not hardcode it for all Drupal installations. Thanks, Uwe. ------------------------------------------------------------------------ October 21, 2004 - 06:06 : robertDouglass +1 I can confirm from my logs that the typical user bungles initial login 1-4 times, with each bungled attempt making an all-out failure more likely. Not only am I in favor of trimming, I am much in favor of investigating other means of initial password assignment like on the initial register form or by generating a unique URL that gets mailed and only has to be clicked or pasted into the browser address bar. Sorry if those alternatives have already been widely discussed here. ------------------------------------------------------------------------ October 21, 2004 - 07:21 : stefan nagtegaal I am all for trimming the spaces in front of the username and after it, but I am absoklutely against another option for such thing. IMO this is only a usability improvement and it is not needed to make it a configurable behaviour.. We have enough options already, and if you'll ask me I'll tell you that we need less options instead of more.. ------------------------------------------------------------------------ October 21, 2004 - 10:58 : Bèr Kessels Admitted: no one will conciously add spaces to his or her passwords. So i will pull out my -1 hereby. but -1 for making ot an option. As steef syis: its useability. I still stick to the -1 for applying this specific patch. I beleive that we should be 1) consitant, and strip /all/ password whitespace. 2) use drupal_set_message() to warn people when whitespace was stripped. And so to educate users to be aware of whitespace when copying passwords. ------------------------------------------------------------------------ October 21, 2004 - 12:39 : kps My proposed patch also strips white space when the user changes the password, so it's not possible to create an unusable password. I agree that a warning message would be a good idea. ------------------------------------------------------------------------ October 21, 2004 - 17:10 : Chris Johnson Part of the problem with users copying and pasting extraneous whitespace around passwords (or userrnames) is the inconsistent behavior in GUI windowing environments. That is to say, in some applications in some GUIs, double-clicking on a word will copy the word and its surrounding white space, for example. In others, it will not. One might think it would be visibly obvious that the surrounding white space was included in the copy operation, but that's not so. The words might be displayed in a very small, proportional font (and further might be justified or kerned in unpredictable fashion) which make it hard to see just where the highlighted copied text begins and ends. This is under the control of the application and the user. Or, the user might think logically that since all he or she wanted was the word, and likewise that "whitespace" is irrelevant, the user may assume that what was copied was only the desired word even if they can visibly see that the adjacent spaces are highlighted. I'm well aware of this behavior myself and even I sometimes get tripped up when copying and pasting bits of data here and there by the occasional undesired white space. My vote would be to always trim leading and trailing white space, and to document in the help that such white space is not valid in passwords.

1 0

[drupal-devel] [bug] Extra parens in taxonomy_term_count_nodes().
by killes 13 Mar '05

13 Mar '05

Issue status update for http://drupal.org/node/18696 Project: Drupal Version: cvs Component: taxonomy.module Category: bug reports Priority: critical Assigned to: Morbus Iff Reported by: Morbus Iff Updated by: killes(a)www.drop.org Status: patch Please apply. @Morbus: Please create patches from the Drupal root. killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ March 10, 2005 - 17:46 : Morbus Iff Attachment: http://drupal.org/files/issues/02_taxonomy.module_extraparens.patch (979 bytes) There is an extra parens in taxonomy_term_count_nodes(), caused by removal of DISTINCT: http://cvs.drupal.org/viewcvs/drupal/drupal/modules/taxonomy.module?r1=1.16… These patches were made during the exploration and customization of Drupal by NHPR.org. In loving support of open source software, NHPR.org will continue to contribute patches they feel the community will benefit from. Questions about this patch should be directed to morbus(a)disobey.com.

1 0

[drupal-devel] [bug] Patches add $node->preview and $comment->preview so themes can style previews
by Geary 13 Mar '05

13 Mar '05

Issue status update for http://drupal.org/node/18847 Project: Drupal Version: cvs Component: node.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: Geary Updated by: Geary Status: patch Attachment: http://drupal.org/files/issues/styled-preview.node.module.patch (384 bytes) I submitted patches to node.module and comment.module to provide $node->preview and $comment->preview flags that themes can use to style previews so they are not confused with ordinary page views. This is a big usability improvement for Drupal. I entered the patches in comments to this issue: http://drupal.org/node/18792 But they didn't show up in the patch queue. I'm posting this separate message with "status: patch" so that it will appear in the patch queue for review (I hope). Thanks for bearing with me; first time I've submitted a patch. Geary

1 1

[drupal-devel] [feature] common.inc Move textarea pre hook between title and textarea
by killes 13 Mar '05

13 Mar '05

Issue status update for http://drupal.org/node/18828 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: jbond Updated by: killes(a)www.drop.org -Status: active +Status: patch Guess that is a patch. killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ March 13, 2005 - 10:52 : jbond Attachment: http://drupal.org/files/issues/common.inc_10.patch (1.8 KB) This patch moves the textarea hook for 'pre' between the title and the textarea. This makes it easier for simply textarea enhancements like quicktags to add a toolbar just above the textarea. It doesn't appear to have any effect on the fckeditor or htmlarea modules. It doesn't introduce any new hooks.

1 0

[drupal-devel] Schema Changes for a Shared Taxonomy OTF/Folksonomy
by Morbus Iff 13 Mar '05

13 Mar '05

I'll be working on this folksonomy thing a lot quicker than I expected. I'm not sure if that's a good thing or a bad thing, sadly - there seems to be four (mine, moshe's, jbond's, and atf's) current thoughts on how it should work. Anyways, I was doing some thinkwork on "my vision" today which, to recap, includes: * multiple folksonomies ("realms" per jbond; "vocabulary" per Drupal). * tags are unique to a unique folksonomy (but, see below). * users share tags per a unique folksonomy/vocabulary. (note, however, that the admin could see create two folksonomies, assign them to different node types, or even to the same type,etc., and "funny" could be a unique value in two different folksonomies.) With that said, it appears that two taxonomy tables would change: * The first would be "term_data". It would include a new "uid" field which would be the uid of the user who created the term. In vocabularies that were not folksonomies, uid would be 0. * The second would be "term_node", which would need a new "uid" column as well. This would represent the uid that assigned the tid to the nid. This is the change that concerns me: * instead of just one tid (3)/nid (5) relation in a normal vocabulary, this change would potentially allow an infinite number, as multiple uids apply the same tid to the same nid. * theoretically, if the tid's vid (this is fun to say!) is not a folksonomy, then the uid would be 0, as before. but, I can see the uid being useful regardless. If multiple admins are editing a nid, then it could be quite useful to see that uid (45) added tid (12), and then, a day later, uid (23) decided that tid (15) was equally as relevant. With the above changes, the following would be possible: * a "my users" page would be easiliy implemented by just grabbing all term_node's that match the $uid (presumably, we wouldn't need a join here as the $user object would be loaded normally). * ownership of tags is possible by checking for the uid of the tid in the term_data table. * All relations/synonyms would utilize the same old code. * We don't have to rely on the taxonomy UI, because the vocabulary.module would be "folksonomy". In 4.6, it'd be hidden in the standard "categories" menu, and we can focus on just the UI and added features in folksonomy.module. Thoughts? -- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ Spidering Hacks: http://amazon.com/exec/obidos/ASIN/0596005776/disobeycom icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus

4 8

[drupal-devel] [bug] Patch adds $comment->preview flag for themed previews
by Geary 13 Mar '05

13 Mar '05

Issue status update for http://drupal.org/node/18792 Project: Drupal Version: cvs -Component: node.module +Component: comment.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: elonen Updated by: Geary Status: patch Attachment: http://drupal.org/files/issues/comment.module_5.patch (290 bytes) Here is a patch to comment.module that adds a $comment->preview flag which themes can use to display previews appropriately. This seems like the simplest possible core change to support styled previews. For more information, screen shots, and a working demo using an updated FriendsLight theme, see: http://mg.to/2005/03/13/drupal-preview-confusion and http://drupal.mg.to/2005/03/13/friendslight-theme-with-styled-preview I am submitting a similar patch to node.module. Geary Previous comments: ------------------------------------------------------------------------ March 12, 2005 - 11:21 : elonen Function theme('node', $node, $teaser, $page) can't detect a preview and therefore often renders it incorrectly. The problem is that !$page is usually interpreted as "the node is part of a listing" in the themes and therefore the previewed page may look, depending on the theme, very different on the actual page. Perhaps theme() should get somewhat more detailed context info than just $page? ------------------------------------------------------------------------ March 13, 2005 - 09:02 : Geary Attachment: http://drupal.org/files/issues/node.module_5.patch (384 bytes) Here is a patch to node.module that adds a $node->preview flag which themes can use to display previews appropriately. This seems like the simplest possible core change to support styled previews. For more information, screen shots, and a working demo using an updated FriendsLight theme, see: http://mg.to/2005/03/13/drupal-preview-confusion and http://drupal.mg.to/2005/03/13/friendslight-theme-with-styled-preview I am submitting a similar patch to comment.module.

1 0

[drupal-devel] [bug] Patch adds $node->preview flag for themed previews
by Geary 13 Mar '05

13 Mar '05

Issue status update for http://drupal.org/node/18792 Project: Drupal -Version: 4.5.2 +Version: cvs Component: node.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: elonen Updated by: Geary -Status: active +Status: patch Attachment: http://drupal.org/files/issues/node.module_5.patch (384 bytes) Here is a patch to node.module that adds a $node->preview flag which themes can use to display previews appropriately. This seems like the simplest possible core change to support styled previews. For more information, screen shots, and a working demo using an updated FriendsLight theme, see: http://mg.to/2005/03/13/drupal-preview-confusion and http://drupal.mg.to/2005/03/13/friendslight-theme-with-styled-preview I am submitting a similar patch to comment.module. Geary Previous comments: ------------------------------------------------------------------------ March 12, 2005 - 11:21 : elonen Function theme('node', $node, $teaser, $page) can't detect a preview and therefore often renders it incorrectly. The problem is that !$page is usually interpreted as "the node is part of a listing" in the themes and therefore the previewed page may look, depending on the theme, very different on the actual page. Perhaps theme() should get somewhat more detailed context info than just $page?

1 0