March 2005 - Development - lists.drupal.org

[drupal-devel] [feature] Pass include and exclude parameters to cron.php for fine grained cron timing
by Chris Johnson 24 Mar '05

24 Mar '05

Issue status update for http://drupal.org/node/19173 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: robertDouglass Reported by: robertDouglass Updated by: Chris Johnson Status: patch It does seem like a good idea to allow running different cron tasks at different intervals, so as to be efficient and reduce web server loads. There is little point in running tasks that do not need to be run. Many cron tasks only need to be run once to a few times per day. Note also that cron job scheduling on most Unix-variants is only within a +/- 1 minute range, so trying to run a cron program every 2 minutes is approaching the crumbling edge of being "on time." Chris Johnson Previous comments: ------------------------------------------------------------------------ March 20, 2005 - 04:08 : robertDouglass Attachment: http://drupal.org/files/issues/cronpatch.txt (1.99 KB) Some sites need fine grained timing for cron runs. For example, a site that relies heavily on moblogging, mailhandler or any other email based function would want to connect with the email server pretty often, say ever 2-5 minutes. On another site I'm working on we generate flat files for all of a certain node type on a regular basis, though not every 2-5 minutes. Thus the need for cron tasks on different schedules. This patch allows you to make a list of modules to either include or exclude when running cron, so that several cron tasks for one site can be defined. The default behavior in the absence of both parameters is to run all, so the patch preserves backwards compatibility. * Examples: * * runs all hooks * http://mysite.com/cron.php * * runs all hooks except the search and aggregator modules * http://mysite.com/cron.php?exclude=search,aggregator * * runs only search, archive and aggregator modules * http://mysite.com/cron.php?includ=search,archive,aggregator ------------------------------------------------------------------------ March 23, 2005 - 15:23 : Dries Isn't it possible to run all cron functions every 2-5 minutes? The impact of that should be minimal. ------------------------------------------------------------------------ March 23, 2005 - 15:33 : moshe weitzman an alternative approach is to make a quick PHP page which simply calls mailhandler_cron and any others that need to be called more frequently than normal. then call that php page from cron every couple minutes ... not so sure this complexity is worth having. ------------------------------------------------------------------------ March 24, 2005 - 01:32 : robertDouglass Whether or not this "complexity" is needed depends a lot on what you expect to do with cron. As soon as one starts aggregating not tens but several hundred RSS feeds or more, it is impossible to run cron every 2 minutes. Yet if the site depends on mailhandler keeping user moblog submissions current, 2 minutes is already about the maximum latency time acceptable. Thus the need for crons on different schedules. In terms of usage, writing ?include=mailhandler,search,event isn't so complex. On the code level, splitting that list on comma and looping over the resultant array also isn't really that complex. The patch defaults to normal behavior for people who don't need the feature, and I've seen more than one site that had to solve this problem. ------------------------------------------------------------------------ March 24, 2005 - 04:48 : Robert Castelo Could different cron runs be set to run different tasks based on a cron ID number.... For instance, set up 3 separate cron to run every hour, each one calls the cron.php page including a number variable which runs a certain set of tasks. An Admin control panel would list all cron tasks and allow administrators to split them into separate cron runs based on the number variable passed to the script when calling cron.php. ------------------------------------------------------------------------ March 24, 2005 - 05:24 : robertDouglass Robert, the id parameter is already a practical necessity for this patch if cron_busy is to be effective. I'm open to suggestions as to how we would track various cron tasks and whether they are busy. First things first, though: does anyone except me need this? I'm not going to program an admin-configurable cron mechanism unless there is demand for it. Furthermore, such a system would really be incomplete unless there were some actual mechanism for setting these cron runs up from the admin interface as well. This wouldn't be such a bad idea, I know a lot of people who still type /cron.php into their browser every day or so to updated thier sites (yes I've mentioned poormanscron). Anyway, first reactions to this patch have been cold, so maybe nobody wants it. ------------------------------------------------------------------------ March 24, 2005 - 05:39 : Robert Castelo +1 from me. I'll be needing something like this once my email newsletter is released and starts hogging cron runs.

1 0

[drupal-devel] Serious hole in dba
by Karoly Negyesi 24 Mar '05

24 Mar '05

Please see http://drupal.org/node/19365 and update your dba.module

2 1

[drupal-devel] [bug] user_access returns invalid data
by javanaut 24 Mar '05

24 Mar '05

Project: Drupal Version: <none> Component: user.module Category: bug reports Priority: critical Assigned to: javanaut Reported by: javanaut Updated by: javanaut Status: patch Attachment: http://drupal.org/files/issues/user_access_bug.patch (473 bytes) The user_access function in user.module returns the results of the *strstr()* function, which returns a string, not a Boolean like the documentation suggests. This was screwing things up for me since flexinode relies on user_access for it's node_access('create'..) functionality. The attached patch uses strpos instead of strstr. It was created from a 4.5 codebase, but I noticed that the same issue is in HEAD as well. I'm using it on my dev site, and node_access('create'..) calls are now working properly and nothing I'm using seems to have any problems with it. javanaut -- View: http://drupal.org/node/16705 Edit: http://drupal.org/project/comments/add/16705

6 18

[drupal-devel] new module container
by Bèr Kessels 24 Mar '05

24 Mar '05

Hello fellow drupalleers ;) About requests for new modules: Very often I see quite nice feature reqests on drupal.org, but most of the time they should be implemented in a new module and not in the module they are assigned to. However, I see no way of placing them in a container, or so. The danger of having such a container is, that it will be flooded with silly feature reqests, and already we do not have the manpower to keep up with these requests. I was thinking . of adding a simple project, with no files released, called "New modules". That would act as a container for requests for new modules. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]

3 3

[drupal-devel] Image module's coming out
by James Walker 24 Mar '05

24 Mar '05

This new image.module that everybody keeps mentioning (you know - the one that people blame that "walkah" guy for?) is no longer in my sanbox. I've just moved it it's "proper" home at modules/image and changed the uid for the project node. So, besides now having just shy of 200 issues with my name on 'em - we also have a place to track bugs/patches and feature requests that is not reliant on my inbox. That's a good thing (tm). So, please everyone - hammer away! I'll be watching the issue queue closely (looking particularly for patches ;) . Also, if you're one of the people who has emailed me a patch and either haven't heard from me (I hope there aren't many of those) or don't see it included - *please* file an issue and we'll track it from there. Just a quick thanks to everyone that's helped test, offered feature requests, etc.. keep it coming! -- James Walker :: http://www.walkah.net/

2 1

[drupal-devel] [feature] Pass include and exclude parameters to cron.php for fine grained cron timing
by Robert Castelo 24 Mar '05

24 Mar '05

Issue status update for http://drupal.org/node/19173 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: robertDouglass Reported by: robertDouglass Updated by: Robert Castelo Status: patch +1 from me. I'll be needing something like this once my email newsletter is released and starts hogging cron runs. Robert Castelo Previous comments: ------------------------------------------------------------------------ March 20, 2005 - 11:08 : robertDouglass Attachment: http://drupal.org/files/issues/cronpatch.txt (1.99 KB) Some sites need fine grained timing for cron runs. For example, a site that relies heavily on moblogging, mailhandler or any other email based function would want to connect with the email server pretty often, say ever 2-5 minutes. On another site I'm working on we generate flat files for all of a certain node type on a regular basis, though not every 2-5 minutes. Thus the need for cron tasks on different schedules. This patch allows you to make a list of modules to either include or exclude when running cron, so that several cron tasks for one site can be defined. The default behavior in the absence of both parameters is to run all, so the patch preserves backwards compatibility. * Examples: * * runs all hooks * http://mysite.com/cron.php * * runs all hooks except the search and aggregator modules * http://mysite.com/cron.php?exclude=search,aggregator * * runs only search, archive and aggregator modules * http://mysite.com/cron.php?includ=search,archive,aggregator ------------------------------------------------------------------------ March 23, 2005 - 22:23 : Dries Isn't it possible to run all cron functions every 2-5 minutes? The impact of that should be minimal. ------------------------------------------------------------------------ March 23, 2005 - 22:33 : moshe weitzman an alternative approach is to make a quick PHP page which simply calls mailhandler_cron and any others that need to be called more frequently than normal. then call that php page from cron every couple minutes ... not so sure this complexity is worth having. ------------------------------------------------------------------------ March 24, 2005 - 08:32 : robertDouglass Whether or not this "complexity" is needed depends a lot on what you expect to do with cron. As soon as one starts aggregating not tens but several hundred RSS feeds or more, it is impossible to run cron every 2 minutes. Yet if the site depends on mailhandler keeping user moblog submissions current, 2 minutes is already about the maximum latency time acceptable. Thus the need for crons on different schedules. In terms of usage, writing ?include=mailhandler,search,event isn't so complex. On the code level, splitting that list on comma and looping over the resultant array also isn't really that complex. The patch defaults to normal behavior for people who don't need the feature, and I've seen more than one site that had to solve this problem. ------------------------------------------------------------------------ March 24, 2005 - 11:48 : Robert Castelo Could different cron runs be set to run different tasks based on a cron ID number.... For instance, set up 3 separate cron to run every hour, each one calls the cron.php page including a number variable which runs a certain set of tasks. An Admin control panel would list all cron tasks and allow administrators to split them into separate cron runs based on the number variable passed to the script when calling cron.php. ------------------------------------------------------------------------ March 24, 2005 - 12:24 : robertDouglass Robert, the id parameter is already a practical necessity for this patch if cron_busy is to be effective. I'm open to suggestions as to how we would track various cron tasks and whether they are busy. First things first, though: does anyone except me need this? I'm not going to program an admin-configurable cron mechanism unless there is demand for it. Furthermore, such a system would really be incomplete unless there were some actual mechanism for setting these cron runs up from the admin interface as well. This wouldn't be such a bad idea, I know a lot of people who still type /cron.php into their browser every day or so to updated thier sites (yes I've mentioned poormanscron). Anyway, first reactions to this patch have been cold, so maybe nobody wants it.

1 0

[drupal-devel] [feature] Pass include and exclude parameters to cron.php for fine grained cron timing
by robertDouglass 24 Mar '05

24 Mar '05

Issue status update for http://drupal.org/node/19173 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: robertDouglass Reported by: robertDouglass Updated by: robertDouglass Status: patch Robert, the id parameter is already a practical necessity for this patch if cron_busy is to be effective. I'm open to suggestions as to how we would track various cron tasks and whether they are busy. First things first, though: does anyone except me need this? I'm not going to program an admin-configurable cron mechanism unless there is demand for it. Furthermore, such a system would really be incomplete unless there were some actual mechanism for setting these cron runs up from the admin interface as well. This wouldn't be such a bad idea, I know a lot of people who still type /cron.php into their browser every day or so to updated thier sites (yes I've mentioned poormanscron). Anyway, first reactions to this patch have been cold, so maybe nobody wants it. robertDouglass Previous comments: ------------------------------------------------------------------------ March 20, 2005 - 11:08 : robertDouglass Attachment: http://drupal.org/files/issues/cronpatch.txt (1.99 KB) Some sites need fine grained timing for cron runs. For example, a site that relies heavily on moblogging, mailhandler or any other email based function would want to connect with the email server pretty often, say ever 2-5 minutes. On another site I'm working on we generate flat files for all of a certain node type on a regular basis, though not every 2-5 minutes. Thus the need for cron tasks on different schedules. This patch allows you to make a list of modules to either include or exclude when running cron, so that several cron tasks for one site can be defined. The default behavior in the absence of both parameters is to run all, so the patch preserves backwards compatibility. * Examples: * * runs all hooks * http://mysite.com/cron.php * * runs all hooks except the search and aggregator modules * http://mysite.com/cron.php?exclude=search,aggregator * * runs only search, archive and aggregator modules * http://mysite.com/cron.php?includ=search,archive,aggregator ------------------------------------------------------------------------ March 23, 2005 - 22:23 : Dries Isn't it possible to run all cron functions every 2-5 minutes? The impact of that should be minimal. ------------------------------------------------------------------------ March 23, 2005 - 22:33 : moshe weitzman an alternative approach is to make a quick PHP page which simply calls mailhandler_cron and any others that need to be called more frequently than normal. then call that php page from cron every couple minutes ... not so sure this complexity is worth having. ------------------------------------------------------------------------ March 24, 2005 - 08:32 : robertDouglass Whether or not this "complexity" is needed depends a lot on what you expect to do with cron. As soon as one starts aggregating not tens but several hundred RSS feeds or more, it is impossible to run cron every 2 minutes. Yet if the site depends on mailhandler keeping user moblog submissions current, 2 minutes is already about the maximum latency time acceptable. Thus the need for crons on different schedules. In terms of usage, writing ?include=mailhandler,search,event isn't so complex. On the code level, splitting that list on comma and looping over the resultant array also isn't really that complex. The patch defaults to normal behavior for people who don't need the feature, and I've seen more than one site that had to solve this problem. ------------------------------------------------------------------------ March 24, 2005 - 11:48 : Robert Castelo Could different cron runs be set to run different tasks based on a cron ID number.... For instance, set up 3 separate cron to run every hour, each one calls the cron.php page including a number variable which runs a certain set of tasks. An Admin control panel would list all cron tasks and allow administrators to split them into separate cron runs based on the number variable passed to the script when calling cron.php.

1 0

[drupal-devel] project dropdown order
by Bèr Kessels 24 Mar '05

24 Mar '05

I am sure you all have encoutered the problem where you want to add a bug to a project, and have to hunt trough a dropdown with hundreds of unsorted projects ;) I made a very simple patch [1] for this, bout cannot test it ;) Anyone? [1] http://drupal.org/node/19371 Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]

1 0

[drupal-devel] RE: drupal-devel Digest, Vol 27, Issue 135
by Aldon Hynes 24 Mar '05

24 Mar '05

Well, if you check how Google approaches it, the use double quotes to indicate a phrase with a blank in it. e.g. http://www.google.com/search?q=%22horse+riding%22 Aldon -----Original Message----- > Still fails the "horse riding" test.

2 1

[drupal-devel] [feature] Pass include and exclude parameters to cron.php for fine grained cron timing
by Robert Castelo 24 Mar '05

24 Mar '05

Issue status update for http://drupal.org/node/19173 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: robertDouglass Reported by: robertDouglass Updated by: Robert Castelo Status: patch Could different cron runs be set to run different tasks based on a cron ID number.... For instance, set up 3 separate cron to run every hour, each one calls the cron.php page including a number variable which runs a certain set of tasks. An Admin control panel would list all cron tasks and allow administrators to split them into separate cron runs based on the number variable passed to the script when calling cron.php. Robert Castelo Previous comments: ------------------------------------------------------------------------ March 20, 2005 - 11:08 : robertDouglass Attachment: http://drupal.org/files/issues/cronpatch.txt (1.99 KB) Some sites need fine grained timing for cron runs. For example, a site that relies heavily on moblogging, mailhandler or any other email based function would want to connect with the email server pretty often, say ever 2-5 minutes. On another site I'm working on we generate flat files for all of a certain node type on a regular basis, though not every 2-5 minutes. Thus the need for cron tasks on different schedules. This patch allows you to make a list of modules to either include or exclude when running cron, so that several cron tasks for one site can be defined. The default behavior in the absence of both parameters is to run all, so the patch preserves backwards compatibility. * Examples: * * runs all hooks * http://mysite.com/cron.php * * runs all hooks except the search and aggregator modules * http://mysite.com/cron.php?exclude=search,aggregator * * runs only search, archive and aggregator modules * http://mysite.com/cron.php?includ=search,archive,aggregator ------------------------------------------------------------------------ March 23, 2005 - 22:23 : Dries Isn't it possible to run all cron functions every 2-5 minutes? The impact of that should be minimal. ------------------------------------------------------------------------ March 23, 2005 - 22:33 : moshe weitzman an alternative approach is to make a quick PHP page which simply calls mailhandler_cron and any others that need to be called more frequently than normal. then call that php page from cron every couple minutes ... not so sure this complexity is worth having. ------------------------------------------------------------------------ March 24, 2005 - 08:32 : robertDouglass Whether or not this "complexity" is needed depends a lot on what you expect to do with cron. As soon as one starts aggregating not tens but several hundred RSS feeds or more, it is impossible to run cron every 2 minutes. Yet if the site depends on mailhandler keeping user moblog submissions current, 2 minutes is already about the maximum latency time acceptable. Thus the need for crons on different schedules. In terms of usage, writing ?include=mailhandler,search,event isn't so complex. On the code level, splitting that list on comma and looping over the resultant array also isn't really that complex. The patch defaults to normal behavior for people who don't need the feature, and I've seen more than one site that had to solve this problem.

1 0