Improve Usability of the Cron information in the Status Report

Nice! Here is a screenshot of what the warning and error look like.

A couple code style things:
- Should be spaces in between *
- 2nd comment needs a space after //

After that this is RTBC IMO. +1 webernet!

Also, not sure if it generates a notice or not, but regardless I think

  $requirements['cron']['value'] = $t('Last run !time ago', array('!time' => format_interval(time() - $cron_last)));

should be

  $requirements['cron'] = array('value' => $t('Last run !time ago', array('!time' => format_interval(time() - $cron_last))));

so it is properly initialized. Just minor stuff.

+1 to this patch. Nice idea :)

Going to move this to D6.

I don't think this behavior is correct. Not running cron is not necessarily an error.

99% of sites do use watchdog so why hold back the patch for 1%. even more true now that we omitted the error after 7 days.

I think it is an error, not to run cron. Most sites would use something, which needs cron to run. Ie. watchdog, stats module (required by throttle) and so on. Even system module itself does cleanup on cron: cleans up the flood table, the batch table, removes old temporary files. I think it pretty much an error, if cron is not run regularly. Let's discuss this!

I agree that it's an error, and would go one step further of re-displaying the error if cron hasn't run within some specified time-frame, say a week.

Lullabot has been asked to save Drupal sites before from crippling performance problems. More often than you'd think, one of the biggest problems is that their watchdog table has 29 billion records from cron only having been run once, a year and a half ago. Truncate that table and suddenly the site gets a lot more zippy.

OMG. RTFI. Sorry. :(

Doesn't the update module use cron to perform its checks? And isn't update enabled by default? If so, by not running cron, you are disabling a core default-enabled module, perhaps inadvertently, and you'll never be notified of security updates. I'd call that an error-worthy condition.

This patch also has the opportunity to fix another user-friendliness pet peeve of mine: On a fresh install, the first thing the new admin-user does is visit Administer, and the first thing they see is an error message ("On or more problems have been detected with your Drupal installation.")! It turns out the error is that cron has never run. Of course it hasn't, the site was just created 30 seconds ago. Presenting an error message so early in the game does not make a good first impression.

This patch can solve that problem simply by declaring that "cron never run" is no longer an error. After two days (or however long we decide), it can become an error if they haven't gotten to it yet.

So, +1 from me. Since I think this is a pretty serious UI/useability improvement, I'd vote for it going into D6. I have not yet reviewed the patch, though.

patch doesn't suppress the error message for me on a fresh install.

+1 though. It's no fun getting that warning just after you install the site, and good to have it refresh the error if cron stops running (say on moving a site to a different server and forgetting to set up a new cron job).

Running cron during install solves my pet peeve of not reporting an error immediately upon installation but is somewhat misleading: it may make the user wonder who invoked cron.php when in fact no one did. Also, a one-time message during installation "please see the docs re: cron" is likely to be missed.

A new version of the patch is attached. It's behavior:

  // Report cron status.
  //
  // The general idea is that cron not having run recently is okay
  // until cron_threshold_warning, a warning until
  // cron_threshold_error, and an error after that.  For a newly
  // installed system where cron has not run, system install time is
  // used as the start time from which to measure the thresholds.
  //
  // Also, if cron has never run, a friendly reminder is displayed on
  // the Administer page until it becomes an error condition.
  // Previously, new users saw a "cron never run" error condition
  // immediately upon installation

If Dries questions whether this 'cron not run becomes an error' behavior is correct at all, however, I doubt this is getting to D6. I think it is fairly important, though.

I think this is pretty important functionality as it helps administrators a lot with fixing a condition which could lead in their databases grow very big, their search indexes getting outdated, some of their mails not being sent, etc.

I only looked through the code and noticed these:

- "Administer page" should not be capitalized IMHO... we also say "administration page" or something along those lines (ie. don't use the verb)
- there is a code style error on the last line added

Otherwise it would indeed be great to know what Dries thinks about this now.

@#19: "Administer page" and code style error corrected.

I tested this with an existing install and a new install. worked as advertised. this is a significant usability bump. code looks clean as well.

- I wouldn't classify this a "significant usability bump". It's only a small improvement for me.

- The PHP doc comments are hard to understand, especially the one in the first blob of the patch. I can't make sense of it.

- Code like this is simply not needed, IMO: + $description .= ' '. $t('This will become an error condition in !time.', array('!time' => format_interval($cron_last + $threshold_error - time())));. It's too verbose. I think the patch can be simplified a bit.

Dries, the big glaring red error message shown because cron is not run yet is also mentioned by Chris Messina's review (http://factoryjoe.pbwiki.com/FeedbackForDrupal6) you pointed us to. This patch solves that problem, so one item to tick off of Chris' list.

Anyone interested in moving this forward to get this into Drupal 6? We are pretty short on time now.

OK, tested the patch, and it works nicely. Also reviewed the code, and all looks fine, IMHO the code flow is easy to understand. Thanks, committed.

Having a green box at the top of the admin screen is a much better improvement than having a big red box, however, the ability to easily get rid of that green box has been removed causing a new usability annoyance.

This patch presents the following text & option to run cron manually directly from the status message in additional to the drupal.org help page.

Cron has not run. Please check the help pages for configuring cron jobs or you can run cron manually.

This is the current text on the /admin page.

Cron has not run. Please check the help pages for configuring cron jobs.

Note no quick and easy option to get rid of this message.

This is the current text on the admin/reports/status page.

Cron has not run. Please check the help pages for configuring cron jobs. You can run cron manually.

The sentence structure is choppy, and combined to be consistent in both places.

Bumping this to critical to sneak in before the usability freeze.
Feel free to downgrade otherwise.

Well, I don't think this is critical. I see a problem with advocating running cron by hand. It is not in an 'or' relationship with setting it up properly, so it should not be presented as such. I am also not sure we need this full information on the admin page. The goal of the note is to get people set up cron, not to get over it with a click. IMHO this is back to fixed.

Gabor,
I want to make a few more points.
Please re-consider re-activating it for more feedback if you find merit.

Consider what Chris Messina had to say about this:

The second problem was the creation of cron scripts. This is where Drupal's heritage started to show. First, cron is a word that developers know but that probably means nothing for normal humans.

Do we really want to direct brand new users who've never heard of a cron job to this overwhelming help page within the first 15 minutes of their Drupal experience? Try going to this page and actually reading it from start to finish through the eyes of one of these "normal humans" Messina speaks of.

"The goal of the note is to get people set up cron, not to get over it with a click."

Correct me if I'm wrong, but isn't this /admin cron status message going to show up every two days if they do opt to run it by hand?

// Cron warning threshold defaults to two days.
$threshold_warning = variable_get('cron_threshold_warning', 172800);

So it's not fair to say that they'd be getting over it with just one click -- they would soon realize after a week that they have to manually run it every other day, or to invest the time to set it up properly. IMHO, that's an option I'd like to leave up to these normal human users. Otherwise these types of users will have to see that cron status message on the top of their admin page forever possibly without ever figuring out an easy way for them to do something about it.

My understanding was that "admin/reports/status/run-cron" exists for those who either can't automate it for some hosting reason, don't have the technical expertise to properly set it up or want more frequent cron job updates.

So I don't think it's advocating running cron by hand to because the status message will reappear every couple of days.

If the goal is to improve the initial first impression, then give the user a quick workaround for running cron jobs and let them focus on getting started with exploring the power of Drupal. If they're still around in a couple of days, then they'll be more motivated to sift through this help page that'll be prominently linked at the top of their admin page.

First of all, if the help page is overwhelming, it is a documentation issue, it is not solved by looking in a different direction.

If the goal is to improve the initial first impression, then give the user a quick workaround for running cron jobs and let them focus on getting started with exploring the power of Drupal. If they're still around in a couple of days, then they'll be more motivated to sift through this help page that'll be prominently linked at the top of their admin page.

Why not run cron in the install process then automatically at the finished stage (ie. after update status is enabled so the update information can be collected also)? This clicking is completely pointless, if we talk about first impressions of brand new users.

I see value in this follow-up patch, but Gabor's last comment makes sense to. Because we're short on time, I decided to commit this patch and to recategorize this as 'code needs work' in Drupal 7.

So, patch committed to Drupal 6. Thanks.

Might be too late, but it seems I got credited for this patch, when it should've been KentBye.

That last patch looks good to me. Committed tot CVS HEAD. Thanks.

Just checked out the changes, and it's much better that it now links to the /admin/reports/status page from that initial message of "Cron has not run. Please visit the status report for more information."
I think that's a lot more friendly than linking to the handbook page.
Thanks for getting this change in everyone.