[wp-trac] [WordPress Trac] #39591: Introduce wp_doing_cron()

[WordPress Trac]

#39591: Introduce wp_doing_cron()
-------------------------+------------------
 Reporter:  tfrommen     |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  4.8
Component:  Cron API     |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:
-------------------------+------------------

Comment (by rmccue):

 Replying to [comment:7 tfrommen]:
 > Also, since the constant is not defined in all situations (in fact, in
 WordPress core, it is only defined when doing a CRON task), noone can
 simply ''check the constant''. They'd have to check `defined( 'DOING_CRON'
 ) && DOING_CRON`, which is '''not''' only looking up a constant.

 My point was that the `defined` check doesn't really cost anything, apart
 from the mental overhead of writing it. :) (Specifically, it's 3 PHP
 opcodes for `defined('X') && X, which is basically an instant lookup.)

 > To make that clear, I am not saying, nor assuming, to really boost
 anyone's WordPress site by these micro-optimizations. That's just nonsene.
 However, caching that kind of data clearly isn't a bad thing at all.

 I'm more just saying that you're not saving anything by storing in a
 variable. The performance is never really going to matter. Saving in a
 variable ''does'' increase the indirection though. Compare:

 {{{
 $foo = a();
 $bar = b();
 $baz = c();
 echo $foo . $bar . $baz;
 }}}

 vs

 {{{
 echo a() . b() . c();
 }}}

 It's more that there's no real ''need'' for a variable. If I'm reading the
 code, I now potentially need to read the variable declaration rather than
 just seeing it inline with the rest of the code. The clarity from the
 direct use can be better, and the performance difference is negligible, so
 might as well go with the clearer option. :)

 (I don't really care, but there are downsides to unneeded caching. It's
 not fair to say it's always a good thing. :))

 > Currently, the only thing one can do is to check the constant. If the
 ''storage'' of the CRON status definition ever were to change (I know, I
 know: won't happen; but still), all of the code directly working with the
 constant would have to be adapted.

 It's possible already to do basically whatever you want with cron
 replacements, so I'm not sure I see that argument.

 ---

 The main argument against this is that it's essentially a "mode" of
 WordPress, and therefore shouldn't be able to change during a request. It
 usually doesn't really make sense to be in cron mode, then not be in cron
 mode.

 ''However'', unit tests do occasionally want to do things like this, so
 having it filterable is very handy for that. This was one of the key
 points on #25669 (`wp_doing_ajax()`).

 One other thing I forgot to note: `cron` should always be lowercase. It's
 an abbreviation of "chronological", not an acronym. Apart from that (and
 potentially the variable), patch looks good to me.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/39591#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform