Ability to run cron manually

Sounds like a neat addition to Drupal Core; it would help me with testing on my desktop in WAMP as I can't setup cron easily (windows box etc).

+1 in principle. my only concern is that once you click on the "manually" link, you go directly to cron.php (the intention) which returns no data (by design) and all you see is a blank page with no indication that anything happened. not sure if the solution is to just explain this in the text with some additional instructions about what to expect, or to change cron.php to at least print out some basic output (maybe if there's a ?verbose=true argument or something) and then this link would be changed to use that, too.

however, i think 1 of these 2 changes should happen before this goes in, which is why i'm setting this to "needs work". also, i'm attaching a new patch that removes an unnecessary newline, and that is build from drupal root (the top-level "drupal" directory, not from inside modules/system) since that's the recommended way to roll patches against core. ;) so, my patch isn't ready, either, it's just here to help forngren see what i'm talking about...

overall, thanks for the patch, i think this will be a good improvement. it's certainly something i do manually a lot on my test sites already, so having a link on that page will be handy. which reminds me, maybe we should put a similar link in the devel.module's main devel block. ;)

to clarify: cron.php had better *not* return any data by default, or it'll screw up the usual case. that's why i'm proposing an optional arg to specify you're running it manually and want some kind of output.

upon further consideration, killes, fireangel and myself think providing this link directly is a bad idea. a properly secured site won't allow cron.php to be run from an external client, for example. it'd be better to provide a button that causes the drupal site to internally invoke cron.php via drupal_http_request() (see http://api.drupal.org/api/head/function/drupal_http_request for more on that). this would probably also solve the problem of displaying the blank page, since the form with this button could just redirect you back to the admin page once cron.php is done.

good luck! ;)
-derek

"why not?" b/c if any of that code from cron.php changes, someone has to remember to fix the copy in here, too. cut + paste coding is *never* a good idea. ;)

now's as good a time as any to learn the right way to do this. just read the link i posted before about drupal_http_request(). that's how i learned drupal's code. i started fixing stuff i wanted fixed, and people showed me better ways to solve things.

also, i don't think the menu description needs to mention manually running cron. most of your help text changes are good, but i think you went 10% too far. ;)

keep up the good work, and i'm sure this can make it in before the 4.8 code freeze...

Just tested and ran it; seems to be working well. +1 for the concept, haven't had time to review the code thoroughly.

latest patch does not use drupal_http_request. This would break manual cron runs if you protect cron.oho with a file directive in your htaccess which limits access to a handfull of IPs.

Sorry, not yet fully awake, you don't need to start a separate request if you simply call the function.

doesn't apply cleanly any more. :( the help text changes are now rejected from system.module (due to recent changes -- HEAD is a fast-moving target)... forngren, please re-roll with the latest HEAD, and i'll review and RTBC it. ;)

thanks,
-derek

1 minor change to forngren's latest patch. if you click on the "manually" link from admin/settings/cron-status, you go to (and stay on) admin/settings/cron-status/cron. this seems counter-intuitive. it tells you that the last cron job ran 0 seconds ago. when you reload the page, it keeps telling you it was only 0 seconds ago, since it keeps re-running cron. ;) i'd rather you were sent back to admin/settings/cron-status once admin/settings/cron-status/cron is done. i added a single drupal_goto() and now i think it makes much more sense and works as folks would anticipate.

also, i changed the wording of "Cron ran unsuccessfully" to "Cron run failed" to be a little more visually obvious.

setting to needs review (so forngren and killes can comment on my goto), but i think this patch is RTBC.

thanks for getting this done, forngren! ;)
-derek

Coding style needs work: incorrect spacing and indentation.

(Wouldn't it be nicer if we'd reuse the scrollbar widget for this? At least, you'd be able to see progress.)

re: scrollbar -- that'd be a lot more code (i've seen how it works in update.php, and it's not trivial) for a relatively minor UI enhancement. if we go that route, we shouldn't put all that crap in common.inc, and instead create a cron.inc that's only conditionally included. also, we'd have to be careful *not* to output anything when invoked via cron.php (the usual case). manually running cron seems rare enough as it is, i'm not sure it's worth the trouble/bloat to add this functionality. but, if you're into it, i'm sure forngren will be happy to roll a new, even bigger patch. ;)

p.s. sorry i missed the coding style -- i'm usually pretty good about that. ;)

ahh, i found some other indentation problems in system_cron_status() and a stray space at the end of a comment somewhere else. also, i changed the comment in cron.php back to what it was, since i think the original text was more clear than your version.

dries, if you're talking about the indentation for the <ul> list in the help page, sadly, there seems to be no consistent convention. node.module's help block does it exactly like how it is in this patch. menu.module does it differently (that could be my fault, in fact). ;) a quick sample of other core modules shows that most of them do it this way, and menu.module is the outcast...

Committed to CVS HEAD.