March 2005 - Development - lists.drupal.org

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

15 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: stefan nagtegaal Status: patch Indeed, nice and simple patch! +1 from me either.. stefan nagtegaal 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. ------------------------------------------------------------------------ March 13, 2005 - 18:56 : killes(a)www.drop.org Guess that is a patch. ------------------------------------------------------------------------ March 14, 2005 - 14:38 : Bèr Kessels +1 From me. Any module that adds something, will want to add it after the title. I really cannot think of any case where aditional content should sit above the title, but I can think of loads of cases where content needs to sit between the title and textarea.

1 0

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

14 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: Olen Status: patch How about creating a bunch of "reserved" users (like most linux distributions do)? uid 1 = root uid 2 = cron uid 3 - 8 = reserved for later use uid 9 = anonymous And then let the admin log in as root the first time. We still let him/her change the username of any of these users, so it should not cause to many problems for new installations. Older ones would either just have to live with it, or do a lot of 'UPDATE module_table SET uid=X WHERE uid=2'-queries. Olen 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. ------------------------------------------------------------------------ March 13, 2005 - 20:37 : killes(a)www.drop.org I like the idea, some comments, though: +if (!$cron_is_running) { + session_start(); +} Is this neccessary? 'User ID '.$cron_uid.' does not exist' ------------------------------------------------------------------------ March 13, 2005 - 21:11 : killes(a)www.drop.org 'User ID '.$cron_uid.' does not exist' < == needs to be made translatable. Setting to active. ------------------------------------------------------------------------ March 14, 2005 - 06:56 : Chris Johnson Attachment: http://drupal.org/files/issues/cron_uid3.patch (3.29 KB) Ooops. Sorry I missed that text that needed translating. New patch attached with that bit corrected. Yes, I think the if (!$cron_is_running) code is needed to keep the cron user from creating many unneeded sessions. ------------------------------------------------------------------------ March 14, 2005 - 10:48 : stefan nagtegaal I am all for the idea of introducing a special id for running the cronjobs, but the approach you took here is far from perfect imo.. After looking at your patch, there are several questions and remarks that came up to my mind: I agree with Gerhard that the $cron_is_running is probably unneeded, I think it's better todo: <?php if (!variable_get('cron_busy', true)) { session_start(); } ?> I think that this is much to technical. Severa newbies will probable ask what a user id is, or what cron jobs are.. From both usability and userfriendlyness this patch is a big -1 from me.. I would suggest todo the following: - Make a new user in the db called 'Cron' with a user id -1, or something like that.. That way you don't have to add extra options to the administration, and the way of implementing should be much cleaner. Also does it improves usability... What do you think? ------------------------------------------------------------------------ March 14, 2005 - 14:11 : Anonymous Hi, The functionality is great, but your interface is not. IMO you should just choose good defaults and leave it with that. Why would users want to choose "UIDs" ofr "cron Jobs". Joe user should not have to think about UIDs and Crons. IT should Just Work[tm]. I know there are lots of places in Drupal where this is not the case either, but we are working on that. So when we introduce new functionality we should do it good at once. Why not go for Stefans suggestion of choosing a cron UID and jsut leave it like that. UIDs are not really used anyway, so you can choose just any UID (just the next one available, most often will be '2'). Bèr ------------------------------------------------------------------------ March 14, 2005 - 14:45 : javanaut "Make a new user in the db called 'Cron' with a user id -1" Just on a technical note, the database type for uids is "unsigned" and -1 won't work. ------------------------------------------------------------------------ March 14, 2005 - 20:08 : killes(a)www.drop.org @Chris: I am pretty sue that this patch will not be usefull if the cron user does not get a session. Drupal relies on the session to authenticate the user. If you are worried about too many sessions, you should make sure the session is clossed at the end of the run. his could be done in cron.php. @Stefan, Ber: I think we should introduce just a standard user and assign the "authneticated user" role to him. The set the variable to that uid so we can check which user it is. The problem is that we cannot create the user from database.mysql beacuse the next uid would be No. 1 which is reserved. So we would need to create the user on the first visit to the admin/settings page. We could also use drupal_set_message to inform the admin of this. We should also extent the relevant help text. While we are at it we could make the anon user use the db tabe for its name too and not a variable. ------------------------------------------------------------------------ March 14, 2005 - 21:33 : Chris Johnson Looks like we are sort of in a corner. Really the cron user should be in the database at install time, but we have to reserve uid 1 for the first user. Maybe there is another way to do that without having the first entry to admin create the cron user? That seems hackish to me. I agree that the anonymous user should also be completely coded into the database, and not a variable. The current methods causes anomolous behaviors. I, in fact, wrote several patches to do that a long time ago (http://drupal.org/node/5639) I looked at updating that patch a couple of months ago, but the new unregistered user comment capability where the user can enter his name made the code a lot more complicated. Maybe I will get motivated to try it again. If only my patch had been applied the first time! :-)

1 0

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

14 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 Looks like we are sort of in a corner. Really the cron user should be in the database at install time, but we have to reserve uid 1 for the first user. Maybe there is another way to do that without having the first entry to admin create the cron user? That seems hackish to me. I agree that the anonymous user should also be completely coded into the database, and not a variable. The current methods causes anomolous behaviors. I, in fact, wrote several patches to do that a long time ago (http://drupal.org/node/5639) I looked at updating that patch a couple of months ago, but the new unregistered user comment capability where the user can enter his name made the code a lot more complicated. Maybe I will get motivated to try it again. If only my patch had been applied the first time! :-) 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. ------------------------------------------------------------------------ March 13, 2005 - 13: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. ------------------------------------------------------------------------ March 13, 2005 - 13:37 : killes(a)www.drop.org I like the idea, some comments, though: +if (!$cron_is_running) { + session_start(); +} Is this neccessary? 'User ID '.$cron_uid.' does not exist' ------------------------------------------------------------------------ March 13, 2005 - 14:11 : killes(a)www.drop.org 'User ID '.$cron_uid.' does not exist' < == needs to be made translatable. Setting to active. ------------------------------------------------------------------------ March 13, 2005 - 23:56 : Chris Johnson Attachment: http://drupal.org/files/issues/cron_uid3.patch (3.29 KB) Ooops. Sorry I missed that text that needed translating. New patch attached with that bit corrected. Yes, I think the if (!$cron_is_running) code is needed to keep the cron user from creating many unneeded sessions. ------------------------------------------------------------------------ March 14, 2005 - 03:48 : stefan nagtegaal I am all for the idea of introducing a special id for running the cronjobs, but the approach you took here is far from perfect imo.. After looking at your patch, there are several questions and remarks that came up to my mind: I agree with Gerhard that the $cron_is_running is probably unneeded, I think it's better todo: <?php if (!variable_get('cron_busy', true)) { session_start(); } ?> I think that this is much to technical. Severa newbies will probable ask what a user id is, or what cron jobs are.. From both usability and userfriendlyness this patch is a big -1 from me.. I would suggest todo the following: - Make a new user in the db called 'Cron' with a user id -1, or something like that.. That way you don't have to add extra options to the administration, and the way of implementing should be much cleaner. Also does it improves usability... What do you think? ------------------------------------------------------------------------ March 14, 2005 - 07:11 : Anonymous Hi, The functionality is great, but your interface is not. IMO you should just choose good defaults and leave it with that. Why would users want to choose "UIDs" ofr "cron Jobs". Joe user should not have to think about UIDs and Crons. IT should Just Work[tm]. I know there are lots of places in Drupal where this is not the case either, but we are working on that. So when we introduce new functionality we should do it good at once. Why not go for Stefans suggestion of choosing a cron UID and jsut leave it like that. UIDs are not really used anyway, so you can choose just any UID (just the next one available, most often will be '2'). Bèr ------------------------------------------------------------------------ March 14, 2005 - 07:45 : javanaut "Make a new user in the db called 'Cron' with a user id -1" Just on a technical note, the database type for uids is "unsigned" and -1 won't work. ------------------------------------------------------------------------ March 14, 2005 - 13:08 : killes(a)www.drop.org @Chris: I am pretty sue that this patch will not be usefull if the cron user does not get a session. Drupal relies on the session to authenticate the user. If you are worried about too many sessions, you should make sure the session is clossed at the end of the run. his could be done in cron.php. @Stefan, Ber: I think we should introduce just a standard user and assign the "authneticated user" role to him. The set the variable to that uid so we can check which user it is. The problem is that we cannot create the user from database.mysql beacuse the next uid would be No. 1 which is reserved. So we would need to create the user on the first visit to the admin/settings page. We could also use drupal_set_message to inform the admin of this. We should also extent the relevant help text. While we are at it we could make the anon user use the db tabe for its name too and not a variable.

1 0

[drupal-devel] theme 'page'... ideas
by Negyesi Karoly 14 Mar '05

14 Mar '05

Hi, Currently, theme('page', $output) $output is a string which is built by concatenating other themed elements. Let it be an array, and let the themer decide what to do with it. An associative array maybe would be practical. I'd suggest replacing the argument of form to be also an array, and it would call theme_form. Also, the remaining HTML code shall disappear from the code. I have even found a <br>! I know that code is golden, but first, a bit of talk is necessary, especially for the first proposal... Regards Karoly Negyesi

4 4

[drupal-devel] [bug] possible logic error in taxonomy_node_save
by killes 14 Mar '05

14 Mar '05

Issue status update for http://drupal.org/node/18861 Project: Drupal Version: cvs Component: taxonomy.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: nkurz Updated by: killes(a)www.drop.org -Status: active +Status: patch Well, spotted. I don't think that the current code will corrupt the database, but it should get fixed nevertheless. killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ March 14, 2005 - 03:34 : nkurz I'm brand new to Drupal and really rusty with PHP, but I just did a CVS checkout and was looking through taxonomy.module wondering how I could go about adding weights to taxonomy terms (http://drupal.org/node/18824) and think I've found a small logic error in taxonomy_node_save(). Or else I'm misunderstanding some really simple PHP. In any case, it seemed worth reporting so that someone familiar with the module could at least take a quick look. function taxonomy_node_save($nid, $terms) { taxonomy_node_delete($nid); if (is_array($terms)) { foreach ($terms as $term) { if (is_array($term)) { foreach ($term as $tid) { if ($tid) { db_query('INSERT INTO {term_node} (nid, tid) VALUES (%d, %d)', $nid, $tid); } } } if ($term) { db_query('INSERT INTO {term_node} (nid, tid) VALUES (%d, %d)', $nid, $term); } } } } Walkthrough: taxonomy_node_save is passed an integer $nid and an array $terms. Each array element in $terms is either an array of tid's or a single integer tid. If the element is an array of tid's, we insert each (nid, tid) pair into {term_node}. But then after doing this, it looks like we also try to insert (nid,ARRAY) into {term_node} after we finish the foreach loop. Is this perhaps supposed to be 'else if ($term)'? Or is 'if(ARRAY)' false in PHP? Apologies for making a bad first impression if I'm just dead wrong here. ------------------------------------------------------------------------ March 14, 2005 - 03:47 : nkurz Attachment: http://drupal.org/files/issues/taxonomy_node_save.patch (504 bytes) Here's the trivial untested patch in case that makes anything clearer.

1 0

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

14 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 @Chris: I am pretty sue that this patch will not be usefull if the cron user does not get a session. Drupal relies on the session to authenticate the user. If you are worried about too many sessions, you should make sure the session is clossed at the end of the run. his could be done in cron.php. @Stefan, Ber: I think we should introduce just a standard user and assign the "authneticated user" role to him. The set the variable to that uid so we can check which user it is. The problem is that we cannot create the user from database.mysql beacuse the next uid would be No. 1 which is reserved. So we would need to create the user on the first visit to the admin/settings page. We could also use drupal_set_message to inform the admin of this. We should also extent the relevant help text. While we are at it we could make the anon user use the db tabe for its name too and not a variable. 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. ------------------------------------------------------------------------ March 13, 2005 - 20:37 : killes(a)www.drop.org I like the idea, some comments, though: +if (!$cron_is_running) { + session_start(); +} Is this neccessary? 'User ID '.$cron_uid.' does not exist' ------------------------------------------------------------------------ March 13, 2005 - 21:11 : killes(a)www.drop.org 'User ID '.$cron_uid.' does not exist' < == needs to be made translatable. Setting to active. ------------------------------------------------------------------------ March 14, 2005 - 06:56 : Chris Johnson Attachment: http://drupal.org/files/issues/cron_uid3.patch (3.29 KB) Ooops. Sorry I missed that text that needed translating. New patch attached with that bit corrected. Yes, I think the if (!$cron_is_running) code is needed to keep the cron user from creating many unneeded sessions. ------------------------------------------------------------------------ March 14, 2005 - 10:48 : stefan nagtegaal I am all for the idea of introducing a special id for running the cronjobs, but the approach you took here is far from perfect imo.. After looking at your patch, there are several questions and remarks that came up to my mind: I agree with Gerhard that the $cron_is_running is probably unneeded, I think it's better todo: <?php if (!variable_get('cron_busy', true)) { session_start(); } ?> I think that this is much to technical. Severa newbies will probable ask what a user id is, or what cron jobs are.. From both usability and userfriendlyness this patch is a big -1 from me.. I would suggest todo the following: - Make a new user in the db called 'Cron' with a user id -1, or something like that.. That way you don't have to add extra options to the administration, and the way of implementing should be much cleaner. Also does it improves usability... What do you think? ------------------------------------------------------------------------ March 14, 2005 - 14:11 : Anonymous Hi, The functionality is great, but your interface is not. IMO you should just choose good defaults and leave it with that. Why would users want to choose "UIDs" ofr "cron Jobs". Joe user should not have to think about UIDs and Crons. IT should Just Work[tm]. I know there are lots of places in Drupal where this is not the case either, but we are working on that. So when we introduce new functionality we should do it good at once. Why not go for Stefans suggestion of choosing a cron UID and jsut leave it like that. UIDs are not really used anyway, so you can choose just any UID (just the next one available, most often will be '2'). Bèr ------------------------------------------------------------------------ March 14, 2005 - 14:45 : javanaut "Make a new user in the db called 'Cron' with a user id -1" Just on a technical note, the database type for uids is "unsigned" and -1 won't work.

1 0

[drupal-devel] Adopt a contrib module?
by Nicholas Ivy 14 Mar '05

14 Mar '05

Would you be willing to adopt one of the following contributed Drupal modules? I am not able to give them the time and attention they need, and their quality has suffered because of it. By maintaining one or more of these modules, you do the Drupal community a big favor. * paypal_subscription.module * paypal_tipjar.module * site_map.module * taxonomy_otf.module (taxonomy on-the-fly) Please write to me off-list to let me know if you are interested. Thank you! Nic Ivy P.S. What is the best way to cede control of a contrib module, particularly the drupal.org project pages?

1 0

[drupal-devel] [bug] Pushbutton Header CSS Cleanup
by Robert Castelo 14 Mar '05

14 Mar '05

Issue status update for http://drupal.org/node/18879 Project: Drupal Version: cvs Component: theme system Category: bug reports Priority: normal Assigned to: Robert Castelo Reported by: Robert Castelo Updated by: Robert Castelo Status: patch Attachment: http://drupal.org/files/issues/pushbutton-header.patch (973 bytes) Update to CSS used by Pushbutton in the header of the page, fixes two issues: * img was specified to display as block, which wasn't neccessary. Better to leave it as the default (inline), making it easier to control image placement. * Border to top and bottom of secondary-menu was not displaying in Safari, fixed by overiding drupal.css "table {border-collapse: collapse;}" Robert Castelo

2 1

[drupal-devel] [feature] Localize date formats
by pancho 14 Mar '05

14 Mar '05

Issue status update for http://drupal.org/node/11623 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: pancho Reported by: Goba Updated by: pancho Status: patch */First of all: This patch works! Even it may be not yet ready to be adopted in the core, it is good for individual use./* To Steven: Okay, Steven, I was asking for criticism... :) With some of the points you make I can agree: - This feature should be completely and properly rewritten and not just fixed to have a good solution for a longer period and not only for now. - The "if (!module_exist('locale_dateformat'))" solution is not good code style at least for core, as well as the spaces. I didn't take enough care about that, as I wanted to present a solution now, before the release of 4.6. - Sorry about the zipped patches. I didn't expect it to bother anyone. But on the other hand: - It's not about adding more and more date formats. You will agree that the German web is a big enough market which should not be left aside anymore. Therefore the feature request /is critical/ from my perspective at least. And the solution I presented doesn't blow up the date format lists, in the contrary it makes them easier to use. - How can you complain about the tiny version not to be used. If it doesn't exist it /can't be used/. - The apostrophees do make sense, because the separator can also be a single space. Nobody would identify that in the menu without apostrophees. So you were critizising some points which I will fix in a new version of the patch as soon as possible. But you didn't say anything about the split of date and time formats. To me it makes sense, as there have already been more people asking for "just date" or "just time". While I already started the development of a "locale_dateformat.module", I will put this on hold, until we figured out a good solution altogether. Anyway, I'm ready to help developing this feature within "locale.module" if I'm being asked. Otherwise developing a separate module would at least offer the so needed functionality /within this century/ ;-) Pancho pancho Previous comments: ------------------------------------------------------------------------ October 15, 2004 - 19:52 : Goba Attachment: http://drupal.org/files/issues/Drupal-translate-date-formats.patch (1.99 KB) Currently if I set a date format for the site, then it will be used with all interface translations. Different languages however have different needs when presenting dates. The Hungarian date format does not allow the day name to be the first and it calls for a dot between the hour and minute (yes, a dot not a colon). This means that Drupal ships with no suitable date format for Hungarians. Also none of the Hungarian date formats will be suitable on an English interface, while none of the English date formats are acceptable on a Hungarian interface on a bilingual site. The only option is to make date formats translateable. Since these are dynamic t() calls, extractor.php needs to be extended to include the date formats shipped with drupal in the pot output, so translators will get them (much like we do for some numbers and day names). I will take care of extending extractor.php, once this patch gets applied. ------------------------------------------------------------------------ October 15, 2004 - 20:00 : Goba Attachment: http://drupal.org/files/issues/Drupal-translate-date-formats_0.patch (1.99 KB) Well, the t() needs to be called on the date format set by the admin, so I needed to fix three t() calls. Updated patch attached. ------------------------------------------------------------------------ October 15, 2004 - 20:01 : killes(a)www.drop.org *g* I recall that there was a time when you didn't like this approach. Anyway, I fully endorse it and would like to see it in 4.5. There is also no suitable data format for German in core. And yes, that's a bug not a feature request. ------------------------------------------------------------------------ October 15, 2004 - 20:05 : Goba Yes, I didn't like it, because these are dynamic t()s. But since the selected format always needs to be presented in the actual language, it needs to be dynamic by nature. We have some of these dynamic t()s already, handled specially in extractor.php. ------------------------------------------------------------------------ October 16, 2004 - 00:07 : Steven I like this idea a lot, but I don't like the simplistic "wrap it all in t" feature. There are instances where format_date output is intended for script output. Changing those date formats would mean a bug in the code or UI (for example the way a node date is specified and parsed). Only those strings that are intended for user consumption should be translated. That's why I think we need a more specialized date handling component. It would deal with stuff like variations ('show hour/hide hour'), long/short variations (we need to review the usage of small/medium/long), as well as localizing them. We would need to revise the formats shipped with Drupal, but this gets tricky. For example would we only ship US-style AM/PM date formats with core? Should we only have M/D/Y ordering, or also D/M/Y ordering? If we move the time format settings to locale (where they do below, in principle) we might get a drop in usability: moving from a simple selection box, to requiring the whole localisation framework 'just to switch from 12 hours to 24 hours'. In some parts of the world, there is only one format for dates (e.g. chinese/japanese 2004年10月16日 1時00分). For them, the only variations are long vs short (whether to show the year, the time, etc), in other parts of the world all bets are off and people use what they like. This would mean that if we provide a default set of formats, and let them be translated through PO files, some languages might require more items than provided and some languages would have to use duplicates to fill all available options. On top of that, there is no guarantee that format #3 in French matches format #3 in German, so you'd need to be able to specify this per language. Ideally, we would let a language define any number of date formats, and let the user choose one of those per language. We could also provide a custom option where you enter your own date format, for the realy picky ones. The question remains: what do we do for sites without locale enabled? We can't go to requiring locale just to switch the date on a non-localized site. In that case, perhaps we could do this: - Have locale.module deal with date formats when it is enabled. Have a per-language format setting, selected from a language-specific, po-defined date format list. - Have system.module implement a 'localization' admin menu item if locale.module is /not/ enabled. This page carries the old selector, which acts like a simplified version of locale's format selector, with the list we current have in Drupal (i.e. variations of 24/12hours, d/m/y, y/m/d, m/d/y, ...). To prevent confusion, we add a link to system.module's version of the localization page, which instructs users to enable locale.module for full localization abilities). I know it sounds a bit weird (we certainly don't do this anywhere else), but it would be consistent in terms of UI (the date format is "localization" no matter how you look at it) and keep both non-localized site admins and localized site admins happy, without sacrificing too much ease of set up. ------------------------------------------------------------------------ October 16, 2004 - 10:34 : Goba Steven, you say: "/There are instances where format_date output is intended for script output. Changing those date formats would mean a bug in the code or UI/ " But the current approach is to translate the month and day names in every case, so format_date **already** assumes that the date it outputs is for human consumption and not for machines. So changing the order of the fields in user date formats should not hurt. Sure it might not be a useability dream, but it does not hurt. By the way, adjusting date formats based on user language is only a small piece of localisation not covered by Drupal core yet. I need to use one mission statement and site name in all languages, and even my primary and secondary links need to have the same text in all site languages, since they are not translateable. If we are about to find a generic solution for locale covered settings, we need to take these into account too. ------------------------------------------------------------------------ October 29, 2004 - 01:10 : Steven ""so format_date *already* assumes that the date it outputs is for human consumption and not for machines." " What I mean is changing the placement of the date components (day, month, year). For numerical dates which are parsed by a program, this will introduce bugs. I'd much rather have a cleaner date format selection method integrated with locale. ------------------------------------------------------------------------ October 29, 2004 - 14:19 : Goba Steven, the custom date formats are not translated, only those selected by the admin. And the admin can select date types with spelled out month/day names at any level, so they are not machine parsable anyway in the current Drupal version. **This patch does not introduce bugs.** I admit it does not look good, but there is no system for locale dependant admin settings yet. ------------------------------------------------------------------------ October 29, 2004 - 16:05 : Steven I'm saying we do need such a system. With your patch, the format that the admin selects in language A will not necessarily match the one in language B. We should go for locale-defined formats with a locale-neutral list to fallback on. ------------------------------------------------------------------------ March 13, 2005 - 15:55 : pancho Attachment: http://drupal.org/files/issues/dateformat.patch.zip (14.91 KB) ************************ DATEFORMAT-PATCH PACKAGE ************************ by pancho(a)suenderhauf.net 2005-03-13 03:07 This 'DateFormat' patch package only works with the latest CVS version of Drupal 4.60 RC. This 'DateFormat' patch package applies the following changes: 1. It introduces a more flexible system of standard date and time formats which helps both users and developers while staying backwards-compatible. We often see special date formats be used in modules, which is only second best, as these can neither be adapted by the user nor localized. More flexibility allows the developers to use the built-in format functions wherever possible. Changes in detail: - The standard date formats used to be combined date&time-formats. This is now split into separate date formats and time formats, to allow dates and times to be rendered in a more flexible way. - Still it's backward compatible: the combined formats - while deprecated - still exist. - A "Tiny" format is added to the "Small", "Medium" and "Large" formats. 2. It enables Drupal to show e.g. German and Hungarian date formats (with a colon as separator), which was _not_ possible before. 3. It prepares both the Drupal system and module developers for the upcoming locale_dateformat module. This module will fully localize date and time formats according to the localization of the current user. The locale_dateformat module will be available within the next weeks. I'm always happy about suggestions and criticism, if constructive. You can either write a comment on www.cvs.net or an email to pancho(a)suenderhauf.net. Bye, Pancho ------------- INSTALLATION: ------------- The package contains two patches for the latest CVS versions of Drupal 4.60 RC, both of which should be applied: 1. common.inc (patch for v.1.429) 2. system.module (patch for v.1.197) There are no changes in database structure. ------------------------------------------------------------------------ March 13, 2005 - 15:59 : pancho P.S. What the hell did I write about www.cvs.net? No, what I meant was of course www.drupal.org (here), where you can write a comment! ------------------------------------------------------------------------ March 13, 2005 - 16:08 : pancho I feel better if I refile the thread as a feature request. The only thing you could describe as a bug was that German & Hungarian date formats were not supported. The rest are definitely feature improvements. ------------------------------------------------------------------------ March 13, 2005 - 17:38 : Steven - Localizing date formats seems like something that should be solved properly in core once and tied into locale.module. We need a solution which does not pose problems with mixing languages, and which does not require us to keep adding more and more date formats to the list (e.g. what about asian date formats? They don't have spaces.) Your "if (!module_exist('locale_dateformat'))" solution is unacceptable for core. - What's the point of the 'tiny' date format if it's not used anywhere? Where would it be used? - Please don't post patches as zips, this is annoying. Just make one global patch file instead of separate ones. Multiple files can be posted with multiple follow ups. - You need to see how this affects the date usage around Drupal, e.g. the profile date field formatting, which depends on the date format being in a specific format. - Code style: check spaces around quotes. Also, avoid trailing spaces on lines, this is untidy. - This issue is not "critical" IMO. It is a new feature request, and as such should probably wait until after 4.6, as 4.6 is in feature freeze. - The apostrophes around the separator item seem a bit unnecessary.

1 0

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

14 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: javanaut Status: patch "Make a new user in the db called 'Cron' with a user id -1" Just on a technical note, the database type for uids is "unsigned" and -1 won't work. javanaut 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. ------------------------------------------------------------------------ March 13, 2005 - 13: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. ------------------------------------------------------------------------ March 13, 2005 - 13:37 : killes(a)www.drop.org I like the idea, some comments, though: +if (!$cron_is_running) { + session_start(); +} Is this neccessary? 'User ID '.$cron_uid.' does not exist' ------------------------------------------------------------------------ March 13, 2005 - 14:11 : killes(a)www.drop.org 'User ID '.$cron_uid.' does not exist' < == needs to be made translatable. Setting to active. ------------------------------------------------------------------------ March 13, 2005 - 23:56 : Chris Johnson Attachment: http://drupal.org/files/issues/cron_uid3.patch (3.29 KB) Ooops. Sorry I missed that text that needed translating. New patch attached with that bit corrected. Yes, I think the if (!$cron_is_running) code is needed to keep the cron user from creating many unneeded sessions. ------------------------------------------------------------------------ March 14, 2005 - 03:48 : stefan nagtegaal I am all for the idea of introducing a special id for running the cronjobs, but the approach you took here is far from perfect imo.. After looking at your patch, there are several questions and remarks that came up to my mind: I agree with Gerhard that the $cron_is_running is probably unneeded, I think it's better todo: <?php if (!variable_get('cron_busy', true)) { session_start(); } ?> I think that this is much to technical. Severa newbies will probable ask what a user id is, or what cron jobs are.. From both usability and userfriendlyness this patch is a big -1 from me.. I would suggest todo the following: - Make a new user in the db called 'Cron' with a user id -1, or something like that.. That way you don't have to add extra options to the administration, and the way of implementing should be much cleaner. Also does it improves usability... What do you think? ------------------------------------------------------------------------ March 14, 2005 - 07:11 : Anonymous Hi, The functionality is great, but your interface is not. IMO you should just choose good defaults and leave it with that. Why would users want to choose "UIDs" ofr "cron Jobs". Joe user should not have to think about UIDs and Crons. IT should Just Work[tm]. I know there are lots of places in Drupal where this is not the case either, but we are working on that. So when we introduce new functionality we should do it good at once. Why not go for Stefans suggestion of choosing a cron UID and jsut leave it like that. UIDs are not really used anyway, so you can choose just any UID (just the next one available, most often will be '2'). Bèr

1 0